Не вдаваясь в подробности, уверяю вас, что решение «Сотрудник/Менеджер/Отдел» в долгосрочной перспективе является источником неудовольствия (сначала), а затем настоящим PITA (позже) для лиц, ответственных за ведение базы данных и /или разработка его интерфейса. Поэтому я советую вам придерживаться вашего второго предложения.
Что касается отношения менеджер/отдел, у вас есть в основном два способа представления этого отношения. Оба решения разрешают вам сохранить ваше рекурсивное отношение «Менеджер управляет сотрудником» в дополнение к отношению «менеджер управляет отделом», которое вы можете реализовать следующим образом:
1 - первый/простой способ: добавьте идентификатор менеджера/сотрудника в таблицу вашего отдела. Это поле, конечно же, является внешним ключом к таблице сотрудников.
2 - второе/более сложное решение: добавьте таблицу «менеджер» со следующими полями:
Manager id (PK, surrogate)
Department id (FK)
Employee id (FK)
beginningDate
endingDate
где вы будете хранить историю управления: кто, для какого отдела, когда, до когда
В этом случае не забудьте добавить некоторую логику (триггер или контроль на стороне клиента), чтобы перевести ваши бизнес-правила, например, вы можете иметь только одного менеджера на определенный период и определенный отдел, ни один отдел не может оставаться более ... без менеджера и т.д.
РЕДАКТИРОВАТЬ:
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 для этого сотрудника равен нулю). ...). Но это только бизнес-правила. Ваша модель данных может принимать все правила, если соблюдается основное правило, а именно то, что отделом управляет сотрудник!
person
Philippe Grondier
schedule
02.04.2012
