Моделирование множественных отношений во многих отношениях между одними и теми же объектами в реляционной базе данных

Question

Когда две таблицы имеют отношение «многие ко многим» или когда таблица имеет отношение «многие ко многим», мы можем моделировать это с помощью таблицы соединений ,

Однако тип отношений может израсходовать за пределы первоначального типа, например:

Требования: мы имеем пользователей. каждый пользователь может иметь 0 или более других пользователей в качестве друзей

Решение: таблица пользователей и таблица соединений, называемая «user_user».

Затем мы обнаруживаем новое требование: некоторые дружеские отношения романтичны, или, другими словами, два пользователя могут быть связаны иначе, чем дружба.

• Решения: с добавить столбец в таблицу соединения, которая содержит тип дружбы (друг | партнер | экс-друг) и так далее.

• Решение b: переименуйте таблицу «user_user» в «дружбу» (это было бы лучшее имя, чтобы начать с этого подхода) и создать новую таблицу, называемую романсами, а также подключение пользователя к пользователю.

Затем мы обнаруживаем еще одно новое требование: пользователи могут платить другим пользователям. Опять же, мы можем контрейлеризовать на том же перекрестке или создать новый, называемый «долгами». На этот раз моя интуиция на 100% имеет отдельную таблицу.

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

Вопрос в том, что является хорошим правилом для принятия решения о создании новой таблицы?

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

Это когда дополнительный столбец не является логически определением одного типа отношений?

ОК: начало дня дружбы связана непосредственно к дружбе 1 1

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

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

Answer 1

TL; DR Столы представляют прикладные/деловые отношения/ассоциации. Как в Entity- Отношения Модель. Т.е. Отношения. Как и в модели Relational.Каждый раз, когда нас интересует отдельный, нам нужна новая таблица («соединение»/«ассоциация»).

---

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

Employee(e, n, ...) -- employee identified by E is named N and ... 
Manages(e, m) -- employee M manages employee E 

Вы не можете знать, что таблица говорит о приложении или установить в соответствии с приложением, не зная его предиката! Когда вы указываете «мощность» «отношения», вы должны иметь , который определяет, какие отношения/ассоциации/предикат вы говорите о.

К сожалению, «отношения» используются многими так называемыми методами ER & продукты относятся к внешний ключ таблицы.

Иногда мы можем объединить несколько таблиц в один или заменить таблицу другими. Предикат JOIN - это AND из предикатов его аргументов. Например, если работник всегда имеет ровно один менеджер, то мы могли бы объединить таблицы выше в

--  employee identified by E is named N and ... 
-- AND employee M manages employee E 
EmployeeM(e, n, ..., m) 

Принимая во внимание, если сотрудник имеет один или несколько менеджеров, то последний стол, хотя он все равно содержит строки, которые делают этот предикат в в истинном заявлении, появятся аномалии обновлений, поэтому мы предпочли бы отдельные таблицы. Если у сотрудника может быть ноль или более менеджеров, мы могли бы по-прежнему использовать эту таблицу, но не только эту таблицу, потому что она не может рассказать нам о сотрудниках без менеджеров. Нам бы нужен стол как Работника, но с разные сказуемоеemployee identified by E is named N and ... AND E has no manager. (Гадкий.) Или вместо того, чтобы те два мы могли использовать только таблицу как Работника, но это позволяет аннулирует через иной предикатemployee identified by E is named N and ... AND (employee M manages employee E OR M IS NULL AND no one manages employee E) ,

Подробнее о оригинальной модели/методе Chen ER, где есть типы объектов, значки & таблицы и типы отношений, значки & таблицы. Каждый тип отношений четко обозначен как бриллиант. Каждая строка явно представляет собой участие типа сущности (возможно, тип ассоциативной сущности) в типе отношений, то есть явно представляет FK между таблицами. В то время как многие так называемые ER-методы даже не делают различий между сущностями и отношениями. (Это не должно быть хорошим или плохим, но их презентации, как правило, не объясняют, как правильно моделировать.)

Реляционная модель не заботится о сущности и взаимоотношениях как таковых. Его таблицы - это просто отношения на значениях. ER и так называемые ER-методы делают ненужным и ограничивают произвольное различие между сущностями и отношениями. Естественно, таблица все еще может сказать, что она делает с приложением, как в модели ER, потому что подначисления значений могут идентифицировать объекты. См. this answer.

Если у вас есть отношения со сложным предикатом/таблицей нормализация показывает вам, когда и как разложить его на более мелкие предикаты/таблицы, которые AND/JOIN возвращаются к оригиналу.

PS Нет ничего плохого в дублированных значениях как таковых. В чем может быть проблема, когда несколько строк подразумевают одно и то же о приложении, находясь или нет в таблицах в соответствии с вашим выбором предикатов. Не все такие избыточности ошибочны; это просто неконтролируемое избыточность, это неправильно. В общем, мы хотим иметь проекты, которые так же важны в 5NF. (Т. Е. Уменьшая аномалии обновления, сложность и ограничения предикатов.)

Answer 2

Это зависит от вас. Вы можете определить «дружбу» в отличие от «романтически вовлеченных» и поэтому нужны две таблицы переходов. Или вы можете определить «романтически вовлеченный» как особый случай «дружбы», и поэтому нужна одна таблица. Я склонялся к последней как более простой и менее запутанный. (Что, если те же самые два человека указаны как друзья, а также как любовники?)

Однако «деньги должны быть» разные. Если A дружит с B, тогда B дружит с A. Но если A должен деньги B, неверно утверждать, что B должен деньги A. Таким образом, вы не только определяете разные отношения, но и позиционируете какое поле содержит ссылку на A и которое содержит ссылку на B, становится значительным. Для этого тогда было бы лучше иметь отдельную таблицу соединений.