При проектировании базы данных в реляционной СУБД основной целью разра­ботки логической модели данных является создание точного представления дан­ных, связей между ними и требуемых ограничений. Для этого не­обходимо определить, прежде всего, подходящий набор отношений. Метод, используемый при этом, называется нормализацией (normalization). Нормализация представляет собой вариант восходящего подхода к проектированию базы данных, который начинается с установления связей между атрибутами.

Цель нормализации

Нормализация - метод создания набора отношений с заданными свойствами на основе требований к данным, установленным в некоторой орга­низации.

Нормализация часто выполняется в виде последовательности тестов для некоторого отношения с целью проверки его соответствия (или несоответствия) требованиям заданной нормальной формы.

Процесс нормализации является формальным методом, который позволяет идентифицировать отношения на основе их первичных ключей (или потенциальных ключей, как в случае НФБК) и функциональных зависимостей, существующих между их атрибутов. Проектировщики баз данных могут использовать нормализацию в виде наборов тестов, применяемых к отдельным отношениям с целью нормализации реляционной схемы до заданной конкретной формы, что позволит предотвратить возможное возникновение аномалий обновления.

Основная цель проектирования реляционной базы данных заключается в группи­ровании атрибутов и отношения так, чтобы минимизировать избыточность данных и таким образом сократить объем памяти, необходимый для физического хранения от­ношений, представленных в виде таблиц.

Функциональные зависимости

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

Функциональная зависимость - описывает связь между атрибутами отношения. Например, если в отношении. R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается как АВ), то каждое значение атрибута А связано только с одним значением атрибута В. (Причем каждый из атрибутов А и В может состоять из одного или нескольких атрибутов.)

Функциональная зависимость является смысловым (или семантическим) свойст­вом атрибутов отношения. Семантика отношения указывает, как его атрибуты могут быть связаны друг с другом, а также определяет функциональные зависимости меж­ду атрибутами в виде ограничений, наложенных на некоторые атрибуты.

Зависимость между атрибу­тами А и В можно схематически представить в виде диаграммы, показанной на рисунке 5.

Детерминант - детерминантом функциональной зависимости называется атрибут или группа атрибутов, расположенная на диаграмме функциональ­ной зависимости слева от символа стрелки.

Рисунок 5 - Диаграмма функциональной за­висимости

При наличии функциональной зависимости атрибут или группа атрибутов, распо­ложенная на ее диаграмме слева от символа стрелки, называется детерминантом (determinant). Например, на рис. 6.1 атрибут А является детерминантом атрибута В.

Концепция функциональной зависимости является центральным понятием про­цесса нормализации.

Информация всегда имела адекватный динамичный интерес. Развитие языков программирования, реляционных баз данных и информационных технологий кардинально изменило содержание и структуру интереса. Сложилась определенная строгая система представлений. Формализация, точная математика и бинарные отношения стали успешной и, стремительно развивающейся, областью знаний и опыта.

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

Информация > формализация >> данные

Информация, превращается в информационная структура, база данных…) так, как это видит программист. Нет никакой гарантии, что это видение правильно, но если его программа решает поставленную задачу, значит данные были представлены возможно надлежащим образом.

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

Функциональная зависимость: «правильное решение = программа (программист)» и условие: «непрерывное соответствие задаче» действительны в большинстве случаев, но только совместно. Но это не та математическая основа, которая применяется при создании баз данных.

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

и базы данных

Как хранятся данные уже давно неважно: будь то оперативная память или внешнее устройство. Аппаратная составляющая достигла уверенных темпов развития и обеспечивает хорошее качество в больших объемах.

Основные варианты хранения, отличающиеся вариантами использования данных:

• файлы;
• базы данных.

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

Скорость выборки и записи информации при работе с файлами (разумного размера, а не астрономического) очень быстра, а скорость аналогичных операций с базой данных может порой быть заметно медленной.

Личный опыт и коллективный разум

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

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

Даже в самом простом случае программист зависит от логики базы данных, какую бы он ни выбрал для работы. Нет желания следовать канонам, можно использовать файлы, получится много файлов и много личного опыта. Будет потрачено много личного времени и задача будет решена за длительное время.

Какими бы сложными ни казались примеры функциональной зависимости, вовсе не обязательно погружаться в глубины смысла и логики. Часто следует признать, что коллективный разум сумел создать отличные базы данных, различного размера и функциональности:

• солидный Oracle;
• требовательный MS SQL Server;
• популярный MySQL.

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

Особенности программирования и данных

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

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

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

Бывают случаи, когда общий хостинг ограничивает функциональность PHP и это накладывает отпечаток на программирование доступа к базе данных.

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

БД: простая зависимость в данных

Прежде всего, понятие БД - это и база данных как система управления (например, MySQL), так и некая информационная структура, отражающая данные задачи и связи между ними. Одна база MySQL «держит» на себе сколько угодно информационных структур по различным сферам применения. Одна база Oracle, может обеспечивать информационные процессы крупной компании или банка, контролировать вопросы безопасности и сохранности данных на высочайшем уровне, располагаясь на множестве компьютеров, находящихся на различном удалении, в различных инструментальных средах.

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

Имя каждой колонки в каждой таблице должно быть уникальным в контексте задачи. Одно и то же данное не может быть в двух таблицах. Знать смысл понятий:

• «определить сущности»;
• «исключить избыточность»;
• «зафиксировать взаимосвязи»;
• «обеспечить достоверность».

Элементарная необходимость для использования базы данных и построения модели данных для конкретной задачи.

Нарушение любого из этих понятий - низкая эффективность алгоритма, медленная выборка данных, потеря данных, и другие неприятности.

Функциональная зависимость: логика и смысл

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

Не обязательно, но вовсе не помешает представлять функциональную зависимость как:

F(x1, x2, …, xN) = (y1, y2, …, yN).

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

Обычно, таблицы преобразуются друг в друга, потом в результат. Но использование функциональной зависимости не ограничивается только такой идеей. Программист сам строит свое представление картины данных, информационной структуры… неважно, как это именовать, но если оно работает на конкретной базе данных, оно должно строиться по ее логике, учитывать ее смысл и диалект используемого языка, как правило, SQL.

Можно утверждать, что свойства функциональных зависимостей базы данных доступны через диалект используемого языка SQL. Но гораздо важнее понимать: после всех перипетий развития, не так много баз данных выжило, но диалектов этого языка много и особенностей внутренних конструкций в базах тоже.

О старом добром Excel

Когда компьютер показал себя с положительной стороны, мир сразу разделился на программистов и пользователей. Как правило, первые используют:

• PHP, Perl, JavaScript, C++, Delphi.
• MySQL, Oracle, Visual FoxPro.

• Word.
• Excel.

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

Опыт работы пользователей в Excel по созданию баз данных - практичен и интересен. Важно то, что Excel, сам по себе, функционален, красочен и практичен.

Табличная идея, определила понятие функциональной зависимости наглядно и доступно, но нюансы есть у каждой базы данных. У каждой свое «лицо», но все от Excel до Oracle манипулируют простыми квадратами, то есть таблицами.

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

Что такое функциональная зависимость, с чем, куда, почему… очевидно только автору или коллективу таковых.

О том, куда реляционные отношения идут

Научно-технический прогресс - весьма мучительная процедура, а местами жестокая. Если вспомнить с чего начинались базы данных, что такое *.dbf, как клеймили кибернетику, потом полюбили информатику и стали устраивать препоны перемещению высоких технологий на уровне стран, становится ясно почему реляционные базы данных так живучи и хороши. Почему классический стиль программирования по сей день живет, а объектно-ориентированное программирование просто ценится, но еще не властвует.

Как бы ни была прекрасна функциональная зависимость в контексте математики:

Это не бинарные отношения, точнее, это повод переосмыслить идею устанавливать отношения между множеством атрибутов, исследовать связи «один к многим», «многие к одному», «многие ко многим» или «многие вообще, а одни в частности».

Вариантов отношений можно придумать великое множество. Это математика с логикой, и она строгая! Информация - это своя математика, особенная. В ней о формальности можно говорить только с очень большим минусом.

Можно формализовать работу отдела кадров, написать АСУ для добычи нефти или производства молока, хлеба, сделать выборку в огромной базе гугла, яндекса или рамблера, но результат будет всегда статичен и каждый момент времени одинаков!

Если функциональная зависимость = строгая логика и математика = основа для баз данных, то о какой динамике можно вести речь. Любое решение будет формальным, любая формальная модель данных + строгий алгоритм = точное и однозначное решение. Информация и область применения любой программы меняются всегда.

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

Даже если программа чисто математическая и ее база данных даже не мыслит о динамике, все всегда есть строки . А у строки есть длинна. И бесконечной она быть не может. Она не может быть даже переменной, только условно-переменной. Помимо всего прочего, любая база данных своим математическим и бинарным-бюрократическим аппаратом накладывает массу формальностей, а это скорость+качество выборки и обработки информации.

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

Если сменить тон и прислушаться к пульсу динамики, то все можно расписать на объекты. В первом приближении имя колонки в таблице - это объект, список имен - тоже объект, короче таблица - это объект шапки и в нем имена колонок в шапке. И шапки может вовсе не быть...

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

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

Что такое функция? Функциональная зависимость, или функция, - это такая зависимость между двумя переменными, при которой каждому значению независимой переменной соответствует единственное значение зависимой переменной. Независимую переменную иначе называют аргументом, а о зависимой говорят, что она является функцией от этого аргумента. Все значения, которые принимает независимая переменная, образуют область определения функции.

Существует несколько способов задания функции: 1.С помощью таблицы. 2.Графический. 3.С помощью формулы. Графиком функции называется множество всех точек координатной плоскости, абсциссы которых равны значениям аргумента, а ординаты - соответствующим значениям функции.

Линейной функцией называется функция, которую можно задать формулой вида y=kx+b, где x – независимая переменная, k и b – заданные числа. Для построения графика линейной функции достаточно найти координаты двух точек графика, отметить эти точки в координатной плоскости и провести через них прямую. Прямая пропорциональность – функция вида у=кх, где х – независимая переменная, к – не равное нулю число. Графиком прямой пропорциональности является прямая, проходящая через начало координат.

Построение графика линейной функции Для построения графика линейной функции необходимо: - выбрать любые два значения переменной х (аргумента), например 0 и 1; - вычислить соответствующие значения переменной y (функции). Полученные результаты удобно записывать в таблицу x01 y - полученные точки А и В изображаем в системе координат; - соединяем по линейке точки А и В. Пример. Построим график линейной функции y = -3·x+6. x01 y63

Обратной пропорциональностью называется функция, которую можно задать формулой вида у=k/х, где х - независимая переменная и k - не равное нулю число. Областью определения такой функции является множество всех чисел, отличных от нуля. Если величины x и y обратно пропорциональны, то функциональная зависимость между ними выражается уравнением y = k / x, где k есть некоторая постоянная величина. График обратной пропорциональности есть кривая линия, состоящая из двух ветвей. Этот график называют гиперболой. В зависимости от знака k ветви гиперболы расположены либо в 1 и 3 координатных четвертях (k положительно), либо во 2 и 4 координатных четвертях (k отрицательно). На рисунке изображен график функции y = k/х, где k – отрицательное число.

ЧАСТНЫЕ СЛУЧАИ ЛИНЕЙНОЙ ФУНКЦИИ. y=kx, k0, b=0 - прямая пропорциональность,. График - прямая, проходящая через начало координат; y=b, k=0, b0. (b>0, выше оси OX; b 0, выше оси OX; b"> 0, выше оси OX; b"> 0, выше оси OX; b" title="ЧАСТНЫЕ СЛУЧАИ ЛИНЕЙНОЙ ФУНКЦИИ. y=kx, k0, b=0 - прямая пропорциональность,. График - прямая, проходящая через начало координат; y=b, k=0, b0. (b>0, выше оси OX; b"> title="ЧАСТНЫЕ СЛУЧАИ ЛИНЕЙНОЙ ФУНКЦИИ. y=kx, k0, b=0 - прямая пропорциональность,. График - прямая, проходящая через начало координат; y=b, k=0, b0. (b>0, выше оси OX; b">

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

Рассмотрим для примера конкретную схему отношений и проанализируем её недостатки. Предположим, что данные о студентах, факультетах, специальностях, включены в таблицу со следующей схемой отношения: СТУДЕНТ (Код студента, Фамилия, Название факультета, Название специальности).

Эта схема отношений обусловливает следующие недостатки соответствующей базы данных :

• Дублирование информации (избыточность). У студентов, обучающихся на одном факультете, будет повторяться название факультета. Для разных факультетов будут повторяться специальности.
• Потенциальная противоречивость (аномалии обновления ). Если, например, изменится название специальности, то изменяя её в одном кортеже (у одного студента), необходимо изменять и во всех других кортежах, где она присутствует.
• Потенциальная возможность потери сведений (аномалии удаления ). При удалении информации о всех студентах, поступающих на определенную специальность, мы теряем все сведения об этой специальности.
• Потенциальная возможность невключения информации в базу данных (аномалии включения ). В базе данных будут отсутствовать сведения о специальности, если на ней нет обучающихся студентов.

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

Нормализация. Первая нормальная форма .

Построение рационального варианта схем отношений (обладающего лучшими свойствами при операциях включения, модификации и удаления данных, чем все остальные наборы схем) осуществляется путем так называемой нормализации схем отношений . Нормализация производится в несколько этапов. На начальном этапе схема отношений должна находиться в первой нормальной форме ( 1НФ ).

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

Рассмотрим следующий пример.

Таблица представляет сущность ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ

Код студента	Фамилия	Код экзамена	Предмет и дата	Оценка
1	Сергеев	1	Математика 5.06.08	4
2	Иванов	1	Математика 5.06.08	5
1	Сергеев	2	Физика 9.06.08	5
2	Иванов	2	Физика 9.06.08	5

Теперь на пересечении любой строки и любого столбца находится одно значение и, следовательно, данная таблица находится в первой нормальной форме .

Далее отношение , представленное в первой нормальной форме , последовательно преобразуется во вторую и третью нормальные формы . Процесс построения второй и третьей нормальных форм будет описан в следующих подразделах. При некоторых предположениях о данных третья нормальная форма является искомым наилучшим вариантом.

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

Прежде чем перейти к построению второй нормальной формы , необходимо определить ряд формальных понятий.

8.2. Функциональные зависимости (зависимости между атрибутами отношения)

Пусть R(A 1 , A 2 , ..., A n) – схема отношения , а X и Y – подмножества {A 1 , A 2 , ..., A n } .

Функциональная зависимость на отношении R – это утверждение вида "Если два кортежа R совпадают по атрибутам множества (т.е. эти кортежи имеют в соответствующих друг другу компонентах одни и те же значения для каждого атрибута множества X ), то они должны совпадать и по атрибутам множества . Формально эта зависимость записывается выражением X -> Y , причем говорится, что X функционально определяет Y . Часто используется другое утверждение: X функционально определяет Y или Y функционально зависит от X (обозначается X -> Y ) тогда и только тогда, когда каждое значение множества X отношения R связано с одним значением множества Y отношения R . Иначе говоря, если два кортежа R совпадают по значению X , они совпадают и по значению Y .

Замечание. Вообще говоря, под термином " отношение " могут подразумеваться два понятия:

• отношение как переменная, которая может принимать разные значения (таблица, в строки и столбцы которой могут быть вписаны разные значения);
• отношение, как набор конкретных значений (таблица с заполненными элементами).

Функциональные зависимости характеризуют все отношения, которые могут быть значениями схемы отношения R в принципе. Поэтому единственный способ определить функциональные зависимости – внимательно проанализировать семантику (смысл) атрибутов.

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

Пример функциональных зависимостей для отношения ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ

Код студента -> Фамилия Код студента, Код экзамена -> Оценка

Пример функциональных зависимостей для отношения СТУДЕНТ, приведенного в начале настоящей лекции

Код студента -> Фамилия, Код студента -> Факультет

Заметим, что последняя зависимость существует при условии, что один студент не может обучаться на нескольких факультетах.

Полное множество функциональных зависимостей

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

Заданное множество функциональных зависимостей для отношения R обозначим F , полное множество функциональных зависимостей, которые логически можно получить из F , называется замыканием F и обозначается F + .

Если множество функциональных зависимостей совпадает с замыканием данного множества, то такое множество функциональных зависимостей называется полным .

Введенные понятия позволяют формально определить понятие ключа.

Пусть существует некоторая схема R с атрибутами A 1 A 2 ...A n , F – некоторое множество функциональных зависимостей и X – некоторое подмножество R . Тогда X называется ключом, если, во-первых, в F + существует зависимость X -> A 1 A 2 ...A n и, во-вторых, ни для какого подмножества Y , входящего в X , зависимость Y -> A 1 A 2 ...A n не принадлежит F + .

Полной функциональной зависимостью называется зависимость неключевого атрибута от всего составного ключа .

Частичной функциональной зависимостью будем называть зависимость неключевого атрибута от части составного ключа .

Для вычисления замыкания множества функциональных зависимостей используются следующие правила вывода (

Функциональные зависимости

Функциональная зависимость описывает связь между атрибутами и является одним из основных понятий нормализации. Предположим, что реляционная схема имеет атрибуты (A, B, C,…, Z) и вся база может быть представлена в виде одного универсального отношения R=(A, B, C,…, Z). Следовательно, каждый атрибут в базе имеет уникальное имя.

Если A и B – атрибуты некоторого отношения R, и каждое значение А связано с одним и только одним значением В (причем каждый из атрибутов может состоять из одного или нескольких атрибутов), то атрибут В функционально зависим от атрибута А (ВàА).

Функциональная зависимость, справедливая при любых условиях, называется тривиальной . Нетривиальные зависимости определяют ограничения целостности для отношений.

Транзитивная зависимость для атрибутов A, B и C некоторого отношения означает следующее: если АàВ и ВàС, то С транзитивно зависит от атрибута А через атрибут В (при условии, что А функционально не зависит от В или С).

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

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

Таблица, находящаяся в первой нормальной форме, должна отвечать следующим требованиям:

1) таблица не должна иметь повторяющихся записей;

2) в таблице должны отсутствовать повторяющиеся группы полей;

3) каждое поле должно быть семантически неделимым.

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

Функциональная зависимость АàВ является полной функциональной зависимостью, если удаление какого либо атрибута из А приводит к утрате этой зависимости. Функциональная зависимость АàВ называется частичной , если в А есть некий атрибут при удалении которого эта зависимость сохраняется.

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

Нормальная форма Бойса-Кода (НФБК) основана на функциональных зависимостях, в которых учитываются все потенциальные ключи отношения, но с более строгими ограничениями.

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

Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами.

Различие между 3НФ и НФБК заключается в том, что функциональная зависимость АàВ допускается в отношении 3НФ, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. В отношении НФБК эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно, НФБК является более строгой версией 3НФ, поскольку каждое отношение НФБК является 3НФ, но не всякое отношение 3НФ является НФБК.

Отношения находятся в НФБК только в том случае, если каждый его детерминант является потенциальным ключом.

Четвертая нормальная форма (4НФ) – отношение в НФБК, которое не содержит нетривиальных многозначных зависимостей.

Многозначная зависимость представляет такую зависимость между атрибутами отношения (например А, В и С), что каждое значение А представляет собой множество значений для В и множество значений для С. Однако множество значений В и С не зависят друг от друга.

Многозначная зависимость может быть дополнительно определена как тривиальная или нетривиальная. Многозначная зависимость АàВ некоторого отношения R определяется как тривиальная, если атрибут В является подмножеством атрибута А или . И наоборот, многозначная зависимость определяется как нетривиальная, если ни то ни другое условие не выполняется. Тривиальная многозначная зависимость не накладывает никаких ограничений на данное отношение, а нетривиальная – накладывает.

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

Пятая нормальная форма (5НФ), которая также называется проективно-соединительной нормальной формой, означает, что отношение в такой форме не имеет зависимостей соединения. Отношение R с подмножеством атрибутов А,В,…,Z удовлетворяет зависимости соединения, если каждое допустимое значение R равно соединению его проекций на подмножества А,В,…,Z.