Файл: ДИПЛОМ Аюпова-теория.doc

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

Нормализация – это метод создания набора отношений с заданными свойствами на основе требований, предъявляемых к данным в организации.

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

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

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

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

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

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

Третьей нормальной формой (3НФ) называется отношение, которое находится в 2НФ, причем в нем нет атрибутов, не входящих в первичный ключ, которые транзитивно зависят от этого первичного ключа. Транзитивная зависимость означает следующее: если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А.

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

Четвертой нормальной формой (4НФ) называется отношение, которое находится в НФБК и не содержит нетривиальных многозначных зависимостей. В случае многозначной зависимости, существующей между атрибутами А, В и С некоторого отношения, для каждого значения А имеется набор значений атрибута В и набор значений атрибута С. Однако входящие в эти наборы значения атрибутов В и С не зависят друг от друга.

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

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

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

Otdel (Otdel_№, Otdel_Imya, Tel_№, Fax_№)

Primary Key Otdel_№

Alternate Key Tel_№

Otdel_№ Otdel_Imya, Tel_№, Fax_№

Tel_№ Otdel_№, Otdel_Imya, Fax_№

Rabotnik (Rab_№, Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№)

Primary Key Rab_№

Rab_№ Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№

Object (Object_№, Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec_№)

Primary Key Object_№

Object_№ Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec

Dogovor (Dogovor_№, Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№ )

Primary Key Dogovor_№

Dogovor_№ Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№

Object_№ Cena

При анализе функциональной зависимостиDogovorвыясняется, что имеет место транзитивная зависимость видаObject_№ Cena для первичного ключа Dogovor_№ этого отношения. Подобная зависимость является нарушением третьей нормальной формы (ЗНФ) и, следовательно, должна быть удалена из отношенияDogovor. Однако нет необходимости создавать отдельное отношение для представления этой функциональной зависимости, поскольку она уже представлена в отношенииObject. Кроме того, удаление этой аномалии не потребует измененияER-диаграммы, достаточно будет просто внести соответствующие изменения в документацию.

3.4. Проверка модели в отношении транзакций пользователей.

Назначение этого этапа состоит в проверке локальной логической модели данных представления Менеджер в отношении возможности выполнения всех транзакций, предусмотренных спецификациями. Для этой цели мы используемER-диаграмму, показанную на рис. 3.1.7, а также прилагаемую к ней документацию. Исходя из этих данных, мы предпримем попытку выполнить каждую из транзакций вручную. Если это окажется возможным для всех транзакций, требуемых согласно спецификациям, то можно считать, что данная логическая модель успешно проверена. Если же выполнить вручную некоторую из транзакций окажется невозможным, значит, в логической модели данных присутствует ошибка, которую следует устранить. Вероятнее всего, в модели отсутствует необходимая сущность, связь или атрибут. В то же время, если некоторая часть логической модели окажется излишней для выполнения всего набора требуемых транзакций, даже с учетом возможности его расширения в будущем, есть все основания полагать, что эта часть модели является избыточной и подлежит удалению из окончательного варианта логической модели данных представления.

3.5. Определение требований поддержки целостности данных.

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

3.5.1. Обязательные данные.

Необходимо установить, какие из атрибутов всегда должны содержать одно из допустимых значений. Другими словами, нас интересуют атрибуты, которые всегда должны иметь конкретные значения, отличные от NULL. Например, атрибуты Раб_№ и Полное_Имя (Имя, Фамилия) сущности Работник всегда должны иметь конкретные значения, отличные от пустого. Однако на атрибут Тел_№ этой же сущности данное требование не распространяется, и этот атрибут вполне может иметь значение NULL, означающее, что у работника либо нет телефона, либо номер его неизвестен.

Условие обязательного наличия данных реализовано практически во всех коммерческих СУБД . Это условие целостности требует, чтобы некоторые столбцы не содержали значение NULL. Пользователю предоставляется возможность самостоятельно решить вопрос о том , каким столбцам присваивать значение NULL и каким нет. Это делается при создании таблицы в инструкции CREATE TABLE . Если столбец не может содержать значение NULL , то в этой инструкции на него накладывается ограничение NOT NULL

СУБД обрабатывающая столбец с ограничением NOT NULL проверяет, чтобы ни одна инструкция INSERT или UPDATE не добавляла и не обновляла строку со значением NULL

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