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

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

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

· Удаление связи многие ко многим. Если в концептуальной модели присутствуют связи типа M:N ("многие ко мно­гим"), то их следует устранить путем определения некоторой промежуточной сущно­сти. Связь типа M:N заменяется двумя связями типа 1:М, устанав­ливаемыми со вновь созданной сущностью.

В данной модели связь многие ко многим существует между сущностями «Абонементы» и «Расписание занятий». Для каждого абонемента следует указывать код расписания занятий, на которые он будет приходить, так как одна и та же услуга может проводиться в разное время. И на каждое занятие может быть записано несколько абонементов. На рисунке 12 изображено отношение многие ко многим между сущностями «Расписание занятий» и «Абонементы».

Рисунок 12-Связь многие ко многим

Чтобы устранить отношение многие ко многим вводится промежуточная таблица «Время посещения занятий» и создаются две новых связи типа один ко многому. Появляется еще один атрибут «Количество занятий», в котором указывается число занятий. Результат преобразования изображен на рисунке 13.

Рисунок 13-Преобразование связи многие ко многим

Аналогично удалим отношение многие ко многим между сущностями «Услуги клиентов» и «Расписание занятий».

· Удаление сложных связей. Проводится удаление любых сложных связей, присутствующих в построенных локальных концептуальных моделях. Сложной называется связь, существующая между тремя и больше типами сущно­стей. Сложная связь устраняется с помощью промежуточной сущности и необходимого количества связей типа 1:М, устанавливаемых со вновь созданной сущностью.

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

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

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

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

Нормализация – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели.

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

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

Для приведения сущности к первой нормальной форме следует:

§ создать новую сущность;

§ перенести в нее все «повторяющиеся» атрибуты;

§ создать первичный ключ у новой сущности;

§ установить связь от прежней сущности к новой.

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

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

Модифицируем курсовой проект и нормализуем сущности. Для этого создадим новые сущности, которые будут отвечать правилам нормализации:

    

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

 

Таблица 11 – «Улицы»

Наименование атрибута	Тип данных	Тип ключа	Not Null	Описание атрибута
Код улицы	Числовой	PK		Код улицы
Название улицы	Строковый			Название улицы

        

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

Таблица 12 – «Должности»

Наименование атрибута	Тип данных	Тип ключа	Not Null	Описание атрибута
Код должности	Числовой	PK		Код должности
Название должности	Строковый			Название должности

Сущность «Помещения». Для того, чтобы каждый раз не вводить название помещения в сущность «Расписание занятий» создадим сущность «Помещения» и добавим в него еще один атрибут «Количество занимающихся», в котором будем указывать максимальное число человек, которые могут заниматься в данном зале.

Таблица 13 – «Помещения»

Наименование атрибута	Тип данных	Тип ключа	Not Null	Описание атрибута
Код помещения	Числовой	PK		Код помещения
Название помещения	Строковый			Название помещения
Количество человек	Числовой			Максимальное количество человек, занимающихся в данном помещении

 

⇐ Предыдущая12345678Следующая ⇒

Поделиться: