2.3 Применение правил нормализации

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

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

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

Для того чтобы отношение находилось в 1НФ, необходимо, чтобы оно удовлетворяло следующим условиям:

• в отношении нет одинаковых кортежей;

• кортежи не упорядочены;

• атрибуты не упорядочены и различаются по наименованию;

• все значения атрибутов атомарные [10].

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

Отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ, и все неключевые атрибуты отношения функционально полно зависят от составного ключа отношения. Функционально полная зависимость означает, что атрибут функционально зависит от всего составного потенциального ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него частей. Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа [4].

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

Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

• отношение R (таблица) находится во второй нормальной форме;

• каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

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

Если A -> B и B -> C, то A -> C – транзитивная зависимость, где A — набор ключевых атрибутов (ключ), B и С — различные множества неключевых атрибутов [4].

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