6

I have a problem statement (briefed),

Database for a Fitness Club -

Client's Attributes: Name, Address, Ph. No.

Membership Plan's Attributes: Beg. date, Sub. Fee, Monthly Fee, Duration

Trainer's Attributes: ID, Name, Salary

Relationship-Types: Client is 'Enrolled In' a Mem. Plan, and Client 'Meets' Trainers

Enrolled In: Client has total participation while Mem. Plan does not.

Meets: Client & Trainer, both have total participation.

By Meets, it means, a Client entity attends a session guided by a Trainer entity.

So, Client & Mem. Plan are weak entity types & Trainer is a strong entity type.

When converted to an ER diagram, Client & Mem. Plan are related to each other, and Client is related to Trainer.

Is it a possible to have such an ER diagram or is there another way to rectify the same?

Edit: This ER diagram represents what I think it should be (without partial keys) and consider arrows in diagram as straight lines connecting two blocks/shapes.

enter image description here

Feel free to correct me if I'm wrong anywhere.

I also have an entity 'Workout Session', which has a relation with Trainer. A Workout Session is conducted by one Trainer only, but the problem states to keep data of only Trainers which a Client meets, not the Sessions he/she attends. But since that wasn't related to the question I needed to ask, so I didn't add that part.

I think there is no single attribute of either Client or Membership Plan which I can use to distinguish their respective entities uniquely, so I think Client and Membership Plan are weak entity types.

I have provided as much details as I can as I can't disclose the complete statement due some reasons.

Improve this question
2
  • 5
    @PalashV: The characteristic of a weak entity is not that you need multiple attributes to identify it, but rather that you need a foreign key (a reference to another entity) as part of the fields that identify the weak entity. A weak entity cannot exist without being linked to another entity.
    – Bart van Ingen Schenau
    Commented Mar 25, 2016 at 9:07
  • If in case there is a situation in which any weak entity is related to an other weak entity with total participation then it is better to club them both and represent them as a single entity.
    – Ubi.B
    Commented Nov 2, 2019 at 2:33

2 Answers 2

Reset to default
4
+150

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.

Improve this answer
0
2

Client and Trainer are both strong entities with a many to many relationship catagorised by the weak entity Meeting.

Membership Plan : seems like a weak enitity with one to one relationship with Client. But I would add a primary key and make it a strong entity with a many to one relationship to client. This enables historical membership plans etc

Current Membership Plan : weak entity with one to one relationship with Client. Indicating the currently active membership plan for the Client.

Edit.. you added the diagram..

It looks like your Membership is more what I would call MembershipType. Ie the list of plans available to buy. Whereas the Membership Plan related to the client should be the instance of the MembershipType they purchased.

Start date for example will vary per client for the instance.

To answer the general question. 'Can a weak entity be related to another weak entity' I would say No. A weak entity has no primary key of its own but does have a foreign key which is linked to the PK of another entity. Thus if you have two weak entities with the same FK id they are infact related to the same strong entity rather than each other.

Improve this answer
3
  • But how can Client be a strong entity? There can be 2 people with same name. There can be 2 members from a single home. I mean, can you explain it more how is it possible? Since what I've only learned is that an entity is strong if it has an attribute which identifies its entities uniquely, otherwise the entity is weak.
    – PalashV
    Commented Mar 25, 2016 at 9:29
  • You add a ClientId and print it on their membership card. After all conceptually two people with the same name are still two people. Presumably this is what you are doing with Trainer and employeeId?
    – Ewan
    Commented Mar 25, 2016 at 9:35
  • Yeah, but the problem statement clearly states the attributes of each and every entity, including Client, and the statement can't be changed. I'm confused, should I still add ClientID? It is a very feasible option though.
    – PalashV
    Commented Mar 25, 2016 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.