CODEWITHSUNDEEP
database-designrelational-database
BOOnZ
BOOnZ

Reputation: 848

database supertype/subtype

I need to implement a database to track a parcel's location.

There can be basically 4 locations, namely on a aeroplane, on a ship, on a car, at a transit office.

I need to have separate entities for these 4 locations because they all have mutiple instances of each (e.g. many aeroplanes, many cars)

Also, each of these 4 entities are managed by one and only one employee (another entity).

I have created an associative entity called job whereby it stores the information about which employee working in each of the 4 locations, similar to a flight number which contains the aeroplane id with the pilot id.

I have examined the attributes of the 4 locations, and found that they could be classified into car being the supertype and aeroplane, ship and office being subtype of car.

there would be a unique attribute of location_id which tells me whether it is on an aeroplane or an office in the supertype, thus the subtype would inherit this attribute.

my question is whether in the tables design, since locations will be separated into four different tables, whenever i referred location_id(FK) from the job entity, is it still possible to do so since a foreign key normally links to only one table and not 4 tables in this case..

EMPLOYEE [ employee_id, employee_name, gender, contact_number, job_scope ]

JOB [ job_id, (employee_id), (location_id) ]

OFFICE [ location_id, office_id, address ]

CAR [ location_id, vehicle_id ]

AEROPLANE [ location_id, vehicle_id, type, unladen_weight ]

SHIP [ location_id, vehicle_id, size ]

Upvotes: 1

Views: 1233

Answers (1)

p.marino
p.marino

Reputation: 6252

Create a Location table.

Location-id
Location-Type
Description

(N.B.: the second field is redundant, because if the Location is a "Ship" you will find a record in the Ship table and nowhere else, but may be nice to have)

Location-ID will be the primary key of the Location Table. And it will be a foreign key for Ship, Air, Office etc.

So let's say that you want to map 2 "locations", one is a ship, the other is an office.

Location table:

Location-Id | Location-Type | Description
      ...   | ...           | ... 
     005768 | Ship          | "The Sea Witch" Mexican Cargo
      ...   | ...           | ...
     087956 | Office        | "Our offices in Albuquerque"

Office Table

Office-Id | Address 
   ...    | ...
   087956 | "145 Rose St. Albuquerque"
   ...    | ...

Ship Table

  Ship-Id | Size 
   ...    | ...
   005768 | 14000
   ...    | ...

In case you manage to find some other field which exists for all 4 types of "locations" add it to the Location table.

The rest should be more or less ok: your Job table will point here, and every "concrete" class will be obtained by joining the Location record with the specific "subtype" record.

Note: If you meant "location" as something else, for example "geographical area" like "Arizona" or "Gulf of Mexico" you will have to add this as an attribute of the Location table. For Office it will be static, while the other types of "locations" may change it as they move around.

So the supertype is "Location", and Office or Ship are subtypes of the "generic" location.

This is a standard way to model Supertypes in RDBMS, btw, as explained already in some other places.

Upvotes: 1

Related Questions