Hey, everyone. Welcome back. In this video, part nine of topic four in our database class, I'm going to describe the difference between strong and weak entities in the context of the entity relationship model. So when we create these entity relationship diagrams, we have these various entities that collectively represent the tables in the database and we have the relationships between them, the cardinalities and so on. Among all of those entities, we can classify each one as either being weak or strong. So the difference between a weak and a strong entity is simply this. Can we add new rows of data to that entity or to that table without their already being some kind of matching row in another table? So if an entity is weak, which is described by this major bullet point, what that means is that we cannot add any rows to that table unless matching or related rows exist in another table. Any entity that is not weak is by definition strong. So with a strong entity, we can add new rows to the table regardless of whether there are any matching or related rows in some other table. So that is the instances of a strong entity can stand or exist on their own in the database without having any sort of connection to or reliance upon another entity for their existence. And also note that it's perfectly feasible for instances of a strong entity to exist independently in a database, meaning that they don't have any relationships. So I can have an unrelated table that would be a strong entity. And I can also have entities that are related to other tables, but are nevertheless strong because it's possible to add rows to those tables. They're needing to be some sort of matching or related row in another table. So strong versus weak entities, let me very briefly switch over to our now very familiar employee's database that we've been tinkering with. And with that notion in mind of strong versus weak entities, we can now look at this simple database diagram out here and ask ourselves which of these entities is strong and which of them may be weak. So remember a strong entity can exist in the database without the necessity of a relationship. So if I look out here and I ask myself this question, like could I add a new row to this skill table without there being any matching rows in another table? And the answer of course is yes, I could have a new skill, right? Maybe my new skill that I want to measure for my employees is there. I don't know their ability to type how fast are they at typing? Okay. So I could add that as a new skill to the skill table without there being any other rows in a connected table that are associated with typing. So a skill table here would be a strong entity. Similarly, we could add departments, right? So we can have additional departments. We can add as many as we need without there being any related employees. So department is a strong table, right? Project is a strong table, right? I could add new projects to this project table without to there being any related rows anywhere else. So then we can take a look at some of these other tables like employee skill, right? In this case, in order for a row to be added to this table, there must already be a matching skill ID in the skill table down here. So then we can see that because this is part of the primary key, right? And it's also a foreign key which connects us down here. So that means I cannot add a new record to this employee skill table unless the skill ID for that new record already exists down here in the skill table and the same applies to the relationship between employee ID and employee ID over here. So employee skill is definitely a week. We can't add any new rows to the employee skill table unless we already have appropriate matching rows here and here. And the same thing applies with this table here, right? We need to have existing projects and existing employees in the related tables in order to add new rows to this table. So this would be a week entity as well. And then we have an interesting question and that is, is the employee entity strong or we? Remember, the difference here is can I add rows to this table without there being some kind of matching value in another table. And so the answer as to whether employee is strong or weak will depend upon department ID. That is, if they, if null values are not allowed, then employee is a week entity. Because the only way for me to enter a new row, like a new employee into this table, would be to provide them with a department ID and that department ID must already exist down here in the department table. So the basic idea of weak and strong entities is simply that is it tool to add a row or to have rows exist in one table without there being some kind of matching row that already exists in another table. If the answer is yes, it's a strong entity. If the answer is no, it is a week entity, right?