Проектирование баз данных

Концептуальное проектирование – процедура конструирования информационной модели предприятия, не зависящей от каких-либо физических условий реализации.

Этап 1. Создание локальной концептуальной модели данных исходя из представлений о ПО каждого из типов пользователей.

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

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

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

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

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

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

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

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

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

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

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

· Выбирают ключ, с которым проще всего работать пользователю

Этап 1.6. Специализация и генерализация (необязательный этап)

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

Этап 1.8. Обсуждение с пользователем

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

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

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

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

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

1. Удаление связей M:N. Если в модели присутствуют связи типа M:N, то их следует устранить путем определения некоторой промежуточной сущности.

2. Удаление сложных связей. Сложной называется связь, существующая между тремя и больше типами сущностей

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

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

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

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

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

Этап 2.2. Определение набора отношений

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

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

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

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

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

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

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

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

Этап 2.7. Обсуждение

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

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

Этап 3.2. Проверка глобальной логической модели

Этап 3.3. Проверка возможности расширения модели

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

Этап 3.5. Обсуждение

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

Этап 4. Перенос глобальной логической модели в среду целевой СУБД

Этап 4.1. Проектирование таблиц в среде целевой СУБД

Этап 4.2. Реализация бизнес правил

Этап 5. Проектирование физического представления БД

Этап 5.1. Анализ транзакций

Этап 5.2. Выбор файловой структуры

Этап 5.3. Определение вторичных индексов

Этап 5.4. Анализ необходимости введения контролируемой избыточности данных

Этап 5.5. Определение требований к дисковой памяти

Этап 6. Разработка механизмов защиты

Этап 6.1. Разработка пользовательских представлений

Этап 6.2. Определение прав доступа