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

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

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

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

Глава 6. Методология логического проектирования баз данных реляционного типа

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

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

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

Этот этап включает в себя следующую последовательность действий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1.1. Удаление связей типа m:n

Если в концептуальной модели присутствуют связи типа M:N ("многие ко многим"), то их следует устранить путем определения некоторой промежуточной сущности . В качестве примера рассмотрим связь типа M:N Газета Рекламирует Недвижимость (Газета печатает объявления об объектах, сдаваемых в аренду), представленную на рис. 6.1а.

Рис. 6.1а. Связь Газета Рекламирует Недвижимость типа M:N;

Обратите внимание: сущность Объявление показана как слабая сущность, поскольку ее существование зависит от сущностей-владельцев, а именно от сущностей Газета и Недвижимость.

Рис. 6.1б. Устранение связи Рекламирует типа M:N посредством замены ее двумя связями типа 1:М Печатает и Рекламирует и новой сущностью Объявление