@6:00 In the case of 1:N without (weak entity), it does not make sense to me to have the same song with 37 different Songs# (assume that all songs are the same, i.e. same record/version).
Mina Ise: Yes, if an album couldn't exist without songs (a reasonable assumption), then album participation should be mandatory and the line should be doubled. While this is not an issue related to understanding weak entity modeling, it is a good observation.
If you go with M:N, you will wind up with a table that contains album attributes for all albums, one that contains song attributes for every song, and one that records every instance of every song's being in each album. If you want to be able to answer a question like, say, "which song or songs have been in the most number of albums?", then you will need that M:N arrangement. If you have a physical album collection and only care about songs in the context of albums, weak is the way to go
If you model using a weak entity, songs are uniquely identified only within the context of a given album. If you go with M:N, each time a song appears on an album will be uniquely identified. Sometimes you want that, sometimes you don't. Hope that is of some help.
Hi! Thank you, it was helpful. Just one question - shouldn't the line from the album be "double"? As in my opinion an album can't exist without songs... am I wrong?
+Ogulcan Kayhan That's perfectly fine, although different and no longer a weak entity design in that case. You would then keep track of and uniquely delineate (by design) every instance of every song/album pairing across the entire domain. Sometimes you want that, sometimes you do not.
Hi Brian Great video. My background is an UG degree in Economics, but still your video was very comprehensible. Specially the point was made clear by illustrating an example where 37 uniques ID's all pointing to one song . Thanks
Thank you for your previous answer! Let's suppose we have an entity called STUDENT and an entity called ADDRESS. In my opinion (maybe I'm wrong) there's no need for the address to have a specific ID since it's linked to the STUDENT. However if we try to put the cardinality of it we would end up with STUDENT 1 ------- ---------- 1 ADDRESS... So since it's not a 1 - n cardinality there's no weak entity but... what about address that doesn't have a primary key? that's a little hard to get
If the student-address cardinality is 1:1 then just combine address with student. There is no need for two entities. If address is a multi-valued entity/entity set, then model as a weak entity. In neither case would you want to have a PK for address. Does that make sense?
something I didn't get was when you said that it doesn't make sense to have multiple instances of the song Purple Haze in different albums with different ID's. Because you were talking about a relationship of 1 album to n. Since it is just one it didn't make sense to me when you gave your example where multiple Purple Haze songs would be in 37 albums =(
If we didn't use a weak entity approach, the relationship *would* be many-to-many. In that case, we'd be obligated to treat as distinct and to track every time the original studio Purple Haze showed up in a different album. You'd be treating every occurrence as unique. That could be something you wanted to do, but probably doesn't get you anything here. Imagine an online shopping cart scenario - without a weak entity approach, you'd need to create a unique key every time any of the products you sell was ordered by someone. You don't need that. All you need is unique keys for each order and to be able to know which orders have what items in them. You do this by ignoring the fact that the relationship is really M:N and instead uniquely identify the items ordered only within the context of the orders in which they appear.
Chris Trader M and N both just indicate some number greater than 1. We use two different letters to make clear that the values are not necessarily the same
I would always use a many to many relation in this case, as a weak entity model would have the same song over and over again, right? I don't understand/can't think of when you would use weak entity types, which is the problem i have =/
" If you go with M:N, you will wind up with a table that contains ...." Brian Would not the same thing happen if it was a 1:N relation (& also if without a weak entity )?
Hi Brian Great video. My background is an UG degree in Economics (ANU), but still your video was very comprehensible. The point was made specially clear by illustrating an example where 37 unique ID's all pointing to one song . Thanks