0

I have to implement an EER diagram where there is a table called Person. Two subclasses of that Person table are Customer and Employee. I can visualize when it comes to a diagram, but now I'm trying to implement it in SQL Server.

My question is: do I have to create two tables or three?

In case of three tables, would I create a Person table and then somehow reference it in the two tables called Customer and Employee? If so, could you provide an example in SQL form?

Or would I create two tables (Customer and Employee) and the fact that both of them are subclasses of Person are just in the mind of the DB admin.

In my EERD, the Person table has an attribute called IsEmployee (which is a bool). Would this attribute be in both tables (Customer and Employee) if indeed I have to make two tables. There is also a 'manages' attribute pertaining to the Employee table.

Thank you for your time! Here is a screenshot of the tables:

enter image description here

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Rad Jre
  • 49
  • 3
  • MySQL <> SQL Server <> PostgreSQL. Please don't spam tags. – Thom A Jun 20 '22 at 18:01
  • Why not create one Person table? Classes and tables are very different – Hogan Jun 20 '22 at 18:02
  • I'm not trying to make a class. This is just a representation diagram. We were asked to implement a few tables with disjoint/overlap to show what we have learned. – Rad Jre Jun 20 '22 at 18:04
  • What you are looking for is called **Supertype and SubType** in data modeling. Look it up on Internet. For example: https://www.youtube.com/watch?v=UCvAa5wh5lg – miriamka Jun 20 '22 at 18:22

1 Answers1

0

In programming languages with inheritance the way this is implement has to do with how memory works -- in short the base class is allocated and then depending on the sub-class memory is reserved after that for the properties needed for the sub-class

In this way the base class always looks the same -- it is the top.

In SQL relational databases things work differently -- if there is data you want to add on you create a new table and join to the base table.

For example I might have a Person table with all the data for a Person and then I might have a Student table -- in the student table I have an id for the base Person and then additional columns for all data that is only for a student.

You should do the same. Have a contacts table (or person table) for all data that is common across all people. Then if you have specific data for an employee make a new table for employee -- it has a contact_id column which joins to all the base person stuff (first name, last name, etc etc) and then you put in the special stuff for employee (salary, title etc.)

Do the same thing for customer.

Lets say your company decides to expand the customer base over seas. Then you would make an international_customer table -- this table would have a column for an id in the customer table which in turn points to the contacts table.

Note: in this model you don't need an is_employee column; someone is an employee if they have a record in the employee table.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Hogan
  • 69,564
  • 10
  • 76
  • 117