February 26, 2020
Entity Relationship Diagram (ERD) Tutorial – Part 1

Entity Relationship Diagram (ERD) Tutorial – Part 1

Hi, my name’s Taylor and I’m from Lucidchart. Today you’ll be learning all about entity relationship diagrams or ERD’s. We’re going to start off by discussing a high-level overview, and then together we’ll dive in
and build an example together, complete with entities, attributes,
relationships, and cardinality. By the end of this video, you’ll be able to build an entire Entity Relationship Diagram from scratch. Have you ever wondered why you get an error message telling you that your ideal Twitter handle is already taken? Or how Amazon can keep track of so many different orders, and customers, and products? The answers to these questions lies within the creation of a database, which in other words, is a collection of information that is organized so data can be easily stored,
managed, updated, and retrieved. Now there’s a lot of moving information in a database, and understanding how the many elements of a database interact with each other
can be difficult to grasp. Engineers need a visual way to understand how all the separate elements are related to each other and how they’re working together. To show this, they build Entity Relationship Diagrams. So let’s talk about how you’re going to
make these ER diagrams. You can draw them out with pen and paper, but it’s going to be way easier for you to use a diagramming tool. Today I’m going to use an easy-to-use tool called Lucidchart. And you can too, for free actually, by clicking on the top right corner here you can access Lucidchart’s website, enter your email address, and have a free account in just a few seconds. That way you can follow along with me and continue building your own ER Diagrams as well. Before we can create an actual ERD, we need to better understand the individual components of the
Entity Relationship Diagram. And this is going to start with entities, which are an object such as a person, place, or thing to be tracked in the database. For example, in the case
of buying something on Amazon, let’s say a Snuggie, an entity could be a customer, an order, and lastly, we can’t forget our Snuggies, the product. Now each one of these entities is going to have what we call attributes, which are various properties or traits. In this case, under the customer entity, we have a customer ID, first name, last name, street, city, zip, and phone. It’s important to remember that the entities in your database will be the rows, and that the attributes in your database will be depicted as the columns. Now we have the different entities
and the different attributes on the screen here, but now let’s talk about the relationships that exist between these different entities. The relationships describe how these entities will interact with each other, if at all. And you do that by drawing a line in between them. So when I draw a line in between
these particular elements, I’m showing that there is some sort of interaction or connection in some way. Now that we have our relationships in place, you’ll see some funky notation attached to these lines. This, in fact, is called the cardinality, which further defines the relationship in a numerical context, particularly within minimums and maximums. So for example here on this right side, you can see some different types of cardinality we have in ER Diagrams. We have one, many, one and only one, zero or one, one or many, zero or many. Now don’t be afraid if this isn’t making sense quite yet. We’re going to walk through some examples that’ll help you understand this perfectly. So let’s talk about the relationship and the cardinality that exists between a customer and the order. Now the best way to do this is to think about it logically. We have to think about… what is the minimum number of orders that a customer could have, and what’s the maximum number of orders that a customer could have? So let’s start with minimums. What is the minimum number of orders that a customer could have? Well, a customer could exist, but he or she could have zero orders. So to show that over here, we’ll have that zero sign. Now we have to think about the maximum. What are the maximum number of orders that a customer could have? Well as you probably already know, a customer can have infinite orders. In the case of Snuggies,
you can never just have one Snuggie. So to show that, we’ll use this zero or many crow’s foot notation. Now let’s talk about the minimum and maximum relationship between orders and customers. So we ask ourselves the same questions. What is the minimum amount of customers that an order may have? And what’s the maximum number of customers that an order may have? Now a specific order can only have one and only one customer. Or you can imagine the confusion that could come if the same specific order had lots of customers. So in this case, there can be only one and only one number of customers to an order. And we can show that using this sign here. So now let’s talk about the relationship or cardinality between orders and products. So we’ll ask ourselves the same question. A certain order can have how many products? Well, for an order to exist it has to have one product. But a lot of different products can be comprised of that order So to show that on our diagram, we’ll change this notation. Now we ask ourselves that question in reverse. A product can be a part of how many orders? Well, a product could be a part of no orders. But it also could be a product of many orders. So we’re going to use this zero or many notation on our diagram. So now you’ve built your entire ER diagram. And we’ve built something small here, but now you have the foundation and framework that you need to build complex, complete Entity Relationship Diagrams. Although this can seem a little bit overwhelming at first, just be sure to walk yourself through that logic, and you’ll be able to build entire, complex ERD’s. You’ll also see on this diagram that there are some unfamiliar object such as PK and FK, which refer to primary keys and foreign keys. Something that we’re going to be covering in a video coming soon, so stay tuned. Additionally, if you need to actually have this diagram to be database-ready, you can use the import and export features of Lucidchart to have all of that done automatically for you. Using the export feature, you’ll have that code automatically generated for you and exported to the database management system you’re using. Thanks for watching this tutorial on ER Diagrams. Subscribe to our channel below to get access to more helpful videos and tutorials. Leave comment as well if you have any thoughts or questions on ERD. And don’t forget: sign up for a free Lucidchart account by clicking on the link in the top right corner. Thanks!

100 thoughts on “Entity Relationship Diagram (ERD) Tutorial – Part 1

  1. Awesome. Thanks for the helpful explanation. It's a lot more helpful than lectures and power point slides. We use Visio in class, but the app you use looks more simple and easier to use.

  2. Just a quick errata for this tutorial. A purchase is a transaction. Think of it transferring zero money to another bank account, that isn't allowed as it is a bad practice. So the correct ERD cardinality should be "one or many". To be consider a costumer you should at least have one order and the order should at least have one product.

  3. Actually, a true ERD is not a direct 1 to 1 mapping to a table as explained here. As an example an Entity can be mapped out to more than 1 table and in fact may not even be a table. That point is missing in this simple video. However, if you want to go with the assumption that your 'entities' are going to be tables than sure this information is fine.

  4. Great job explaining! I have interviews coming up soon and need to brush up on relational database concepts. This has been very helpful.

  5. Hey!! Thank you very much!! Really it was a great video, you were able to explain it with the best (and easy) way… I will be attentive on your new videos. Thank you!!

  6. شرح متكامل عن مخطط قواعد البيانات ..

    خذت فكرة عامة لاكن الفكرة الي عندي خابر ان التمثيل على المخططات يكون على شكل مستطيل للكيان و معين للعلاقة ودائرة للخواص

    هالشي ضيعيني نوعا ما لاكن جودة الشرح جدا ممتاز وسهلة تاخذ الفكرة على الماشي

    اتمنى يكون لها شرح بالعربي(دبلجة)

  7. Lucidchart, pls explain how one product can have no order? Only when a customer places an order, then only product will get delivered. Pls explain my ambiguity

  8. Can you do a video on creating a complicated ERD from the actual business rules? As if a company hired you to create a database and they give you a rough over view of the entity relationships. I am a student at SUU and would appreciate the extra practice very much!

  9. This looks more like a relational schema diagram but not an entity-relationship diagram. Where are the relationships?

  10. great video, i have a question. why I see there are other forms of ERD, shapes like square, oval, and diamond. is that another form than explained on video?

  11. Perhaps a stupid question but I am trying to "follow along" and can't find/open the same tutorial on the screen. Is that just not a possibility? I've created an account and can get to other documents and such just can't find the one in the video

  12. I like the energy presented at the beginning of the video, I like the confidence too.. Seems like i'm gonna enjoy this

  13. Great video. If one knows what he is talking about it takes minutes, otherwise it takes hours and still, you feel it sucks.

  14. Can someone make it clear? what is the difference between '1 ' and '1 and only 1'? If a relation edge is set to be '1' it can't be anything except '1' which is precisely as '1 and only 1' … so what do I miss here?

  15. but there is no attribute connecting orders and products, this database design is wrong xD you need an order_id in products. n00bz

  16. Shouldn't the order be one or many to customers? From what I understood, if there is zero orders it wont make someone a customer, there has to be 1 or many orders to make a customer. Please don't judge. Help me with this.

  17. OMG! this was absolutely perfect in every way! thank you! Idk why college professors can't just keep it clear and simple like you did here.

  18. Hello? I love this tutorial, but may I ask, what is the name of the software you were using in this tutorial?

  19. Doesnt make sense…

    In some cases a company wouldnt have this "customer" if it doesnt even had at least 1 order… Also an order might have more customers because huge companies sometimes sharing the developing costs…

  20. are rows in a table "Entity" or "Instances" my teacher told that rows are Instances but your video telling it is entities

  21. I think the order should be thought of in a single order. A single order can have many products. But just because a product is part of many orders does not mean that you document it that way. Your order is referring to a single order.

  22. Taylor although this video is old in future videos you should let people know that this ERD is a crow’s feet diagram.

  23. Database Conceptual Design ER and EER Modeling Tutorial PDF https://www.article.education/tutorials/database-conceptual-design-er-and-eer-modeling-tutorial-pdf/

  24. I was sitting and when I was making my legs comfortable my last finger of my foot touched subscribe button

  25. Hi there. I'm a bit confused about the entities in this video. At 2:16 it says that entities in Database are rows, but as far as I know, the Entities from the Diagram are the Tables from the Database. So which of this two is correct?

  26. ive seen some using the rectanglem triangle and ellipsis version of doing ER diagrams, why is this one different? Ar there two ways in which you can draw ER diagrams?

  27. I have a problem with your definition of a database. It is in the name DATAbase. It's an integrated collection of stored DATA that is centrally managed and controlled.

    NOT INFORMATION, information is the product of meaningful data that is collected!

    Simply it is that INFORMATION reveals the meaning of DATA

Leave a Reply

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