- •2. Создание локальной концептуальной модели данных
- •Этап 1.1 .Определение типов сущностей
- •Этап 1.2. Определение типов связей
- •Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей
- •Этап 1.4. Определение доменов атрибутов
- •Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами
- •Этап 1.6. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап)
- •Этап 1.7. Проверка модели на отсутствие избыточности
- •Этап 1.8 Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям
- •Этап 1.9. Обсуждение локальных концептуальных моделей данных с конечными пользователями
- •Контрольные вопросы
- •Этап 2.1. Исключение особенностей, несовместимых с реляционной моделью (необязательный этап)
- •1 .Удаление двухсторонних связей "многие ко многим" (*:*)
- •2. Удаление рекурсивных связей "многие ко многим" (*:*)
- •3. Удаление сложных связей
- •4. Удаление многозначных атрибутов
- •Этап 2.2. Определение набора отношений, исходя из структуры локальной логической модели данных
- •1. Сильные типы сущностей
- •2. Слабые типы сущностей
- •3. Двухсторонние связи типа "один ко многим" {1:*}
- •4. Двухсторонние связи типа "один к одному" (1:1)
- •5. Рекурсивные связи "один к одному" (1:1)
- •6. Связи типа суперкласс/подкласс
- •7. Двухсторонние связи "многие ко многим" (*:*)
- •8. Сложные типы связей
- •9. Многозначные атрибуты
- •Этап 2.3. Проверка отношений с помощью правил нормализации
- •Этап 2.4. Проверка соответствия отношений требованиям пользовательских транзакций
- •Этап 2.5. Определение требований поддержки целостности данных
- •Этап 2.6. Обсуждение разработанных локальных логических моделей данных с конечными пользователями
- •2. Создание и проверка глобальной логической модели данных
- •Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных
- •1. Анализ имен и содержимого сущностей/отношений и их потенциальных ключей
- •2. Анализ имен и содержимого связей/внешних ключей
- •3. Слияние сущностей/отношений, соответствующих локальным моделям данных
- •4. Включение (без слияния) сущностей/отношений, характерных только для отдельных локальных моделей данных
- •5. Слияние связей/внешних ключей из отдельных локальных моделей данных
- •6. Включение (без слияния) связей/внешних ключей, характерных только для отдельных локальных моделей данных
- •7. Проверка того, нет ли пропущенных сущностей/отношений и связей/внешних ключей
- •8. Проверка внешних ключей
- •9. Проверка ограничений целостности
- •10. Формирование глобальной er-диаграммы/схемы отношений
- •11. Обновление документации
- •Этап 3.2. Проверка глобальной логической модели данных
- •Этап 3.3. Проверка возможностей расширения модели в будущем
- •Этап 3.4. Обсуждение глобальной логической модели данных с пользователями
- •Контрольные вопросы
- •2. Этапы физического проектирования Этап 4. Перенос глобальной логической модели данных в среду целевой субд
- •Этап 4.1. Проектирование основных отношений
- •Этап 4.2. Разработка способов получения производных данных
- •Этап 4.3. Реализация ограничений предметной области
- •Этап 5. Проектирование физического представления базы данных
- •Этап 5.1. Анализ транзакций
- •Этап 5.2. Выбор файловой структуры
- •Этап 5.3. Определение индексов
- •Этап 5.4. Оценка потребности в дисковом пространстве
- •Этап 6. Проектирование пользовательских представлений
- •Этап 7. Проектирование средств защиты
2. Этапы физического проектирования Этап 4. Перенос глобальной логической модели данных в среду целевой субд
Самым первым заданием на этапе физического проектирования баз данных является преобразование отношений, созданных на основе глобальной логической модели данных, в такую форму, которая может быть реализована в среде целевой СУБД. Первая часть этого процесса предусматривает проверку информации, собранной на этапе логического проектирования базы данных и помещенной в словарь данных. Вторая часть процесса заключается в использовании этой информации для разработки проекта основных отношений. Этот процесс требует наличия глубоких знаний о функциональных возможностях, предоставляемых целевой СУБД. В частности, разработчик должен знать следующее:
способы создания основных отношений;
поддерживает ли система определение первичных, внешних и альтернативных ключей;
поддерживает ли система определение обязательных данных (т.е. допускает ли система указывать в определении атрибута, что для него запрещено использование значения NULL);
поддерживает ли система определение доменов;
поддерживает ли система реляционные ограничения целостности;
поддерживает ли система определение ограничений предметной области.
На этапе 4 процедуры разработки баз данных выполняются следующие действия.
1. Проектирование основных отношений.
2. Разработка способов получения производных данных.
3. Реализация ограничений предметной области.
Этап 4.1. Проектирование основных отношений
Приступая к физическому проектированию, прежде всего необходимо проанализировать и хорошо усвоить информацию об отношениях, собранную на этапе построения логической модели базы данных. Эта информация может содержаться в словаре данных и в определениях отношений, записанных на языке DBDL. Определение каждого выделенного в глобальной логической модели данных отношения включает следующие элементы.
имя отношения;
список простых атрибутов, заключенный в круглые скобки;
определение первичного ключа и (если таковые существуют) альтернативных (АК) и внешних (FK) ключей;
список производных атрибутов и описание способов их вычисления;
определение требований ссылочной целостности для любых внешних ключей.
Для каждого атрибута в словаре данных должна присутствовать следующая информация;
определение его домена, включающее указание типа данных, размерность внутреннего представления атрибута и любые требуемые ограничения на допустимые значения;
принимаемое по умолчанию значение атрибута (необязательно);
допустимость значения NULL для данного атрибута.
Реализация основных отношений
Теперь необходимо принять решение о способе реализации основных отноше¬ний. Это решение зависит от типа выбранной целевой СУБД – при определении основных отношений некоторые системы предоставляют больше возможностей, чем другие.
Документальное оформление проекта основных отношений
Подготовленный проект основных отношений должен быть подробно описан в сопроводительной документации с указанием причин, по которым был выбран данный конкретный проект. В частности, необходимо указать, почему был выбран именно этот подход, если есть целый ряд других вариантов.