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

Данный этап включает следующее.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. На данном этапе выполняются следующие действия:

2. Удаление связей типа M: N.

3. Удаление сложных связей.

4. Удаление рекурсивных связей.

5. Удаление связей с атрибутами

6. Удаление множественных атрибутов.

7. Перепроверка связей типа 1:1.

8. Удаление избыточных связей.

1. Удаление связей типа M:N

Если в концептуальной модели присутствуют связи типа M:N ("многие ко мно­гим"), то их следует устранить путем определения некоторой промежуточной сущно­сти (см. раздел 5.2.1). Связь типа M:N заменяется двумя связями типа 1:М, устанав­ливаемыми со вновь созданной сущностью. В качестве примера рассмотрим связь ти­па M:N Newspaper Advertises Property (Газета печатает объявления об объектах, сдаваемых в аренду), представленную на рис. 8.1, а. С целью устранения связи Ad­vertises мы определяем промежуточную сущность Advert и создаем две новых связи типа 1:М (Lists и Advertisedin). В результате связь Advertises типа M:N будет заме­нена двумя связями — Newspaper Lists Advert и Property Advertisedin Advert (как по­казано на рис. 8.1, б).

Обратите внимание: сущность Advert показана как слабая сущность, поскольку ее суще­ствование зависит от сущностей-владельцев, а именно от сущностей Newspaper и Property.

Дата добавления: 2014-01-04