I'm struggling with a question, I'm just trying to figure is it even valid , if not where does it violates the rules of a weak entity relationship, I think it's not valid because how can a weak entity have n weak entities.
so is it valid ?
Best Answer
You can combine B and C to one new key that is used in A and also have a key from B directly, it is no problem as you have two keys.
If you don't add something new to the key you would have the same key, but referring to different entities A and C.
Ok as long as you don't try to 3NF or higher, it is at least possible but redundant.
so C being weak can take n instances of A which is also weak and attached to the same owner?
Your relationship T is wrong. A weak relationship is always 1 to n or 1 to 1, never n:m. The essential part is that the weak entity has to know which key it relates to, see http://infolab.stanford.edu/~ullman/fcdb/slides/slides2.pdf, so if it where a 1:n , it is possible.
If you are running a video rental store, then whether or not your children eat depends very much on a video appearing in as many reservations as possible.
In your example, RESERVATION is a weak entity which relies on both the FK to CUSTOMER and the FK to VIDEO in addition to a further attribute, perhaps date, to comprise its primary key.
It is not possible for a M:N relationship to be supporting for a weak entity (although the intersection table which resolves a M:N relationship can be a weak entity). This is because a supporting relationship needs to be to a particular entity object. A set of entity objects can't identify something in relational algebra.
It is possible for a 1:1 relationship to be supporting for a weak entity, although this would be rare "in the wild". I could imagine it coming up in the context of situations that would typically be 1:M, but where there is a business rule that restricts the child to one at a time.
Depending on how much you briefed your problem statement, it can be stated that:
Trainer is a strong entity (it has an ID)
Neither Client nor Membership Plan seem to be weak or strong entities.
They both could be considered strong entities provided that a primary key is defined on them*; e.g. Client.(Name, Phone) and Membership Plan.("Beginning Date", Duration)
In your Chen diagram, Meets entity should have both ends total participation, but there's an arrow between Trainer and Meets?
Other than that, it seems to be alright.
* A strong entity is defined as having a key that does not depend on any other key; a weak entity as as having a key that depends on a foreign key. E.g. Order has a primary key order_id which is independent, and that makes it a strong entity, whilst Order_Detail has a primary key order_detail_id and unique key order_id, line_no, which makes it a weak entity since order_detail_id does not provide a meaningful independent ID, and the unique key depends on Order table. See weak entity entry in Wikipedia.
They're independent from other entities, so they are candidates for being considered strong entities provided that they have a primary key, which is not known if they have and is not clear if they could in the definition.
Best Answer
You can combine B and C to one new key that is used in A and also have a key from B directly, it is no problem as you have two keys.
If you don't add something new to the key you would have the same key, but referring to different entities A and C.
Ok as long as you don't try to 3NF or higher, it is at least possible but redundant.
Your relationship T is wrong. A weak relationship is always 1 to n or 1 to 1, never n:m. The essential part is that the weak entity has to know which key it relates to, see http://infolab.stanford.edu/~ullman/fcdb/slides/slides2.pdf, so if it where a 1:n , it is possible.