I think the trickiest thing about creating an ERD from a problem description is trying to figure out the cardinalities between two entities and their association. I find it simple if it is a “many to many” relationship stated in the problem, but if it is not specifically stated in the problem, I find it more difficult. For example, the problem that we did in class for the “Housing Authority”, it was difficult for me to find the relationship between development and unit because it was not specifically stated.
I learned that good advice to deal with this situation would be to consider all the possibilities, as we did in class, and just to be logical. Also, talking through problems aloud is beneficial.
I think that the trickiest thing about creating an ERD from a problem description is deciding where to put the correct cardinality. I sometimes mix up where the symbols go in relation to their specific entity. For example, if the entities have a 1:many relationship, I frequently switch where the 1 symbol should go and where the many symbol should go because I think about the relationship too much and in the wrong way. My advice to deal with this specific issue is to just keep practicing where the symbols go by re-reading past problem sets and thinking through them.
The trickiest thing about making an ERD from a problem description is figuring out the cardinality, because it can be so debatable, in lots of situations there is not a clear answer. The best way to handle this is to write out all of the options you find logical, and weigh them by how they look on the ERD, how they effect the flow of the ERD, and which seems more logical in your daily life.
Personally, I feel the trickiest thing about creating a ERD from a problem description is distinguishing relationship attributes. Determining the entity seems simple enough, basic attributes are easy to figure out (ex. first name, last name, gender). But determining whether the attribute is associated with entity or relationship gets a bit complicated. From what I can examine, it seems that if attribute that is associated with a relationship could be a variable attribute meaning it could be liable to change (don’t quote me on this).
I believe the hardest thing about creating an ERD is figuring out cardinality. Because you have to stick to exactly what the problem says, but sometimes you can think of a logical reason for many different cardinalities when the problem isn’t explicit. Sometimes figuring out cardinality can help determine whether or not two entities actually have a relationship. My advice when figuring out cardinality is to go to the place in the problem description that described the relationship and then try and put into words the cardinality. Basically eliminating unnecessary words to just “at least” and “at most” for each relationship.
The trickiest thing about making an ERD from a problem description is figuring out the cardinality. There is an unclear answer in a complex scenario. The best way to handle this is draw a basic relationship between entities, go back and forth with each option, and add the option on ERD by finding logical and weighting it.
Identifying the cardinality is the most difficult part of creating an ERD from a problem description unless it’s explicitly written. It seems that many of the options are arguable. I think the best way to deal with this issue is simply to use logic and go through all of the possibilities out loud, choosing the option that makes the most sense.
I believe the trickiest part about creating an ERD from a problem description is figuring out what the cardinalities are between two entities. Some relationships are quite easy to interpret, however if it is not clearly mention in the problem description, it is challenging. For example, in the ERD Diagram homework #1, it was challenging to find the cardinality between Passenger and Trip. The problem description gave intricate instructions on the relationship between those two entities. I had to reread it a few times and look at previous examples we have done in class to help aid my decision. My advice to deal with such a situation would be to reread the problem several times thoroughly and then take each sentence in the problem description one at a time to develop your ERD diagram.
I think the trickiest thing about creating an ERD from a problem description is using cardinality correctly. I would recommend underlining the relationships within the description like many:many, one:many, etc. For those that aren’t directly listed, use logical reasoning and look at it in terms of real life examples.
The most trickiest thing for me to create an ERD is finding the relationship between each entity. Sometimes it doesn’t appear obviously in the problem description, and it’s hard to find a exact word to express their relationship. And sometimes I am not sure how the relationship changes when each two entities’ direction changes.
I will suggest to read each sentence carefully, and try to find every words that indicate the relationships.
In my opinion, the most difficult part about ERD is to establish the cardinality relationship between entities. Unless it is stated explicitly in the problem, it is difficult to prove whether the relationship between two entities is mandatory or optional. In order to tackle this problem, I think the solution is to think about the problem critically and consider all possibilities. In addition, it will be great if we could ask for clarification on the problem (in real life scenario). Examine real-life example is a good way too. I still remember the example in class when the number of items in the order could be 0 as the customer may want to buy stuff but then decide against it. It was a good example of using real-life experience and logic to tackle this problem
The toughest aspect of an ERD diagram for my own personal self has to be figuring out the cardinality’s primarily and also figuring out relationships between entities &/or attributes. Both of these steps have to be derived directly from the problem set (which does not always make it simple/easy) and for someone like myself who overthinks massively or wants to “out” logic any problem – sometimes it confuses and sets me back more than it helps. I think that overlooking past problems and practicing more will clear up the discontent.
In my opinion, the most challenging part about creating an ERD based on a problem description would be identifying those attributes that describe a relationship, rather than an entity. Identifying entities is fairly simple, as they have multiple attributes that describe them. However, sometimes attributes may seem confusing, as they could seem like attributes of more than one entity. In such cases, the attributes that describe two or more entities are drawn separately as attributes of the relationship in the middle of the two entities. Therefore, to deal with this issue, you could first create a list of all the entities and their attributes and when you find an attribute conflict with two entities, you can separate that one out and put it as an attribute of their relationship.
The most common difficulty a person who is new to creating ERD diagrams has is creating the relationships between two entities. The in- class exercises have clear instructions on 1:1 or 1:n relationships because it is specific which entities have those characteristics. Scenario one of the in-class exercise emphasizes, “Each order can contain multiple parts, and a part can be part of more than one order”. This is a literal translation of a one to many relationship.
Other problem descriptions (as in the case of the homework assignment 1) has you decide what the relationships, attributes, and entities are. The key is to be logical about the problem description; when in doubt, just ask! ERD diagrams can present solutions to business problems. When laid out, we can find errors in the original problem description and adjust accordingly. The other difficulty is when an attribute can belong to more than one entity. An example from slide deck 2 illustrated this concept with a many to many relationship. Grade and semester described both entities, student and course. One cannot simply put either into just one entity. To resolve this, connect the attributes to the relationship (diamond) that connects the two entities (student and course).
I think the trickiest part of ERD is the Cardinality, it’s the last and most important step of the whole ERD process, and it determined the relationship with all the entities. So, in order to make sure you are using the right cardinality to express the relationship, you have to pick up the related attribute from every next entity, because you don’t want to miss or skip any entity. Then, read the article carefully to decided how you want to describe it, because it’s easy to get confuse with “one to many” and “many to many” relationship at the beginning. My advice for improving ERD skills would be doing every example, and always double check if the relationship is working or not. The more you practice, the easier to solve it.
I think the trickiest part of ERD is the Cardinality, it is the last and most important step of the whole ERD process, and it determined the relationship with all the entities. So, in order to make sure you are using the right cardinality to express the relationship, you have to pick up the related attribute from every next entity, because you don’t want to miss or skip any entity. Then, read the article carefully to decided how you want to describe it, because it’s easy to get confuse with “one to many” and “many to many” relationship at the beginning. My advice for improving ERD skills would be doing every example, and always double check if the relationship is working or not. The more you practice, the easier to solve it.
I think the most challenging part of creating an ERD from a problem description is figuring out which attributes are attached the the relationship between two entities instead of just tied to one entity. Sometimes the wording in the problem statement can be tricky so its important to know what the attribute it actually means. It’s important to read through the problem a few times and really understand what the attribute is tied to and if it is fixed or variable. If it is variable it will most likely be attached to the relationship.
I think the most difficult part of creating an ERD diagram is the cardinalities. The process of figuring out the cardinalities and its relations to the entities is not easy. I always mess up with the symbols because it is hard to interpret and place them at the right location. Also. to figure out cardinalities one has to think logically and outside of the given description. My advice to deal with cardinalities or any other problem with ERD is rereading. I read the description multiple times until I feel confident to work on it.
I think the two trickiest parts about creating an ERD is figuring out when certain attributes pertain to relationships rather than entities, and figuring out cardinality when the situation isn’t as obvious. In a few examples we did in class, there were attributes that belonged to relationships which I would have never thought about if the professor didn’t explain it in a particular way. My advice on handling those sort of attributes is to ask yourself “does this entity always contain this attribute or is it only during a specific situation with another entity”. This is what I asked myself in the exercise we did where move in/move out time were part of the relationship between unit and household.
Furthermore, my advice for handling cardinalities is to analyze the different possibilities, but also follow the instructions given. It is easy to overthink a problem too much, but every situation is different so focus on the instructions with the possibilities in the back of your head. Make sure to see how cardinality affects the logical flow of the problem, as well. Also, the more we practice, the easier all of it will become!
I believe that the trickiest thing about creating an ERD is figuring out the cardinality. I find myself unsure of whether I am drawing the correct cardinality to describe the relationship, as well as if I am putting the relationship into words correctly. My advice when figuring out cardinality is to go over the practice problems and re-watch the class capture to thoroughly understand the cardinality symbols and how to describe each relationship.
The hardest part about creating an ERD from a problem description is finding the tiny details that complete it through cardinality. The smallest misstep in defining how entities relate can throw off the entire scenario. A one-to-many or many-to-many can be tricky but it is important to be very methodical in reading. The “other attributes” that fit with a relationship can be confusing too. An example would be how a Move-In Date would be an attribute of lived in between a unit and household. Not every household has the same dates for a unit, it is again very tough to carefully sort out those details.
I believe that the most difficult part about creating an ERD would be when deciding which cardinality to put between each relationship. I feel as though I am not very good at understanding the specifics of each symbol. I think some advice that helps me is talking through the problem and picking out specific words that will help better determine the correct cardinality.
I think the trickiest thing about creating an ERD from a problem description is to find the right attributes and also find the relationships of many to many and least or most. The challenge exercises are little hards, but the best way is to solve these exercises are first to write all the entities and attribute. Then, read line to line to find the relationship between the entities and highlights the important words. After you find all entities, attribute, and the relationship starts to draw your diagram; draw your diagram according to paragraphs. By doing this way it is more easier and interesting drawing ERD diagram.
The trickiest part about creating an ERD from a problem statement is listing all the details that would complete the ERD. Then as well as listing all these components, it is very difficult to determine the entities and the attributes that connect to each of them. It is very important to be able to properly identify each of them and one mistake can throw off the entire ERD. I think that carefully reading the problem description and going one entity at a time is a big help in the ERD process.
I believe the most difficult part of building an ERD is establishing cardinality. Often there is multiple answers all with logical explanations, especially if the problem is not precise and has no definitive answer. I like to tinker with the different possibilities and read the different combinations aloud to help decide which I feel is the best option. Similar to the class activities, it is important to re-read, get a firm grasp on exactly what is trying to be accomplished, and decide from there.
The trickiest part of an ERD is finding attributes that don’t belong to an entity initially and having to place them. I believe what really helped me was thinking about what entity it is most likely to fit into then looking at the decisions that need to be made between two entities and placing it there if that means there can be variability between the two decisions.
The most trickiest part that i think is to find the relationship between different entities, meaning finding which one to connect. Sometimes there is so many of them that there are higher chances of errors. In my opinion, the easiest way to deal with this is to chose different highlighter colors for entities, attributes and relationship so they are visible. On the other hand, going from paragraph to paragraph makes things easier.
I think the trickiest thing about creating an ERD from a problem description is determining whether attributes belong to an entity, or go with the relationship between two entities. Sometimes, we come across an attribute that doesn’t fit an entity exactly, and it can be tricky figuring out where to put it. To solve this issue, I recommend thinking about whether the attribute is constant, or can change. If it can change, there is a good chance it belongs to the relationship instead of the entity.
To me, the most challenging part of creating an ERD from a problem description is assigning the right cardinality between entities. I think it is helpful when assigning cardinality to use a simple word like “has” in the relationship diamond so that I don’t get myself more confused by trying to make the relationship between two entities more complex than necessary. All of the different symbols involved in assigning cardinality can also be confusing because I am still new to using them, but keeping a key with me that shows what each relationship means is helpful for me.
The most complicated thing about interpreting an ERD from a problem description is that everything is not always straightforward. The problem descriptions we receive in class are generally very self-explanatory and are not too difficult to construct an ERD out of. However, in the case of our homework assignment or a real-life scenario, everything is not always neatly presented to you in an organized manner. As the interpreter, you must take bits and pieces from the description and attempt to create a comprehensive ERD that perfectly captures the scenario.
I think the hardest part is identifying and distinguishing what the cardinality is. Cardinality is not like identifying attributes and variables, where they are explicitly written in the problem statement. Its the part of the ERD that brings everything together and knowing the attributes to each variable is crucial to successfully identifying the cardinality.
In my opinion, the most trickiest part of creating an ERD from a problem description is determining which nouns are important (entities) and which nouns are irrelevant. Sometimes, important looking nouns like “store” in our in-class example may stand out and seem very important. However, by closely reviewing the problem, one may realize it is only playing a part in the context and is not a relevant noun. Thus, to avoid such mistakes, it is very important to go over the list of nouns in the problem statement to determine which nouns are synonyms for other nouns and choose the best option.
The hardest part of ERDs is figuring out the cardinalities. I suggest looking all your details carefully and organize your important details to figure out the relations to the entities.
I think the trickiest thing in the process of learning ERD is to determine the correct cardinality. The relationships between each entity are always confusing. Especially where we need connect the primary key to and whether we should create a new table seem to be my biggest issue. To figure out the right answer, I always come back to the problem and reread the sentence. Also, I keep in mind the rules of each type of cardinality (one to many, many to many and one to one) to help me choose the most reasonable way.
The main issue I struggle with when mapping out an ERD is overthinking relationships between entities. Problem descriptions aren’t always straight forward, so I find myself overthinking relationships which further complicate the cardinalities. I would suggest reviewing in-class exercises to locate a similarities with your current problem description. In my case, I need to read the problem description aloud to myself to make everything nice & simple.
The hardest part for me when it comes to ERDs is differentiating between actual entities and normal nouns. While reading through the scenarios there are usually lots of nouns, but after dissecting the text only a few of the nouns are relevant entities. This process of figuring out which nouns are important and which nouns are strictly there to trick the reader I find to be hard.
The trickiest part for me when creating an ERD is figuring out if any relationships have attributes. I also sometimes get confused with deciding what the correct cardinality should be. I am sure with practice and time this will become easier.
I think that the hardest parts for me are cardinality and attributes on relationships. Unless the cardinality is specifically stated in the project I find it hard to immediately grasp what it is and I tend to overthink it. I find it help to just think about it logically and use what I consider to be the most correct cardinality. I also find it difficult to assign attributes to relationships as I find when there are a lot of entities and relationships it becomes complex and confusing. In order to make it easier I read the scenario multiple times and try to color code the different entities,attributes, and relationships.
I think the hardest thing about creating an ERD from a problem description is making sure you capture the true intent of the process described. This includes anything from making sure ‘First Name’ and ‘Last Name’ remain separate to making sure attributes are correctly assigned to entities, even if that means they belong to a relationship. The way I work through this is to systematically work through the process description circling words I believe to be entities and underlining words I believe to be attributes. Anything I do not feel fits in a specific category I put off to the side in its own column to attend to after I am sure I have the rest of the ERD correct.
The other difficulty I am having is with cardinalities. It is important to make sure you are constructing the carnality with all possible scenarios in mind, but making sure they are also probable scenarios. I think this is best learned through experience, so practicing as many schemas as possible is the best way to learn this skill.
In my opinion, the trickiest part of the ERD’s is the cardinality because of the many possibilities that one could have during the situation. Also, finding out if it is a many to many or one to many is a tricky part that corresponds with cardinality. The best advice i could give for cardinality would be to read the scenario thoroughly and read it over multiple times.
I would say the trickiest thing about completing and ER Diagram would be establishing carnality between two entities. The best advice I could give is to not think into it too much and to go with the most intuitive answer. Ask yourself questions as it would relate to the real world (unless the problem statement states otherwise), like “can a product be apart of multiple orders?” I think ERD’s are difficult for anyone starting off; understanding how to map them out comes with practice, so I would also suggest practicing a lot until you feel more comfortable.
The trickiest thing to form an ERD from a problem description is the last component which is cardinality. Some advice I would give to this issue is to first see the association between the entities- such as if its a one to many relationship. Read the passage carefully and remember that cardinality is defined by business rules.
The trickiest thing to form an ERD from a problem description is figuring out the entities. When we first started out making the diagrams I had 1 or 2 more entities than the solution had. Some advice I would give is to look for the specific information in each entity to make sure its relevant.
Figuring out what the primary key is is probably the hardest thing in an ERD. Some advice I would give to someone is to make sure that its an attribute that uniquely defines the entity.
I believe the most difficult part to create an ERD is determining if the relationship has attributes and how to put the right cardinality. I usually put the attributes that should belong to a relationship to an entity and overthink the cardinality between two entity. I think the best way to solve these problems is to reread the paragraphs and the ERD you create at the same time, then check if the attributes in an entity are logical and if the cardinality can be more reasonable when you change it.
I feel that the trickiest part about creating an ERD is determining when the attributes are connected to the relationship and not to the entity as well as determining the correct cardinality for each relationship. When it comes to determining the attributes and whether or not they go on an entity or relationship, I think that the best advice would be to really think through who the attributes belong to. If it belongs to both the entities, then it would be placed on the relationship rather than just one entity. When it comes to the placement of the cardinality, really taking the time to think through all possibilities and just being logical when it comes to each scenario is helpful in these situations.
The trickiest part of creating ERDs is paying attention to the cardinalities. It is important to look at the relationship between two entities and follow the wording of the prompt carefully, It is also tricky to figure out whether an attribute belongs with an entity or if it is related to a relationship.
In my opinion, the trickiest aspect of ERD Models are the cardinalities between entities and their relationships to other entities. I keep using zero to many instead of the one to many. The advice I would give is to read the scenario carefully and choose the cardinality that makes the most sense without overthinking. What makes the most sense in this given scenario.
The trickiest part about creating ERD diagrams for me was when I began making it before writing it out. I’ve found that writing it out and detailing the attributes and entities prior to designing the ERD has made it significantly easier and less frustrating. With that being said, it also helps to conceptualize the cardinality and write that out before creating the diagram.
I think that though I find several aspects of making an ERD quite challenging, specifically I think that the cardinalities along with correctly identifying entities for the diagram are more challenging for me. I think that the reason these aspects of creating the ERD are hard for me, is because I have a tendency to overthink the details within the problem descriptions. I think the best way I have been able to tackle this challenge when trying to make ERDs, is using the step-by-step breakdown of identifying entities on the PowerPoint that explains ERD diagrams. It helps me to correctly identify entities and their relevant attributes. It then also explains cardinalities. I like to refer to this PowerPoint, as I think it’s a helpful guide when making ERDs.
The trickiest thing about creating an ERD from the description is when I define the rules of the association between entities. It is confused when the description does not have not enough information between two entities. when it’s happened, I cross out all unnecessary information and highlight the information that I need. Even though I cannot figure out the relationships than I think the realistic situation.
The trickiest part of creating an ERD diagram from a problem description is determining the cardinality. I personally find myself wrongly interpreting the cardinality of some relationships as they are all different and not necessarily very straightforward. That said, my advice to overcome this problem would be to carefully work through each portion of the ERD diagram in order to determine the cardinality. Thinking through each part allows you to better understand the problem and properly figure out the cardinality.
One of the more difficult aspects I have found with the ERDs is when to put attributes with relationships rather than entities. Sometimes I will see an attribute but can’t seem to find where exactly it ties into the ERD. These tend to be because they don’t attribute to an entity but rather a relationship. My advice to this problem would be to stop and think. Does this attribute explain a specific entity? Does it tie two different entities together? If you answered yes to the latter, this probably means the attribute belongs to the relationship between the two entities rather than one of the entities.
What I find the trickiest about creating an ERD from a problem description is the cardinality. It is easier to find the different entities and their attributes because it is stated in the problem description, but the cardinalities are not always explicitly written. My advice would be to first go through the problem description and plug in the places where it may state there is a “many to many” or “one to one” relationship. Then go through again for the ones that are not openly stated and use the entity relationships as a sentence to see what makes the most logical sense.
I believe that the hardest aspect of creating an ERD would be to figure out the relationships between the entities, and how they work with one another. It is pretty simple to figure out the entities and the attributes that go along with them. However, when you’re finished with all those, and then when trying to look at relationships, it’s easy to overthink. It is fairly simple to look at the all the entities and attributes, and not be able to figure out the cardinality between them.
I find myself having difficulty finding the correct relationships among entities along with their cardinalities. This problem may be based off my own overthinking while not really analyzing the problem statement. The same goes for the cardinalities, such as one-to-many and many-to-many relationships. This issue can be solved with constant practice through class capture and previous slides and in-class work.
It is the cardinality that troubles me most of the time because the it can vary depending on different situations and subjects. My best bet for this problem is to really understand the given information and relate back to real life situations to make sure the cardinality actually makes sense.
The trickiest part of creating an ERD for me, is figuring the cardinality. Sometimes, the problem statement is worded in a way that makes you think one cardinality is appropriate, but when you think about it logically, it adds or takes away cardinality. I also have to actively check myself to make sure I’m not accidentally flipping the way the cardinalities should be facing. In order to combat this, I actually find making the schemas helpful. They help to sort out the ways the cardinalities should be facing due to the rules about cardinalities in relationships.
In order to get started with the ER Modeling, one needs to first get started with identifying the entity, their relationship and the attributes. This could be tricky as well if the problem at hand is not understood correctly. After the above is sorted out, the most tricky part is the relationship between the entities and their cardinalities. My advice would be to learn all possible outcome in real world senario as the professor point out in class and they apply it to the problem at hand
Figuring out the correct cardinality between two entities was a big challenge. I also found it difficult to identify when an attribute should be attached to a relationship, instead of to one of the entities. My advice to dealing with this would be to first identify all entities and its attributes, and then figure out how they interact between each other. Also, I’d suggest go over the problems we resolved in class, read the problem description and look at the ERD in order to understand how the cardinalities work.
The trickiest thing about creating an ERD would probably be the connection between each entities because one entity could be connected to multiple other entities with different cardinalities. Also the entity could be connected to two other entities that are connected to each other. Just from reading the description of the relationships, it’s difficult to figure out which is connected to which and sometimes it seems like everything is connected.
I think the trickiest thing about creating an ERD from a problem description is trying to figure out the cardinalities between two entities and their association. I find it simple if it is a “many to many” relationship stated in the problem, but if it is not specifically stated in the problem, I find it more difficult. For example, the problem that we did in class for the “Housing Authority”, it was difficult for me to find the relationship between development and unit because it was not specifically stated.
I learned that good advice to deal with this situation would be to consider all the possibilities, as we did in class, and just to be logical. Also, talking through problems aloud is beneficial.
I think that the trickiest thing about creating an ERD from a problem description is deciding where to put the correct cardinality. I sometimes mix up where the symbols go in relation to their specific entity. For example, if the entities have a 1:many relationship, I frequently switch where the 1 symbol should go and where the many symbol should go because I think about the relationship too much and in the wrong way. My advice to deal with this specific issue is to just keep practicing where the symbols go by re-reading past problem sets and thinking through them.
The trickiest thing about making an ERD from a problem description is figuring out the cardinality, because it can be so debatable, in lots of situations there is not a clear answer. The best way to handle this is to write out all of the options you find logical, and weigh them by how they look on the ERD, how they effect the flow of the ERD, and which seems more logical in your daily life.
Personally, I feel the trickiest thing about creating a ERD from a problem description is distinguishing relationship attributes. Determining the entity seems simple enough, basic attributes are easy to figure out (ex. first name, last name, gender). But determining whether the attribute is associated with entity or relationship gets a bit complicated. From what I can examine, it seems that if attribute that is associated with a relationship could be a variable attribute meaning it could be liable to change (don’t quote me on this).
I believe the hardest thing about creating an ERD is figuring out cardinality. Because you have to stick to exactly what the problem says, but sometimes you can think of a logical reason for many different cardinalities when the problem isn’t explicit. Sometimes figuring out cardinality can help determine whether or not two entities actually have a relationship. My advice when figuring out cardinality is to go to the place in the problem description that described the relationship and then try and put into words the cardinality. Basically eliminating unnecessary words to just “at least” and “at most” for each relationship.
The trickiest thing about making an ERD from a problem description is figuring out the cardinality. There is an unclear answer in a complex scenario. The best way to handle this is draw a basic relationship between entities, go back and forth with each option, and add the option on ERD by finding logical and weighting it.
Identifying the cardinality is the most difficult part of creating an ERD from a problem description unless it’s explicitly written. It seems that many of the options are arguable. I think the best way to deal with this issue is simply to use logic and go through all of the possibilities out loud, choosing the option that makes the most sense.
I believe the trickiest part about creating an ERD from a problem description is figuring out what the cardinalities are between two entities. Some relationships are quite easy to interpret, however if it is not clearly mention in the problem description, it is challenging. For example, in the ERD Diagram homework #1, it was challenging to find the cardinality between Passenger and Trip. The problem description gave intricate instructions on the relationship between those two entities. I had to reread it a few times and look at previous examples we have done in class to help aid my decision. My advice to deal with such a situation would be to reread the problem several times thoroughly and then take each sentence in the problem description one at a time to develop your ERD diagram.
I think the trickiest thing about creating an ERD from a problem description is using cardinality correctly. I would recommend underlining the relationships within the description like many:many, one:many, etc. For those that aren’t directly listed, use logical reasoning and look at it in terms of real life examples.
The most trickiest thing for me to create an ERD is finding the relationship between each entity. Sometimes it doesn’t appear obviously in the problem description, and it’s hard to find a exact word to express their relationship. And sometimes I am not sure how the relationship changes when each two entities’ direction changes.
I will suggest to read each sentence carefully, and try to find every words that indicate the relationships.
In my opinion, the most difficult part about ERD is to establish the cardinality relationship between entities. Unless it is stated explicitly in the problem, it is difficult to prove whether the relationship between two entities is mandatory or optional. In order to tackle this problem, I think the solution is to think about the problem critically and consider all possibilities. In addition, it will be great if we could ask for clarification on the problem (in real life scenario). Examine real-life example is a good way too. I still remember the example in class when the number of items in the order could be 0 as the customer may want to buy stuff but then decide against it. It was a good example of using real-life experience and logic to tackle this problem
The toughest aspect of an ERD diagram for my own personal self has to be figuring out the cardinality’s primarily and also figuring out relationships between entities &/or attributes. Both of these steps have to be derived directly from the problem set (which does not always make it simple/easy) and for someone like myself who overthinks massively or wants to “out” logic any problem – sometimes it confuses and sets me back more than it helps. I think that overlooking past problems and practicing more will clear up the discontent.
In my opinion, the most challenging part about creating an ERD based on a problem description would be identifying those attributes that describe a relationship, rather than an entity. Identifying entities is fairly simple, as they have multiple attributes that describe them. However, sometimes attributes may seem confusing, as they could seem like attributes of more than one entity. In such cases, the attributes that describe two or more entities are drawn separately as attributes of the relationship in the middle of the two entities. Therefore, to deal with this issue, you could first create a list of all the entities and their attributes and when you find an attribute conflict with two entities, you can separate that one out and put it as an attribute of their relationship.
The most common difficulty a person who is new to creating ERD diagrams has is creating the relationships between two entities. The in- class exercises have clear instructions on 1:1 or 1:n relationships because it is specific which entities have those characteristics. Scenario one of the in-class exercise emphasizes, “Each order can contain multiple parts, and a part can be part of more than one order”. This is a literal translation of a one to many relationship.
Other problem descriptions (as in the case of the homework assignment 1) has you decide what the relationships, attributes, and entities are. The key is to be logical about the problem description; when in doubt, just ask! ERD diagrams can present solutions to business problems. When laid out, we can find errors in the original problem description and adjust accordingly. The other difficulty is when an attribute can belong to more than one entity. An example from slide deck 2 illustrated this concept with a many to many relationship. Grade and semester described both entities, student and course. One cannot simply put either into just one entity. To resolve this, connect the attributes to the relationship (diamond) that connects the two entities (student and course).
I think the trickiest part of ERD is the Cardinality, it’s the last and most important step of the whole ERD process, and it determined the relationship with all the entities. So, in order to make sure you are using the right cardinality to express the relationship, you have to pick up the related attribute from every next entity, because you don’t want to miss or skip any entity. Then, read the article carefully to decided how you want to describe it, because it’s easy to get confuse with “one to many” and “many to many” relationship at the beginning. My advice for improving ERD skills would be doing every example, and always double check if the relationship is working or not. The more you practice, the easier to solve it.
I think the trickiest part of ERD is the Cardinality, it is the last and most important step of the whole ERD process, and it determined the relationship with all the entities. So, in order to make sure you are using the right cardinality to express the relationship, you have to pick up the related attribute from every next entity, because you don’t want to miss or skip any entity. Then, read the article carefully to decided how you want to describe it, because it’s easy to get confuse with “one to many” and “many to many” relationship at the beginning. My advice for improving ERD skills would be doing every example, and always double check if the relationship is working or not. The more you practice, the easier to solve it.
I think the most challenging part of creating an ERD from a problem description is figuring out which attributes are attached the the relationship between two entities instead of just tied to one entity. Sometimes the wording in the problem statement can be tricky so its important to know what the attribute it actually means. It’s important to read through the problem a few times and really understand what the attribute is tied to and if it is fixed or variable. If it is variable it will most likely be attached to the relationship.
I think the most difficult part of creating an ERD diagram is the cardinalities. The process of figuring out the cardinalities and its relations to the entities is not easy. I always mess up with the symbols because it is hard to interpret and place them at the right location. Also. to figure out cardinalities one has to think logically and outside of the given description. My advice to deal with cardinalities or any other problem with ERD is rereading. I read the description multiple times until I feel confident to work on it.
I think the two trickiest parts about creating an ERD is figuring out when certain attributes pertain to relationships rather than entities, and figuring out cardinality when the situation isn’t as obvious. In a few examples we did in class, there were attributes that belonged to relationships which I would have never thought about if the professor didn’t explain it in a particular way. My advice on handling those sort of attributes is to ask yourself “does this entity always contain this attribute or is it only during a specific situation with another entity”. This is what I asked myself in the exercise we did where move in/move out time were part of the relationship between unit and household.
Furthermore, my advice for handling cardinalities is to analyze the different possibilities, but also follow the instructions given. It is easy to overthink a problem too much, but every situation is different so focus on the instructions with the possibilities in the back of your head. Make sure to see how cardinality affects the logical flow of the problem, as well. Also, the more we practice, the easier all of it will become!
I believe that the trickiest thing about creating an ERD is figuring out the cardinality. I find myself unsure of whether I am drawing the correct cardinality to describe the relationship, as well as if I am putting the relationship into words correctly. My advice when figuring out cardinality is to go over the practice problems and re-watch the class capture to thoroughly understand the cardinality symbols and how to describe each relationship.
The hardest part about creating an ERD from a problem description is finding the tiny details that complete it through cardinality. The smallest misstep in defining how entities relate can throw off the entire scenario. A one-to-many or many-to-many can be tricky but it is important to be very methodical in reading. The “other attributes” that fit with a relationship can be confusing too. An example would be how a Move-In Date would be an attribute of lived in between a unit and household. Not every household has the same dates for a unit, it is again very tough to carefully sort out those details.
I believe that the most difficult part about creating an ERD would be when deciding which cardinality to put between each relationship. I feel as though I am not very good at understanding the specifics of each symbol. I think some advice that helps me is talking through the problem and picking out specific words that will help better determine the correct cardinality.
I think the trickiest thing about creating an ERD from a problem description is to find the right attributes and also find the relationships of many to many and least or most. The challenge exercises are little hards, but the best way is to solve these exercises are first to write all the entities and attribute. Then, read line to line to find the relationship between the entities and highlights the important words. After you find all entities, attribute, and the relationship starts to draw your diagram; draw your diagram according to paragraphs. By doing this way it is more easier and interesting drawing ERD diagram.
The trickiest part about creating an ERD from a problem statement is listing all the details that would complete the ERD. Then as well as listing all these components, it is very difficult to determine the entities and the attributes that connect to each of them. It is very important to be able to properly identify each of them and one mistake can throw off the entire ERD. I think that carefully reading the problem description and going one entity at a time is a big help in the ERD process.
I believe the most difficult part of building an ERD is establishing cardinality. Often there is multiple answers all with logical explanations, especially if the problem is not precise and has no definitive answer. I like to tinker with the different possibilities and read the different combinations aloud to help decide which I feel is the best option. Similar to the class activities, it is important to re-read, get a firm grasp on exactly what is trying to be accomplished, and decide from there.
The trickiest part of an ERD is finding attributes that don’t belong to an entity initially and having to place them. I believe what really helped me was thinking about what entity it is most likely to fit into then looking at the decisions that need to be made between two entities and placing it there if that means there can be variability between the two decisions.
The most trickiest part that i think is to find the relationship between different entities, meaning finding which one to connect. Sometimes there is so many of them that there are higher chances of errors. In my opinion, the easiest way to deal with this is to chose different highlighter colors for entities, attributes and relationship so they are visible. On the other hand, going from paragraph to paragraph makes things easier.
I think the trickiest thing about creating an ERD from a problem description is determining whether attributes belong to an entity, or go with the relationship between two entities. Sometimes, we come across an attribute that doesn’t fit an entity exactly, and it can be tricky figuring out where to put it. To solve this issue, I recommend thinking about whether the attribute is constant, or can change. If it can change, there is a good chance it belongs to the relationship instead of the entity.
To me, the most challenging part of creating an ERD from a problem description is assigning the right cardinality between entities. I think it is helpful when assigning cardinality to use a simple word like “has” in the relationship diamond so that I don’t get myself more confused by trying to make the relationship between two entities more complex than necessary. All of the different symbols involved in assigning cardinality can also be confusing because I am still new to using them, but keeping a key with me that shows what each relationship means is helpful for me.
The most complicated thing about interpreting an ERD from a problem description is that everything is not always straightforward. The problem descriptions we receive in class are generally very self-explanatory and are not too difficult to construct an ERD out of. However, in the case of our homework assignment or a real-life scenario, everything is not always neatly presented to you in an organized manner. As the interpreter, you must take bits and pieces from the description and attempt to create a comprehensive ERD that perfectly captures the scenario.
I think the hardest part is identifying and distinguishing what the cardinality is. Cardinality is not like identifying attributes and variables, where they are explicitly written in the problem statement. Its the part of the ERD that brings everything together and knowing the attributes to each variable is crucial to successfully identifying the cardinality.
In my opinion, the most trickiest part of creating an ERD from a problem description is determining which nouns are important (entities) and which nouns are irrelevant. Sometimes, important looking nouns like “store” in our in-class example may stand out and seem very important. However, by closely reviewing the problem, one may realize it is only playing a part in the context and is not a relevant noun. Thus, to avoid such mistakes, it is very important to go over the list of nouns in the problem statement to determine which nouns are synonyms for other nouns and choose the best option.
The hardest part of ERDs is figuring out the cardinalities. I suggest looking all your details carefully and organize your important details to figure out the relations to the entities.
I think the trickiest thing in the process of learning ERD is to determine the correct cardinality. The relationships between each entity are always confusing. Especially where we need connect the primary key to and whether we should create a new table seem to be my biggest issue. To figure out the right answer, I always come back to the problem and reread the sentence. Also, I keep in mind the rules of each type of cardinality (one to many, many to many and one to one) to help me choose the most reasonable way.
The main issue I struggle with when mapping out an ERD is overthinking relationships between entities. Problem descriptions aren’t always straight forward, so I find myself overthinking relationships which further complicate the cardinalities. I would suggest reviewing in-class exercises to locate a similarities with your current problem description. In my case, I need to read the problem description aloud to myself to make everything nice & simple.
The hardest part for me when it comes to ERDs is differentiating between actual entities and normal nouns. While reading through the scenarios there are usually lots of nouns, but after dissecting the text only a few of the nouns are relevant entities. This process of figuring out which nouns are important and which nouns are strictly there to trick the reader I find to be hard.
The trickiest part for me when creating an ERD is figuring out if any relationships have attributes. I also sometimes get confused with deciding what the correct cardinality should be. I am sure with practice and time this will become easier.
I think that the hardest parts for me are cardinality and attributes on relationships. Unless the cardinality is specifically stated in the project I find it hard to immediately grasp what it is and I tend to overthink it. I find it help to just think about it logically and use what I consider to be the most correct cardinality. I also find it difficult to assign attributes to relationships as I find when there are a lot of entities and relationships it becomes complex and confusing. In order to make it easier I read the scenario multiple times and try to color code the different entities,attributes, and relationships.
I think the hardest thing about creating an ERD from a problem description is making sure you capture the true intent of the process described. This includes anything from making sure ‘First Name’ and ‘Last Name’ remain separate to making sure attributes are correctly assigned to entities, even if that means they belong to a relationship. The way I work through this is to systematically work through the process description circling words I believe to be entities and underlining words I believe to be attributes. Anything I do not feel fits in a specific category I put off to the side in its own column to attend to after I am sure I have the rest of the ERD correct.
The other difficulty I am having is with cardinalities. It is important to make sure you are constructing the carnality with all possible scenarios in mind, but making sure they are also probable scenarios. I think this is best learned through experience, so practicing as many schemas as possible is the best way to learn this skill.
In my opinion, the trickiest part of the ERD’s is the cardinality because of the many possibilities that one could have during the situation. Also, finding out if it is a many to many or one to many is a tricky part that corresponds with cardinality. The best advice i could give for cardinality would be to read the scenario thoroughly and read it over multiple times.
I would say the trickiest thing about completing and ER Diagram would be establishing carnality between two entities. The best advice I could give is to not think into it too much and to go with the most intuitive answer. Ask yourself questions as it would relate to the real world (unless the problem statement states otherwise), like “can a product be apart of multiple orders?” I think ERD’s are difficult for anyone starting off; understanding how to map them out comes with practice, so I would also suggest practicing a lot until you feel more comfortable.
The trickiest thing to form an ERD from a problem description is the last component which is cardinality. Some advice I would give to this issue is to first see the association between the entities- such as if its a one to many relationship. Read the passage carefully and remember that cardinality is defined by business rules.
The trickiest thing to form an ERD from a problem description is figuring out the entities. When we first started out making the diagrams I had 1 or 2 more entities than the solution had. Some advice I would give is to look for the specific information in each entity to make sure its relevant.
Figuring out what the primary key is is probably the hardest thing in an ERD. Some advice I would give to someone is to make sure that its an attribute that uniquely defines the entity.
I believe the most difficult part to create an ERD is determining if the relationship has attributes and how to put the right cardinality. I usually put the attributes that should belong to a relationship to an entity and overthink the cardinality between two entity. I think the best way to solve these problems is to reread the paragraphs and the ERD you create at the same time, then check if the attributes in an entity are logical and if the cardinality can be more reasonable when you change it.
I feel that the trickiest part about creating an ERD is determining when the attributes are connected to the relationship and not to the entity as well as determining the correct cardinality for each relationship. When it comes to determining the attributes and whether or not they go on an entity or relationship, I think that the best advice would be to really think through who the attributes belong to. If it belongs to both the entities, then it would be placed on the relationship rather than just one entity. When it comes to the placement of the cardinality, really taking the time to think through all possibilities and just being logical when it comes to each scenario is helpful in these situations.
The trickiest part of creating ERDs is paying attention to the cardinalities. It is important to look at the relationship between two entities and follow the wording of the prompt carefully, It is also tricky to figure out whether an attribute belongs with an entity or if it is related to a relationship.
In my opinion, the trickiest aspect of ERD Models are the cardinalities between entities and their relationships to other entities. I keep using zero to many instead of the one to many. The advice I would give is to read the scenario carefully and choose the cardinality that makes the most sense without overthinking. What makes the most sense in this given scenario.
The trickiest part about creating ERD diagrams for me was when I began making it before writing it out. I’ve found that writing it out and detailing the attributes and entities prior to designing the ERD has made it significantly easier and less frustrating. With that being said, it also helps to conceptualize the cardinality and write that out before creating the diagram.
I think that though I find several aspects of making an ERD quite challenging, specifically I think that the cardinalities along with correctly identifying entities for the diagram are more challenging for me. I think that the reason these aspects of creating the ERD are hard for me, is because I have a tendency to overthink the details within the problem descriptions. I think the best way I have been able to tackle this challenge when trying to make ERDs, is using the step-by-step breakdown of identifying entities on the PowerPoint that explains ERD diagrams. It helps me to correctly identify entities and their relevant attributes. It then also explains cardinalities. I like to refer to this PowerPoint, as I think it’s a helpful guide when making ERDs.
The trickiest thing about creating an ERD from the description is when I define the rules of the association between entities. It is confused when the description does not have not enough information between two entities. when it’s happened, I cross out all unnecessary information and highlight the information that I need. Even though I cannot figure out the relationships than I think the realistic situation.
The trickiest part of creating an ERD diagram from a problem description is determining the cardinality. I personally find myself wrongly interpreting the cardinality of some relationships as they are all different and not necessarily very straightforward. That said, my advice to overcome this problem would be to carefully work through each portion of the ERD diagram in order to determine the cardinality. Thinking through each part allows you to better understand the problem and properly figure out the cardinality.
One of the more difficult aspects I have found with the ERDs is when to put attributes with relationships rather than entities. Sometimes I will see an attribute but can’t seem to find where exactly it ties into the ERD. These tend to be because they don’t attribute to an entity but rather a relationship. My advice to this problem would be to stop and think. Does this attribute explain a specific entity? Does it tie two different entities together? If you answered yes to the latter, this probably means the attribute belongs to the relationship between the two entities rather than one of the entities.
What I find the trickiest about creating an ERD from a problem description is the cardinality. It is easier to find the different entities and their attributes because it is stated in the problem description, but the cardinalities are not always explicitly written. My advice would be to first go through the problem description and plug in the places where it may state there is a “many to many” or “one to one” relationship. Then go through again for the ones that are not openly stated and use the entity relationships as a sentence to see what makes the most logical sense.
I believe that the hardest aspect of creating an ERD would be to figure out the relationships between the entities, and how they work with one another. It is pretty simple to figure out the entities and the attributes that go along with them. However, when you’re finished with all those, and then when trying to look at relationships, it’s easy to overthink. It is fairly simple to look at the all the entities and attributes, and not be able to figure out the cardinality between them.
I find myself having difficulty finding the correct relationships among entities along with their cardinalities. This problem may be based off my own overthinking while not really analyzing the problem statement. The same goes for the cardinalities, such as one-to-many and many-to-many relationships. This issue can be solved with constant practice through class capture and previous slides and in-class work.
It is the cardinality that troubles me most of the time because the it can vary depending on different situations and subjects. My best bet for this problem is to really understand the given information and relate back to real life situations to make sure the cardinality actually makes sense.
The trickiest part of creating an ERD for me, is figuring the cardinality. Sometimes, the problem statement is worded in a way that makes you think one cardinality is appropriate, but when you think about it logically, it adds or takes away cardinality. I also have to actively check myself to make sure I’m not accidentally flipping the way the cardinalities should be facing. In order to combat this, I actually find making the schemas helpful. They help to sort out the ways the cardinalities should be facing due to the rules about cardinalities in relationships.
In order to get started with the ER Modeling, one needs to first get started with identifying the entity, their relationship and the attributes. This could be tricky as well if the problem at hand is not understood correctly. After the above is sorted out, the most tricky part is the relationship between the entities and their cardinalities. My advice would be to learn all possible outcome in real world senario as the professor point out in class and they apply it to the problem at hand
Figuring out the correct cardinality between two entities was a big challenge. I also found it difficult to identify when an attribute should be attached to a relationship, instead of to one of the entities. My advice to dealing with this would be to first identify all entities and its attributes, and then figure out how they interact between each other. Also, I’d suggest go over the problems we resolved in class, read the problem description and look at the ERD in order to understand how the cardinalities work.
The trickiest thing about creating an ERD would probably be the connection between each entities because one entity could be connected to multiple other entities with different cardinalities. Also the entity could be connected to two other entities that are connected to each other. Just from reading the description of the relationships, it’s difficult to figure out which is connected to which and sometimes it seems like everything is connected.