ER Diagram Definition

ER Diagram

ER diagram is  called the entity relationship diagram or ER diagram for short this kind of diagram depicts entities which are essentially things and the relationships between them along with attributes of those

entities and relationships we use them extensively in business analysis primarily as a way to start thinking of modeling data you can't really understand what they are before you see it so let's take a look at the building blocks of an ER diagram and then assemble one together well actually make a very small model for udemy which I think we're all familiar with enough entities are the first component of any ER diagram and they're represented by rectangles like this as with just about any shape you see in diagramming we have entered some text into it to show what the entity represents by convention the name of the entity is a noun and it's also singular in number this doesn't mean that you can only have one indeed unity has loads of courses it's just the convention that we that we use ER diagrams also have relationships and they're represented by diamond shapes there's an example just as you would expect we also place text in the diamond shape that represents the type of relationship now here is a rule of ER diagrams a relationship is always between two entities two rectangles so let's put together our first picture that actually makes any sense ah great okay great here we have a user entity studying a course entity and that's coincidentally what you're doing right now however there is one missing piece in this diagram in order for it to be well formed and that is what we call cardinality let's display that on the screen and then talk about it okay so you'll notice that there is now an M next to the user entity and next to the course entity okay what do these mean in this case it means in short that any number of users can study any number of courses the M and n are simply variables that represent any whole number from 0 to infinity there are a couple other variants that we could put in here as well we could make the N a 1 and that would mean that a course can be studied by any number of users but a single user can only study one course alternatively we can make the M a 1 and that would represent there is only one user but she can study any number of courses generally we have three different types of relationships we have one-to-one relationships one-to-many relationships and many to many relationships one-to-one relationships are when there is a single instance of one entity which has a relationship to a single instance of another entity one-to-many relationships are when there is a single instance of identity which can have a relationship with many instances of another entity and many-to-many relationships are when there are many

instances of an entity that are related to many instances of another entity that's a mouthful alright since there are many users of unity and unity has many courses available and since users can study as many courses as they like this relationship is considered many to many let's illustrate this by adding another relationship between these two entities like this okay here we have a teacher's relationship that's new because instructors are also users here I've made this a one-to-many relationship using the assumption that only one instructor can teach any particular course I'm not sure if that's true or not but let's just make that assumption for purposes of this model I realized that getting cardinality right can be challenging so I'll give you a heuristic for it rule of thumb when you have two entities like user of course that are joined by a studies relationship ask yourself these Question get a user study multiple courses or only one if it's multiple then we want to put an end next to the course if it's only one put a one next to the course second can of course be studied by multiple users or only one if it's multiple then put an M next to user if only one put a 1 next to user and that's how we ended up with the cardinality rules that are in this diagram there is one more attribute that we commonly place in ER diagram so those are while they're called attributes they are essentially descriptions of you can think of them as adjectives you there they're their attributes of an entity or of a relationship and we represent them with ovals like this and we put the name of the attribute inside the oval shape and then we connect them to whatever entity or attribute they are an attribute of and here is an example of tying the old diagram together ok great so in this diagram we have the user entity on the left having the attributes of first name last name and email and we have the course entity on the right having the attributes of title description and category and then the rest of that diagram we are already covered besides cardinality I think the other common point of confusion that that newbie A's encounter is you know when is something at attribute of an entity and when is it an entity of its own well let's take a look at that title attribute of the course entity as an example the way that I think if the title is is that it's just text you know so somewhere in unity systems any course has a simple string of text associated with it that is called its title there just isn't anything more to know about the title of a course than the title itself and for that reason I consider it to be an attribute on the other hand let's say that we realize that well courses also have lectures associated with them we also know that lectures have a lot of attributes themselves such as a title and a time duration and probably other stuff well we also know that lectures are watched by users right so that's that's a new relationship that we have to think about all this complex description means that lectures should be an entity in their own right and by the way we would diagram them like this all right so you'll notice that we added a lecture entity in the top right has the attributes title and duration the lecture entity has a one-to-many has relationship with course meaning that a course can have a end number of lectures but a lecture can only belong to one course and it also has a many to many watches relationship with the entity user so that means that M users can watch end lectures so any number of users can watch any number of lectures that's pretty much the the ER diagram it's funny I actually used to hate these but just in the course of lecturing about them I've come to love them again so as you aged you'll be a career you'll probably experience the same kind of thing yourself but I hope that you'll love the ER diagrams.