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

Проверка отношений локальной логической модели данных с использованием метода нормализации. Целью выполнения этого этапа является обеспечение того, что каждое из отношений, созданных на основе логической модели данных, соответствует, по крайней мере, требованиям НФБК (нормальной формы Бойса-Кодда).

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

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

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

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

Таблица 2. Рекомендации по выбору способа представления связи суперкласс/подкласс с учетом ограничений степени участия и непересечения

Ограничение степени участия	Ограничение непересечения	Требуемые отношения
Mandatory	Nondisjoint {And}	Одно отношение (с одним или несколькими определителями, позволяющими обозначить тип каждого кортежа)
Optional	Nondisjoint {And}	Два отношения: одно отношение для суперкласса и еще одно отношение для всех подклассов (с одним или несколькими определителями, позволяющими обозначить тип каждого кортежа)
Mandatory	Disjoint {Or}	Много отношений: по одному отношению для каждой комбинации суперкласс/подкласс
Optional	Disjoint {Or}	Много отношений: одно отношение для суперкласса и несколько отношений для каждого подкласса

Этап 2.6. Обсуждение разработанных локальных логических моделей данных с конечными пользователями

Проверка того, что локальная логическая модель данных правильно отражает рассматриваемое представление.

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

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

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

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

• Пересмотр имен и содержимого сущностей/отношений и их потенциальных ключей.

• Пересмотр имен и содержимого связей/внешних ключей.

• Слияние сущностей/связей из отдельных локальных моделей данных.

• Включение (без слияния) сущностей/связей, уникальных для каждой локальной модели данных.

• Слияние связей/внешних ключей из локальных моделей данных.

• Включение (без слияния) связей/внешних ключей, уникальных для каждой локальной модели данных.

• Проверка наличия недостающих сущностей/отношений и связей/внешних ключей.

• Проверка внешних ключей.

• Проверка ограничений целостности.

• Составление глобальной ER-диаграммы/диаграммы отношений.

• Обновление документации.

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

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

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

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

Этап 3.4. Обсуждение глобальной логической модели данных с пользователями

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

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

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

Этап 4.1. Проектирование базовых отношений

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

Этап 4.2. Представление в проекте производных данных

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

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

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

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

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

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

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

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

Определение наиболее эффективной файловой структуры для каждого базового отношения.

Этап 5.3. Выбор индексов

Определение того, будет ли добавление индексов способствовать повышению производительности системы.

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

Оценка объема дискового пространства, необходимого для размещения базы данных.

Этап 6. Проектирование пользовательских представлений

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

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

Разработка механизмов защиты базы данных в соответствии с требованиями пользователей. Документирование проекта средств защиты.

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

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

Этап 9. Текущий контроль и настройка операционной системы

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

[Перейти к началу страницы]

Задания

Вариант 1

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

Фирма является владельцем некоторых товаров (автомобили, бытовая техника, туристское снаряжение и т. п.), которые характеризуются стоимостью, годом выпуска и имеют некоторые технические и эксплуатационные характеристики, по которым клиент осуществляет выбор. Размер месячного взноса за прокат определяется начальной стоимостью товара и сроком его службы. При длительных сроках проката возможна скидка. Кроме того, в каждый момент времени товар может находиться в одном из следующих состояний: в наличии, выдано или в ремонте. Клиент сообщает о себе следующие данные: Ф.И.О.; адрес, документ, подтверждающий личность (наименование, номер, кем выдан). При заказе клиент указывает наименование товара, дату получения его в прокат и срок проката. Возможно в одном заказе указание нескольких товаров. Срок проката может быть продлен заблаговременно (например, за 10 дней до окончания срока проката) путем уведомления об этом фирмы, или же в момент окончания срока проката, при условии, что на этот товар не поступили заказы от других клиентов.

Система должна обеспечивать: проверку возможности выполнения заказа. Если товар выдан или в ремонте, то будет ли он в наличии к дате начала проката. Выдачу информации по группам товаров (например, телевизорам) с информацией об их состоянии; сведения об оплате клиентами услуг проката и выдачу списка должников по оплате и несвоевременной сдаче прокатываемых товаров.

[Перейти к началу страницы]