Четвертая и пятая нормальные формы.

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

Многозначная зависимость определяется следующим образом.

■ В таблице X существует многозначная зависимость А→В, если в этой таблице можно обнаружить ситуации, в которых пара строк содержит дублирующееся значение А и одновременно существуют другие пары строк, полученные путем перестановки значений В, присутствующих в первой паре.

Прежде всего, для существования многозначной зависимости требуется существование пар строк. А и В могут быть как отдельными атрибутами, так и объединением некоторого набора атрибутов. Тривиальная многозначная зависимость для А→В существует в случае, когда В является подмножеством А или А объединяет B=XS (более крупная таблица содержит исходную таблицу).

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

Определим четвертую нормальную форму.

Таблица X представлена в 4НФ тогда и только тогда, когда она представлена в БКНФ и для любой многозначной зависимости А→В в этой таблице можно сказать, что эта зависимость либо является тривиальной, либо А является суперключом таблицы X.

И последнее. Рассмотрим пятую нормальную форму.

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

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

4.6. Нормализация – за и против.

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

Однако у нормализованной БД есть и недостатки, прежде всего практического характера.

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

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

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

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

■ временем выполнения запросов;

■ временем проведения обновлений;

■ общим необходимым объемом хранилища данных;

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

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

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

 

КОНТРОЛЬНЫЕ ВОПРОСЫ:

1. Сколько существует нормальных форм? Какие из них важны при практической разработке базы данных?

2. Когда таблица представлена в первой нормальной форме?

3. Что означает термин «неделимость поля» в определении первой нормальной формы? Приведите пример иллюстрирующий это понятие?

4. Что означает термин «повторяющиеся поля» в определении первой нормальной формы? Приведите пример иллюстрирующий это понятие?

5. Когда таблица представлена во второй нормальной форме?

6. Когда таблица представлена в третьей нормальной форме?

7. Какие причины могут вынудить отступить от принципа полной нормализации данных проекта?