Контрольные вопросы

1. В чем заключается основная цель этапа концептуального проектирования базы данных?

2. Каковы основные этапы концептуального проектирования базы данных?

3. Как происходит выявление типов сущностей и связей исходя из спецификации требований пользователя?

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

5. Для чего применяется процедура уточнения/обобщения типов сущностей? Почему этот этап концептуального проектирования базы данных является необязательным?

6. Опишите способы проверки избыточности модели данных. Приведите со-

ответствующий пример.

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

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

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

Цель лекции: Изучение методологии логического проектирования баз данных.

Время: 2 часа.

Учебные вопросы:

1. Создание локальной логической модели данных

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

1. Создание локальной логической модели данных

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

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

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

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

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

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

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

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

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

2. Формирование отношений на основе локальной логической модели данных.

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

4. Проверка применимости отношений для выполнения пользовательских транзакций.

5. Определение ограничений целостности.

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