У всех структур реляционных баз данных требуется соединение или ассоциативная таблица для отношений «многие ко многим»?

Question

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

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

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

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

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

Answer 1

В реляционной базе данных ни один столбец не содержит более одного значения в каждой строке. Поэтому вы никогда не будете хранить данные в формате «CSV» или любой другой системе с несколькими значениями в одном столбце в реляционной базе данных. Также не допускаются повторные столбцы, содержащие экземпляры одного и того же элемента (Course1, Course2, Course3 и т. Д.). Это первое правило создания реляционной базы данных и называется Первой нормальной формой.

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

Answer 2

Я не знаю ответа на ваш вопрос, но я могу ответить на аналогичный вопрос: почему мы используем таблицу соединений для отношений «многие ко многим» в базах данных?

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

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

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

Answer 3

«Соединительные столы» поступают из презентаций/методов/продуктов ER/ORM, которые на самом деле не понимают реляционную модель.

В реляционной модели (и в исходном моделировании ER-данных) отношения приложения представлены отношениями/таблицами. Каждая таблица содержит кортежи значений, которые находятся в этом отношении друг к другу, т. Е. Являются такими взаимосвязанными, то есть удовлетворяют этим отношениям, то есть участвуют в отношениях.

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

Причина, по которой вы не видите много отношений «многие ко многим», а также столбцы об участниках, а не об их участии в отношениях, заключается в том, что такие таблицы лучше разделяются на части участников, а на отношение. Например, столбцы в таблице «многие-ко-многим», которые касаются участников 1. не могут ничего сказать о сущности, которые не участвуют, и 2. говорят то же самое об объекте каждый раз, когда он участвует. Методы информационного моделирования, направленные прежде всего на определение типов независимых сущностей, тогда отношения между ними, как правило, приводят к проектам с небольшим количеством таких проблем. Причина, по которой вы не видите отношения «многие ко многим» в двух таблицах, состоит в том, что это избыточно и восприимчиво к ошибкам таблиц, которые не согласуются. Проблема с сборными столбцами (последовательностями/списками/массивами) заключается в том, что вы не можете в общем случае запрашивать их части, используя обычную нотацию и реализацию запроса, поскольку СУБД не видит частей, упорядоченных в таблицу.

См. this recent answer или this one.