CODEWITHSUNDEEP
database-designdata-modelingmultiple-inheritanceclass-diagramerd
piresashwin
piresashwin

Reputation: 165

How to Model Inheritance

I am a bit confused in choosing an approach to model the following relationships.

Scenario:

  1. The system has a User.

  2. The User can perform 2 functions :

    • He Can be a normal User who can buy products listed on the website.
    • He Can Subscribe to Sell Products on the website.
    • He Can Subscribe for the Delivery Service to Delivery his orders placed
      from the website
    • He can Subscribe for Both i.e. Sell Products as well as subscribe for Delivery Service.

How can i model the user who can do both the functions of a seller as well as place delivery requests.

                               User
                                 |
                                 |
         _________________________________________________
        |                                                 |
      Seller (ONLY)                                   Delivery (ONLY)

                      **SELLER AND DELIVERY**

Upvotes: 0

Views: 123

Answers (4)

Gerd Wagner
Gerd Wagner

Reputation: 5673

You have two options how to implement the class hierarchy formed by Seller and DeliverySubscriber being subtypes of User. If your subclasses/subtables do not have many additional properties/columns, one would normally use the Single Table Inheritance approach with just one table User and a type (or category) column for discriminating between users who are sellers and users who are delivery subscribers. Otherwise, if there are many additional properties/columns, it's better to use the Joined Table Inheritance approach, where subtables (representing subclasses) are joined to their supertable via their primary key being also a foreign key referencing the supertable. You can read more about these two forms of implementing class hierarchies with tables in my book chapter Subtyping and Inheritance.

Upvotes: 1

barakcaf
barakcaf

Reputation: 1324

assuming the person must be a user and can also be a Seller or Delivery or both - the relationship should be - User ------ Seller - 1:1 (one to one - any user can be one seller and every seller must be a user). the same goes to Delivery (a user can sign for delivery and a delivery must be a user).

in c# - this will mean than the seller class is derived from user, same as the delivery class.

in DB - the dilevery and Seller tables will hold a FK to a Users PK which will also be their primary key.

Upvotes: 0

Walter Mitty
Walter Mitty

Reputation: 18940

If you are interested in just ER modeling, look into "generalization/specialization".

If you are interested in table design, take a look at the questions and the tag wiki for these two tags:

One of these two should fit your case.

Upvotes: 0

koriander
koriander

Reputation: 3258

I would just use 3 tables: User, UserSeller, UserDelivery with a field UserType in User table to indicate which case applies. The three tables hare a common primary key.

Upvotes: 2

Related Questions