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

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

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

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

Построение отношений для бинарной связи степени 1 : 1

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

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

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

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

Правило 5. Если степень бинарной связи равна 1:n и класс принадлежности n-связной сущности является необязательным, то необходимо формирование трех отношений: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.

Правило 6. Если степень бинарной связи равна m:n, то для хранения данных необходимо три отношения: по одному для каждой сущности, причем ключ каждой сущности используется в качестве первичного ключа соответствующего отношения, и одного отношения для связи. Последнее отношение в числе своих атрибуто должно иметь ключ сущности каждой сущности.

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

Трехсторонние связи

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

Правило 7. В случае трехсторонней связи необходимо использовать четыре предварительных отношения: по одному для каждой сущности6 причем ключ каждой сущности должен служит первичным ключом для соответствующего отношения, и одно для связи. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключ сущности от каждой сущности. Аналогично, для n-сторонней связи требуется n+1 предварительных отношений.

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

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

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

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

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

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

Этап 2.5. Создание диаграммы «сущность-связь».

Создание диаграмм «сущность -связь» (ER- диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.

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

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

Имеются следующие типы ограничений целостности данных:

· обязательные данные;

· ограничения для доменов атрибутов (допустимые значения);

· целостность сущностей (первичный ключ не может содержать пустого значения);

· ссылочная целостность (ограничения внешнего ключа);

· требования данного предприятия.

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

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