Unfortunately, the only reason I wanted to watch this video was in trying to figure out participation and cardinality in ternary relationships (that is, which ends are minimum 0 or minimum 1, that is, mandatory or optional), and he basically skipped over that because "it is a bear". :-(
why are we always focusing on a given instance of two entities to find out if they are many of the third, if is many in all of them, cant we say multiple instances of these two entities goes into many of the third? sorry I'm having a hard time understanding the way to approach this diagram.
why is the cardinality to supplier many? I thought if you're looking at 1 car and 1 part, then that 1 part for that car can only come from 1 supplier no? Like you can't have half the steering wheel coming from supplier A and the other half from supplier B. Could you please clarify this for me? will really appreciate :)
Good question. You are absolutely correct that for a specific individual steering wheel, that part can only come from a single, specific supplier. HOWEVER, it is possible that Company X sources the steering wheel for Vehicle Y from more than 1 supplier, such that some specific vehicle IDs get their steering wheel from Acme and others get them from WheelCo, etc. Make Sense?
+Wai Lok Poon Replacing a ternary relationship with 3 binary relationships does indeed lose information. For example, you can say a given supplier supplies a given part, and that given part is used in a given car, and that given supplier supplies a car, but you can't say for sure that a given supplier supplies a given part to a given car.
what if only one entity type A participates with many in a ternary relationship while the other two only participate with 1? Then could you model the relationship in the table of A?
+Cookie Monster I don't use or know MySQL Workbench, but its EER model appears to be strictly binary, which means that relationships aren't explicitly modeled and direct representation of a ternary relationship is not accommodated. That said, there are two workarounds: 3 binary relationships (A-B,B-C, A-C), although some information is lost there (see my response to Wai Lok Poon below) or you can create a table for the relationship with a primary key that is the concatenation of all 3 participating entities PKs (A#B#C#) and that has an M:N relationship to all 3 participating entities. This is the closest approximation, although you lose the ability to represent all possible ternary cardinality states (1:1:1, 1:1:N,....N:M:P), which doesn't typically make any practical difference.
