4. Уровни моделирования базы данных.

Концептуальное проектирование БД

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

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

Концептуальный уровень моделирования включает этапы:

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

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

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

4. Определение атрибутов и связывания их с типами сущностей и связей.

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

6. Определение атрибутов, являющихся потенциальными и первичными ключами.

7. Специализация или генерализация типов сущностей (необязательный этап).

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

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

10. Корректировка модели.

Логическое проектирование

Фаза логического проектирования БД заключается в преобразовании КМ в логическую (ЛМ). На уровне логического моделирования рассматривается необходимость в связях 1:1, удаляются все связи типа m:n (множественные связи – ввод слабых сущностей) и рекуррентные связи (связи, в которых одни и те же сущности участвуют несколько раз и в разных ролях; связи, в которых сущность некоторого типа взаимодействует сама с собой).

Логический уровень включает этапы:

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

2. Создание и проверка глобальной ЛМ.

3. Проверка возможностей расширения модели в будущем.

4. Создание окончательного варианта диаграммы «сущность-связь».

5. Обсуждение глобальной ЛМ с пользователями.

Если КМ содержит рекурсивные связи, они должны быть устранены посредством определения некоторой промежуточной сущности и все связи должны быть заменены на 1:n или 1:1. Если в КМ присутствуют связи типа m:n («многие-ко-многим»), то их следует устранить путем определения некоторой промежуточной сущности (слабой). Связь типа m:n заменяется двумя связями типа 1:n, устанавливаемыми со вновь созданной сущностью. Удаляются все связи со свободными атрибутами, удаляются сложные атрибуты, заменяются простыми, удаляются вычисляемые атрибуты. Проверяются все связи, при необходимости удаляются все избыточные.

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

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

При логическом проектировании разработчик сосредотачивается на том, что надо сделать, а при физическом проектировании он ищет способ, как это сделать. Этап физического проектирования БД имеет обратную связь с логическим проектированием.

Физический уровень моделирования включает этапы:

1. Перенос глобальной ЛМ данных в среду целевой СУБД (проектирование таблиц БД в среде целевой СУБД; реализация бизнес правил предприятия в среде целевой СУБД).

2. Проектирование физического представления БД (анализ транзакций; выбор файловой структуры; определение вторичных индексов; анализ необходимости введения контролируемой избыточности данных; определение требований к дисковой памяти).

3. Разработка механизмов защиты (разработка пользовательских представлений (видов); определение прав доступа; орг-ция мониторинга и настройки функционирования системы).

Все связи на уровне ЛМ долж быть привед-ны к модаль-ти должен одной из сущ-тей или к связи 1:1 с мод-тью «должен» одной из сущ-ти и мод-тью «может» др сущ-ти.