Второй этап проектировании бд (характеристика подэтапов)
Логическое проектирование баз данных реляционного типа
Процесс конструирования общей информационной модели предприятия на основе отдельных моделей данных пользователей, которая является независимой от особенностей реально используемой СУБД и других физических условий.
Этап 2. Построение и проверка локальной логической модели данных для отдельных представлений каждого из типов пользователей.
Этап 3. Создание и проверка глобальной логической модели данных.
Этап 2
Построение и проверка локальной логической модели данных для отдельных представлений каждого из типов пользователей
Цель - Построение логической модели данных на основе концептуальной модели данных, отражающей представление отдельного пользователя о предметной области приложения, и проверка полученной модели с помощью методов нормализации и контроля выполнения транзакций.
Этап 2.1
Преобразование локальной концептуальной модели данных в локальную логическую модель
Цель - Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных.
В результате выполнения первого этапа мы получим набор локальных концептуальных моделей данных, отражающих представление отдельных пользователей о работе предприятия.
Этап 2.2
Определение набора отношений исходя из структуры локальной логической модели данных
Цель - Определение набора отношений на основе локальной логической модели данных.
Этап 2.3 Проверка модели с помощью правил нормализации
Цель Проверка локальной логической модели данных с использованием технологии нормализации.
■ приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов;
■ приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;
■ приведение к третьей нормальной форме (ЗНФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;
■ приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.
Этап 2.4. Проверка модели в отношении транзакций пользователей
Цепь Убедиться в том, что локальная логическая модель данных позволяет выполнить все транзакции, предусмотренные данным представлением пользователя.
Перечень транзакций определяется в соответствии со спецификациями, описывающими действия, выполняемые данным пользователем.
Используя ER-диаграммы, словарь данных и установленные связи между первичными и внешними ключами, указанные в описании отношений, нужно выполнить все необходимые операции доступа к данным вручную.
Два подхода проверки соответствия логической модели
Первый подход предусматривает выполнение проверки того, что данная логическая модель предоставляет всю информацию (сущности, связи и их атрибуты), необходимую для выполнения каждой из транзакций.
Второй подход заключается в нанесении непосредственно на ER-диаграммы всех путей, которые потребуются для выполнения каждой из транзакций.
Этап 2.5 Создание диаграмм „сущность-связь"
Цель Создание окончательного варианта диаграмм "сущность-связь" (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.
Этап 2.6. Определение требований поддержки целостности данных
Цепь Определение ограничений, налагаемых в представлениях пользователей требованием сохранения целостности данных.
Ограничения целостности данных представляют собой такие ограничения, которые вводятся с целью предотвратить помещение в базу противоречивых данных.
Этап 2.7. Обсуждение с конечными пользователями
Цепь Убедиться, что созданные локальные модели данных точно отражают представления пользователей о предметной области приложения.
пять типов ограничений целостности данных
■ обязательные данные;
■ ограничения для доменов атрибутов;
■ целостность сущностей;
■ ссылочная целостность;
■ требования данного предприятия