3 ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
3.1 Основные задачи и этапы проектирования
Проектирование баз данных — это
процесс создания схемы базы данных и
определения необходимых ограничений
целостности. Основными задачами проектирования баз данных являются:
•
Обеспечение хранения в БД всей необходимой
информации.
•
Обеспечение возможности получения данных по всем
необходимым запросам.
•
Сокращение избыточности и дублирования данных.
•
Обеспечение целостности данных (правильности их
содержания): исключение противоречий в содержании данных, исключение их потери
и т.д.
Процесс проектирования БД представляет собой
последовательность переходов от неформального словесного описания
информационной структуры предметной области к формализованному описанию
объектов предметной области в терминах некоторой модели. В общем случае можно
выделить следующие этапы проектирования (рис. 13):
Решение проблем проектирования на физическом уровне во
многом зависит от используемой СУБД, зачастую автоматизировано и скрыто от
пользователя. В ряде случаев пользователю предоставляется возможность настройки
отдельных параметров системы, которая не составляет большой проблемы.
Логическое проектирование заключается в определении
числа и структуры таблиц, формировании запросов к БД, определении типов
отчетных документов, разработке алгоритмов обработки информации, создании форм
для ввода и редактирования данных в базе и решении ряда других задач.
Решение задач логического проектирования БД в основном
определяется спецификой задач предметной области. Наиболее важной здесь
является проблема структуризации данных.
3.2 Методы проектирования реляционных баз данных
Основная проблема проектирования реляционной базы данных
состоит в обоснованном принятии решений о том, из каких отношений должна
состоять БД и какие атрибуты должны быть у этих отношений.
Для построения «хорошей» базы данных, которая находилась хотя
бы в третьей нормальной форме, можно использовать следующие методы:
1) Метод
нормальных форм–метод пошаговой декомпозиции,
заключающийся в последовательном разбиении исходной и промежуточных схем
отношений до тех пор, пока результирующие отношения не будут удовлетворять
заданным свойствам.
2) Метод
синтеза, состоящий в конструировании (синтезе) набора декомпозиционных
подсхем, удовлетворяющих определѐнным свойствам, из заданного множества
атрибутов выбранной предметной области на основе заданного множества функциональных
зависимостей, связывающих эти атрибуты.
3) Метод
ER-диаграмм (семантическое моделирование) представляет
собой моделирование структуры данных, опираясь на смысл этих данных. В качестве
инструмента семантического моделирования используются различные варианты
диаграмм сущность-связь (ER – Entity-Relationship).
1.
Метод нормальных форм (классический
метод)представляет собой вариант восходящего подхода при
проектировании БД. Нормализация предусматривает идентификацию требуемых
атрибутов с последующим созданием из них нормализованных таблиц, основанных на
функциональных зависимостях между этими атрибутами (подраздел 2.4).
Восходящий подход в наибольшей степени приемлем для
проектирования простых (как правило, централизованных) БД с относительно
небольшим количеством атрибутов. Однако использование этого подхода существенно
усложняется при проектировании распределенных БД, особенно при интеграции
локальных баз данных, которые могут быть выполнены с использованием различных
моделей данных с большим количеством атрибутов, установить среди которых все
существующие функциональные зависимости довольно затруднительно
2.
Более подходящей стратегией проектирования
сложных баз данных является использование нисходящего подхода (метода
синтеза). Начинается этот подход с разработки моделей данных, которые содержат
несколько высокоуровневых сущностей и связей, затем работа продолжается в виде
серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним
атрибутов. Например, сначала можно было бы идентифицировать сущности ВЛАДЕЛЕЦ и
ОБЪЕКТ_НЕДВИЖИМОСТИ, затем установить между ними связь ВЛАДЕЛЕЦ владеет
ОБЪЕКТОМ_НЕДВИЖИМОСТИ и лишь после этого определить связанные с ними атрибуты —
например, ВЛАДЕЛЕЦ (номер_вл, имя_вл, адрес_вл) и ОБЪЕКТ_НЕДВИЖИМОСТИ(номер_об,
адрес_об).
3.
Все варианты
диаграмм сущность-связь исходят из одной идеи – рисунок всегда нагляднее текстового
описания. Все такие диаграммы используют графическое изображение сущностей
предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Без семантического моделирования можно обойтись, если
число таблиц не превышает десяти, но оно совершенно необходимо, если БД
включает более сотни таблиц.
В настоящее время на рынке существует большое
количество систем автоматизации проектирования баз данных (Сomputer-Аided
Software Engineering – CASE-средств), обеспечивающих автоматизированное преобразование
диаграммных концептуальных схем баз данных, представленных в той или иной
семантической модели данных, в реляционные схемы данных конкретной СУБД
(подраздел 4.1). Все CASE-системы имеют развитые средства документирования
процесса разработки, автоматические генераторы отчетов позволяют подготовить
отчет о текущем состоянии проекта с подробным описанием объектов БД и их
отношений, что существенно облегчает ведение проекта.
3.3 Проектирование базы данных «Университет»
3.3.1 Инфологическое проектирование
Инфологическое
проектирование проводится, как правило, методом последовательных
приближений к удовлетворительному набору схем отношений. Исходной точкой
является представление предметной области в виде одного или нескольких
отношений, а на каждом шаге проектирования производится некоторый новый набор
схем отношений, обладающих лучшими свойствами.
Пусть в результате системного анализа установлена
необходимость отразить в БД сведения о студентах вуза.
При этом БД должна содержать данные о каждом студенте:
СТУДЕНТ(Номер зачетной книжки, Фамилия, Имя, Отчество, Номер группы, Номер
факультета, Наименование, Декан, Номер специальности, Наименование
специальности, Стоимость, Дата рождения, Курс, Коммерческий).
Определим функциональные зависимости в исходном отношении
(рис. 14).
Рисунок 14 – Функциональные зависимости
в исходном отношении СТУДЕНТ
Следовательно, инфологическая модель предметной области
будет иметь вид, показанный на рис. 15.
Рисунок 15 – Инфологическая модель
предметной области
Модель содержит не только информационные объекты, но и
взаимосвязи между ними. Так, связь типа «один ко многим» устанавливается:
•
между объектами ГРУППА и СТУДЕНТ по их общему
атрибуту Номер группы;
•
между объектами ГРУППА и ФАКУЛЬТЕТ по их общему
атрибуту
Номер факультета;
•
между объектами ГРУППА и СПЕЦИАЛЬНОСТЬ по их
общему атрибуту Номер специальности.
Стоит, однако, обратить внимание на то, что полученная
инфологическая модель, в целом удовлетворяющая требованиям нормализации, с
точки зрения логики может некорректно описывать предметную область. Модель
допускает существование некоторой специальности, которая не преподается ни на
одном факультете. Естественным желанием при этом является добавление связи между
объектами ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ. Альтернативой этому может быть определение
домена для атрибута Номер специальности, который будет содержать только
«существующие» номера специальностей.
3.3.2 Даталогическое проектирование
Выполняется описание логических структур сформированных
информационных объектов, предполагаемых к реализации в базе данных. Описания
приведены в табл. 2 – 5.
Таблица 2 – Логическая структура
информационного объекта СТУДЕНТ
Таблица 3 – Логическая структура
информационного объекта ГРУППА
Таблица 4 – Логическая структура
информационного объекта ФАКУЛЬТЕТ
Таблица 5 – Логическая структура
информационного объекта
СПАЦИАЛЬНОСТЬ
После описания информационных объектов необходимо установить
правила ссылочной целостности для
каждой связи инфологической модели.
Правила ссылочной целостности – это
логические конструкции, которые выражают правила использования взаимосвязанных
данных при их добавлении, обновлении и удалении.
В ходе физической реализации БД каждой связи будут
приписаны триггеры ссылочной целостности
(RI-триггеры), которые и обеспечат установленное правило целостности.
Триггеры – это подпрограммы, которые
запускаются всякий раз при выполнении команд вставки (INSERT), обновления(UPDATE)
и удаления (DELETE).
Допустим, что необходимо удалить один из экземпляров
информационного объекта ГРУППА. Экземпляр информационного объекта СТУДЕНТ не
может существовать без соответствующего экземпляра объекта ГРУППА.
Следовательно, необходимо либо запретить удаление группы, в которой числится
хотя бы один студент, либо сразу удалять всех студентов вместе с группой. Такие
правила ссылочной целостности называются RESTRICT
и CASCADE соответственно.
В другой ситуации, когда, например, экземпляр
информационного объекта СТУДЕНТ может существовать без ссылки на номер группы в
объекте ГРУППА, при удалении какой -либо группы информация о ней должна
остаться в объекте СТУДЕНТ. Такое правило называется SET NULL. При этом значение атрибута Номер группы объекта СТУДЕНТ
принимает значение NULL.
Правило SET
DEFAULT устанавливает атрибуту значение по умолчанию. Например, при
«удалении» группы все студенты, которые в ней учились, зачисляются в другую
группу (значению атрибута Номер группы объекта СТУДЕНТ присваивается значение
по умолчанию).
Наконец, правило NONE
не меняет значение атрибута. При «удалении» группы запись о ней «повисает в
воздухе», т. е. экземпляр объекта СТУДЕНТ ссылается на несуществующую уже
запись о группе.
3.3.3 Физическое проектирование
Основной целью физического проектирования базы данных
является описание способа физической реализации логического проекта базы
данных, т.е. реализации базы данных на вторичных запоминающих устройствах. На
этом этапе рассматриваются основные отношения, организация файлов и индексов,
предназначенных для обеспечения эффективного доступа к данным, а также все
связанные с этим ограничения целостности и средства защиты.
Физическое проектирование неразрывно связано с
конкретной СУБД. Между логическим и физическим проектированием существует
постоянная обратная связь, так как решения, принимаемые на этапе физического
проектирования с целью повышения производительности системы, способны повлиять
на структуру логической модели данных.
Комментарии
Отправить комментарий