3.3.5 Пример построения ideFlX-диаграммы

В качестве примера построения IDEFlX-диаграммы рассмотрим задачу проектирования концептуальной модели для предметной области “РАСПИСАНИЕ” (рис.12).

Рис. 12. Пример IDEF1X-диаграммы.

4. Логическое проектирование

4.1. Обоснование необходимости нормализации.

Как известно, единственным средством структуризации данных в реляционной модели является отношение. Совокупность отношений составляет реляционную базу данных.

Отношения, допустимые в реляционной модели, должны удовлетворять следующему условию.

Каждое значение в отношении, т.е. значение каждого атрибута в каждом кортеже, должно являться атомарным (неделимым).

Иными словами, на пересечении любой строки и любого столбца в таблице должно быть точно одно значение, а не множество значений.

Отношение, удовлетворяющее приведенному выше условию, называется нормализованным.

Ненормализованное отношение достаточно просто преобразуется в эквивалентное нормализованное. Рассмотрим этот процесс на примере. Пусть имеется отношение:

СОТРУДНИК(Фамилия, Адрес),

содержащее кортежи

Петров Пенза, Кирова, 32, 5

Сидоров Пенза, Калинина, 22, 31

Из отношения видно, что атрибут Адрес содержит для каждого сотрудника город, улицу, дом и квартиру его места проживания.

В принципе понятие атомарности атрибута - понятие субъективное. Только проектировщик может определить - атомарный данный атрибут или нет.

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

Для его нормализации необходимо схему отношения записать в виде:

СОТРУДНИК(Фамилия, Город, Улица, Дом, Квартира).

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

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

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

Рациональные варианты группировки атрибутов в отношения должны отвечать следующим правилам:

• выбранные для отношений первичные ключи должны быть минимальными;

• выбранный состав отношений базы данных должен быть минимальным (отличаться минимально избыточностью атрибутов);

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

• перестройка набора отношений при введение новых типов данных должна быть минимальной;

• разброс времени ответа на различные запросы к базе данных должен быть небольшим.

Рассмотрим более подробно те трудности (аномалии), которые возникают при выполнении операций включения, удаления и модификации данных в “неправильном” проекте базы данных.

В качестве примера рассмотрим схему отношения

СОТРУДНИК (ФИО, Кафедра, ФИО_Зав_Каф, Должность)

Аномалия обновления. Атрибут ФИО_Зав_Каф повторяется для каждого сотрудника кафедры. Аномали обновления(или модификация) заключается в том, что если на определенной кафедре меняется ее заведующий, необходимо изменять значение поля ФИО_Зав_Каф во всех кортежах, содержащих сведения о сотрудниках этой кафедры.

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

Аномали может считаться и то, что изменения только одного поля приводит к изменению значений в неопределенном количестве кортежей. Желательно, чтобы одно изменение влияло на один кортеж.

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

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

Аномалия удаления. Когда увольняется последний сотрудник некоторой кафедры, автоматически теряются сведения и о самой кафедре.

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

В приведенном выше примере можно избавиться от аномалий путем разбиения исходной схемы СОТРУДНИК на две схемы СОТРУДНИК И КАФЕДРА,

СОТРУДНИК (ФИО, Должность, Наз_Кафедры)

КАФЕДРА (Наз_Кафедры, ФИО_Зав_Каф).

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