Цели:
- Почему нам нужно думать об отношениях «многие ко многим»?
- Как они работают? (независимость от языка программирования)
Вступление
На прошлой неделе я узнал об отношениях «один ко многим» («имеет много»), когда один класс объектов может принадлежать другому классу, а один класс может иметь много объектов другого класса. Примером из реальной жизни может быть музей и его отношения с искусством. Произведение искусства может принадлежать только одному музею одновременно, но музей может содержать одно или несколько произведений искусства. Поэтому в музее «много» произведений искусства. Это моделируется в коде с помощью «внешних ключей» для ссылки на другой столбец, но это тема для другого раза.
Вот визуальная диаграмма созданной мной связи "один ко многим":
Ну и замечательно. Но что, если нам нужно описать отношения чего-то более сложного? Возьмем пример из жизни. Подумайте об отношениях между фильмом и его актерами. Если у нас есть фильм, в нем может быть много актеров. Это нормально, как в примере выше! У нас может быть что-то вроде таблицы фильмов со столбцами ID, Title, Actor ... подождите, но у актеров также может быть много фильмов! Здесь мы сталкиваемся с проблемой проектирования базы данных. Вот как будет выглядеть отношение фильма к актеру один-ко-многим:
Это работает только потому, что в этих двух фильмах есть совершенно разные актеры. Но в реальной жизни у актера может быть несколько фильмов! Так как бы вы это смоделировали? Если вы попытаетесь связать его только с двумя таблицами, все станет беспорядочно очень быстро.
Итак, как лучше всего это сделать? Решение: используйте другую таблицу! Правильно, всякий раз, когда вы хотите смоделировать отношения "многие ко многим", было бы проще использовать другую таблицу для связи этих отношений. В нашем случае у нас была бы другая таблица, которая знает отношения между каждым актером и каждым фильмом. Так на что это похоже?
Давайте разберемся с этим.
- У нас есть таблица фильмов, в которой перечислены фильмы с их названиями, и у каждого фильма есть идентификатор.
- У нас есть таблица «Актеры», в которой перечислены актеры по именам, и у каждого актера есть идентификатор.
- А теперь самое сложное: мы создали третью таблицу! Единственная задача этой таблицы - определить отношения между фильмами и актерами.
В этой третьей таблице происходит волшебство. Если мы действительно посмотрим на то, что здесь происходит, то увидим, что в фильме с идентификатором 1 есть актер с идентификатором 1. Если мы посмотрим на соответствующие данные, мы увидим, что в фильме «Дэдпул» есть актер Райан Рейнольдс! Но подождите, есть еще кое-что: если мы перейдем к следующей строке, мы увидим, что этот ход Детектив Пикачу также имеет соответствующий актерский идентификатор 1, который ТАКЖЕ РАЙАН РЕЙНОЛДС! Итак, прямо здесь мы определили актера, у которого два фильма.
Эти отношения работают в обоих направлениях! Если мы посмотрим на следующую строку, то увидим, что movie_id 1 снова соответствует Дэдпулу, но на этот раз act_id of 3 соответствует актрисе Морене Баккарин. Итак, в фильме может быть несколько актеров. И вот вам суть отношений "многие-ко-многим"!