- •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.6. Обсуждение разработанных локальных логических моделей данных с конечными пользователями
К этому моменту локальная логическая модель данных, соответствующая конкретному пользовательскому представлению, должна быть закончена и полностью описана в документации. Однако прежде чем данный этап разработки можно будет считать полностью завершенным, необходимо обсудить с пользователями созданные логические модели данных и всю сопроводительную документацию.
Если в приложении базы данных предусмотрено только одно представление, то можно непосредственно перейти к этапу физического проектирования базы данных, который описан в следующей главе. А если имеется несколько представлений и применяется подход, предусматривающий интеграцию представлений, необходимо перейти к третьему этапу методологии, описанному ниже. Прежде чем перейти к третьему этапу, предусмотренному обсуждаемой методологией проектирования баз данных, мы кратко познакомимся с полезным дополнительным методом проверки локальных логических моделей данных, выполняемой с помощью диаграмм потоков данных.
Взаимосвязь между логическими моделями данных и диаграммами потоков данных
Логическая модель данных отражает структуру сохраняемых данных организации. Диаграмма потоков данных (Data Flow Diagram – DFD) отображает перемещение данных в пределах организации и размещение их в хранилищах данных. Все атрибуты, которые сохраняются в организации, должны быть объявлены в одном из типов сущностей и, вероятно, могут найти свое место в потоках данных, перемещающихся в пределах организации. Обе эти технологии (основанные на применении логических моделей данных и диаграмм потоков данных) используются для моделирования спецификаций требований пользователей, поэтому каждая из них может применяться для взаимной проверки не¬противоречивости и полноты. Правила, которые определяют отношения между этими двумя технологиями, приведены ниже.
Каждое хранилище данных должно представлять целое число типов сущностей, т.е. ни один тип сущности не должен распределяться по разным хранилищам.
Атрибуты потоков данных должны принадлежать сущности того или иного типа.
2. Создание и проверка глобальной логической модели данных
На данном этапе методологии логического проектирования баз данных путем слияния отдельных локальных логических моделей данных, соответствующих конкретным пользовательским представлениям, создается глобальная логическая модель данных. По завершении объединения локальных моделей может потребоваться проверить правильность полученной глобальной модели как в отношении правил нормализации, так и в отношении возможности выполнения транзакций, предусмотренных спецификациями всех представлений. Проверка происходит с использованием тех же методов, которые применялись при выполнении этапов 2.3 и 2.4. Однако проведение нормализации потребуется только в том случае, если в процессе слияния были внесены изменения в состав отдельных отношений. Аналогичным образом, проверка возможности выполнения транзакций требуется только для тех транзакций, связанных с областями модели, которые были подвергнуты изменениям в ходе слияния. В больших системах подобный подход позволяет существенно сократить объем требуемых повторных проверок.
Хотя каждая отдельная логическая модель данных должна быть корректной, полной и непротиворечивой, любая из них отражает лишь восприятие системы отдельным пользователем или группой пользователей. Иными словами, любая модель представляет собой не модель организации, а модель представления некоторого пользователя об этой организации, и это представление может оказаться неполным. А это означает, что между отдельными моделями в полном наборе представлений могут существовать несовместимость и взаимное перекрытие. Следовательно, при слиянии локальных логических моделей данных в единую глобальную модель придется прилагать усилия для устранения конфликтов между отдельными представлениями, а также устранять их возможное перекрытие.
На этом этапе предусмотрено выполнение следующих действий.
1. Слияние локальных логических моделей данных в единую глобальную модель данных.
2. Проверка глобальной логической модели данных.
3. Проверка возможностей расширения модели в будущем.
4. Обсуждение глобальной логической модели данных с пользователями.