Instructor: David Schuff

Weekly Question #2: Complete by September 14, 2017

Leave your response as a comment on this post by the beginning of class on September 14, 2017. 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 this question:

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 Responses to Weekly Question #2: Complete by September 14, 2017

  • In my opinion, the toughest part of creating an ERD is determining the cardinality, or the rules of association between entities. This is particularly difficult because sometimes it isn’t explicitly stated in the problem description, and you must infer the relationship. My advice would be to simply ask yourself “does this make sense?” For example, can a course have more than one section? This makes sense because I’ve taken the same course as friends who are different sections. It also makes sense because professors ask you to fill in your section number on exams so that they don’t mix it up with their other sections.

  • A challenging component of making an ERD is staying true to the problem statement. I find it difficult to translate directly from the narrative without considering what it may look like as a real database. I found that taking extra time to complete every step given in the slide deck helps to understand which task is next. When I follow the process one piece at a time, I don’t leave out or duplicate as much data. Following the process of taking apart a problem statement is helpful for staying focused.

  • The trickiest thing about creating an ERD diagram, in my opinion, is determining the association between entities, in other words, the cardinality. It is crucial to distinguish the right association between entities because it affects the way one would implement the ERD in a database schema. My advice to figuring out cardinality between entities is to infer the association using common sense and also asking yourself “Does this make sense? “. In addition, one should make sure not to overthink the problem and strictly stay to what the problem statement says.

  • One of the trickiest things about creating an ERD from a problem description is missing or incorrectly identifying the attributes which don’t belong to any entities. Since we also have to sort out which info we need for the ERD and which info is irrelevant, we sometimes miss the attributes because it does not stay close to the entity word in the problem description. My suggested solution for that is filter carefully all the nouns and the info in the description by asking “Do we need to include this in the ERD?/ How this word/noun/info contribute to the ERD for the problem?” to sort out the attributes and the necessary info for the ERD.

  • When creating an ERD, I find one of the most difficult parts to be separating entities from non-entities. When reading the problem statement, sometimes it will go into detail over certain nouns in a way that makes them sound as if they are their own entities with their own attributes (the trucks in the Scenario 1 in-class activity for example). To me, they’re the “gotcha” questions of creating an ERD. The best way to go about them, in my opinion, is to imagine them as an entity and to see if they actually make sense in the ERD. If they have no logical connection to any other part of the ERD, then it’s safe to say that it can be eliminated and ignored.

  • One of the trickiest parts of the ERD’s is cardinality. The reason I find it so tricky is the fact that you have to determine the number a particular entity can be. For example, an employee has to be assigned at least one office but an office can have zero employees. Once you break down the problem set it is easy to determine the association between entities but it still trips me up. My advice would be to completely dissect the problem set before defining cardinality. Breaking it down line by line helps one to calculate the amount of associations.

  • I think the hardest part for me when creating ERDs is deciding which ones are entities. Going through the scenario and underlining all of the nouns is a great way to keep yourself on track. Once I have all of the nouns, it usually takes me a few minutes to decide which ones would be attributes or entities, and which ones would not be used in the diagram. Once I have all of the entities, the rest of the diagram is not hard to put together.

  • The trickiest thing about creating an ERD from the problem statement is how to connect the attributes to their entities for some attributes that is connected to relationship element. To deal with this kind of problem, we should list all attributes together with the relating entity and for an attributes that does not seems to belong to any entity, write them in a different attributes section. When creating the ERD diagram, you will find that the extra unknown attributes will actually connect to one of the ‘relationship’ elements.

  • In my experiences, one of the trickiest parts about creating an ERD diagram from a problem description is normalizing the ERD model. It is very easy to leave your ERD diagram exactly how it is stated in the problem description even if it can be further simplified. I find that the easiest way to normalize your ERD model is to draw the diagram out as the problem description states and go through each entity and attribute set to see if any entity has sets of related attributes. Finally, split the related attributes into a separate entity and attribute set.

  • I originally planned on saying that cardinality was the most difficult aspect of creating ER diagrams, but after starting the first assignment I changed my mind. I found that the ERDs we created in class, for the most part, I understood what should be included as an entity, but for the homework, I’m finding myself struggling more with deciding which nouns in the problem description should be classified as entities. I think it depends on the difficulty of the problem in some ways. This is a bigger challenge when the problem is harder because if you mess up which entities should be included in the diagram, you will have a lot more errors to fix than if you just make an error with the cardinality. Overall, I just think ‘practice makes perfect’ is the way to get passed these trouble spots. You have to do your best to approach it with the logic that you’re trying to capture a certain flow of information, and practice extracting that information flow from a larger piece of information.

  • In my opinion, the trickiest thing about creating an ERD from a problem description is making sure that the ERD matches the problem description verbatim. On several occasions, my instinct was to add more to my ERD than the problem description explicitly stated. However, I had to make sure that my ERD reflected what was indicated in the problem statement. Even though my changes made sense to me, it is important that the ERD that I create does not deviate from the problem description. Also, making sure the cardinality matches exactly what is stated in the problem description is tricky when there are multiple options that make sense. The best general advice that I could give for creating ERDs is to make sure that you follow the problem description verbatim.

  • In my opinion, cardinality is easily the most difficult concept to extract from a problem statement. Entities (nouns) Attributes (nouns describing nouns) and Relationships are simple if you follow a a logical system. Same goes with cardinality, but as of this point in the semester it is difficult to discern what constitutes multiple, at least 1, at least 0, etc. The advice I would give to help deal with this issue, especially for those who create the problem statements, is it explicitly label the cardinalities in the problem statement, in terms that are associated with developing cardinalities used in an actual ERD; terms such as “Mandatory”, “Optional”, “One”, and “Many”. This would make it easier for the person reading it to quickly and accurately determine cardinalities within the ER diagram.

  • While we were doing the in-class exercises, I would have said the trickiest part of creating an ERD would be the cardinality rule, and I still have a hard time with that but after looking at our first assignment, I’m having a hard time figuring out what attributes go to what entity and if some of the things even really are an entity. My advice would be to reread the problem and see what it’s asking for and think through it. I also try to use the noun trick that we learned in class and it helps

  • While we were doing the in-class exercises, I would have said the trickiest part of creating an ERD would be the cardinality rule, and I still have a hard time with that but after looking at our first assignment, I’m having a hard time figuring out what attributes go to what entity and if some of the things even really are an entity. My advice would be to reread the problem and see what it’s asking for and think through it. I also try to use the noun trick that we learned in class and it helps a little!

  • I think the hardest part about creating an ERD’s is the wording. Since they sometimes are open for interpretation (or mis-interpretation), it can be tricky to figure out how to draw from there. Also, knowing when a noun is useful or not, and can be used the the diagram, can be a bit tricky at times. The cardinality is also definitely a challenge, figuring out if it’s one to many, many to many, or 0 to many.

  • I think the trickiest thing about creating an ERD from a problem description is finding the right word or phrase to describe the relationship between entities. Sometimes the problem description doesn’t exactly give you the word or phrase so you might have to make up a “best answer”. I think a good way to approach it is to be simple. Your word or phrase doesn’t have to be very technical – it just has to relate the two entities.

  • I feel that the trickiest part about creating ERD’s is determining the cardinality between two entities. Specifically, I get confused choosing whether a relationship should have 1 or 0 minimum cardinality. I find myself always leaning towards a minimum of 1 but that is not always the case. I think the best way to approach issues like this is to think about it practically and determine whether or not it makes sense to keep track of something that can have no transactions. The example of keeping track of customers that have visited a site but haven’t ordered something yet makes sense to me and helps me work through other issues.

  • I think that the trickiest part of creating the ERDs is determining the appropriate cardinality rule, and then what notation to record it with. I was having some trouble with it in class but hopefully will be able to figure it out for the first assignment. Advice I would give to deal with this issue is to read the problem statement very carefully and review class notes!

  • The trickiest thing about creating an ERD from a problem description is the cardinality. Citing the entities, relationships, and attributes of a problem description is rather easy and straight forward. However, when it comes to cardinality you have to determine whether the relationship is one to many or many to many. The easiest way to solve this issue is to ask yourself what the minimum and maximum cardinalities are for all relationships.

  • I think the trickiest thing about creating an ERD from a problem description is finding out what all the USEFUL entities are and knowing if it needs a primary key or not. To deal with this issue I take my time and follow the steps that were provided to me during class. I seek out all the nouns (tangible or intangible) and from there if I see that a noun is a describing another noun, from that I can get my entity and attributes from that.

  • Determining the cardinality between two entities is the most difficult thing when creating an ERD from a problem description. Sometimes the relationship is clearly stated, which is fairly easy to pick out from the description. However, sometimes the relationship must be inferred because it does not clearly state it in the description. It can be done, but some analytical thinking is involved in figuring it out. When coming across this issue, I suggest pulling the two entities out of the situation as a whole and just think about them individually and how they relate to each other as a couple. Think about what would make sense for the situation between just those two entities.

  • To me, the most difficult part of creating an ERD from a problem statement is the interpretation of words into data – the subjectivity of putting words into a data format is especially difficult to me due to my difficulties with interpretation as a result of being a student on the autistic spectrum. My advice is simply to read the problem over as carefully as possible, and over and over again, until it begins to make sense.

  • I think the trickiest part about creating an ERD from a problem description is determining the cardinalities. These are mostly inferred and explicitly stated in the problem description. So you must contemplate on the correct relationship and apply the relationship accordingly. My suggestion would be to think about whether the relationship (many to many, one to many, or one to one) makes sense.

  • I find myself struggling with two aspects of an ERD; determining the cardinality and the “other” attributes that describe a relationship of two entities. Depending on the assignment the wording of relationships makes this seem tricky. My advice for figuring out cardinalities is just down to reading the problem description as plainly as you can, and not letting interpretations mislead you. These characteristics are usually written very plainly in the text. I still struggle with determining “other” attributes, but I would recommend mapping out all the entities you can definitely create, and then seeing where “other” attributes lie. Do they describe a relationship? Or is this an independent entity?

  • The trickiest thing about creating an ERD from a problem statement is the placement of an attribute that is linked to two entities. When an attribute is describing two entities or the relationship between those entities, then the attribute must be linked to the relationship between those entities that is represented in the ERD as a diamond.

  • For me, the hardest part of creating an ERD is determining the relationship Cardinality. This can get very confusing because you have to consider many possibilities between the two entities. Cardinality can also be different based on different situations and this can be overwhelming, I feel I tend to over think cardinality. Some advice I have when creating an ERD takes it one step at a time. Break the problem up so it does not get too overwhelming.

  • The hardest part I find when creating ERD systems is to get the entity and attributes laid out correctly. Sometimes it can be on the fence between what is an entity or an attribute, so its important to think it through entirely and write everything down separately. I feel like I’m not in a position to give advice about completing ERDs but my tip would be to take your time.

  • The hardest part about creating an ERD is determining which nouns are entities and which are not. It is not the hardest as in struggling to complete the problem, but it certainly delays the smooth process of creating an ERD system. Advice that I could give toward the problem would be to take your time and carefully analyze the nouns and choose which have multiple relevant attributes to describe them. After selecting entities, attributes, and relationships properly; the next hardest part would have to be the varying minimum cardinality. Advise to resolve this problem is to take your time and analyze the problem in a logical business sense.

  • I feel that the most difficult part of creating an ERD is determining the relationship cardinality. What makes it so difficult is that you must consider how many possibilities there are between two entities, and depending on the situation it can vary from each problem statement. I’m still having trouble myself figuring this out, but my advice would be to take the problem statement one sentence at a time, evaluate all the possible options and write it down on a separate sheet, then you can go back and slowly piece it together. Sometimes the cardinality is very self explanatory and you don’t want to overthink it, but all it takes is practice and I’ll be able to have no problems with it.

  • The challenging aspect of ERDs is the Cardinality between two entities. This can be difficult because you have to determine the relationship and depending on the prompt it can affect the type of relationship there is. My advice would to be think of the possibilities and pick the one that makes the most sense.

  • What I find difficult in creating ERDs is the cardinality aspect of the entities. The prompt provided can sometimes be confusing, and that’ll have me doubting the type of relationship I insert into my answer. There are quite a few ways one entity holds a cardinality, and I often spend too much time trying to figure out if I have the proper one, even though it may be clear from the start.

  • In my opinion, the hardest thing about ERD’s would be cardinalities. It gets tricky when having to determine wether the relationship is one-to-many or at least-one because there could be so many possible scenarios and I sometimes find myself overthinking how many possible associations there could be between entities. Also, if you get the cardinality wrong on the diagram; for example, if in your diagram you were supposed to have a many-to-many cardinality and didn’t draw it that way then you will be missing a table and it will ruin your schema.

  • The thing I find most difficult about ERD’s is trying to figure out exactly what information that is given is going to be relevant to the diagram you are trying to create. Often in ERD problems, you are given loads of details about the process that a company makes. All this detail can be great because it makes it easier to visualize how the process works, but it can also become confusing trying to find out what is important to include and what not. Such as in the in-class exercise we did last week, in scenario #1 it mentions a customer, most people would assume that the customer would end up being an entity in the ERD. However, in this scenario, it was not. My advice is to take your time and really evaluate the problem step by step to make sure you capture all that you need but to also not overthink the prompt at the same time.

  • The thing that I find most difficult about an ERD is knowing exactly where to put all of the entities based off of their connections to each other. It can be difficult to know exactly where to put a particular entity because it may only have one or several interactions with the entity. You want to put it somewhere where it can stay organized and where you can clearly see all of the connections between them. The best advice I have is to do your best to determine all of the connections between the entities before you actually put them down on a drawing so that your connections are clear and your ERD stays organized.

  • The most difficult aspect of creating an ERD diagram is finding the entities. Yes, some entities are very easy to find and establish for your diagram. However, there are some in the problem description that you would not believe is an entity. I was running into issues of having some entities as attributes in my diagram. After re-reading the problem multiple times, I was able to figure out the entities I needed. Some advice, if something is describing something it is 100% an entity. Overall, take your time, re-read, and analyze the paragraphs one by one to successfully create the ERD diagram for the problem description.

  • When creating an ERD, I find it tricky when it comes to cardinality and identifying all entities. When reading the scenario statements, it quite easy to miss an important entity or add an entity that should not be included. When it comes to the cardinality of two entities, it can be difficult to interpret what kind of relationship the entities have if it is not stated directly in the prompt. My advice to someone creating an ERD, would be to take your time and fully understand the prompt. By taking your time, you can accurately identify the important nouns that will create the entities. Also, if the relationship is not stated directly, do not overthink the relationships because they are not meant to be tricky.

  • One of the trickier parts of creating an ERD from a problem description is making sure to capture and translate all the specific business rules a company has from a basic description. Many times, you might have to make assumptions about a business and its relationships when building an ERD. The best solution would be to make sure that the problem description has very specific details about the relationships between the functioning parts of the business by talking to the person supplying the information or asking follow up questions.

  • Personally, the hardest part of ERD’s is keeping close to the problem statement and following the cardinality. After configuring the appropriate entities and attributes, knowing which cardinality to describe it as gets confusing. I always get confused with how to describe the relationship in order for the one-many / zero-to-many relationships to make sense.

  • In my opinion, the hardest part when it comes to creating an ER diagram is the fact that some attributes do not describe an entity, they sometimes describe a relationship between 2 entities. To solve this problem I would suggest reading the problem statement over and over until it makes sense and gets easier to understand and draw.

  • I would say the hardest aspect of creating Entity Relationship diagrams for me is determining the attributes for relationships. The issue for me is figuring out which relationship the attribute belongs to, which is not easy to pick up in a cursory reading. Many will say the solution is simple: just read the paragraph carefully. However, I think there is a better, more specific answer: think about the two entities that are the most pertinent to the attribute. Obviously, one can glean this knowledge from carefully analyzing the paragraph, but I think my tip provides a more logical approach to the problem.

  • In my opinion the toughest part of creating an ERD model is figuring out what information from the problem description is relevant to creating the database for the specific issue at hand. I think finding out what’s an entity and what is a attribute is fairy simple but deciding which entities and attributes to include is the tough part. Also determining the cardinality between two entities is can also create problems. Advice I would give to solving this issue s to read the problem description thoroughly and do not rush when making an ERD model.

  • In my opinion, the trickiest part about creating an ERD is identifying the entities. This is one of the most important steps of creating an ERD and is a very common step for making errors. Sometimes the problem description might indicate that a particular noun might be an entity but logically it might not be relevant to be an entity according to the problem given. This makes this step challenging.

  • Personally, the trickiest part of creating an ERD is determining the entities from the problem statement. I find that listing the nouns in the statement works well, but not all of the nouns are entities, so it requires deeper analysis of the wording in the statement. My advice would be to really think about if a noun is relevant to the problem statement.

  • Personally, I find the most difficult aspect of ERDs to be cardinality. After narrowing down which nouns in the problem statement are relevant, assigning attributes to these entities and determining the relationships is fairly simple. Cardinality is especially tricky though because you have to understand the maximum and minimum number of times that the two entities can be related. Something I do to help with this is to read through the problem statement slowly and carefully. When I see words like “more than”, “only” or “at least”, it can help me figure out what type of relationship it is.

  • I think the most trickiest parts of creating a ERD diagram from a problem description is determining the cardinality. This can get very difficult if the problem description does not explicitly states it. One advice that I would recommend to deal with this issue, is to read the words carefully, use common knowledge and think if the statement make sense or not.

  • The most challenging thing about creating an ERD is identifying the cardinality and the relationships between entities. In scenarios some elements of cardinality are not direct. What I do to help myself understand cardinality is to read the movement as a sentence. For example it wouldn’t make sense to say a student can have no pencils but a pencil can have many students. In addition, I’ve found that underlining the verbs in sentences helps choose the right relationship.

  • The trickiest part about creating ERD is keeping it as simple as possible without overextending the information that’s given. I notice that I always want to put more than I should when it could have been simply added within a few blocks. My advice would be to try to keep things simple and remember that other people will looking at it. If you want a good ERD, it needs to be readable from another persons perspective and without the mindset of “I did it this way because I understand it” since other people won’t see eye to eye with you all the time.

  • The most trickiest thing about creating an ERD from a problem description is figuring out the cardinalities between two entities. A problem description does not always give you both the max and min cardinalities for the entities; sometimes it doesn’t even give you any specific statement about the cardinalities between the entities. In order to deal with that issue, my advice would be to read the problem description over, guess the cardinalities between the relationship, then read and analyzes if the cardinalities make sense with the entities as well as the problem description.

  • The trickiest part about creating an ERD from a problem statement is probably determining the relationship and cardinality. Sometimes the way the problem statement is worded can trip you up,but also sometimes it is just hard to figure out. The cardinality I think is easy to do for one side, but not the other. For example, in the first assignment in the second scenario, obviously a driver can have many ratings, but what goes on the other end of that? Also if I put many on the other side does it mean a rating can be for many drivers or does it mean many drivers can have ratings? My advice would be just to think logically and to think about what would make the most sense.

  • When creating an ERD, I struggle most with determining the cardinality between entities. For this past homework assignment, I found it very helpful to break the problem down. First, I listed my entities and attributes. After some time away for the problem, I began to connect the entities and attributes with relationships and later assigned cardinality. By separating the problem, I was able to easily visualize the process, and it became more and more clear. Also, after assigning cardinality, I found it beneficial to read the entity to entity relationships backward and forward to make sure it made sense.

  • I think the hardest thing about ERD is knowing which is the entities and which is the attribute; sometime it is stated clearly, and other time it sounds so convincing. My only advice is to read everything word by word and take things slowly.

  • I think the trickiest aspect of ERDs is determining how all the entities are related to each other. When you’re creating a database, it’s very important that you accurately relate all the entities from the problem description to each other correctly in order to search for relevant information later on. A way to deal with this issue to to read through the problem description again and try to figure out if there’s any information that ties the two together. For example, if the problem description ever states, “…entity x AND entity y…,” there will likely be a relationship between entities x and y.

  • The most difficult thing about creating an ERD is general efficiency. The idea behind an ERD is to make a system that will store data efficiently. In order to do this it is important to thoroughly read the problem description highlight, underline and circle all of the attributes, entities and relationships to make sure you have all of the components you need before you begin. When you think your ERD is complete pay attention to the details and make sure each relationship has the appropriate cardinality and there is a unique identifier for each attribute. The little details are key in creating an efficient ERD.

  • In my opinion, the trickiest thing about making an ERD is determining which nouns are entities and which are attributes. Listing down the entities is the first step in the process of making an ERD and if that isn’t done correctly, it can mess up the entire diagram. My advice would be to read the description very carefully multiple times to ensure that you fully understand what is going on in the description. That way, it’ll be easier to determine which nouns are more important, the entities, and which are less important, the attributes.

  • I believe the trickiest part to creating ERD’s is when you find what you believe is an entity, then it appears that there’s an attribute with its own attributes. Whenever i come across a situation like this, I know I’m probably not thinking it through properly and that I should find a clear relationship between the entities I’m struggling with. Determining the primary key for certain entities is difficult too when it initially seems that every attribute listed for them doesn’t uniquely identify the entity.

  • For me, the relationship and cardinality are the hardest parts of creating an ERD. When the relationship is stated, determining the cardinalities are straight forward but for the scenarios where there relationship is inferred are trickier. Like the example given in class, an employee is assigned at least one office where an office is able to have no employees. Once the ERD is written out it is easier to put together and see the relationships but initially determining whether a relationship could be “mandatory” or “optional” always makes me think more that other aspects of the ERD.

  • The trickiest thing about creating an ERD from a problem description would have to be figuring out is cardinality between the entities with their relationship. It’s easy to make a mistake on how many relationships an entity can have. One way to solve this is to highlight the entities, attributes, and relationships, and reason it out.

  • I think finding the correct cardinality is the hardest part about creating an ERD, but I also feel that it is easy to miss an attribute. Advice I would give to help with these is make sure you reread the description, so you know you covered everything in the problem. For determining the cardinality I find it best to see if what you put makes general sense then go back and try to confirm if that is what is stated in the description.

  • I think that the hardest part about creating an ERD is figuring out the cardinality between entities. I think this might also be difficult for other people because you can have different perspectives when determining the cardinality or it might be more than one possibility determining the cardinality making it harder to choose the correct one. One way we can fix this problem is by not overthinking the different possibilities and choosing the best possible answer.

  • The part of creating an ERD, that I find the most challenging is finding the correct entities without getting confused with nouns that are not entities at all. During the exercises, and assignments that we have done I have realized that I get somewhat confused with which nouns are entities. The most efficient way that I have found to work for me is by carefully reading the problem statement and making sure that I separate what I believe are entities, and then follow them with their attributes. If i see that I wrote down an entity which has no attributes assigned to it, I cross it off because it just doesn’t make sense. The last assignment that we had to do for homework was very tricky, but as I stated before I carefully separated the entities in the best way possible, then I crossed out the least logical and it completely made it so much easier to finish the assignment.

  • The greatest issue with creating an ERD from a job description is that it can sometimes be unclear how entities connect. There are instances when entities seem to also fit as attributes and vice versa. It is also possible that the description will make it too vague to determine where an entity belongs in the scope of the ERD. To deal with this issue, I recommend asking for clarification when necessary from whoever wrote the description.

Leave a Reply

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

Where and when do we meet?
Alter Hall 232
12:30 - 1:50 Tuesdays and Thursdays
Office Hours
David Schuff (instructor):
2:00-3:00, Tuesdays and Thursdays
Speakman Hall 210E and email (see my site)

Lauren Soentgen (ITA):
1:00 - 2:00 Mondays
11:00-12:00 Fridays
Speakman Hall 210D (and see her site)