Многочисленные отношения между двумя объектами, это хорошая практика?

Question

У меня есть следующий типичный сценарий, касающийся офиса и его сотрудников:

• Каждый сотрудник принадлежит одному офису
• В каждом офисе есть только один менеджер (сотрудник)

Модель ER

er http://img814.imageshack.us/img814/2204/capturefsi.png

Как вы можете видеть, это приводит к тому, что отношения записываются дважды, один раз, когда внешний ключ в таблице office указывает на руководителя, а также в таблице персонала, указывающей на офис, в котором работает сотрудник.

Я искал альтернативные способы моделирования этого, но все еще немного потерян. Пожалуйста, кто-нибудь может посоветовать подходящий способ моделирования этого, или если мой метод приемлем для сценария.

Большое спасибо

Answer 1

Дело не в том, что «взаимосвязь [записывается] дважды», а в том, что у вас на самом деле есть две взаимосвязи между этими таблицами - что совершенно нормально.Моя единственная проблема в том, может ли менеджер принадлежать к тому же офису, в котором он (а) является менеджером?(И в связи с этим: действительно ли верно, что каждый сотрудник имеет офис, а каждый офис имеет менеджера, который является сотрудником?) Если это так, у вас есть круговая зависимость: выне может установить офис менеджера, пока офис не существует, но вы не можете установить менеджера офиса, пока менеджер не существует.Пока одно или другое поле можно обнулять, вы можете обойти это с помощью логики приложения (INSERT одно, затем INSERT другое, затем UPDATE первое), но это немного уродливо.Но если эти отношения существуют, то с этим мало что можно поделать.

Answer 2

Подобные циклические отношения действительны с точки зрения SQL, но некоторые вещи становятся сложными.

Например, когда вы выполняете резервное копирование и восстановление данных, вам необходимо отложить создание одного из ограничений внешнего ключа до тех пор, пока вы не восстановите данные. Потому что, если вы создаете ограничения до того, как заполните таблицы, вы не сможете восстановить менеджера офиса, пока не восстановите его офис, и вы не сможете восстановить офис, пока вы не восстановите его менеджера.

Другой способ решения этой проблемы вместо использования столбца внешнего ключа Office.Manager заключается в использовании логического столбца Staff.IsManager, который является истинным для менеджера, но ложным для всех других сотрудников в данном офисе.

Answer 3

Это нормально для меня, потому что независимо от того, что таблицы в отношениях одинаковы, отношения на самом деле очень разные.Это верно, что вы можете сделать вывод, что менеджер работает в офисе, которым он управляет, однако это скорее правило домена и не отменяет нормализацию этой части структуры базы данных.если вы хотите избавиться от двойных отношений, вы всегда можете создать таблицу менеджеров, которая будет содержать внешний ключ для персонала и офиса.

Answer 4

Это нормально, просто чтобы показать отношения. Но знайте, что это может привести к бесконечному циклу.

staffid ->officeid -> manager -> staffid

Этот цикл может произойти при извлечении данных (однажды я сталкивался с такой же ситуацией), поэтому лучше нормализовать это и избежать этой проблемы 2-отношений.

Answer 5

Это кажется неудобным, когда вы хотите добавить новый офис. В офисе должен быть менеджер, поэтому сначала нужно сделать менеджера. Но менеджер - это сотрудник, у которого должен быть офис, поэтому вам нужно сначала сделать офис.

Чтобы разорвать этот цикл, вам нужно разрешить ему временно иметь значение NULL или какое-либо другое неверное значение, а затем изменить то, что вы создадите первым, чтобы ссылаться на второе. Не невозможно, просто неловко.

Если бы я проектировал это, у меня, вероятно, была бы отдельная таблица "управления", связывающая офисы с менеджерами.