Таблица пересечения трех сущностей "многие-многие-многие" - PullRequest
1 голос
/ 09 августа 2010

В настоящее время я работаю над дизайном модели данных (который будет поддерживаться RDMS).Он основан на 3 субъектах, касающихся льгот для члена организации.Субъектами являются Преимущество, Тип Членства и Поставщик.Я создал стандартную таблицу пересечений «многие ко многим», чтобы связать две сущности, но не 3.Таблица будет выглядеть следующим образом:

create table BENEFIT_MEM_TYPE_PROVIDER
(
   BENEFIT_ID reference BENEFITS not null,
   MEMBERSHIP_TYPE_ID reference MEMBERSHIP_TYPES not null,
   PROVIDER_ID reference PROVIDERS not null,
   primary key (BENEFIT_ID, MEMBERSHIP_TYPE_ID, PROVIDER_ID)
)

Что-то в этих отношениях просто не подходит мне, поэтому я решил спросить у умных людей совета.

Спасибо

Ответы [ 3 ]

4 голосов
/ 10 августа 2010

кто-нибудь сделал такую ​​вещь

Да.

если есть какие-либо потенциальные ловушки, я должен избегать.

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

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

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

Короче говоря, если у вас более 1 отношения, убедитесь, что парные отношения в каждой строке также верны.

3 голосов
/ 10 августа 2010

Да.

Троичные отношения довольно широко используются, хотя и не так широко используются, как бинарные отношения. Это может быть даже распространено на четвертичные или вообще n-арные отношения.

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

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

Звездная схема намеренно идет другим путем. Вот почему схема звезды и нормализация так часто воспринимаются как противоречащие друг другу.

0 голосов
/ 10 августа 2010

Вы должны проверить, удовлетворяет ли ваша таблица Пятой Нормальной Форме (5NF).Если этого не произойдет, то, вероятно, лучше его нормализовать, чтобы оно было в 5NF.

...