Вопрос по database, data-structures, one-to-many, many-to-many – Почему структура данных «многие ко многим» требует наличия двух дополнительных таблиц?

1

Этот вопрос основан нанить.

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

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

альтернативный текст http://files.getdropbox.com/u/175564/db/db-55.png

Why do we need to have the tables Question-Tag-xref and Question-Tags?

Why cannot we just have one table for tags as follows?

   Question_id   |    tag
   1                  C 
   1                  C++
   2                  Java
   2                  C

Why is the fact that two different questions have the same tag a problem for a computer?

Ваш Ответ

7   ответов
0

чем просто столбец тега. Так что, если информации много, то у вас есть избыточные данные (в вашем примере у вас есть 2 "C" значения). Тогда, если одно и то же значение живет более чем в одном месте, обновления становятся проблемой. Таким образом, правило состоит в том, что данные должны находиться в одном месте, а их идентификатор используется в других местах для ссылки на них. Затем, когда вы обновляете его, это нужно сделать только в одном месте.

4

Это потому, что один и тот же вопрос может иметь много тегов.

И потому, что один и тот же тег может использоваться многими вопросами.

Вам нужно где-то хранить (questionId, tagId) и убедиться, что нет дубликатов этого.

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

Почему у Вопрос-тегов есть и строка тега, и идентификатор тега? Это не имеет большого смысла для меня.

Я не хочу возвращаться к последовательности вопросов. Тем не менее, я хотел попытаться проиллюстрировать, о чем я говорил. Поэтому я создал очень простую модель Object-Role Modeling этой части StackOverflow, используяНОРМА инструмент:

Simple model of StackOverflow

Это сгенерировало следующую диаграмму ER:

ER diagram

Обратите внимание, что & quot; дополнительные & quot; Таблица - это все, что нам нужно сохранить для тегов, просто потому, что нет никакой дополнительной информации о тегах. Кроме того, нет необходимости хранить идентификатор тега, который является внешним ключом для таблицы тегов, поскольку имя тега уже уникально. Если бы мы хранили дополнительные данные о теге, то, вероятно, была бы отдельная таблица тегов, первичным ключом которой по-прежнему было бы имя тега. Это можно изменить, чтобы использовать целочисленный идентификатор, если это стало проблемой производительности, и в этом случае имя тега все равно получит уникальный индекс над ним.

На самом деле, это не моя запись. Это нотация объектно-ролевого моделирования. Посмотрите наormfoundation.org сайт. Эти вещи в скобках являются ссылочными режимами. Пунктирные линии означают, что это тип значения, а не сплошные линии, указывающие тип объекта. Пустые прямоугольники - это роли. Точка на роли означает, что она обязательна. Полосы над ролями или последовательностями ролей указывают на уникальность. Все это вместе позволяет инструменту озвучивать отношения:
Пример: пользователь задал вопрос. По каждому Вопросу точно один Пользователь задавал этот Вопрос. Возможно, что один и тот же пользователь задал более одного вопроса.
Я попытался решить проблему, переименовав переменные. Пожалуйста, посмотрите, сохраняется ли та же проблема. Léo Léopold Hertz 준영
@ Маси: я их не рисовал. Инструмент NORMA нарисовал диаграмму ER на основе созданной мной модели Object-Role Modeling. Он также создал операторы SQL Server, необходимые для создания таблиц и ограничений, и сделал бы то же самое для DB2, Oracle, MySQL, Postgres, XML Schema или даже классов LINQ to SQL. Он будет генерировать кучу файлов с расширением .php, но, поскольку я не знаю PHP, я не могу сказать, что они собой представляют.
Такова фактическая & quot; строка & quot; теги хранятся в таблицеQuestion-tags? Léo Léopold Hertz 준영
1

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

4

нормализация, ИМХО одна из лучших книг на эту темуSQL Джо Селко для умников, По сути, вы избегаете так называемых «аномалий». В вашем примере, если я удаляю все вопросы с помощью & quot; Java & quot; я никогда бы не узнал, что у меня когда-либо был тег под названием «Java» (удалить аномалию). Важно также разбить таблицу, потому что вам нужна таблица внешних ссылок для описания свойств отношений между принципалами.

Предположим, у вас очень большой сайт, который должен быть легко расширяемым, например, связанные с Google MapReduce. Я не могу понять, почему вы должны вырезать зависимости. Зависимости могут уменьшить количество интерфейсов и количество таблиц, обеспечивая эффективность и расширяемость. Почему вы не можете иметь очень зависимые структуры, где инструменты, аналогичные Git, предупреждают об аномалиях? Резервные копии скажут, что происходит не так. Léo Léopold Hertz 준영
1

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

First, a one-many relationship between a row in the first table to many rows in the second table. Second, another one-many relationship between a row of the second table to many rows in the first table.

Почему это связано смодель реляционной базы данных.

1

что говорят другие (я не буду повторять их комментарии)

По моему опыту, это обычно не таблица помощи, а таблица соединения. Обычно вы имеете дело с чем-то более сложным, чем простое ключевое слово. «Дополнительные» Таблица моделирует отношения между двумя другими объектами.

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

Campaign 
 - CampaignID (PK)
 - other columns

Contact 
 - ContactID (PK)
 - other columns

CampaignContact
 - CampaignContactID (PK)
 - CampaignID (FK)
 - ContactID (FK)

Это сильно отличается от отношения 1-много (иногда называемого отношением мастер-деталь). Здесь каноническим примером является Invoice - & gt; InvoiceItems. Элементы счета-фактуры связаны конкретно с одним и только одним родительским счетом.

Invoice
 - InvoiceID (PK)
 - other columns

InvoiceItem
 - InvoiceItemID (PK)
 - InvoiceID (FK)
 - other columns
Спасибо за ваше редактирование! Léo Léopold Hertz 준영
Campaign, Contact и Invoice и InvoiceItem - все сложные объекты, но детали были опущены для иллюстрации взаимосвязей.
Как вы можете иметь таблицу, где у вас есть одна запись? - Я думаю, что CampaingContact (CampaingID) - это pk и fk для Campaign (campaignID). --- Хм, я не вижу, что возможно иметь только одну запись в моих таблицах выше (обведено). Должна быть похожая ситуация, и структуры данных должны быть одинаковыми. Léo Léopold Hertz 준영
1

http://en.wikipedia.org/wiki/Database_normalization

это не проблема для компьютера, но теория РСУБД гласит, что дБ должно быть нормализовано, уменьшая дублирование информации. Вот что доктор Кодд сказал о необходимости нормализации:

To free the collection of relations from undesirable insertion, update and deletion dependencies; To reduce the need for restructuring the collection of relations as new types of data are introduced, and thus increase the life span of application programs; To make the relational model more informative to users; To make the collection of relations neutral to the query statistics, where these statistics are liable to change as time goes by.

E.F. Codd, "Further Normalization of the Data Base Relational Model"

Похожие вопросы