Этап 2.3. Проверка модели с помощью правил нормализации

Цель Проверка локальной логической модели данных с использованием техно­логии нормализации.

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

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

Нормализация проекта позволяет организовать размещение данных в соответст­вии с их функциональными зависимостями. Поэтому данная процедура должна выполняться между этапами концептуального и физического проектирования.

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

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

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

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

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

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

приведение к первой нормальной форме (1НФ), 'позволяющее удалить из отношений повторяющиеся группы атрибутов;

приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;

приведение к третьей нормальной форме (ЗНФ), позволяющее устранить, транзитивную зависимость атрибутов от первичного ключа;

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

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

Дата добавления: 2014-01-04