Почему нет отношений "многие-ко-многим"?

Ответ 1

Подумайте о простой взаимосвязи, такой как между авторами и книгами. Автор может написать много книг. В книге может быть много авторов. Теперь, без таблицы моста, чтобы разрешить отношения "многие-ко-многим", какова будет альтернатива? Вам нужно добавить несколько столбцов Author_ID в таблицу Books, по одному для каждого автора. Но сколько вы добавляете? 2? 3? 10? Однако многие из вас выберете, вы, вероятно, закончите с множеством разреженных строк, где многие значения Author_ID будут NULL, и есть хороший шанс, что вы столкнетесь с ситуацией, когда вам нужно "просто еще один". Итак, вы либо постоянно изменяете схему, чтобы попытаться приспособиться, либо наложили какое-то искусственное ограничение ( "ни одна книга не может иметь более 3 авторов" ), чтобы заставить вещи соответствовать.

Ответ 2

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

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

Ответ 3

Обычно (каламбур) вы использовали бы таблицу ссылок, чтобы установить много-ко-многим

Как описано Джо Стефанелли, скажем, у вас были авторы и книги.

SELECT * from Author
SELECT * from Books

вы создали бы таблицу JOIN, называемую AuthorBooks

Затем

SELECT * from Author a JOIN AuthorBooks ab on a.AuthorId = ab.AuthorId JOIN Books b on ab.BookId = b.BookId

надеюсь, что это поможет.

Ответ 4

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

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

Я не нашел конкретной причины (или еще лучшего примера), которая объясняет, почему избежать отношения "многие ко многим",

Они должны использоваться там, где они подходят для использования, были бы более точным способом сказать это. Бывают моменты, например, примеры книг и авторов, приведенные Джо Стафанелли, где любое другое решение будет неэффективным и вводит другие проблемы с целостностью данных. Однако отношения M-M более сложны в использовании. Они добавляют больше работы со стороны дизайнера GUI. Таким образом, они должны использоваться только там, где имеет смысл использовать их. Если вы уверены в том, что один объект никогда не должен ассоциироваться с более чем одним из других объектов, то, во всяком случае, ограничивать его 1-М. Например, если вы отслеживали статус отправки, каждая партия может иметь только один статус в любой момент времени. Это будет усложнять дизайн и не имеет логического смысла, позволяющего отправке иметь несколько статусов.

Ответ 5

Конечно, они могут (и делать) существуют. Это звучит для меня как выражение soapbox. Они требуются для большого количества бизнес-приложений.

Готово правильно, они не являются неэффективными и не имеют дублированных данных.

Взгляните на FaceBook. Сколько существует отношений "многие ко многим" между друзьями и друзьями друзей? Это определенная потребность бизнеса.

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

Ответ 6

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

Для представления этих отношений требуется дополнительная таблица - возможно, то, что ваша книга действительно говорит? В примере, который я только что дал, у вас будет таблица Person (id, имя, адрес и т.д.) И таблица Group (id, имя группы и т.д.). Ни одна из них не содержит информации о том, кто в какой группе; для этого у вас есть третья таблица (назовите ее PersonGroup), в которой каждая запись содержит идентификатор лица и идентификатор группы - эта запись представляет связь между человеком и группой.

Нужно найти членов группы? Ваш запрос может выглядеть так (для группы с ID = 1):

SELECT Person.firstName, Person.lastName 
FROM Person JOIN PersonGroup JOIN Group 
ON (PersonGroup.GroupID = 1 AND PersonGroup.PersonID = Person.ID);

Ответ 7

Это правильно. Отношения "многие-многие" разбиты на несколько отношений "один-на-один". Так что, по существу, отношения НЕТ много-много!

Ответ 8

Конечно, взаимосвязь MM существует в реляционных базах данных, и они также имеют возможность обработки на некотором уровне посредством таблиц мостов, однако, поскольку степень взаимосвязи MM увеличивается, это также увеличивает сложность, что приводит к медленным циклам RW и задержке. Рекомендуется избегать таких сложных отношений MM в реляционной базе данных. Графические базы данных - лучшая альтернатива, и они хорошо справляются с отношениями "многие ко многим" между объектами, и именно поэтому сайты социальных сетей используют базы данных "Граф" для обработки отношений ММ между пользователем и друзьями, пользователями и событиями и т.д.

Ответ 9

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

Ответ 10

В отношении "многие ко многим" существует очевидная избыточность, а также аномалия вставки, обновления и удаления, которая должна быть устранена путем преобразования ее в 2 отношения "один ко многим" через таблицу мостов.

Ответ 11

M: N отношений не должно существовать в дизайне базы данных. Они крайне неэффективны и не используют функциональные базы данных. Две таблицы (сущности) с отношением "многие ко многим" (самолет, аэропорт, учитель, ученик) не могут быть детьми друг от друга, не было бы места, где можно было бы вводить внешние ключи без пересекающегося стола. самолет → рейс - аэропорт; преподаватель < - класс → ученик.

Таблица пересечений обеспечивает место для сущности, которая зависит от двух других таблиц, например, для класса требуется как класс, так и студент, для полета требуется как самолёт, так и аэропорт. Сочетания "многие ко многим" скрывают данные. Таблицы пересечений раскрывают эти данные и создают отношения "один ко многим", которые могут быть более понятными и работающими с. Итак, возникает вопрос: какой стол должен быть в полете или в аэропорту. Они также не должны быть иностранными ключами в таблице пересечений, Flight.