Общая сущность в отношении базы данных один ко многим - PullRequest
1 голос
/ 02 августа 2011

У меня есть база данных, для которой я работаю над дизайном. У меня есть производители, и у меня есть дистрибьюторы на отдельных таблицах, содержащие практически одну и ту же информацию, за некоторыми исключениями. Обе группы имеют один-много контактов, которые должны быть связаны с ними. Я создал таблицу контактов для хранения контактной информации, один!

Нужна ли вторая таблица контактов? Я пытаюсь сделать это как можно более сухим. Как это будет выглядеть? Заранее спасибо

1 Ответ

1 голос
/ 03 августа 2011

Может быть, дело в шаблоне партийной роли ?Manufacturer и Distributor - это роли, которые играют Стороны.Контакты относятся к Сторонам, а не к той роли, которую они играют.Таким образом, у вас будет:

  • таблица с именем Party
  • таблица с именем ContactMethod (или аналогичная)
  • отношение 1: M от Стороныto ContactMethod

, что решило бы необходимость в двух Contact таблицах.То, как вы смоделируете роль ролей, будет зависеть от более широких требований.Каноническая модель будет иметь:

  • один супертип с именем Role
  • отношение M: M от партии к роли
  • подтип роли для каждого конкретногороль (Дистрибьютор и Производитель в вашем случае).

(Примечание: помимо этого, это также позволяет Стороне играть роли как производителя, так и дистрибьютора - что может иметь или не иметь значение).

Существует 3 «стандартных» шаблона для реализации иерархии подтипов в реляционных таблицах:

  1. таблица для всей иерархии
  2. таблица для каждого подтипа листа
  3. таблицадля типа

(1) будет применяться, если у вас нет каких-либо ролевых отношений.(Однако я подозреваю, что это маловероятно; вероятно, существует информация, касающаяся дистрибьюторов, которая не относится к производителям и наоборот).
(2) означает множественные отношения от стороны (т. Е. По одному на каждый подтип роли).

(3) избегает обоих вышеперечисленных, но означает дополнительное объединение при переходе от Стороны к ее роли.

Как я уже сказал, выбор зависит от более широких требований.

hth.

...