Практический пример MVD3: (транзитивность) Если X ↠ Y и Y ↠ Z, то X ↠ (Z - Y)

Question

Я изучал нормализацию и привязку базы данных и 5NF. Мне было тяжело. Может ли кто-нибудь дать мне некоторые практические примеры правила многозначной зависимости:

MVD3: (транзитивность) Если X ↠ Y и Y ↠ Z, то X ↠ (Z - Y).

Answer 1

Функциональная зависимость/Теория нормализации и нормальные формы вплоть до BCNF и включая их, были разработаны в гипотезе о том, что все атрибуты данных (столбцы/типы/...) являются «атомарными» в определенном смысле. Этот «определенный смысл» уже давно устарел, но по существу он сводился к понятию, что «одно значение ячейки в таблице не может само по себе иметь множество значений». Подумайте, текстовый CSV-список номеров ISBN, таблица, отображаемая как значение в ячейке в таблице (действительно вложенные таблицы), ...

Теперь представьте пример с курсами, профессорами и учебными книгами, которые используются в качестве курса материал. Представьте себе все, что смоделировано в одной таблице из трех столбцов, в которой говорится, что «Профессор (P) преподает курс (C) и использует книгу (B) в качестве материала курса». Если может быть более одной книги (B), используемой для любого данного курса (Cn), и может быть более одного курса (C), преподаваемых любым профессором (Pn), и может быть более одного преподавателя (P) любой заданный курс (Cn), то эта таблица явно имеет все ключи (ключ - полный набор атрибутов {P, C, B}).

Это означает, что эта таблица удовлетворяет требованиям BCNF.

А теперь представьте, что существует правило, согласно которому «набор книг, используемых для любого курса (Cn), должен быть одним и тем же, независимо от того, чему его учит учитель».

В дни, когда нормализация была разработана в форме, в которой она теперь широко известна, не было разрешено иметь столбцы таблицы (атрибуты отношения), которые сами были таблицами (отношениями). (Потому что такая конструкция считалась нарушением 1NF, понятие, которое теперь считается подозрительным.)

Представьте себе на мгновение, что нам действительно разрешено моделировать атрибуты отношения для отношения типа. Затем мы могли бы моделировать нашу таблицу из трех столбцов (/ отношение) следующим образом: «Профессор (P) преподает курс (C) и использует КОМПЬЮТЕР КНИГ (SB) в качестве материала курса». Атрибут SB больше не будет номером ISBN, как в предыдущем и более очевидном дизайне, но он был бы (возможно, унарным) RELATION, в котором хранился весь набор номеров ISBN. Если мы нарисуем наш дизайн так, и тогда мы рассмотрим наше правило, что «все профессора используют один и тот же набор книг для одного и того же курса», то мы видим, что это правило теперь выражается как FD из (C) в (SB) !!! И это означает, что у нас есть нарушение более низкого NF на нашей руке !!!

4 и 5 NF возникли из такого рода проблем (где появление одного значения атрибута -courseID (C) - вызывает требование к появлению множества строк (множественный (B) ISBN номера), которые были признаны довольно рано, но без решения, которое в настоящее время считается лучшим (RVA), которое признано действительным. Таким образом, 4 и 5 NF были созданы «новые и более нормальные формы», где тогдашний определения 2, 3 и БК NF были уже достаточными для решения этой ситуации, если RVA были признаны в качестве действительного подхода к проектированию.

Чтобы поддержать это требование, давайте посмотрим, что делать, чтобы устранить NF нарушение в нашей конструкции {P, C, SB} с FD C-> SB:

Мы разделили таблицу на две отдельные таблицы {P, C} и {C, SB} с помощью клавиш {P, C} и {C}, повторно. Обе таблицы удовлетворяют BCNF.

Но у нас все еще есть этот атрибут SB, который содержит набор номеров ISBN. С этим можно справиться, применяя такую ​​технику, как «UNGROUPING». Применив это к нашей таблице {C, SB}, мы получим таблицу {C, B}, где B - номера книг ISBN (или любой другой идентификатор, который вы хотите использовать в своей базе данных), а ключ к таблице - {C , B}. Это точно такой же дизайн, который мы получили бы, если бы устранили нарушение 4/5 NF !!!

Вы также можете взглянуть на Multivalue Dependency violation?