Hey, everyone, welcome back to part 10 of topic four in our database class. And in this video, I'm going to focus on describing different types of weak entities in the context of the entity relationship model. So an ID dependent weak entity then is a weak entity whose primary key consists at least in part of the primary key from the related table. So this is a way of enforcing its weak entity status. And the best way to see this is just to or to understand this is just to see a diagram. So we'll look at this example here. Here we see some examples of on the left of an ID dependent weak entity. One thing that will point out immediately for your contemplation and consideration is you will notice that the corners here are sharp. Right, is there a nice sharp 90 degree corners on our rectangles that represent the entities, but down here we have rounded corners. So the use of rounded corners in a diagram in an entity relationship diagram is a visual way of conveying that this is a weak entity. So weak entities are going to have these rounded corners are like a rounded rectangle to where as strong entities will have sharp corners. So we have these subtle differences in the entity rectangles that visually tell us whether or not this is a strong or weak entity. Right, so with that in mind we can immediately say this building entity is strong this product name entity is strong and this textbook entity is strong. I should say this product entities are where as these entities down here are all weak. And if we didn't know anything else we could tell that by the fact that they use rounded corners. Okay, now back to this notion of ID dependence again we're focused on the weak entity which in this case is an apartment now think about this outside of a database world most of us are familiar with what an apartment is. A self contained room or set of rooms within a larger building that serves as a housing unit. So what that means then is that for an apartment to exist in the real world it must be a part of a larger building. And this is one of those scenarios that works very very well to convey the notion of a strong or a weak entity like it's possible for a building to exist that does not contain any departments any apartments. Right, but it is not possible for an apartment to exist without an associated building. So that is in order for a apartment to exist. It's associated building must already exist. And in the context of strong versus weak entities this means that we could not add any information about new apartments to this apartment table. Unless there was already an associated building up here in the building table and that association in this case is the connection between the primary key which is building name here and part of the primary key down here. So this is an example of an ID dependent weak entity because in order for a row to exist here we must provide a building name because it's part of the primary key. So this is never ever ever allowed to be null it is required it's part of the primary key. So this mechanism enforces the weak entity status of the apartment table. I cannot add rows to this apartment table unless there's already a matching building name up here. This is an ID dependent weak entity. Every row in this apartment table depends for its existence on the prior existence of a building. So once we know the building name we can identify the specific apartment with say an apartment number. So maybe you currently live or have lived in the past in a big apartment complex and it might be like building be apartment 14 right. That's how we can uniquely identify that apartment within the broader apartment complex. So this is an ID dependent weak entity because it's identifier it's key consists in part of the primary key from another table. So in order to exist apartment an apartment must already be associated with with an existing building same thing here in this product table. So we have products they can exist on their own this is a strong entity, but if I have versions of the product let's say it's a software product where you can have I don't know windows 11 windows 10. Office 365 whatever so like Microsoft office and windows have been around for since the 1990s, but we have different versions of them. And we can keep track of that using this sort of design where we have a strong entity here for the product like Microsoft Windows Microsoft office Microsoft Word whatever you might want to use. And then we have this weak entity down here and it is a ID dependent weak entity again we can tell because part of its primary key is the primary key from the related table. And it's possible to add any records here for say a new version of a software program unless that software program that software product already exists up here in the product table. So with this so textbooks have different additions. So the textbook would be like database concepts and then down here at the title and the addition number to record information about that specific addition like how many pages are in that addition what is its copyright date etc. So again these are all ID dependent weak entities because in order for a row to be added to any of these weak entities we need to have a part of the of the primary key needs to be the primary key from the parent table which in this case is a strong entity. So if we have an ID dependent relationship. So if we have a strong entity in a weak entity we call that an identifying relationship. So identifying relationships are those that are ID dependent. Non identifying relationships. Between strong and weak entities are those that are non ID dependent. So graphically when we're doing our entity relationship diagrams from this point forward we will represent our ID dependent or identifying relationships using a solid line. So we're using the two associated tables or entities right non identifying relationships will be represented using a dashed line. And this is also used as it says here between to show the relationship between two strong entities. So again the best way to learn these is just to see examples which is what we have here right so here sorry we have two examples well it's it's one example two different ways of modeling the same thing. In this case it's the relationship between an auto model and a specific vehicle that is an instance of that model. So you might have for example I don't know like a Toyota Camry right or I don't know like a Honda Accord. Okay so that is the model and then you're going to have specific vehicles which are actual cars that people can buy and drive around. And if we have an ID dependent database design to record these concepts we would have something like this so manufacturer and model. Are the primary key from the related. Strong table right and then we add an additional column to our composite key here so that we can uniquely identify every individual vehicle. So this again is ID dependent because the primary key of the parent table is a part of the primary key of our weak entity vehicle. So that means naturally that we cannot add any rows of data to this vehicle table unless a corresponding manufacturer and model already exist up here in the auto model table. Now exactly the same relationship is modeled over here. As a non ID dependent we entity. So you can see in this case our primary key. For auto model is manufacturer and model and those columns. Live down here just as regular foreign keys in our vehicle table. Now because these are weak entities. Put a little FK here so we can note that those are foreign keys. So this is a foreign key. This is a foreign key it's like a composite foreign key. But because it is a weak entity we know that weak entities are those where we cannot add a new row to the table unless a corresponding or matching row already exists in a related table. So in this case because this is a weak entity we know immediately that these foreign key values must be required. If they were null it would not be a weak entity because we would be able to add rows to the table even if a corresponding manufacturer and model did not already exist up here in our auto model table. So when we have a non ID dependent weak entity we're going to have some sort of separate key in this case a vehicle identification number and the primary key from the related table will just serve as a regular required foreign key connection. So do note that in all of these cases again we have rounded corners. To represent weak entities so it doesn't matter if it is a non ID dependent weak entity like what we see here or an ID dependent weak entity like we see here will have rounded corners to indicate that it is a weak entity. However, the ID dependence status of its ID dependence is shown by whether or not we use a solid or dashed line to interconnect the tables. So with an ID dependent weak entity like what we see here remember the key part of the key is from the related table. We use a solid line to visually indicate that this is an identifying relationship that is an ID dependent relationship interesting. Whereas in the case of non ID dependent weak entities or in a relationship between two strong entities we use a dashed line for our relationship line to indicate its status as a non identifying or non ID dependent relationship. So rounded corners is a new thing those are weak entities and that whether or not the relationship line is solid or dashed is a new thing. If it is solid it means that it is an identifying relationship if it is dashed it means it is not identifying.