@Helldrg

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

0

@commun

Не, не считается. Это мой личный вариант.

1

@Helldrg

Воо, а я хотел узнать как в нормализованной форме сделать =)

0

@Панург

А чего тут делать? Стандартно 3 таблицы, в твоём случае - фильмы, жанры и таблица связи с двумя полями (эти поля делаешь составным ключём) для реализации связи "многие-ко-многим". Всё.

2

@texnik-san

Вот я тоже не понимаю, что тут обсуждать две страницы. Первый же ответ в теме был правильным и исчерпывающим.

1

@Helldrg

Я просто не разу не видел нормализованное отношение многим ко многим, обычно оно 1 ко многим

0

mobile

"многие-ко-многим" эмпирическое название, одна из реализаций схемы "звезда" для пары таблиц с таблицей где записываются возможные сочетания ключей из связанных справочников. В отличие от "справочников", где записаны сущности и объекты БД, такие таблицы называются "таблицами фактов" поскольку в них хранится именно деятельность объектов базы. Как частый пример: связь поставщиков с товарами, где есть много поставщиков и много товаров, но каждый поставщик поставляет лишь подмножество товаров и каждый товар может поставляться многими поставщиками. Тогда между Поставщиками и Товарами создают таблицу связи Поставщики_Товары, где хранятся лишь фактические пары идТовара и ИдПоставщика. Вот такая связь 3 таблиц (2 справочников и промежуточной таблицей связи) называется отношением "многие-ко-многим"

4

@commun

да потому как эти жанры и фильмы ...,короче, никого не интересуют. Мы же с другой целью это обсуждаем-у каждого свое. А на схеме многие ко многим нельзя реализовать "борщ" типа: фантастическая комедия (уже применялась и описана ранее в этой же БД), изменение состава которой запрещено и триллера.

0

@texnik-san

И что ж такое есть в отношении "много-ко-многим", что может помешать внести жанр "фантастиеская комедия" в справоник жанров сразу, как только принимается решение считать это самостоятельным жанром, отличным от суммы жанров "фантастика" и "комедия"?

1

@commun

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

1

@Helldrg

Это понятно, такой вариант не нормализован

Добавлено через 1 минуту
Вы очень хорошо описали ситуацию!!!

0

mobile

Мммм... А Вы уверены, что знаете, что такое нормализация?

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

Миниатюры

 

2

@Helldrg

mobile
Я не вижу всех атрибутов данных сущностей поэтому могу предположить, что заказывают сотрудника? Если да, то если у "Клиенты" оставить 2 строчки, у "Заказы" 4 строчки, а у "Сотрудники" 3 строчки то будет нормализованной, при условии, что можно заказывать только одного сотрудника!!! Если же в заказе может быть несколько сотрудников, то уже не нормализованная!!!
P.S.: желательно примеры приводить где 3 - 4 атрибута, а то здесь может быть множество нюансов!

0

mobile

Нет здесь нюансов. Каждая пара Клиенты-Заказы и Сотрудники-Заказы связаны классическим отношением "один-ко-многим". Но вместе они образуют тройку Клиенты-Заказы-Сотрудники, где для каждого Заказа есть однозначно определенная пара КодКлиента, КодСотрудника, связанных с таблицами соответствующих справочников. И получается, что один клиент может иметь множество заказов и каждый сотрудник может быть ответственен за множество заказов. Стандарт! "Многие-ко-многим"

2

@Helldrg

mobile
Так, что делать, если несколько сотрудников могут относиться к заказу?

0

mobile

Ввести еще одну промежуточную таблицу фактов Сотрудники_Заказы. С полями КодСотрудника, КодЗаказа. Связать КодСотрудника с Сотрудниками, КодЗаказа с Заказами. Вот, собственно и все.

2

@Helldrg

Ну в принципе такой вариант уже был, наверно он и правильный. А что делать если 3 или 4 сотрудника могут относиться к заказу?

0

@Бормалей

Как правильно создать отношение фильм - жанр то же самое и делать. Насколько я не опытен, но это же основы.

1

@Helldrg

То есть если нужно добавить 5 сотрудников к 1 заказу нужно 4 таблицы дополнительные делать???

0

@alvk

28 таблиц делать, вам уже ответили:

0

@Бормалей

да так и делай, ты же за нормализацию

1