- •Введение
- •Проектирование базы данных
- •1.1. Требования, предъявляемые к базе данных
- •1.2. Этапы жизненного цикла базы данных
- •1.3. Модель "сущность-связь"
- •1.4. Преобразование er-модели в реляционную
- •Нормализация таблиц
- •1.6. Этапы проектирования базы данных и их процедуры
- •1.6.1. Процедуры концептуального проектирования.
- •1.6.2. Процедуры логического проектирования.
- •1.6.3. Процедуры физического проектирования.
- •Создание базы данных.
- •Связь базы данных.
- •Создание таблиц базы данных.
- •Создание запросов базы данных.
- •Создание форм базы данных.
- •Создание отчёта базы данных.
- •Создание макросов базы данных.
- •Sql запросы базы данных.
- •Список источников.
1.6.2. Процедуры логического проектирования.
Цель этапа логического проектирования - преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физической реализации базы данных. Для ее достижения выполняются следующие процедуры.
1. Выбор модели данных. Чаще всего выбирается реляционная модель данных в связи с наглядностью табличного представления данных и удобства работы с ними.
2. Определение набора таблиц исходя из ER-модели и их документирование. Для каждой сущности ER-модели создается таблица. Имя сущности - имя таблицы. Осуществляется формирование структуры таблиц на основан на изложенных в параграфе 1.4 правил. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.
3. Нормализация таблиц. Для правильного выполнения нормализации проектировщик должен глубоко изучить семантику и особенности использования данных. На этом шаге он проверяет корректность структуры таблиц, созданных на предыдущем шаге, посредством применения к ним процедуры нормализации. Эта процедура была описана в параграфе 1.5. Она заключается в приведении каждой из таблиц, по крайней мере, к ЗНФ. В результате нормализации получается очень гибкий проект базы данных, позволяющий легко вносить в нее нужные расширения.
4. Проверка логической модели данных на предмет возможности выполнения всех транзакций, предусмотренных пользователями. Транзакция — это набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого базы данных. Так, примером транзакции в проекте ОБЩЕПИТ может предоставлять различные виды скидок. В этом случае в базу данных потребуется внести сразу несколько изменений. Если во время выполнения транзакции произойдет сбой в работе компьютера, то база данных окажется в противоречивом состоянии, так как некоторые изменения уже будут внесены, а остальные еще нет. Поэтому все частичные изменения должны быть отменены для возвращения базы данных в прежнее непротиворечивое состояние.
Перечень транзакций определяется действиями пользователей в предметной области. Используя ER-модель, словарь данных и установленные связи между первичными и внешними ключами, производится попытка выполнить все необходимые операции доступа к данным вручную. Если какую-либо операцию выполнить вручную не удается, то составленная логическая модель данных является неадекватной и содержит ошибки, которые надо устранить. Возможно, они связаны с пропуском в модели сущности, связи или атрибута.
5. Определение требований поддержки целостности данных и их документирование. Эти требования представляют собой ограничения, которые вводятся с целью предотвратить помещение в базу данных противоречивых данных. На этом шаге вопросы целостности данных освещаются без относительно к конкретным аспектам ее реализации. Должны быть рассмотрены следующие типы ограничений:
• обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;
• ограничения для значений атрибутов. Определяются допустимые значения для атрибутов;
• целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений;
• ссылочная целостность. Она понимается так, что значение внешнего ключа должно обязательно присутствовать в первичном ключе одной из строк таблицы для родительской сущности;
• ограничения, накладываемые производственными - правилами.
Например, в случае с проектом ОБЩЕПИТ может быть принято правило, запрещающее брать более десяти блюд одному человеку.
Сведения обо всех установленных ограничениях целостности данных помещаются в словарь данных.
6. Создание окончательного варианта логической модели данных и обсуждение его с пользователями. На этом шаге подготавливается окончательный вариант ER-модели, представляющей логическую модель данных. Сама модель и обновленная документация, включая словарь данных и реляционную схему связи таблиц, представляется для просмотра и анализа пользователям, которые должны убедиться, что она точно отображает предметную область.
