Процедура нормализации и проектирования
Мы рассмотрели технологию декомпозиции без потерь, применяемую для проектирования базы данных. Основная идея этой технологии состоит в систематическом приведении первоначального отношения, находящегося в 1НФ, к набору меньших отношений, который в некотором заданном смысле эквивалентен исходному отношению, но более предпочтителен. Каждый этап процесса приведения состоит из разбиения на проекции отношений, полученных на предыдущем этапе. При этом заданные ограничения используются на каждом шаге процедуры нормализации для выбора проекций на следующем этапе. Нормализация – это разбиение отношения (таблицы) на несколько отношений, обладающих лучшими свойствами при обновлении, включении и удалении данных. Этот процесс последовательной замены таблицы ее полными декомпозициями выполняется до тех пор, пока все они не будут находиться в 5НФ (на практике обычно ограничиваются приведением отношения к нормальной форме Бойса-Кодда). В общем, можно выделить следующие цели процесса нормализации:
исключение некоторых типов избыточности;
устранение некоторых аномалий обновления, включения и удаления;
проектирование макета базы данных, который являлся бы "хорошим" представлением реального мира, был интуитивно понятен и служил хорошей основой для дальнейшего развития;
упрощение процесса наложения ограничений целостности.
Перечислим основные правила, которые используются в процедуре нормализации.
Унифицированное отношение должно быть приведено к 1НФ.
О
тношения
в 1НФ следует разбить на проекции для
исключения всех функциональных
зависимостей, которые не являются
неприводимыми. Другими словами, если
отношение имеет составной первичный
ключ вида (К1,К2) и включает также поле
F, которое функционально зависит от
части этого ключа, например, от К2, но
не от полного ключа, то в этом случае
рекомендуется сформировать другое
отношение, содержащее К2 и F (первичный
ключ – К2), и удалить F из первоначального
отношения:
В результате такого действия будет получен набор отношений в 2НФ.
Отношения в 2НФ следует разбить на проекции для исключения любых транзитивных функциональных зависимостей. Другими словами, если отношение имеет потенциальный ключ К, не являющийся потенциальным ключом атрибут F1, который функционально зависит от К, и другой неключевой атрибут F2, который функционально зависит от F1, то рекомендуется удалить из исходного отношения атрибут F2 и сформировать другое отношение, содержащее F1 и F2, с первичным ключом F1.
В
результате будет получен набор отношений
в 3НФ.
Отношения в 3НФ рекомендуется разбить на проекции для исключения любых оставшихся функциональных зависимостей, в которых детерминанты не являются потенциальными ключами. В результате будет получен набор отношений в НФБК.
Отношения в НФБК следует разбить на проекции для исключения всех многозначных зависимостей, которые не являются функциональными зависимостями. В результате будет получен набор отношений в 4НФ (на практике такие многозначные зависимости обычно исключаются при создании исходных отношений, отделяя независимые повторяющиеся группы).
Отношения следует разбить на проекции для исключения любых зависимостей соединения, которые не подразумеваются потенциальными ключами, если их можно выявить. Таким образом будет получен набор отношений в 5НФ (полная декомпозиция отношений).
При следовании предложенным правилам необходимо помнить, что разбиение на проекции должно выполняться без потерь данных и с сохранением функциональных и многозначных зависимостей.
Предложенные рекомендации по нормализации являются всего лишь рекомендациями и, возможно, могут существовать ситуации, когда нормализацию не следует выполнять от начала до конца. У такого предположения есть несколько оснований. Во-первых, нормализация может помочь получить в простой форме некоторые ограничения целостности, но кроме функциональных и многозначных зависимостей и зависимости соединения, на практике могут существовать и другие типы зависимостей. Во-вторых, для выбора предпочтительной декомпозиции существует немного критериев. В-третьих, процесс нормализации и сохранение зависимости не всегда совместимы. В-четвертых, не всякую избыточность можно устранить в процессе нормализации.
Проектирование систем баз данных начинается с построения инфологической модели данных, т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги процедуры проектирования:
Представить каждую независимую сущность таблицей базы данных (базовой таблицей) и определить первичный ключ этой базовой таблицы.
Представить каждую ассоциацию (связь между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей.
Представить свойства сущностей как базовые таблицы с внешним ключом, идентифицирующим соответствующие сущности. Специфицировать ограничения на внешние ключи этих таблиц и их первичные ключи.
Для того, чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить процедуру нормализации.
Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги.
Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.
Для наглядного представления структуры проектируемой системы может быть использован язык инфологического моделирования "Таблица-связь", используемый в наиболее распространенных реляционных базах данных. В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени сущности. Строки таблицы – это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, выделяются. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих.