I would like to ask if I'm doing this right since it's my first time creating a database model.

Basically what I'm trying do build is an Employee Information model where:

  • An employee can have multiple addresses but only one can be tagged as the permanent address
  • An employee can have multiple positions but only one can be tagged as the current position. Same for the employee department
    • The reason I choose one-to-many relationships on the position and department is to track its histories
  • An employee can have multiple dependents.

Here's an example of my initial schema

enter image description here

I would appreciate your feedback if I'm doing it right or if you can help me design it in a much better way.

  • 1
    Hi and welcome to the forum! Schema design questions are really too broad in scope for this site - they require long discursive answers and, in any case, nobody has access to your particular data or a deep appreciation of all the circumstances of your situation. Schema design is an iterative process. Start with your best guess at a schema, code against it, fix the bugs (and there will be bugs) - then rinse and repeat. Get back to us here if you have more specific questions! – Vérace Jun 6 at 11:11

The most common pattern for handling historical data in an OLTP schema is to have a current table and a separate history table. So any time an employee changes department, the employee_department table is updated, and a new row is inserted into the employee_department_history table.

You can also use a single table with begin/end dates. This example of this pattern in SQL Server's older AdventureWorks sample database. Which tracks both department and position (shift) in a single table:

CREATE TABLE [HumanResources].[EmployeeDepartmentHistory](
    [BusinessEntityID] [int] NOT NULL,
    [DepartmentID] [smallint] NOT NULL,
    [ShiftID] [tinyint] NOT NULL,
    [StartDate] [date] NOT NULL,
    [EndDate] [date] NULL,
    [ModifiedDate] [datetime] NOT NULL,
 CONSTRAINT [PK_EmployeeDepartmentHistory_BusinessEntityID_StartDate_DepartmentID] PRIMARY KEY CLUSTERED 
    [BusinessEntityID] ASC,
    [StartDate] ASC,
    [DepartmentID] ASC,
    [ShiftID] ASC

SQL Server eventually added a feature to implement the current/history pattern automatically called Temporal Tables, and the newer WideWorldImporters sample database uses those.

| improve this answer | |

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