Amy Lavin

The trickiest part about creating an ERD from a problem statement is steps to figure out what cardinality each entity has to another. That is challenging because you have to pay close attention to the wording of the problem. Another element to this wrinkle is that there can be attributes to relationships, and that can be confusing too. Because it was not very clear in the class example that one attribute didnt belong to any entity.

I think the toughest part, at least for me, is determining cardinalities based off of the problem statement. I think its always confusing trying to explain the relationships between everything. My advice would be to carefully read and try to understand the relationships. For example when reading the problem statement underline what each entity means to the others, really try to learn what the relationships mean.

The trickiest part of an ERD diagram in my own opinion is figuring out the cardinality from entity to entity. The advice I would give someone is to carefully read the scenario/statement and once you pick a cardinality, make sure it makes sense and try to match it to the scenario/statement to the best of your ability.

I think the trickiest part of ERDs are figuring out whether certain attributes are attributes of the entity or the relationship between two entities in many to many relationships. For example, in the relationship between student and course, grade is an attribute of the relationship. My advice is to just first worry about the cardinality before worrying about attributes you are unsure of.

The trickiest parts of creating an ERD is figuring out the cardinality between entities and parts of the scenario that actually need to be added to the diagram. My advice to someone would be to read the scenario multiple times and then taking note of the “important” nouns. After making note of possible entities and attributes, I would then go over the scenario again and narrow them down to what the reader believes is important.

With more complex scenarios I believe the most difficult part is deciphering entities from attributes. It took me some time to figure out what should be it’s own entity and what was just the attribute of that entity. Determining the entities that should exist before adding attributes helped me with this issue.

ERD’s are diagrams that show the relationships between entities. One of the hardest things with ERDs is finding the relevant information within all the information that is given to you. Many times irrelevant information can trick you into thinking its relevant. Especially because some information may be relevant to the problem but not be relevant to the ERD. That in my opinion is the toughest thing about ERD’s.

What is most difficult about creating ERDs is how differently every person thinks logically. No matter how hard I try to make sure every aspect of the ERD is correct, I will the consult with a friend or a peer only to find that they think the exact opposite of what I did is correct. For Assignment 1, I sat down with my parents to get some different view points on the second ERD. At one point, my Mom thought “A-B-C’ was logical, my Dad thought “C-B-A” was logical, and I thought “B-A-C” was logical. I thought that this instance with my parents truly defined just how difficult it is to make an ERD that is 100% correct because of how differently every mind thinks.

The most difficult part about creating an ERD is trying not to overthink it. Whenever I create an ERD I usually reread the scenario two or three times and each time I picture in my head what the ERD will look like. Another tricky thing about it is figuring out whether or not relationships have attributes and when one entity can have multiple relationships and attributes attached to it. This is the part I find myself struggling with the most. Another aspect that I’ve found to be confusing is cardinality. The relationship aspect of zero to many, one to one, etc. has been difficult for me to understand. The advice I would give for solving these issues is to think literally about it and not overthink it. Also reviewing the basics and features of ERD’s as well as doing examples can help you comprehend them better.

The trickiest part of creating an ERD is not overthinking it. During assignment 1 I kept finding myself second guessing myself. I also found myself struggling with the primary key. It is easier to determine the primary key if the scenario states a unique ID, but if it does not then it gets a bit more difficult. A piece of advice I would give is to through each scenario and underlining or high lighting each entity and attribute. This will really help when making your diagram.

The trickiest part of an ERD is figuring out the cardinality between the entities. To figure out the cardinality between entities, you have to use logic and pick and pull things from the problem statement. I guess one way to solve this is to dissect the problem statement word by word, line by line. Take an objective stance and try to see the overall picture while constructing the diagram.

The trickiest part of initiating an ERD is figuring out the cardinalities between relationships and entities. I tend to overthink the situation that drives me crazy. I guess the best way to try to figure it out is by reading slowly, carefully, and paying attention to all details within the description. in addition, I always like to draw it by hand and make changes as I go, it helps me with the process. finally, when you reach what you are satisfied with and think is right create your final diagram.

Since the last assignment that we submitted before class today. I think I learned more about ERD diagrams, and got a feeling for it more. Although while figuring the diagrams out I had few difficulties. For some reason I always can see something missing in the diagram or I can do it in a different way which is more efficient. I honestly think with more practice of ERD diagrams I will be fine, but the trickiest part is when you have multiple relationships that somehow connect together. I think just by practice it will be more clear!

I find that the trickiest thing about creating an ERD from a problem description is staying organized throughout the process. In many scenarios, attributes will be scattered throughout the description, and not all conveniently listed together next to where the entity is mentioned. I find that the best way to tackle this problem is by using five or six different colored highlighters to highlight all of the attributes that fall under the same entity, which makes navigating the prompt a lot quicker and easier. This is especially useful during exams where you have a limited amount of time to focus on the ERD.

Personally, the trickiest part about creating an ERD is the determining the cardinality between the entities. This is difficult because it can be subjective, and many times it can rely on a case by case scenario. In particular, determining if a situation is one to many or 0 to many can sometimes change between situations. I usually figure out cardinality by closely reading the write-up, and determining from there. If it is not explicit in the write-up I usually determine cardinality by making an educated guess on what fits in the particular situation.

For me, one of the trickiest parts was assigning the cardinality. I didn’t think it would be that hard, but when I had to figure out the specifics, I really started to over think it which tripped me up. Something that helped me was breaking the ERD down piece by piece. Also, I found it helpful to actually draw out the schemas in the next step to see if what I put makes sense in the database.

I think the hardest part of creating an ERD is determining cardinality. I feel like the descriptions aren’t detailed enough and leaves too much up to matter of opinion. Some cardinality can be different depending on how literally you read the description. How I deal with this is I try and put myself in the situation and imagine all the externalities that might be associated with the decision

The most difficult part in creating an ERD from a problem description in my opinion is figuring out how to map out the actual diagram. I think it’s important to find out the proper placement for each entity, relationship, etc. because entities are connected to one another quite often. In addition to entities being connected to one another, it also is difficult to determine when relationships acquire attributes. I think they receive attributes when a specific occurrence is taking place i.e. student taking a course or inspector completing inspection. Mapping out the diagram correctly is essential because proper arrangement will make it much easier to connect entities to one another.

For me, I think the trickiest thing about creating an ERD from a problem description is keeping track of all the entities and attributes that are present. A tactic that I’ve learned to attack this problem is reading the scenario with a few highlighters at hand, highlighting all the nouns that you see present. After that re-read the scenario, focusing only on the nouns, and highlight the entities again in a different color. What ever is left over with the color of the first round of highlights are your attributes. I found this to be much more easier and time-efficient.

The hardest thing for me when creating an ERD determining the cardinality when its clear from in the problem description. In these cases, I just try to take a step back and think of all the logical outcomes/scenarios that could exist for this relationship.

Creating an ERD is kind of like learning a new language, so I think the trickiest part is gearing your mind to think in such language. Once one can understand what words and connections to look for in problem statement, the process will go much quicker. Therefore, my advise would be to practice finding those connecting words that create the relationships between each entity and the rest of the structure falls into place.

The trickiest part about creating an ERD, in my opinion, is identifying the relationship and correct cardinality. When reading the problem description they sometimes include phrases that help to identify the cardinality. When the answer is not so clear, you must step back and think how the two entities interact.

I think that the trickiest part of creating an Entity Relationship diagram is selecting the right entities and figuring out the cardinality between each entity. I will read the narrative multiple times and then underline what I think could be entities and circle the attributes. To determine the unique identifier, I just put either “number” or “ID” after the entity name unless the social security number is provided as an attribute, since that is already a unique identifier. Finding the cardinality is difficult sometimes if the description does not give much detail about the relationships. I also find myself second guessing while creating ERDs, which makes the process a lot longer than it should be.

The trickiest thing about designing an ERD from reading a problem description in my opinion is identifying the cardinality between relationships and entities, as well as identifying whether some particular attributes belong to a relationship or an entity/entities. As far as identifying the cardinality, I normally mark the words identifying it some how in the case description and then come back to it at the end once all Entities, Relationships and Attributes are mapped out. When identifying if an attribute belongs to a relationship, one entity or multiple entities, I normally try and decipher the flow of which pieces of information(attributes) travel in between relevant entities. If the attribute is only necessary under the combination of both entities, then it is usually safe to say that the attribute belongs to the relationship.

The trickiest part about creating an ERD from a problem description is picking the right cardinality. I had alot of trouble deciding which cardinality to use and i was over thinking the situations. my advice is to right down and separately map out everything like we did once in class since it clears up alot of the confusion and helps me to not overthink and change my mind.

The trickiest thing about creating an ERD diagram I believe is finding the cardinality between entities. This can be a bit tricky since cardinality seems to be very subjective. The way an individual interprets the problem description could be right for one individual but wrong for another. If individuals can correctly explain the choice of cardinality then it is really no right or wrong answer. The advice I would give is to completely dissect the statements, draw the diagram out, and then work backwards to see if the chosen cardinality is logical given the relationships between entities.

In my opinion, the trickiest things about creating an ERD from a problem description are to identify the entity, primary keys and the attributes that associate with relationships. It is really hard to differ the attributes for entities and the attributes for the relationships. To be honest, I am still confused about this issue, so I really cannot give any advice for this issue. However, I can give some advice for how to find primary keys. In order to identify the primary keys, it is important to identify the “unique” attribute within the all of the attributes.

Personally, I think that the trickiest parts about creating an ERD is identifying the entities and using the right carnality. The advice I would give to deal with this issue is to read the description carefully and to identify the entities involved. The more you practice and read over the problem description the more you will become familiar with finding the entities. As far as cardinality is concerned, the only way your really going to get familiar with cardinality is practice, practice, practice. The more you read the description and know how all of the entities connect, the easier cardinality will become and the easier it will be to label entities and attributes.

Q: What do you think is the trickiest thing about creating an ERD from a problem description?
A: I think the trickiest thing about creating an ERD from a problem description is to identify one to more or more to more relationship between entities. And sometimes the descriptions would interrupt your thoughts, you might be circle a wrong attributes for an entity. I always add additional attributes to entities, then make the whole database look so messy and complex.
Q: What advice would you give to deal with that issue?
A: To differ the attributes in the problem description, the first step is to make sure the main entities/tables in an ERD. You can have a draft with simple fliter, separate parts of attributes into their own entities. Use of verbs to make relationships between entities, read carefully on specific numberic words like once, both, only one and at least to identify the cardinality.

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

The trickiest part of making an ERD is appropriately assigning the cardinalities to the entity-entity relationships. It can be tricky if you have many entities displayed; there could be discrepencies in cardinalities if you are dealing with entities that are intertwined. A good way to combat this problem later in the process would be to write down the cardinalities of the entities before creating the ERD.

For me the hardest part was navigating the wordiness of the scenarios. This simulates a real world experience where the subjects you interview for gathering requirements will want to tell you every last detail, whether or not it is relevant. So having to sort the redundant and irrelevant information was the hardest part for me.

For me the trickiest part about creating an ERD diagram from a problem statement was identifying the correct cardinality from the various different entities. It was relatively easy to pick out the correct entities and it was also relatively easy to pick out what the attributes were for each entity. However, it got tricky when you had to pick out what the correct cardinality it was from entity to entity. My best advice would be to read it very carefully and try and decipher what cardinality the problem is trying to ask for.

The most difficult thing about creating an ERD from the problem was deciding what entities went where. At first you make the process and it seems right, but then you play out the process in your head and you start second guessing on where the entities should be placed. An easy fix for this is to simply read the problem repeatedly. There is no use in creating an ERD until you are certain what the start to finish process is.