Почему нет отношений «многие ко многим»?

Question

Я изучаю базы данных и SQL впервые.В тексте, который я читаю (Oracle 11g: SQL Джоан Кастил), говорится, что «отношения« многие ко многим »не могут существовать в реляционной базе данных».Я понимаю, что мы должны избегать их, и я понимаю, как создать соединяющую сущность, чтобы устранить их, но я пытаюсь полностью понять утверждение «не может существовать».

Действительно ли это физически невозможноимеют отношение многие ко многим?

Или это просто очень неэффективно, поскольку приводит к многократному дублированию данных?

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

Спасибо!

Answer 1

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

Answer 2

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

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

Answer 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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

Answer 9

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

Answer 10

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