Instructor: David Schuff, Section 003

Weekly Question #2: Complete by February 2, 2017

Leave your response as a comment on this post by the beginning of class on February 2, 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?

54 Responses to Weekly Question #2: Complete by February 2, 2017

  • I think the hardest part of creating an ERD from a problem description is figuring out cardinality between entities and what notation should be used. To deal with this issue I feel that students, including myself, should read the description carefully and think about every possible scenario when choosing a relationship.

    • Ami, I definitely agree. Cardinality is often left out of the problem statement, which only makes it harder on us. My biggest issue is that I try to think of the cardinality that would fit the most far flung scenarios. My advice would be to think of every possible relationship, but not to get off track – stay practical.

  • The trickiest thing about creating an ERD is identifying an attribute that goes with a relationship.
    My only advice concerning that is that you should identify an attribute that can go for two entities (or an attribute that you do not know what to do with), this attribute will go on a relationship; and then look for the appropriate relationship to add it to.

  • I find it confusing when the minimum cardinality is not stated in the problem statement; this leaves room for deep reasoning and justification. Sometimes, choosing either one or zero is correct but sometimes one of those works but only in very rare situations which seem strange to common-sense (but still possible). I guess as long as you can justify it, you can choose either.

    • Han, I too, find this to be the most challenging part about creating an ERD from a problem statement. Often times, the maximum cardinality seems straight forward and sensical. However, when the minimum cardinality is not specified in the problem statement and leaves room for interpretation, I find this to be challenging. It seems that a case for either choosing one or zero can routinely be made. While this process of choosing the minimum cardinality can be challenging, I appreciate that it requires a little bit of decision while the rest of the ERD can sometimes be feel straightforward.

  • In a problem description that is normally several paragraphs long, there is a lot of unnecessary filler information that is not needed for an ERD. The trickiest thing is finding out which information is relevant and which is not. My advice is to skim each paragraph and draw a rectangle on each known entity stated and circle/underline each attribute in a problem description. I find it easier to create an ERD from this because I am only focusing on the necessary information needed.

    • I completely agree with your statement. The hardest part when reading over the problem descriptions is we tend of over think due to there being so much unnecessary filler information. It makes those trying to figure out the solution consider that there are multiple entities when there are in fact just a few related to the same family. Not that all the information is given to trip the student up or confuse them, It just all comes down to looking at the description in a more objective sense than a subjective point of view. When we observe the data more objectively we are able to identify more of the relevant sources of information to use in recognizing entities, attributes, and relationships.

  • Personally, the trickiest part about creating an ERD from a problem description is identifying the cardinality of the relationships and filtering through all the “extra” information to find the correct entities and their attributes. To help with identifying the cardinality, it is important to first analyze the text carefully to see if it explicit references what the correct cardinality should be. If not clearly stated, then try to think logically about the relationships between the 2 entities and mark the cardinality based on that. To easily filter through all the extra information, I tend to box all of the entities and circle the attributes associated with them.

    • Hi Shray, I totally agree with you that the trickiest part is identifying the relationships and also cardinality. The information can be confusing and vague so we have to spend some time to read through the paragraphs to identify all the correct titles. I agree that everyone should think logically through each relationship, see if each one makes sense if we connect them together. Entities and attributes are easier to identify, it’s the cardinality that we need to put more effort in.

  • The trickiest thing about creating an ERD from a problem description is that there can be a lot more attributes and entities that you know should be in the ERD. Therefore, you have to focus entirely on the problem descriptions and eliminate your knowledge about the subject, which makes it very inflexible. An advice would be to reread the problem afterward and eliminate everything that is not described in the problem statement.

  • Personally, I think the “trickiest” thing is identifying the maximum and minimum cardinality for each entity. It’s not that it’s difficult, but rather that it takes a few to get used to seeing them and getting it down quickly. The advice I’d give is to review the types of cardinalities and to have it down pat. Afterwards, the ERDs seem to get fairly simple.

  • I’ve found that the trickiest part about creating an ERD from a problem description is identifying attributes that do not belong to one entity but that belong to a relationship between two entities. Advice I have for this is when initially identifying entities and attributes, if there is an attribute that seems to relate to two entities, it should be an attribute of the relationship between the entities. Looking at examples of these cases also helps.

  • I think the trickiest thing about creating an ERD based off of a description is identifying the cardinality associated with each entity and its relationship. It seems like each time we develop a new ERD in class there is always some sort of uncertainty when it comes to what the actual cardinality would be. Most of the times, the confusion lies between one to many or zero to many. There can be all sorts of reasons that justify a many to one relationship that can easily plead the same case for a many to zero relationship. I do think that everything you should know about cardinality lies within the product description and that it is a matter of keying in on certain words that describe the relationship. The problems with most people including myself is that these key words that identify the relationships are often overlooked.

  • Personally I think the trickiest thing about creating an ERD from a problem description is understanding the cardinality between entities. I think this is the trickiest part for a lot of people in this class especially because we did not discuss cardinality in MIS 2101, so it is brand new. My advice would be to think logically and when they have created the line from one entity to another, read from one end to the other to logically figure out what the cardinality should be. I also think rereading the problem description really helps.

    • I agree with cardinality being the most difficult. I think doing these ERDs is quite a bit different from those we did in Intro, especially because we usually did swimlanes first in that class. Reading the prompt carefully and making sure you are going the correct direction is very important.

  • The trickiest part of creating an ERD from a problem description for me is distinguishing entities and their cardinalities. The problem statement can be vague and hard to interpret which causes me further confusion. What I have found to work best is to mark up the problem statement as I read through, and create drafts of possible ERDs.

    • Hey Ricardo, I agree with you in saying that the trickiest part of an ERD is distinguishing the entities and their specific cardinalities. Because of the vagueness of these questions one must pretend to be in the given scenario and think it out logically. Not every instance in these ERD’s will be straightforward, is seems much easier if the problem is reread about two or three times in order to get a good understanding of the situation. This way it is much easier to differentiate each operation going on in the database process.

  • The trickiest part of creating an ERD for a problem would be which cardinalities belong to the relationship rather than the entity. The problem statement normally has those cardinalities near each other, making it difficult to understand which one explains the relationship more than the entity. The more I read and tinker with my entity charts, I hope to catch mistakes such as these.

  • The trickiest part of creating an ERD from a problem description for me is to identify their attributes and the cardinalities. It is important to identify the entities in order to find the attributes. My advice is to read the problem carefully and underline entities, attributes and what are the relationship with different color pencils.

  • For me, the trickiest part of creating an ERD from a problem description is determining which attributes are related to relationships rather than Entities. Another difficult aspect is determining the cardinality between entities. To make this easier, I write out sentences that saywhat the cardinality is. Reading it in a sentence makes it a lot easier to find mistakes

  • I find the hardest thing about creating a ERD diagram is understanding what attributes because relationship attributes and how that effects the cardinalities of the entity. My solution to this problem is to make sure the attribute is relevent and only relates to the relationship between two entities. Then from there you can find the cardinalities more easily for each of the entities.

  • I think the trickiest thing about creating an ERD from a problem description is defining the rules and association between entities. It is easy to identify the cardinality from one direction, but it is confusing when it comes to the other way around. My recommendation would be reading descriptions of all entities to figure out the relations instead of just reading descriptions of two entities. Because sometime I have a better understanding of entities by looking at the big picture of the ERD.

  • The hardest thing for me is being able to identify what attributes effect relationships between entities. I have made the same mistake multiple times now where I put them under an entity as a regular attribute. My advice to students struggling with the same problem as me would be to think about the logic behind the problem. For example, will somebody always purchase the same quantity of cheerios in every order? After determining that the answer is no, then you need to move quantity to the relationship.

  • I think the hardest part about creating an ERD from a problem description is finding the cardinalities and connecting attributes. It is easy to find the attributes because they describe the entities but I have problems if there are attributes that describe relationships. I also have problems with finding the cardinalities. The advice that I would give is to marks and separate every entities, attributes, and relationship. I would then look at the wordings that connecting them.

  • Personally, I think the trickiest part about creating an ERD diagram is being able to differentiate the cardinalities of each entity. Each description provides a lot of unnecessary information that is there to throw the reader off or make it more difficult to pin point the entities and relationships. In order to filter that extra info, I tend to circle the attributes per entity as I am reading to make it easier when I start creating the diagram.

  • I agree with most people that have posted in this forum related to ERD diagrams. I think that the trickiest part for me is often times identifying the attribute that goes with a relationship. I also have slight difficulty thinking about cardinality…for both of these problems I’ve found a solution that works for me. Though it takes time I think that reading the problem statement over and over again is key, and even reading it out loud allowed me to further digest the info. I also like to write the steps out such as step 1 step 2, and try to connect the dots that way for a better visual aide before the ERD.

    • Dianna I agree with you! I as well find myself getting tripped over whether or not a relationship has an attribute. Sometimes it is very unclear as to whether or not a description in the problem statement is being related specially to an entity or if it is apart of a relationship. I think your advice is something I will definitely use in the future to further help me when creating ERDs. I also agree with you on the determination of what the cardinality should be between relationships. As most students have commented I find myself struggling to determine what the minimum carnality is because there is a very good chance it could be 0 or I and all you would have to do is justify your decision.

  • I think the trickiest thing about creating an ERD from a problem description is choosing the best option for the ERD. It’s almost like when you’re given a multiple choice question and it says choose the BEST answer. I think it’s tricky because there are times that you can have 2 different scenarios but one is the best one. So, my recommendation would be to read the problem carefully and really think about putting the words into a life situation and look at what would make sense as a whole while incorporating the individual specifics that the problem states.

  • The trickiest part about creating an ERD from a problem description for me would be figuring out the relationships between entities. More specifically trying to understand which entities should be linked. This can be caused by overthinking and too much useless information. To solve this, I’d have to pay more attention to the wording around the entities and filter out information that is not relevant to potential entity relationships.

  • I think the trickiest part about creating an ERD from a problem description is to avoid overthinking the situation, which may lead to listing entities irrelevant to the problem description or giving entities attributes they don’t have. This is because the way I approached ERDs back in MIS2101 was an open, unstructured one; I just came up with as many ERDs and attributes possible for the in-class activities. My advice to myself and others who might have the same problem is to focus on the case, use marking tools on entities, and ignore nouns/objects that do not have any concrete attributes.

  • The aspect I find most difficult with ERD modeling is determining the cardinality between two entities if not clearly stated within the problem statement. My recommendation for these situations is to write out each scenario and consider it. If there is no explicit cardinality stated, go with the scenario that most makes sense. One way to ensure there is no statement of cardinality within the problem you may have missed, is go through and color code the statement for entities, attributes, and cardinalities.

  • I think the trickiest part of making an ERD diagram is figuring out when an attribute actually belongs with a relationship rather than an entity. It’s the type of scenario where if you were to pair said attribute with a certain entity, it would only made a little bit of sense, but you can immediately sense a flaw in the grouping. My advice for getting around this is consider all of your options, read the prompt carefully, and don’t overthink it because that’s likely going to hurt.

  • In my opinion, the trickiest part of creating an ERD from a problem statement is understanding the cardinality between two entities. It’s challenging because it requires logical thought, as well as understanding which parts of the problem statement are giving you information regarding the cardinality. I believe the easiest way to deal with this is after you have identified your entities, attributes, and relationships, go back and try to pick out words like “multiple” or “only one” to help you piece together which cardinalities they are giving you. At that point, you will be able to use logic and understand that if there can only be one of something than it will most likely be at least one, and at most one. Breaking down cardinalities from the problem statement is essential to getting them correct.

  • I think that the trickiest part is deciding whether something is an attribute of an entity or an attribute of a relationship. One piece of advice I have is that if the attribute can be used to describe two separate entities, then it is most likely the attribute of the relationship between them. Underlining all of the nouns like we discussed in class is a great way to figure out if what you are looking at is actually an attribute and will also help you determine the number of entities it is describing. Be very careful and do not overthink it. If it looks like an attribute for a relationship then it probably is.

  • I believe that the trickiest part of creating an ERD diagram is discerning between cardinalities for their respected entities. Any notation could seem possible upon an initial glance. I would recommend that those having trouble with this read the descriptions very carefully and write out the cardinalities in a sentence to make sure what you put makes clear and concise sense when considering the pairing of the two entities.

  • I think the hardest part about creating an ERD from a problem description is the cardinality figuring out attributes that are attached to relationships rather than entities. The advice that I would give to deal with this issue is reading the problem over and over again. I would also suggest writing everything in tables first, and then turning the tables into the ERD’s.

  • The trickiest aspect of developing ERDs is when there are multiple entities that are associated with multiple other entities. In other words, when it seems that the diagram cannot be completed without some crossing of relationship lines is when my brain seems to throw a hissy fit at the problem. I would say the best way to solve these is draft up the diagram in a few ways and determine which will cause the least visual confusion: prioritize the entities that seem to have the most amount of relationships to other entities and gravitate those toward the center of the diagram. If we can lay out the ERD in this way, then the copious amount of relationships have plenty of room to associate outward rather than ACROSS each other.

  • The most difficult part of making an ERD diagram for me is dealing with missing attributes and primary keys. I often have trouble deciding when an attribute is an appropriate primary key and when a primary key needs to be invented. I find that the best way to deal with this problem is to reason out whether the given attribute could feasibly be duplicated; if it makes sense that the attribute could be repeated, then the attribute cannot be the primary key.

  • For me, the trickiest part about creating an ERD diagram from a problem statement is figuring out which entities actually link up to each other. This is not always explicitly stated in the problem statement so you have to use your best judgement to figure out how the two entities should be linked. When I go to create this relationships, I like to first sketch it out on a piece of paper so I can visualize what relationships would make the most sense and go from there.

  • I think the trickiest part about creating an ERD is determining the relationships between the entities. My recommendation is to make sure to read the problem description multiple times. I also recommend thinking about all the possible relationships that the entities could have.

  • The trickiest part of creating and ERD diagram is figuring out the min and max cardinality between two entities because it is not always clearly stated in the description. The max cardinality is not as hard because it is often stated, but the minimum is what throws me off. I suggest writing everything out first to get a better picture of the problem then jotting down every possibility the min cardinality could be. Once you have some options, think logically what makes the most sense and what would be the best outcome for the relationship between each ERD.

  • The hardest thing about creating an ERD from a problem description is assigning attributes to their correct entity. This is slightly more difficult when we have to keep in mind that some attributes can actually describe a relationship and not an entity like we saw in some of the in-class activities. The best way to combat this problem is to write everything out before creating the ERD. Find all the entities and the attributes that describe them. Some left over attributes and don’t quite match with an entity could be a special attribute that i just talked about. If an attribute can be placed under two different entities, it could be describing the relationship that the two entities have.

  • I think the most difficult thing about creating an ERD from a problem statement is the process of going through the statement and figuring out what material is actual relevant for the diagram. I found it helpful to think about it in terms of a database to help decide what information is actually useful ti store.

  • I think the hardest part about creating an ERD from a problem description is determining what the other attributes are, and then putting those other attributes off the correct relationship. To fix this issue, I would recommend writing all the attributes down with their corresponding entity, if it does not seem to fit into one entity, then it most likely goes off the relationship of the entities it fits. Also I tend to make too many entities with some problem descriptions. To deal with this issue I would recommend listing the entities with the attributes and if there are no attributes, it is most likely not an entity.

  • The hardest part about creating an ERD diagram for me is the determining the relationship and cardinality between two entities. I often second guess myself while trying to rationalize the relationship and assigning the multiplicity. I think the best way to address cardinality is to read the problem statement carefully and try to rationalize why an order can have many parts and a part can have many orders. Overall, I think cardinalities take some getting used to because they are somewhat of a foreign language to students.

  • There are two difficulties when creating an ERD. First and foremost is figuring out what the relationship and furthermore finding it’s attribute. It seems as if the relationships typically have less attributes and they link entities together. Therefore if it is hard to decide which attribute goes to which entity, it is likely the attribute of a relationship. Other students also have this issue. Another issue that comes up is that sometimes the problem is missing the primary key oran attribute. This is not an issue for designing the problem, but rather an issue that the problem is missing possible important information in their ERD. This is an issue that would need to be brought up to the author of the problem.

  • The trickiest part about creating an ERD for me is figuring out when a relationship has attributes. I tend to get stuck trying to figure out if the attribute belongs to an entity or the relationship of the entity. To deal with this issue, I just read the question over and over again because the answer lies in the question itself. If the attribute is defining two entities together then I add it to the relationship, however, if it talks about one specific entity, then I add it to the entity

  • Personally, the part that I get most stuck on is working with the cardinalities when looking at two entities. My best advice would be to re-read the problem because the problem statement tells you which one to use or think about it in real world setting to help you decided which cardinality is more appropriate for the statement.

  • I agree with what the classmates above said about the cardinality and participation in the ER diagram because it was not enforced at all in the introduction to Management Information Systems. Its difficult to decide what symbol to use for that scenario. I recommend looking at the power point slides because that helped a lot when completing our first assignment, but also I watched YouTube videos on those two concepts and made it easier to understand.

  • I think that one of the trickiest things about creating an ER model from a problem statement is identifying the correct cardinality for the entities and relationships. It’s difficult because it can be a case-by-case scenario when some things could seem like they have a one-one statement when it’s all possible that it is a many-to-many relationship. Setting up the crow’s foot notation in this manner can also be tricky. My advice to someone who is trying to model is to clearly understand the problem and try to immerse themselves in the situation by trying to visualize as much of the scenario as possible. It helps me a lot when doing this.

  • For me the toughest thing is figuring out how all of the entities relate to each other and their cardinalities. To help with this, the best thing you can do is pay really close attention to the problem description. You have to pay close attention to the fine details and read through it multiple times to make sure you did not miss any details and all of those details and relationships are represented clearly in your ERD.

  • The trickiest part about the ERD mapping is the way we interpret the description and the perception we have for different entity and relationship. For instance, in the assignment paper, there’s a payment section which really do confuse me, because i do not know whether making payment as an entity is better for the ERD diagram or worse, since payment require relationship with other entity. In all, figuring out the complexity between particular entity and the relationship in between two entities could sometimes be challenging.

  • The trickiest part of creating an ERD from a problem description is correctly identifying the cardinality between entities. Sometimes the description does not explicitly state what the relationship is or maybe only has a maybe has a phrase to describe this relationship. So I would recommend actually talking out the cardinality relationship. For example “a driver drives at least one car and as many as multiple cars” and “a car has at least on driver or many drivers.” Talking out the cardinality, at least for me, has helped me better understand the relationship between entities and if my previous notion was right or wrong.

  • The trickiest part of the ERD problem descriptions is identifying what attributes belong to an entity and which belong to a relationship. The best way to go about is is ask yourself “can this attribute describe both? Is it truly the connecting factor between them?” It is also beneficial to think about how you could foresee yourself using the data when you have it. Brainstorming potential problems you could try to solve with the data can clarify the discrepancy. I have noticed other students make a comment about cardinality being difficult. For me, it is easy when you think about it in sentence form. Like the example in class about customer and order. “A customer does not have to make an order, but they can also make many.”

  • I think that the hardest part of the ER diagram is knowing which cardinality to use between two entities. Sometimes it can be easy depending on the problem, but some problems have a confusing dialog and I can’t tell if it’s saying one thing or the other. Advice that I would give is to read the dialog very closely and to look out for anything that sounds important.

  • For me the hardest thing is making sense of how the greater part of the substances identify with each other and their cardinalities. To help with this, the best thing you can do is give careful consideration to the issue depiction. You need to give careful consideration to the fine subtle elements and read through it numerous circumstances to ensure you didn’t miss any points of interest and those subtle elements and connections are spoken to clearly in your ERD.

Leave a Reply

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

Where and when do we meet?
Alter Hall 232
11:00 - 12:20 Tuesdays and Thursdays
Office Hours
David Schuff (instructor):
10:00-11:00, Tuesdays and Thursdays
Speakman Hall 207G and email (see my site)

Nodir Zakhidov (ITA):
Monday: 1:00-2:00
Wednesday: 1:00-2:00
Speakman Hall 207 and email (see his site)