Не вдаваясь в подробности, уверяю вас, что решение «Сотрудник / Менеджер / Отдел» в долгосрочной перспективе является источником недовольства (сначала), а затем реальной PITA (позднее) для лиц, отвечающих за поддержание база данных и / или разработка ее интерфейса. Поэтому я советую вам придерживаться вашего второго предложения.
Что касается отношений между менеджером и отделом, у вас есть два основных способа представления этих отношений. Оба решения позволяют вам сохранять рекурсивное отношение «менеджер управляет сотрудником» в дополнение к отношению «менеджер управляет отделом», которое можно реализовать следующим образом:
1 - первый / простой способ: добавьте идентификатор менеджера / сотрудника в таблицу вашего отдела. Это поле, конечно, является внешним ключом для таблицы сотрудников
2 - второе / более сложное решение: добавьте таблицу «менеджер» со следующими полями:
Manager id (PK, surrogate)
Department id (FK)
Employee id (FK)
beginningDate
endingDate
где вы будете хранить историю управления: кто, для какого отдела, с какого времени, до когда
В этом случае не забудьте добавить некоторую логику (триггер или управление на стороне клиента) для перевода ваших бизнес-правил, например, вы можете иметь только одного менеджера на определенный период и конкретный отдел, ни один отдел не может оставаться более ... без менеджера и т. д.
EDIT:
3 - более богатое решение будет обобщением моего второго предложения и позволит вам отслеживать карьеру каждого в компании. Вы можете сделать это с таблицей 'works in', такой как эта (так как мы называем ее здесь таблицей 'position', я сохраню здесь ту же терминологию:
Position id (PK, surrogate)
Department id (FK)
Employee id (FK)
Position Level (FK)
beginningDate
endingDate
Там, где «уровень позиции» ведет к другой таблице, содержащей различные позиции, которые могут существовать в отделе, одна из которых, конечно, является позицией «менеджера».
Это предложение ближе к тому, что используется в базе данных и программном обеспечении HR, и вам может не понадобиться такое сложное решение. Но имейте в виду, что разделение людей на несколько таблиц ВСЕГДА является ошибкой.
РЕДАКТИРОВАТЬ: после вашего комментария ...
Чтобы прояснить ситуацию, я бы посоветовал вам настроить имена полей. Я бы предложил вам иметь следующие поля:
Tbl_Employee.id_EmployeeManager
и
Tbl_Department.id_DepartmentManager
Делая это, мы (или любой разработчик) сразу поймем, что id_EmployeeManager участвует в рекурсивных отношениях между людьми, а id_DepartmentManager участвует в отношениях между людьми и отделом.
Возвращаясь к вашим вопросам, и, по моему мнению, вам не следует создавать следующую ссылку:
Tbl_Department.id_DepartmentManager -> Tbl_Employee.id_EmployeeManager
Делая так, вы имеете в виду, что кто-то не может быть руководителем отдела , если он уже не управляет сотрудниками. Как насчет отделов с одним сотрудником? А как насчет людей, называемых менеджерами недавно созданного отдела, в котором до сих пор нет сотрудников? Это не работает. Правильная ссылка должна быть:
Tbl_Department.id_DepartmentManager -> Tbl_Employee.id_Employee
Конечно, вы можете добавить некоторые бизнес-правила, например, что «сотрудник, управляющий отделом, может быть только менеджером» (id_Employee существует где-то как id_EmployeeManager) или «сотрудник, управляющий отделом, не может иметь менеджера (где для этого id_EmployeeManager сотрудник является нулевым ...). Но это только бизнес-правила. Ваша модель данных может принять все правила при условии соблюдения основного правила, а именно, что отделом управляет сотрудник!