Как вы решаете сущность «многие ко многим» в РСУБД?

Question

Я пытаюсь смоделировать артистов и песни, и у меня есть проблема, когда у меня есть Song_Performance, которую могут исполнять многие артисты (скажем, дуэт), поэтому у меня есть Artist_Group, чтобы представлять, кто исполняет песни.

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

Мне трудно придумать, как найти первичный ключ для сущности Artist_Group, который сохраняет тот факт, что один и тот же набор исполнителей представляет одну и ту же группу, а отсутствие первичного ключа для сущности Artist_Group означает, что я ' Мне не хватает внешнего ключа для объекта Artist_Group_Participation.

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

Edit:

Похоже, что все предлагают таблицу пересечений, но это не моя проблема здесь. У меня есть это. Моя проблема заключается в применении ограничения, заключающегося в том, что вы не можете добавить запись Artist_Group, если содержащаяся в ней группа художников совпадает с существующей группой, игнорируя порядок. Я думал о том, чтобы идентификатор Artist_Group был varchar, представляющим собой объединение различных художников, которые его составляют, что решило бы проблему, если бы порядок имел значение, но наличие Artist_Group для «Элтона Джона и Билли Джоэла» не препятствует добавлению группы "Билли Джоэл и Элтон Джон".

Answer 1

Вы можете сделать так, чтобы идентификатор каждого исполнителя соответствовал битам в битовом поле. Таким образом, если Элтон Джон является идентификатором 12, а Билли Джоэл - идентификатором 123, то «группа», образованная дуэтом между Элтоном Джоном и Билли Джоэлом, имеет Artist_Group ID 10633823966279326983230456482242760704 (т. Е. У него установлены 12-й и 123-й биты).

Вы можете установить связь с помощью таблицы пересечений. Например, используя ограничение CHECK в PostgreSQL:

CREATE TABLE Artist_Group_Participation (
  artist_id int not null,
  artist_group_id int not null,
  PRIMARY KEY (artist_id, artist_group_id),
  FOREIGN KEY (artist_id) REFERENCES Artists (artist_id),
  FOREIGN KEY (artist_group_id) REFERENCES Artist_Group (artist_group_id),
  CHECK (B'1'<<artist_id & artist_group_id <> 0)
);

Правда, это хак. Это придает дополнительное значение суррогатному ключу Artist_Group, когда предполагается, что суррогатные ключи уникальны, но не содержат информации.

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

Answer 2

Полагаю, мне не хватает точки отношения "Artist_Group".

Модель данных в моем уме:

Исполнитель: физическое лицо.

Песня: сама песня.

Исполнение: конкретное исполнение или аранжировка песни. Обычно это одна песня, но вы можете предоставить связующую таблицу m: n для размещения попурри. В идеале это было бы единственное реальное исполнение, т. Е. Была бы соответствующая дата.

Запись: конкретная фиксированная версия исполнения (CD или что-то еще). Обычно у исполнения есть только одна запись, но наличие отдельной таблицы будет обрабатывать сценарий Grateful Dead / множественная бутлега, а также переиздание альбомов, воспроизведение по радио в прямом эфире против версий CD и т. Д.

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

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

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

Answer 3

Первичным ключом для Artist и Artist_Group будет числовой инкрементный идентификатор. Тогда у вас будет таблица Artist_Group_Participation, которая имеет два столбца: artist_id и group_id. Это будут внешние ключи, которые ссылаются на идентификатор соответствующих таблиц. Затем, чтобы выбрать все, что вы использовали бы JOIN.

РЕДАКТИРОВАТЬ: Извините, я неправильно понял ваш вопрос. Единственный другой способ, о котором я могу подумать, - это добавить в таблицу Artist_Group столбец «Artist», содержащий сериализованный массив (при условии, что вы используете PHP, но другие языки имеют эквиваленты) артистов и их идентификаторов. Затем просто добавьте к столбцу уникальное ограничение.

Answer 4

У меня нет большого опыта работы с RDBMS. Тем не менее, я прочитал статьи Кодда и книги С.Дж. Дейта.

Итак, вместо использования жаргона СУБД, я попытаюсь объяснить в более общих чувственных терминах (по крайней мере для меня!)

Здесь идет -

1. Имена певцов должны быть стандартными на основе «Имя - Фамилия»

2. Каждый «Певец» должен иметь запись в таблице «Artists Group», даже если он исполнил соло

3. Каждая запись в «Группе художников» будет состоять из нескольких «Певцов», упорядоченных по алфавиту. Должно быть единственное вхождение определенной комбинации.

4. В каждой песне будет запись уникальной записи от «Artists Group» независимо от того, являются ли они соло, дуэтами или в банде.

Не знаю, имеет ли это смысл, но это мои два цента!

Answer 5

Я думаю, вы могли бы создать первичный ключ, отсортировав и связав идентификаторы артистов ??

группа: 3,2,6 -> 2-3-6 и 6,3,2 -> 2-3-6