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.
@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).
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
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?
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
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 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.
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?
" 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 )?
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.
+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.
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
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
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.
“The concept of albums is kind of going away” even more true now
weak entity- dependent on a strong entity to exist
string entity - can exist on its own
Thank you so much for this wonderfull clip , i finally understand weak entitys!
This video solves my confusion, thank you!
yeah me too!
@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).
Thanks a ton! Never came across a better explanation of weak entities..
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
Thank you, this was explained very well!!
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?
Glad you found it helpful!
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
Thank you for your clarification!
Thank you so much! Easiest to understand explanation on the Internet :)
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 =/
Thank you Brian.
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.
That helped a lot ! nicely explained :)
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?
" 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 )?
Very well explained
Hey Brian/guys, how are you?
I am trying to make an E-R diagram but i get confused easily. Can you help me to draw it? :/
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.
Thx buddy helped me alot
What if we keep the "ALBUM" entity as many, and put an identifier to it?
+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.
Thank you for the reply, really helpful. :)
The hero we don't deserve.
Well done!
really good lesson
Trying to explain this in a report is a nightmare.. :(
what is the difference between M and N?
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
very helpful
Thank you so fucking much.
Your weakest video TBH.
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