Есть отделы и менеджеры. В отделе больше менеджеров, но только один менеджер является главным менеджером отдела. У отдела должен быть только один главный менеджер. Во время праздников главный менеджер отдела может быть временным главным менеджером другого отдела. Как бы вы это сформулировали?Как бы вы моделировали следующие отношения с базой данных?
Пожалуйста, объясните свой выбор.
Один стол для отделов, один стол для менеджеров, один стол для руководителей.
Реляционная таблица для менеджеров по отделам, реляционная таблица для главных менеджеров отделов, реляционная таблица для главных менеджеров в других отделах, которым им надлежит контролировать (или вместо этого, если она приводит к меньшему набору данных, таблица должны быть относительными для главных менеджеров к отделам, к которым им НЕ разрешено наблюдать).
Связь между Департаментом и Главным менеджером будет тогда взаимно-однозначным отношением. Я думал создать единый менеджер таблиц и сохранить идентификатор главного менеджера в таблице отдела. Что ты думаешь об этом? – yoozz
@CarlBruun Это тоже хорошо. На самом деле, меньше таблиц, так что было бы лучше. Это до тех пор, пока руководители и главные менеджеры не должны быть разделены по какой-либо причине. – smilebomb
Причина, по которой я не уверен в своей модели, заключается в том, что она позволяет удалить менеджера, даже если его идентификатор сохранен в качестве главного менеджера в отделе, в результате чего есть отдел с несуществующим идентификатором менеджера. – yoozz
вы можете использовать эту модель
Отдел ( IdDepartment, другие свойства ... )
Менеджер ( Idmanager, другие свойства ... )
DepartmentManager ( IdDepartment, IdManager, IsTemporary )
В вашей физической модели
DepartmentTable
IdDepartment в качестве первичного ключа
ManagerTable
IdManager в качестве первичного ключа
DepartmentManagerTable (IdDepartment + IdManager) в качестве первичного ключа IsTemporaryChef как имущество
И как эта модель остановит отделение с двумя главными менеджерами? (не временные) – yoozz
, если у вашего отдела есть два шеф-повара, которые вы можете иметь в своей базе данных в таблице ссылки (iddepartment: 1, idmanager: 1, idtemporary: 1) (iddepartment: 1, idmanager: 2, idtemporary: 0) –
Деловое правило гласит, что не разрешено иметь более одного главного менеджера, принадлежащего отделу. – yoozz
Один стол для подразделений (в том числе главный менеджер ID)
Один стол для менеджеров (на одного человека)
Один стол для отдела/отношений Manager (департамент ID & менеджер ID)
Пример:
В чем причина того, что таблица отношений менеджера-менеджера для вашей модели? – yoozz
Это позволяет одному менеджеру подключаться к нескольким отделам, а также к одному отделу, чтобы иметь более одного менеджера, и хранить идентификатор главного менеджера в таблице отделов обеспечивает только одного руководителя отдела. – bendataclear
В нормальной ситуации менеджер принадлежит только одному отделу. Единственный случай - когда главный менеджер становится временным главным менеджером другого отдела. В этом случае таблица Mgr_Dept_Link не была бы полезна? – yoozz
Предполагая, что один «обычный» менеджер может управлять более чем одним отделом, ваша модель данных шо пакетирования, вероятно, искать что-то вроде этого:
CHIEF_MANAGER_ID может "точка" или:
В случае, если вы хотите, чтобы обеспечить тот же человек не может управлять несколько отделов в своей роли в качестве главного менеджера (в то время как еще в состоянии управлять еще один отдел, как обычный менеджер), добавьте UNIQUE ограничение на CHIEF_MANAGER_ID.
В случае, если вам нужно запомнить как первичные, так и замещающие главные менеджер одновременно использовать два поле, а не просто CHIEF_MANAGER_ID (в этом случае, вы также должны обеспечивать отдел соответствия, не декларативно).
В приведенной выше модели DEPARTMENT.CHIEF_MANAGER_ID имеет значение NULL. Это делается для разрыва цикла внешних ключей, поэтому данные могут быть фактически вставлены в базу данных без отсрочки внешних ключей. Если ваша СУБД поддерживает отложенные ограничения, вы можете сделать это поле NOT NULL и отложить один из FK, поэтому он проверяется в конце транзакции (после того, как обе строки были вставлены).
Я только что понял, что есть дополнительное требование: не каждый менеджер может быть заменен. Только начальник может. Вы могли бы сделать что-то подобное, чтобы смоделировать его:
SUBSTITUTE_DEPARTMENT_ID баллы в отдел мы «заимствование» главный менеджер заменитель из. Поскольку мы указываем на департамент, а не на непосредственного менеджера, мы знаем, что мы должны с ним руководить начальником .
Благодарим вас за ответ. Я также рассмотрел эту модель. Это правда, что я хочу запомнить как основного, так и временного менеджера. Мой вопрос относительно этого решения: для временного менеджера мне нужно сохранить период этой временной позиции, чтобы я знал, когда мне приходится рассчитывать на основного менеджера или на заменяющего/временного менеджера. Где я должен это делать? В таблице отделов? (это выглядело бы неплохо) – yoozz
@CarlBruun Возможно, вы просто добавили поля даты начала и окончания в DEPARTMENT (в модели в нижней части моего обновленного ответа). Таким образом, вы сохраняете как первичные, так и заменяющие, и знаете _when_, чтобы использовать это. Разумеется, если вам нужны _multiple_ периоды, для этого потребуется дополнительная таблица. –
Кажется, это единственный способ добавить дату начала и окончания с вашей точки зрения. Но я считаю несоответствующим (или не очень приятным) сохранение этих двух данных в таблице отделов, но это решение и охватывает все требования. Большое спасибо за Вашу помощь! – yoozz
Основная идея состоит в том, чтобы отделить иерархию организационной диаграммы от сотрудников (менеджер - сотрудник). Как разница между Президентом (положением) и лицом, занимающим эту должность.
Для простоты иерархия здесь смоделирована с помощью списка выровненных смежности; не самый эффективный для SQL-иерархий, но достаточно хорош для этого.
Примечание. Главный менеджер отдела имеет должность, которая не сообщает никому в этом отделе. Генеральный директор всей организации имеет ReportsTo = NULL, для всех остальных он указывает на позицию босса.
Каждый сотрудник может выполнять любую роль с течением времени.
Для более эффективных моделей иерархии см. Книгу Celko или просто «иерархии SQL» Google.
Благодарим вас за ответ. Ваша модель фактически позволяет сотруднику быть частью более чем одного отдела, не так ли? Если это правда, оно не распространяется на мое требование. – yoozz
Правда, один сотрудник может играть несколько ролей одновременно. Вы можете или не можете предотвратить это с ограничениями. Реальность заключается в том, что люди поощряются и понижают рейтинг вверх по иерархии в удовольствие высшего руководства, человек часто работает на двух должностях неполный рабочий день. Это, как говорится, есть еще несколько вещей, на которые нужно обратить внимание - например, продвигать узлы, если позиция босса удалена, имея все позиции, заполненные людьми, предотвращая циклические циклы ... Это может быть более гибким для реализации основанных на правилах -checks (на уровне приложения или хранимой-proc), чтобы ограничить все с помощью простых ограничений DB. –
Звучит как домашнее задание. Вы должны добавить этот тег к своему вопросу, если это так. – JAB
Это вопрос домашнего задания? –
Нет, это упрощенная реальная ситуация, с которой я столкнулся. У меня больше идей моделирования, и мне было любопытно услышать другие идеи. – yoozz