 Get over here on the blackboard. I added a few examples. These are pulled directly from the book It shows you here the different types of relationships, right? Look at that one here a one-to-one relationship Can you see that this table here? You know links directly to a locker, right? So that means a member here a user or whatever a club member has exactly one locker Okay, assuming in a perfect environment, right? So we have over here the dashed line here You see as opposed to a solid line like this. Okay, the solid line means there's a very What do you call this one? Dependent I guess you can say that Okay, so they have a very strong connection. The solid line that and then the dashed line here is like Something is kind of weak and dependent. Okay, so locker can exist by itself a locker Doesn't have to be assigned to a member, right? If you think about that type of relationship So you see the dashed line before I for our example We're not gonna worry about in data in data line or the solid line We'll just use the solid line for our program. Okay The plus sign up here if look like plus it's not a plus It's a it's a if you think about your line you draw one single tick Line this on this side. It just means it's a one, right? So it's a one they have a one to one relationship. It's circle here It's an O a circle right and from this line here Indicates that it's also optional Right. So that means that a club member can have only one locker in this case You cannot have two locker. Okay, so that only one locker or the club member have may have no locker Okay, so that's why it's optional. You can have zero locker or at least but at most one locker It's with the other way around a locker can be assigned to only one club member Okay, the one here exactly only one or it may not be assigned to any member at all, right? So that's how you read it from this direction. You're referring to the symbols on the opposite side Okay, not the one that is next to it. Okay, so the next way is referring from the other side relationship so little bit figure out this is right, but Always refer to the other side with the line joins the other table. So that's what it means Over here. We have one too many and use the annotation as opposed to the M But it's fine. So if you re-film the club member side to the uniform side, we say One club member can have the O is zero uniform So they don't have to have a uniform is not required Or they can have many uniforms. Okay, so a team member for example like the Packers, right? They have two or three different types of cuz uniforms Okay, like that, but a uniform can only be worn by one member, right? Okay, or none it can just they have extra uniform and not being used. Okay, they have the company here is it many too many So the company here can have in many I don't know if you're with a part member part number is here But it doesn't matter right a company can have no part number or no parts or we're gonna have many No parts or one or many Okay, but the part number in this case cannot exist by itself. It must have For example, exactly one only one Well, I mean, I guess it could it could except because of this dotted line a part number can have Exactly only one company can be assigned to one company. It cannot be assigned to two companies more, right? So there's no oh, so there's not optional. It must be assigned to them, right? So that is how you read this diagrams here Down here is another one. So we have something that now we add a third table here To represent the many too many I mentioned earlier that When you have a many too many is it's easily drawn this way. It's understood. Okay, but when you actually get it down to the Physical design then it's not possible to just write your code like this in the program. It will not work and it won't work So that's why sometimes the ERD will go a step further by adding a junction table here So that they are somehow connected Okay, and then in the junction table you will see So this this part number here, even though they don't have the information here So we can say that this is also the primary key for each of these tables and then in the junction table You will see that it lists both the primary keys from both tables are joined together here Okay So this is a junction table It's very common this way when you could join two tables and a many too many Relationship and this has to do with the price right Because the price could change Based on a company like if you think about the parts for of a car, right? my dealership Okay, owns a car it could be a car and I say, you know, my dealership has a Tesla S3 The price of my company I said before they say it's 60k But the next dealer also has an S3 and they have a different price Right, so if you put a if you put a single price here That means all companies all dealership will have the same car the same price and that's not true, right? So that's why the only way to do that to make it work is they can have the same car But the price will be different Okay, so that's how you would map it like this and this is also how you actually design it using the Physical modeling as well next time we do it next week