1.2 Разработка концептуальной и реляционной модели

Поэтапное пособие по концептуальному проектированию БД.

1. Определение типов сущностей.

Могут возникать следующие сложности: 1) использование пользователями при составлении спецификаций синонимов ("отделение" и "филиал"), омонимов ("программа" может обозначать курс обучения или план работ), примеров (употребление в спецификации не обобщенного работника, а одного или нескольких имен); 2) решение о том, чем является определенный объект - сущностью, атрибутом или связью (пример - объект Семейный брак).

2. Определение типов связей.

Могут возникать следующие сложности: 1) возможность присутствия связей, которые объединяют более двух сущностей, и рекурсивных связей; 2) проверка того, выделены ли все связи.

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

Могут возникать следующие сложности: 1) определение, простым или составным является атрибут ("адрес" может сохраняться как единое целое или может быть разбит на составляющие "город", "улица" и т.д.); 2) выявление атрибутов, значение которых могут быть вычислены с помощью других атрибутов, и проверка того, не могут ли быть изменены в дальнейшем значения атрибутов, от которых зависит значение вычисляемого (пример - курс валюты).

4. Определение доменов атрибутов.

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

5. Определение атрибутов, которые являются потенциальными и первичными ключами. Рекомендации из выбора первичного ключа среди потенциальных:

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

• использовать тот потенциальный ключ, вероятность изменения значений которого минимальная;

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

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

• использовать тот потенциальный ключ, с которым проще работать с точки зрения пользователя.

6. Создание диаграммы "сущность-связь".

7. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

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

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

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

Два или больше элементы модели идентичны, если имеют одинаковое семантическое (смысловое) значение.

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

1) в одном представлении агрегатный объект определен как единое целое, а во втором рассматриваются его составные части;

2) агрегатный объект как единое целое не определен ни в одном из представлений, но в обеих представлениях рассматриваются его составные части;

3) один агрегатный объект рассматривается в разных представлениях, но по составу различается.

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

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

Правила преобразования модели "сущность-связь" в реляционные таблицы:

1. объект с атрибутами преобразуется в таблицу;

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

3. конкретизация объекта представляется таблицей, которая содержит ключ таблицы для объекта, который конкретизируется, и дополнительные атрибуты конкретизации;

4. отношение 1:1 преобразуется путем помещения ключа одного из объектов как дополнительного атрибута в таблице второго объекта;

5. в отношении 1:М в таблицу, которая описывает объект, мощность со стороны которого равняется "много", включается столбец, который соответствует ключу объекта, мощность со стороны которого равняется "один», этот столбец будет внешним ключом;

6. для преобразования отношения М:N создаются три таблицы - по одной для каждого объекта и пересечение, которое содержит ключи двух других таблиц.

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

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

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

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

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

Приведение таблиц к 1й, 2й и 3й НФ последовательно устраняет аномалии при включении, удалении и модификации записей соответствующей БД. Процесс нормализации позволяет проектировщику глубже понять семантику атрибутов и их взаимосвязей и упорядочивает проведение анализа данных.

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

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