Weekly Question #2 – Complete by May 26, 2017

Leave your response as a comment on this post by May 26, 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.

Here is the 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?

25 Responses to Weekly Question #2 – Complete by May 26, 2017

  • The hardest part of creating an ERD is focusing on what is part of the database that the problem is asking for. It can be hard because there can be information that is not needed for the database and it can be deceiving. To deal with this, I would say to read the problem multiple times to fully understand what is needed for the ERD

  • In my opinion, the most trickiest part is to identify the relationship between two or more entities. First, it has many kinds of relationships like one to one, one to many, many to many. Then, some time the sentences in the scenario will make you confuse their relationship. To deal with this, I think a good way is to think about your experience, and take the scenario into the real example in your life to consider about the relationship.

  • I believe the trickiest thing is determining the useful entities in a problem. Closely followed by determining the relationship between each entity. Once you have found both pieces of information, it’s much simper to look out for the descriptive words for each. A good idea to determine the entities is to list each NOUN in the scenario and the cross off the list the ones that don’t have attributes, are duplicates or synonyms, or not applicable in any way. Taking the time to do this makes the ERD model process much easier.

  • One of the trickiest things for me about creating an ERD from a problem description is the entity/attribute identification. Sometimes I have trouble determining if a certain noun is supposed to be its’ own entity or if it just belongs as an attribute of another entity. In the process of determining that, I have to figure out where to place it in the ERD diagram and sometimes finding a relationship for it that makes sense is difficult. I have just been reading the problem multiple times and breaking it down noun by noun and eventually it all finds its’ place.

  • For me, the most difficult part of creating an ERD is identifying the actual question that is being asked and then entities that are necessary to answer this question. Having extra information can muddle the important information and confuse you. I think the best way to deal with this is to underline the actual question or write it down. Then as you work through the problem and begin identifying entities, refer back to the original question you are answering and make sure the entity is necessary to answer the problem.

  • I think the hardest challenge for me in creating an ER diagram is Identifying the attributes that describe the entities and the one that can identify the relationship. it can be complicated for me to figure out. if the different is clearly stated in the problem statement, that will be helpful.

  • In my view, the trickiest thing is to deal with relationships between different entities. For example, one to many, one to one, many to many are different and need to tell clearly. In addition, sometime one entity can has many matches during a period, but cannot has more than one match at the same time. It is complex and hard to deal with. In the real case, it might be harder. However, in class, there are clear stories. We should read them carefully and just follow the description.

  • Relationships with attributes were tricky for me. I decided that if an attribute changes each time entities interact, it is probably a good candidate for a relationship attribute. To use the product/order entity relationship as an example- quantity of a product may change depending on the product being ordered or the order being placed, so rather than update one of these entities each time, it’s more streamlined to have the attribute describe the relationship between a particular order and product combination.

    I also had trouble with cardinality, especially when thinking of an ERD over short periods of time. For instance, a baker makes only one cake at a time, but a baker can make many cakes over the course of a week. And a cake can only be made by one baker, but over time many bakers will make many cakes. Rather than using the entities to determine cardinality, I started using the primary keys. So baker123 can make many cakes with numerous IDs, but cake123 can only be made by one baker with one ID.

  • 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 explicitly 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 Everyone!

    For me, the difficulties in the Entity Relationship Diagram were defining the specifics of the relationship. Setting relationships cardinality and participation is important because it characterizes the relationship. When talking the problem out these details are quite obvious, but when I review the diagram I always question whether I did this portion correctly. I would advise anyone who has this same difficulty to focus on getting everything else set and then read through the scenarios to make sure what is said matches the rules described. Do not worry about the symbols being in the right place as the program will do this automatically. Rereading and verifying scenario to setup was the key to getting over this issue for me.

    Have a great week!

  • The hardest thing about it is the hardest thing about a math problem: the phrasing can change everything. Sometimes there are relations between entities that are implied, but could potentially be wrong. For example, in the class activity #2 exercise #1, you could argue that there’s a relationship between the supplier and the orders since it’s implied that the orders are made to the supplier, but the answer says no. Solution, don’t think about the relationships implied, but simply focus on just what is written down in ink.

  • The trickiest part for me is not letting extra details derail you from creating an ERD that is to the point and not over complicated. The way that I was able to do this was by not sticking with the first diagram I made. Make the diagram, read the narrative, make a better diagram, read the narrative again, and so on.

  • I think the thing I found trickiest with thing about creating an ERD from a problem description was piecing together the idea that entities can have multiple relationships to other entities. Like for instance maybe one entity has multiple relationships with multiple other entities, which has multiple relationships with even more entities. In our ER Modeling assignment (especially assignment 2), that took me the longest. Sometimes it felt like I was getting lost in a circle of relationships. I would advise doing a more complex/complicated example in class as a group so that when it comes to the exam or projects it seems simpler doing it by oneself.
    Have a great weekend!

  • 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.

  • I believe the most difficult part of ERD problems is finding which entities are connected and how to formulate the connection. Sometimes even differentiating separate entities can be difficult. Reading over the problem several times helps fully understand what entities are related and how they are connected.

  • The hardest part in creating an ERD is correctly identifying the cardinality of the relationship. Often times, the cardinality is hidden within the text and can be deciphered, but sometimes it is not. To help in identifying the cardinality in which it does not state it specifically within the text is to simply think it out logically. Read it in your head with different variations and then decipher what the cardinality is.

  • The trickiest thing about creating an ERD is figuring out which attributes belong to relationships or entities. This was very hard when attempting the UBER ERD we did for homework. The best way to choose is to weight whether an attribute affects more than one entity.

  • For me the trickiest thing about creating a ERD from a problem description is after I indentify all entities and their attributes, indentifying their relationships with their cardinality. There are many different ways people can create the same ERD. I think for me is just second guessing myself. But with more practice I think I’ll get better.

  • The trickiest thing about creating an ERD is when one entity needs to be connected with multiple entities, and they have different relationships. It takes long time to figure out the right anwser. The best way to solve the problem is carefully read the question multiple times, and do more practice.

  • The trickiest aspect of creating an ERD is figuring out the cardinality that connects the entities through their relationships. A good way to help understand the cardinality is to write out how the two entities relate to one another or actually say it out loud to help hear how they interact. This made it easier to understand cardinality for me. Another thing that helped me was watching the creating an ER Diagram video, this video shows you how to create an ERD using some software. Using the software and watching the video helped something in my brain click and helped me to understand cardinality better.

  • For me personally, I think the trickiest part is identifying the relationships between the entities. While creating ERD diagrams, I struggled the most with identifying the relationships because in some cases i’m not familiar with the process of operating or working the entity in real life, so I have noway of knowing if it’s one to one, one to many, many to many in that case. I would suggest reading the problem over and over again to get a clear grasp of what it is.

  • The most tricky aspect for creating the ERD from a problem description is ignoring the irrelevant information that is given in the problem. It can make the problem seem much more complicated than it actually is. I find that the easiest way to declutter the problem is the use of a highlighter, multiple if possible. This way you can color code the entities, attributes and the relationships. Doing this will make the writing of the ERD much more manageable.

  • i think the trickiest part about creating the ERD is trying to figure out what information could be important, and what information is important but can be left out. i think the only way to solve this is to not overthink it. if your ERD makes sense and relays the message the description asks for then you should be fine.

  • I think the hardest part about creating an ERD is determining the relationships and cardinalities of the entities. The wording in the description can be difficult to decipher sometimes when trying to figure out what entities are related and how, and whether their cardinality is one-to-one, one-to-many, or many-to-many. I think making a rough draft was what helped me the most. Instead of tying the entire diagram together, I would write down each segment piece by piece, such as only finding a relationship between two entities at a time. This helped me to better understand how to put the whole thing together. As for cardinalities, you really just had to read it thoroughly and think logically about which rule it falls under.

  • The hardest part of creating and ERD is figuring out the cardinality. It s confusing because each scenario can be argued because of overthinking the situation. For example Customer orders pepperoni pizza. Customer can order one or many pepperoni pizza, but pizza can only be ordered by that one customer. I guess some can argue that the pizza can be ordered by other customers but thats where the overthinking takes place because we aren’t talking about customer(s). We are only talking about one customer. I guess the advice I would give is to keep it simple.

Leave a Reply

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