Instructor: Jing Gong

Weekly Question #2 (Due Friday, September 11)

Leave your response as a comment on this post by the beginning of class on September 11, 2015. Remember, it only needs to be three or four sentences. For these weekly questions, I’m mainly interested in your opinions, not so much particular “facts” from the class!

If you sign in using your AccessNet ID and password you won’t have to fill in the name, email and captcha fields when you leave your comment.

Answer one of the two questions below (not both):

  1. What do you think is the trickiest thing about creating an ERD from a problem description? What advice would you give to deal with that issue?
  2. Give an example of how choosing the wrong cardinality (1-to-many, many-to-many) could cause problems when the database is implemented and used.

69 Responses to Weekly Question #2 (Due Friday, September 11)

  • The trickiest part of creating an ERD from a problem description is defining what information is important and what isn’t. Put another way, when you create an ERD for a problem you may be forced to make a set of limiting assumptions that could totally change the functionality of a data model. It is important that a data model address the most basic parts of a problem, and that the assumptions that you make allow for the problem to be solved easily. For example, a limiting assumption might be “A student can only register for classes at one school,” thats a reasonable assumption to make, but it precludes a Student entity from being associated (through registration with classes) with another school. However, the basic problem of registering for classes is solved. The important thing to do in this case is to make sure that the set of limiting assumptions that you are making still provide a functional data model.

  • I look forward to creating and updating a database the most because I do not know much about the topic. My future career is gonna involve organizing data and keeping it up to date to ensure we are keeping a competitive edge so this knowledge is essential. However, I believe that data visualization will be the most useful for me in the future. Data visualization is important to my future because I am going to need to present data to my colleagues in a clear fashion.

  • I think the trickiest part of ERD is the cardinality. I have trouble remembering which symbols to use for each situation. I have gotten better watching the class examples then practicing on my own. My advice for improving ERD skills would be re doing the slideshow examples at home

  • I say the trickiest thing for creating an ERD is finding what attributes correspond to any entity. While this is easy for some attributes such as first name, last name, and date of birth for a customer because they are an entity in itself. I find it difficult when an attribute can belong to two entities which happens in an ERD. For example, when we were doing the examples on Monday regarding House developments and people living in one of those developments. My partner and I got heavily confused on what was was. However, If I were to give a tip on how to figure out what attributes correspond to would be to identify certain key-words like corporation, department, and things that separate other entities from the rest.

  • Assigning the wrong cardinality in an ERD could cause major problems when a database is implemented as used in many different ways. One example I can think of off the top of my head is the cardinality relationship between customers and orders. Let’s say that the company that we are dealing with is a cell phone company that gives out “free” phones to low-income college students. Because their “free” phones are actually subsidized by TU, it is important that each student only be able to receive one free phone. If a database designer assigned a cardinality of anything other than “at least one and at most one” it would be possible for a customer to theoretically get two free phones. If this mistake wasn’t found immediately, it would take a lot of effort to reverse the adverse effects of the cardinality mistake.

  • I would say the trickiest thing about creating an ERD is finding which attributes do not belong to an entity and rather to a relationship as well as finding the cardinality for the corresponding entitys. It is often very simple to identify the easy attributes such as names, product description, the id numbers for an enity, date ordered, etc. because they are identified by the entity itself. However in many problem descriptions, there are attributes that can be relatable to the relationship because they relate to two entities. For example in the housing problem description, moving in and out was related to the relationship between the unit and household, because a household could move in and out of a unit which results in a household living in many units. In order to make this process easier, I often list all the options and talk out the possible scenarios and apply them to problem description. As a result, you can figure out if the cardinality needs at least one or at most one and if all the attributes actually correlate to one or many entities resulting in it being related to the relationship.

    • Creating an ERD is not so difficult the difficulty stems from deciding on the correct elements and attributes. Elements can act in different ways and sometimes if an attribute could act as an element then thats a relationship. Organization is key and making sure everything is in place like the different elements and attributes is important because you do not want recurrences in databases.

  • I think one of the trickiest things about ERD is trying to distinguish what are the many different types of attributes inside of every function. Dissecting a paragraph can get confusing because I am more focused on reading the material instead actually picking out Entities, Attributes, and more. By the time I complete a couple more of these I feel as though this could become second nature in completing these type of assignments. But for now this would be the trickiest thing for me as of right now!

  • At this stage in the game, I would say the most difficult thing in establishing an ERD would be clearly identifying cardinality. Understanding entities and attributes was relatively straight-forward, but ‘optional’ vs. ‘mandatory’ relationships could potentially vary between points of view. My advice on dealing with ambiguities concerning relationships would simply be to ensure thorough understanding of the linkage and testing scenarios, depending on complexity of the ER diagram. More simply, at this level just studying the structure and playing out the definitions in one’s mind should reveal any discrepancies in the logic. Additionally, being mindful of establishing each entities primary key is integral for data mining purposes, as it uniquely identifies the entity in question and can save time in, say, research to fine-tune future business planning.

    As for an example of utilizing an erroneously chosen cardinality definition, I am reminded of the scenario #1 from class. If, say, the programmer chose a ‘1-to-many’ definition between the ‘part’ and ‘order’ entities the system may conclude that the order demands a minimum of one part every time the end-user logs on and scans the catalog of the distributor. Such a fault would resort in mistaken charges and inventory decreases, which would have to be returned and would serve to create, at the very least, discord between the distributor and customer. Potentially, it is a simply fix, but it suggests lack of attention to detail and may be interpreted as poor performance on behalf of the customer. As a worst case scenario, the distributor could lose business and, hence, value if such a mistake were applied to enough accounts without being mitigated quickly enough.

  • The trickiest thing about creating an ERD from a problem description is distinguishing the entities and their relationships with each other as well as figuring out the cardinality. The in class exercise that we did on Monday was very confusing to me and my partner. We had a hard time because there were so many possible entities and it was hard to tell which of those entities are relevant to the problem. A tip that would help with that is finding out what the problem is asking first. Usually, the main entities that are in the diagram are already within the one or two sentences that describes what the situation is demanding.

  • The trickiest thing about creating an ERD from a problem description is figuring which attributes belong to which entities. I find this tricky because it is not always clear where an attribute is supposed to go and this can throw off the rest of the process of creating the ERD. Some advice I would give for fixing this problem would be to watch our for key words that would indicate that something is an attribute for an entity. For example, a car is”described by” a VIN number. I advise looking for words that would suggest that something is described by something else to tell if it is an attribute or not.

  • I find the trickiest thing about creating an ERD is listing the entities and figuring out which entity is relevant to the question. For example, in the first question of the class exercise, I was overwhelmed with how many entities there was in the question that I got confused. I found a way that would help solve this situation if it would arise again. Whenever trying to solve an ERD program, read the question first. Before going on to list out the entities, list out the entities IN the question itself. That way, after listing out the entities in the entire problem, you can match the entities you listed from the problem with the entities you listed from the question and that should help you figure out which is needed for the problem.

  • I think it is most difficult to determine the cardinality between entities of an ERD from a problem description. To properly label the cardinality of an ERD, I would suggest working through each relationship, one-by-one, rather than examine the cardinalities of all of the relationships in the ERD at once. It’s easy to overlook relationships that are less than obvious when you are trying to solve the problem using the entire ERD structure. Isolating each relationship and determining how each entity relates to the other prevents oversight.

  • 1. I personally find the entire process of creating an ERD diagram to be confusing but I think the most challenging part is identifying which entities in the problem are relevant as well as figuring out the relationships between the entities. I think a tip for helping with this would be to make sure you understand what the problem is asking of you and then to create a table like we did in class. The table really helps put the diagram together and distinguish what is relevant and what is not.

  • For me the trickiest part of an ERD is picking out the most relevant nouns to identify as the entities. For example my partner and I had trouble because we thought the purchasing department could be an entity when really department was an attribute of the order. My advice would be to not overthink when deciding what the entities are. After receiving the key I realized that it was easy to match the attributes to the entities, but I was overthinking what the entities should be.

  • Like most people mentioned in their responses, the trickiest part of an ERD diagram is distinguishing entities and attributes. The in-class activity we did on entities was a little overwhelming. My partner and I both thought that truck, van, etc. were entities. There was a bunch of information given in the activity so it made it confusing to dissect which is the entity and the cardinality corresponding with it. I recommend underlining the entities and circling the attributes, this helped me because it gave me a better sense on what attributes connected with which entities.

  • One of the trickiest things about the creation of an ERD model is the way that you perceive the entity, attribute and the relationship between them. To identify what is of importance can be a challenge in its self; meaning that if the entity is a product then a primary key is going to be the product id number. Initially I wanted to identify the customers first and last names as a primary key because the customer is putting in the order for the product.
    In this case we are looking at the product as being of importance in the transaction so with this being truth, we are identifying the product id number as the primary key. I would suggest not to think too deeply into the identifying of each aspect.
    Best GJR

  • I think one of the trickiest things about an ERD model is choosing the right cardinality along with accurately choosing the entities and attributes. Cardinality is essentially one big puzzle that allows us to “view” the flow of the ERD diagram. Its very valuable but its also very easy to confuse. To master ERD diagrams as well as cardinality, I would recommend that you don’t over complicate things, and simply just ask yourself the rhetoric questions that help with cardinality.

  • I would say that the trickiest part of making an ERD from the problem description is definitely figuring out which is an Entity, Attribute and their relationship. Initially, it was difficult for me to read through the problem and sort it out into a table. However, I realized to not over think it and to solve it by figuring first which are the entities, and then which attributes each entity will have.

  • When using ERD modeling, I think it is most difficult to recognize when an an attribute relates to a relationship versus an entity. During class examples, my first reaction is always to connect attributes to entities and later find that they are attributes of a relationship instead. It can also be difficult to choose a relationship name that efficiently describes how to entities relate to each other.

  • I’ve found that the most difficult thing about creating ERD diagrams is identifying entities. The way that some of the problems describe irrelevant details about attributes makes it seem like they are entities.

    Choosing the correct cardinality is important because it opens up the database for additional information or restricts it to certain fields. Choosing the wrong cardinality can cause attributes to left out of entities or spread over too many entities.

  • The trickiest part of using a ERD is figuring out which cardinality to use between two entities. It can get confusing picking one, zero or multiple to ink the entities together. The relationship between the entity and attributes are pretty simple to pick out. Advice I would give to figure out the cardinality is to think logically and don’t over think the relationships. Once you over think it, every type of relationship will be in your head and you will be flustered.

  • I believe the hardest part of creating an ERD diagram is correctly distinguishing entities and relationships from other possibilities in the scenario because there are so many options the task can become overwhelming. Carefully analyzing the document and organizing your possible responses seems to be the best way to help you logically solve through the problem.

  • One of the most complicated parts of building an ERD from a problem description is figuring which nouns are attributes and which nouns are entities. Also, choosing a relationship can be confusing when choosing the relationship that should be given. This process takes a lot of practice on identifying the entities and attributes. It will also be good for me to keep “checking to see if the noun can be described by another noun” to differentiate the two.

    • The hardest part about creating an ERD is figuring out what attributes fit with certain entities. I always get mixed up that supplier part ID attaches to the relationship between the supplier and Part, and not the supplier directly. In order to deal with this issue I make it a point to start out by creating the supplier part ID first, then moving to the rest of the problem.

  • I think creating an ERD is tricky over all. I have a hard time figuring out the attributes and entities and creating the relationships between them. I especially have a hard time figuring out the cardinality, I dont understand 1-to-many or the many-to-many.

  • I would say that the trickiest thing about creating an ERD is determining the primary keys, entities and attributes. I find that listing all of the possible entities related to the problem on the actual assignment helps me see it easier. I also think that comparing the possible entities from specific problems with the ones we have taken notes on in class helps me decipher easier.

  • I think the hardest part thing about making an ERD is finding the cardinality for corresponding entities, in addition to assigning attributes to relationships instead of entities when applicable as this does not always happen. It can be very easy to assign attributes to entities, but it often requires careful reading to correctly assign attributes to relationships. Figuring out the cardinality also requires careful reading because it is not always explicitly stated. In my opinion, the cardinality is often the hardest to understand part of creating an ERD model.

    When I make an ERD, I usually read through the problem one time and underline or circle all pertinent information. Then, I list all entities and list their attributes. After that, I create a rough ERD model that consists of only entities and relationships, but no relationships. I typically make the most changes to where I place entities and the relationships between them. After I have my preliminary ERD model, I add the attributes to the entities and relationships where appropriate. During this last step, I usually read through the problem again to make sure I have place everything correctly. I then do the cardinality last, because I always consult the problem many times during this step.

  • I think it can get really tricky when figuring out what is the Cardinality between the entities, also finding entities and attributes and most importantly differentiating them are also really tricky, especially when we were given the whole paragraph with so many texts on it. You really have to read it carefully to figure out what’s the relationship and Cardinality. Making notes on the scenarios would be a very good idea to differentiate entities and the cardinalities. Sometimes, cardinality can be mutually the same between entities. Make sure you understand how it works, otherwise it can really confuses you when you need to make an ER Diagram.

  • I think the most trickiest part about ERD is to distinguish many to many, one to many relationship. i got confusion when I try to dissect a paragraph.

  • I think the trickiest concept how attributes can describe both entities and relationships. Another tricky concept is to understand the cardinality between the entities. My advice I believe that could work is to reread the problem statement and look for words that relate to many:many, one:one, and one:many like “at least one address, multiple rides, and only one ride per inspection.” Let’s use the example from lecture about “Customer makes order” using many:many relationship, which is the a wrong cardinality. The many:many relationship is wrong because many customer making many orders causes errors and redundancy.

  • One of the most difficult things about constructing an ERD model is differentiating between what should be considered as an entity and an attribute. Identifying which items should be classified as “uniquely identifiable” and which are irrelevant in a specific problem has proved to be a problem for me so far. One piece of advice I would give would be to go through the problems and highlight the nouns as shown in our notes.

  • I think the trickiest part of creating an ERD from a problem description is finding every entity and attribute that should go in the database. It is helpful to read the problem description before picking out the entities. If the problem description is read before choosing the entities, it will be clear what entities need to be included in the database. It is important to carefully read the problem description to understand what information is important.

  • What do you think is the trickiest thing about creating an ERD from a problem description? What advice would you give to deal with that issue? I believe the trickiest part about creating an ERD from a problem is understanding the perspective of its use. What I mean by that is who is the ERD meant for and how is the organization prioritizing their information. Is it customer focused? Or is it product focused? This can be achieved by ascertaining specifics like is it a retail store or a department in a manufacturing company. Having a sound basis of perspective can lead to a better understanding of entity relationship dynamics.

  • The trickiest thing about creating an ERD from a problem description the way it is worded. Sometimes I get confused from the way its but and thought it’s an entity and attritubes. My advice is to do an outline separating the entity and attributes. After that, figure out what goes where then use the ERDplus.

  • I believe the trickiest thing about creating an ERD is finding the cardinality for each entity and determining what attributes fit with certain entities. A good way to help determine these things is to read the problem and make sure you understand exactly what its asking and then make a table like we did in class. You have to read the problem throughly to determine what parts are important. It helps to circle what information is important as you read through the problem and make a rough sketch of the attributes and entities before you make your ERD model.

  • The hardest thing about creating an ERD from a problem description is deciding which nouns are entities and what attributes apply to the entities. It’s hard not to repeat but I think the best way to go about it is to list everything out and then go through and delete repeats or nouns that don’t apply. Getting it all down on paper to start is definitely my best advice for setting up an effective ERD.

  • 1.) I feel that the trickiest part about creating an ERD based on a problem description is determining the relevancy of the given information. When using the paragraphs, I found myself coming up with too many entities than what the problem needed because some of my entities were irrelevant or simply attributes. My tip for correcting the problem would be to create an outline, as we did in class, showing each entity’s relationship to the next entity with all of their attributes defined around them. This helped me eliminate the items I falsely thought were entities and allowed me to visually see how each entity played a role in the relationships.

  • The hardest thing about creating an ERD from a problem description for me is identifying the nouns as either entities or attributes or irrelevant. The advice I would give to help with this issue is to write all of the nouns down in the problem and then go back and delete the irrelevant ones and label which nouns are entities and attributes. Getting it all down on paper is definitely my advice for the best place to start creating an ERD.

  • The trickiest thing about creating an ERD from a problem description is being able to assign the appropriate attribute to the appropriate entity. In general, it’s difficult to differentiate between the entities and attributes in general, because of the relevancy/irrelevancy it has to the problem description. The advice I would give to deal with this issue is to create a chart (like we did in class) with all the entities listed first and go back into the problem thoroughly to see which attributes are relevant to cite. Putting everything down on paper first is the best move in creating an accurate ERD model.

  • 1.What do you think is the trickiest thing about creating an ERD from a problem description? What advice would you give to deal with that issue?
    The trickiest thing is that it’s hard to define the cardinality between entities. This is because sometimes, you have to infer the relationship in your own and this can be really tricky. People may interpret the given scenario in different way. So I think when you compose ERD, I prefer skecth schima too and see how it works. I know that ERD is good tool but I think schema is more intuitive.

  • 1.What do you think is the trickiest thing about creating an ERD from a problem description? What advice would you give to deal with that issue?

    The trickiest thing is that it’s hard to define the cardinality between entities. This is because sometimes, you have to infer the relationship in your own and this can be really tricky. People may interpret the given scenario in different way. So I think when you compose ERD, I prefer skecth schima too and see how it works. I know that ERD is good tool but I think schema is more intuitive.

  • The trickiest thing about creating an ERD from a problem description is figuring out if an attribute is related to an entity or a relationship. In order to figure this out, you must analyze and dissect the paragraph to discern what the entities, attributes and relationships are. Think critically! Another difficult aspect is finding the cardinalities. Ask yourself questions about whether the entities are mandatory/optional or one/many.

  • The trickiest part of creating an ERD from a problem description to me is separating the relevant entities within a given problem, like what we did in class last Monday. My partner and I had a tough time trying to separate everything that was relevant in general, but also got lost in the more fine details of separation. An example of these fine details would be that we knew “first and last name” was an entity, but didn’t realize that “first name” and “last name” were actually separate entities.

  • The trickiest part of creating an ERD from a problem description to me is separating the relevant entities within a given problem, like what we did in class last Monday. My partner and I had a tough time trying to separate everything that was relevant in general, but also got lost in the more fine details of separation. An example of these fine details would be that we knew “first and last name” was an entity, but didn’t realize that “first name” and “last name” were actually separate entities…

  • The trickiest part of creating an ERD from a problem description to me is separating the relevant entities within a given problem, like what we did in class last Monday. My partner and I had a tough time trying to separate everything that was relevant in general, but also got lost in the more fine details of separation. An example of these fine details would be that we knew “first and last name” was an entity, but didn’t realize that “first name” and “last name” were actually separate entities….

  • The trickiest part of creating an ERD from a problem description to me is separating the relevant entities within a given problem, like what we did in class last Monday. My partner and I had a tough time trying to separate everything that was relevant in general, but also got lost in the more fine details of separation. An example of these fine details would be that we knew “first and last name” was an entity, but didn’t realize that “first name” and “last name” were actually separate entities

    .

  • The trickiest part of creating an ERD from a problem description is separating attributes from entities. Sometime the entities are more obvious like in the housing problem, but other times it can be hard to distinguish whether or not a noun is its own separate entity. Advice would give to help with this problem is to go through and list all the nouns. After you’ve listed all the nouns you go through again, rereading the problem to help you filter out which ones are separate entities or simply attributes. Pulling the nouns out of the problem can better help you identify them.

  • The most difficult part about ERD systems is figuring out what nouns are actually entities. I also have a tough time figuring out which noun is more specific when there are two nouns referring to the same entity. my advice would be to take your time and write everything out. once it is written out on paper it makes it much easier to see which nouns are talking about the same thing and from there if you look back in the paragraph deciding which one is more specific is easy.

  • What do you think is the trickiest thing about creating an ERD from a problem description? What advice would you give to deal with that issue?
    Give an example of how choosing the wrong cardinality (1-to-many, many-to-many) could cause problems when the database is implemented and used.

    From what I’ve experienced when creating the ERD table is trying to determine the relationship between attributes. However it is not always the case because sometimes it is fairly easy but at times it does get really tricky determining what it is. Advice I would give is to just play around with the charts and to look at the other attributes. If you’re stuck on one then move on to the next.

  • From working on ERD mapping, I believe the most trickiest part is understanding what comes first when mapping. For instance, understanding what the core of the ERD map is, then going from there and understanding the other entity’s and relationship involved. I also believe that when it comes to mapping, knowing the placement of extra attributes in the map becomes difficult to understanding. My advice would be to list out the things you believe are Entities and then map it out. If you look over the map and see that there are entities that do no belong with the other entity and the relationship. Eliminate them and work from there to fix your map.

  • 1. The most challenging part of creating an ERD for me is identifying entities and their attributes. It is easy to confuse the two. It is hard to decide what is and is not an entity and I often worry if some of the entities I am choosing are actually attributes. Things get especially tricky when there are entities that could be multiple entities themselves, such as the first and last name example.

  • In my point of view, the trickiest part of an ERD is distinguishing entities and attributes. But if we just connect the every facts related to the information we get, it will be easier for us to do that. If we choose the wrong cardinality, the logic will be mass. And the system will do not work. For example, if one key can open one door, it will results one key can open many doors if we choose the wrong cardinality.

  • I think the most challenging aspect about creating an ERD from a problem description is determining exactly the correct entities and their corresponding attributes. I had difficulties in class with my partner on differentiating the two and we really had to check over our answers. Advice I would give to someone dealing with this issue is group your entities down on paper first and make sure you are being careful when identifying. Then draw out the diagram and make it very visual so it is easy to see if a mistake was made or not.

  • The trickiest part I believe about creating an ERD from a problem is separating attributes from entities from one another. Some entities and attributes can be easy to figure out but not all the time. It can be difficult to differentiate between if a noun is a attribute or an entity. One thing that I do to help me is to list all the nouns in the problem on a separate sheet of paper so I know what I’m working with. I then go back into the problem and filter out which nouns are entities or attributes. It can get confusing when your just circling nouns in the problem. Taking those nouns and putting them on a separate sheet of paper can help a lot.

  • A1: I think the trickiest thing about creating an ERD model is determining which are the primary Entities, more specifically deciphering between which attributes that go with specific relationships.
    A1: Choosing the wrong cardinality can cause problems because if you choose the wrong cardinality relationship, the entire rest of the diagram wont make sense. When searched it will give the incorrect information to the associate that he/she is searching about the specific entity with its relationships to its attributes. This wrong information can cause that person to make administrative decisions that will be wrong because it based on incorrect information.

  • The trickiest part of creating an ERD from a problem description to me is separating the relevant entities within a given problem, like what we did in class last Monday. My partner and I had a tough time trying to separate everything that was relevant in general, but also got lost in the more fine details of separation. An example of these fine details would be that we knew “first and last name” was an entity, but didn’t realize that “first name” and “last name” were actually separate entities..

  • Choosing the wrong cardinality could cause a major issue. For example, if someone marks the relationship between the product and the order wrong where like you can only have one product in a order instead of multiple then it creates a huge issue. This will confuse the who system becuase it won’t allow someone to order more then one item. This is a mistake you want to avoid .

  • An example of using the wrong cardinality would be if you used a 1-to-many rather than Many-to- many, for a database set of information that is based on multiple authors for a given set of books. That would cause havoc with the database because the SQL system wouldn’t have multiple authors linked to one book it would have multiple rows for the multiple authors for the same book and essentially make the system work less efficiently and harder, when in all reality if it was many-many it would organize it as it should and allow the system to run more effectively.

  • Creating the ERD itself is not particularly difficult. The difficulty arises in deciphering the correct elements and attributes from a product statement. A lot of times, if an element seems like it could act as an attribute for another element, it means that those two elements have a relationship. Besides that, it’s important to take a step back once you think you have categorized all of the different elements and attributes and try to evaluate the problem from a bird’s eye view one more time.

  • In my opinion the hardest part of turning a problem description into an ERD is initially identifying the entities and their relationships without overlaps or mistakes. Once I’ve given it a go I can usually tell if I’ve done something wrong or sub-optimally, but at first I’m not usually sure which entities to connect and how they should be connected. I’ve found that if I do a couple very quick sketches of the ERD (without attributes or cardinality) it helps me understand the situation better and correctly pick the right set up from my sketches.

  • I think the trickiest part about creating an ERD is picking the right attributes and elements from the problem statement. It is important not to confuse the two even if there is a present relationship between two elements. It is vital that you get the cardinality right, otherwise your database will not function like you intended it to. Limiting the customer to only being able to purchase one item is a big deal and makes your database and company look bad.

  • I think creating the wrong cardinality could cause major problems when implementing that database because the operational database would not be able to recognize the order in which to process the data correctly. This in turn can cause the database to operate very slowly. For example, if someone were to mess up the order of a customer picking an item and used instead an item picking a customer, then the entities and attributes of the database would be wrong making it more difficult to analyze and extract the information that you need.

  • Creating an ERD is not so difficult the difficulty stems from deciding on the correct elements and attributes. Elements can act in different ways and sometimes if an attribute could act as an element then thats a relationship. Organization is key and making sure everything is in place like the different elements and attributes is important because you do not want recurrences in databases.

  • The trickiest part about creating an ERD from a problem statement is identifying the correct entities and attributes. Sometimes an entity can be irrelevant to what the problem is asking and it is up to you to determine what matters and what doesn’t. My advice to dealing with this issue would be to just step back and carefully look at what the problem statement is telling you. This would allow you to determine the relevant data.

  • The hardest component of creating an ERD from a problem is assigning the cardinality. I still struggle with assigning thr proper cardinakity as so i do not feel comfortable advisi g others on how to do it. I still need to think through how the cardinakity woukd affect the database relatiinshios once the association is implemented. It is a tough skill to master and varies situationally.

  • Constructing the database model wasn’t the hardest part when I was creating the entity relationship diagram (ERD). However for me, the difficult part for me was when I refined the diagram, especially when I was trying to figure out the relationships and its cardinality. I would suggest reverse engineering. It was helpful, for me, to edit my ERD by working backwards. The mistakes became more apparent using this method, as opposed to looking at the ERD in a normal order. Moving forward I would take time to think critically about whether a relationship is what kind.

  • I think the most trickiest concept is the relationships between the entities and I also always confused about the concept of cardinality between the entities, I sometimes don’t know I should choose one-many or many-many. The solution for this problem is reading question carefully and reread till I understand it. And use pen to mark some important sentences which indicate the relationship. For example, “There is only one ride per inspection”. Also, I think I need to practice more to familiar with the knowledge and ask professor.

  • Thank you all for posting comments to this question.

    I will try to address some of the issues when we discuss the solution keys to Assignment #1. Let me know if you have further questions.

    -Jing

  • A difference between an ERD and and a schema is the visual representation. An ERD shows the relationship between attributes and entities by giving them a square or circle shape. and the relationship between entities are shown by diamonds. A schema though shows the relationship between tables by connecting them to foregin keys located in their fields.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 16 other subscribers