How would you model the following database relationship? - sql

Question

There are departments and managers. A department has more managers, but only one manager is the chief manager of the department. A department must have only one chief manager. During holidays, a chief manager from a department can be the temporary chief manager of another department. How would you model this ?
Please explain your choice.

Answer 1

Assuming a single "ordinary" manager can manage at most one department, your data model should probably look something like this:
A CHIEF_MANAGER_ID can "point" either:
to a manager from the same department (i.e. whose MANAGER.DEPARTMENT_ID matches the DEPARTMENT.DEPARTMENT_ID of the row containing this CHIEF_MANAGER_ID), in which case it is the "primary" chief manager
or to a manager from the different department, in which case it is the "substitute" chief manager.
In case you want to ensure a same person cannot manage multiple departments in its role as a chief manager (while still being able to manage one more department as an ordinary manager), add a UNIQUE constraint on CHIEF_MANAGER_ID.
In case you need to memorize both primary and substitute chief managers at the same time, use two fields instead of just CHIEF_MANAGER_ID (in which case, you'd also have to enforce department matching non-declaratively).
In the model above, the DEPARTMENT.CHIEF_MANAGER_ID is NULL-able. This is done to break the cycle of foreign keys, so data could actually be inserted into the database without deferring foreign keys. If your DBMS supports deferrable constraints, you can make this field NOT NULL and defer one of the FKs, so it is checked at the end of the transaction (after both rows have been inserted).
I just realized there is an additional requirement: not every manager can be substitute. Only a chief can. You could do something like this to model it:
The SUBSTITUTE_DEPARTMENT_ID points to the department we are "borrowing" the chief manager substitute from. Since we are pointing to a department, and not directly manager, we know we must be getting the chief manager with it.

Answer 2

One table for departments, one table for managers, one table for chief managers.
A relational table for managers to departments, a relational table for chief managers to departments, a relational table for chief managers to other departments they are allowed to oversee (or instead, if it results in a smaller data set, the table should be relational for chief managers to departments they are NOT allowed to oversee).

Answer 3

you can use this model
Department
(
IdDepartment,
other properties ...
)
Manager
(
Idmanager,
other properties ...
)
DepartmentManager
(
IdDepartment,
IdManager,
IsTemporary
)
In your physical model
DepartmentTable
IdDepartment as primary key
ManagerTable
IdManager as primary key
DepartmentManagerTable
(IdDepartment + IdManager) as primary key
IsTemporaryChef as property

Answer 4

One table for departments (including chief manager ID)
One table for Managers (Per person)
One table for Department/Manager relationships (Department ID & Manager ID)
Example:

Answer 5

The main idea here is to separate hierarchy of an organizational chart from employees (manager is an employee). Like the difference between the President (position) and the person who holds the office.
For simplicity, the hierarchy is here modelled with the levelled-adjacency-list; not most efficient for SQL hierarchies, but good enough for this.
Note, chief manager of a department has a position that does not report to anyone in that department. CEO of the whole organization has ReportsTo = NULL, for everyone else it points to the boss-position.
Each employee can fulfill any role over time.
For more efficient hierarchy models, see Celko's book or just google 'SQL hierarchies'.