Thanks for the great video! I had some questions, though... For each table, why don't you have any foreign keys on the many sides? The mandatory side must donate its key to the many side. A professor told me that entities and attributes are the same thing, not like a hierarchical thing. I was super confused. Aren't attributes like the sub-characteristics of what entities have? For example, I said an Employee table will have EmployeeName as one of its attributes. But he said Student table having an StudentName attribute is actually a Student table having a relationship with another table named "StudentName" that has a whole list of available names in the whole world. But what if I only keep the data that I typed in (not referring to a whole infinite list of names out there)? I'm not even sure why I had to think of the whole list of dropdown list of names... The professor also mentioned that associative entity can only happen for a one to one relationship of a many to many relationship. For example, if many customers can visit the seller many times, even though it is a many to many relationship, it cannot become an associative entity based on Set Theory. But is every single visit, even when the visit happened twice within an hour, is that really an identical visit? Yes, the CustomerID and SellerID will be the same if it is a composite primary key. But each visit by nature must always be a different visit, and that's why there should be a surrogate key, and then the primary keys can exist as foreign keys in the associative entity in that case, wouldn't it? Also, the professor mentioned that technically I CANNOT have a surrogate primary key in my associative entity because it's an associative entity that is supposed to be a creation of two other primary keys from the other tables. But you said having a surrogate key as the primary key is possible. Then, is having three primary keys available? If it's a surrogate primary key, that means I do not have to have it as a composite primary key with the other primary keys. But Another thing was, I thought having a surrogate primary key and then having the other primary keys from other tables as foreign keys would still be available in an associative entity, but he said if that happens, it is NOT an "associative entity" anymore, regardless of the fact that it was a many-to-many relationship, and despite that fact that it needs a record of an attribute that is something that happens only when the two entities meet and creates a certain result. But isn't the associative entity created so that we have a certain attribute that we wanted to record, say, when Employee table and Certificate table has a many to many relationship, we will squeeze in an associative entity table titled ""Completed" in between the two, and record the "completion" as an attribute of the "COMPLETED" table? If it is NOT an associative entity even when we were recording the instances of "completion"s, and if that was actually just able to be recorded as a normal entity, the meaning of "completion" as a joint event of when Employee meets Certificate and reaches a specific event of "completion" becomes meaningless as a joint event. It's just another list of records. Sorry for the long comment, but I'm just so confused... It would be great if you could answer these questions. Thank you.
I just wrote up a response to all your questions and it didn't post. In essence, the idea is that you professor is wrong on many accounts. Here are a few things I highlighted: 1) Entities and attributes are not the same thing. An attribute is a characteristic of an entity. 2) Associative entities are made because a relationship and exist regardless of the attributes in it. If there is a many-to-many relationship or ternary degree relationship, an associative entity is always created regardless of how the attributes make of the PK or what not. 3) You can have more than two attributes make up the PK. You can use a surrogate key or not. This doesn't make an associative entity no longer an associative entity. 4) There is always only one PK per table; however, this PK could be made up of more than one attribute. Sometimes it makes sense to add date to the other attributes to make every record unique or just use a surrogate key. 5) Attributes of the relationship will become attributes of the associative entities.
Very well presented . Thanks for sharing.
Thanks for the great video! I had some questions, though... For each table, why don't you have any foreign keys on the many sides? The mandatory side must donate its key to the many side.
A professor told me that entities and attributes are the same thing, not like a hierarchical thing. I was super confused. Aren't attributes like the sub-characteristics of what entities have? For example, I said an Employee table will have EmployeeName as one of its attributes. But he said Student table having an StudentName attribute is actually a Student table having a relationship with another table named "StudentName" that has a whole list of available names in the whole world. But what if I only keep the data that I typed in (not referring to a whole infinite list of names out there)? I'm not even sure why I had to think of the whole list of dropdown list of names...
The professor also mentioned that associative entity can only happen for a one to one relationship of a many to many relationship. For example, if many customers can visit the seller many times, even though it is a many to many relationship, it cannot become an associative entity based on Set Theory. But is every single visit, even when the visit happened twice within an hour, is that really an identical visit? Yes, the CustomerID and SellerID will be the same if it is a composite primary key. But each visit by nature must always be a different visit, and that's why there should be a surrogate key, and then the primary keys can exist as foreign keys in the associative entity in that case, wouldn't it?
Also, the professor mentioned that technically I CANNOT have a surrogate primary key in my associative entity because it's an associative entity that is supposed to be a creation of two other primary keys from the other tables. But you said having a surrogate key as the primary key is possible. Then, is having three primary keys available? If it's a surrogate primary key, that means I do not have to have it as a composite primary key with the other primary keys. But
Another thing was, I thought having a surrogate primary key and then having the other primary keys from other tables as foreign keys would still be available in an associative entity, but he said if that happens, it is NOT an "associative entity" anymore, regardless of the fact that it was a many-to-many relationship, and despite that fact that it needs a record of an attribute that is something that happens only when the two entities meet and creates a certain result. But isn't the associative entity created so that we have a certain attribute that we wanted to record, say, when Employee table and Certificate table has a many to many relationship, we will squeeze in an associative entity table titled ""Completed" in between the two, and record the "completion" as an attribute of the "COMPLETED" table? If it is NOT an associative entity even when we were recording the instances of "completion"s, and if that was actually just able to be recorded as a normal entity, the meaning of "completion" as a joint event of when Employee meets Certificate and reaches a specific event of "completion" becomes meaningless as a joint event. It's just another list of records.
Sorry for the long comment, but I'm just so confused... It would be great if you could answer these questions. Thank you.
I just wrote up a response to all your questions and it didn't post. In essence, the idea is that you professor is wrong on many accounts. Here are a few things I highlighted:
1) Entities and attributes are not the same thing. An attribute is a characteristic of an entity.
2) Associative entities are made because a relationship and exist regardless of the attributes in it. If there is a many-to-many relationship or ternary degree relationship, an associative entity is always created regardless of how the attributes make of the PK or what not.
3) You can have more than two attributes make up the PK. You can use a surrogate key or not. This doesn't make an associative entity no longer an associative entity.
4) There is always only one PK per table; however, this PK could be made up of more than one attribute. Sometimes it makes sense to add date to the other attributes to make every record unique or just use a surrogate key.
5) Attributes of the relationship will become attributes of the associative entities.
thanks sir keep going