Какова наилучшая практика в отношении двух или более таблиц отношений?

Question

У меня есть поездка (основная: idTrip), где я могу связать больше пакетов (основной: idPackage), поэтому я получил таблицу отношений для связи поездок с пакетами (основной: idRelTripPackage).(отношение n-to-n)

И затем я получил таблицу регистрации (основной: idRegistration).Как мне лучше связать их (отношения 1 к 1)?

1. Я добавляю два столбца в таблицу регистрации (idTrip, idPackage)?
2. Я добавляю таблицу отношений, где я связываю idRegistration, idTrip, idPackage?
3. Iдобавить таблицу отношений, где я связываю idRegistration, idRelTripPackage?

Answer 1

Правильно ли я считаю, что отношение регистраций относится к RelTripPackage, и это определенно один к одному. Есть несколько вариантов:

1: Поскольку это действительно один-к-одному, на самом деле нет ничего, что могло бы помешать вам помещать данные регистрации непосредственно в RelTripPackage или делать наоборот и помещать idPackage и idTrip прямо в регистрации как FK с уникальными введите два столбца FK, чтобы не было дубликатов.

2: Если вам нужны две отдельные таблицы, просто добавьте idRetTripPackage в «Регистрация как FK», а затем добавьте уникальное ограничение для него - снова, чтобы обеспечить уникальность.

Нет необходимости в отдельной таблице отношений, так как это отношение 1-1 - они действительно становятся релевантными, только когда вы используете n-n. В остальное время FK следует размещать непосредственно на дочернем столе.

Answer 2

Если вы будете следовать этой логике, вы будете

• добавлять таблицы и отношения каждый раз, когда вам нужно добавить отношения
• В итоге получаются запутанные или дублирующие отношения (несколько путей между любыми двумя таблицами)

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

• если вы предоставите информацию по таблицам (Персона, Поездка, Пакет и т. Д.); что такое регистрация и т. д. Я могу дать более четкие ответы.

Обычно любой атрибут, который равен 1 :: 1 с PK объекта, должен быть атрибутом в этом объекте. Любой атрибут, который равен 1 :: 0-1 с PK объекта, должен находиться в отдельной таблице.

Диаграмма ER

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

Читатели, не знакомые со стандартом моделирования реляционных баз данных, могут найти ▶ IDEF1X ◀ полезными.