Тема 1.4 Этапы проектирования баз данных

Проектирование баз данных — это процесс создания схемы базы дан- ных и определения необходимых ограничений целостности. Основными за- дачами проектирования баз данных являются:

·        Обеспечение хранения в БД всей необходимой информации.

·        Обеспечение возможности получения данных по всем необходимым запросам.

·        Сокращение избыточности и дублирования данных.

·        Обеспечение целостности данных (правильности их содержания): исклю- чение противоречий в содержании данных, исключение их потери и т.д.

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структу- ры предметной области к формализованному описанию объектов предметной

области в терминах некоторой модели. В общем случае можно выделить сле- дующие этапы проектирования (рис. 13):

Рисунок 13 – Этапы проектирования БД

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

Логическое проектирование заключается в определении числа и струк- туры таблиц, формировании запросов к БД, определении типов отчетных до- кументов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.

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

1.1  Методы проектирования реляционных баз данных

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

Для построения «хорошей» базы данных, которая находилась хотя бы в

третьей нормальной форме, можно использовать следующие методы:

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

2)    Метод синтеза, состоящий в конструировании (синтезе) набора декомпозиционных подсхем, удовлетворяющих определѐнным свойствам, из заданного множества атрибутов выбранной предмет- ной области на основе заданного множества функциональных зави- симостей, связывающих эти атрибуты.

3)    Метод ER-диаграмм (семантическое моделирование) представ- ляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирова- ния используются различные варианты диаграмм сущность-связь (ER – Entity-Relationship).

1.    Метод нормальных форм (классический метод)представляет собой

вариант восходящего подхода при проектировании БД. Нормализация преду- сматривает идентификацию требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимо- стях между этими атрибутами (подраздел 2.4).

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

2.  Более подходящей стратегией проектирования сложных баз данных яв- ляется использование нисходящего подхода (метода синтеза). Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуров- невых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов. Например, сначала можно было бы идентифицировать сущности ВЛАДЕЛЕЦ и ОБЪЕКТ_НЕДВИЖИМОСТИ, затем установить между ними связь ВЛАДЕЛЕЦ владеет ОБЪЕКТОМ_НЕДВИЖИМОСТИ и лишь после этого определить свя- занные с ними атрибуты — например, ВЛАДЕЛЕЦ (номер_вл, имя_вл, адрес_вл) и ОБЪЕКТ_НЕДВИЖИМОСТИ(номер_об, адрес_об).

3.  Все варианты диаграмм сущность-связь исходят из одной идеи – ри- сунок всегда нагляднее текстового описания. Все такие диаграммы исполь- зуют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

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

В настоящее время на рынке существует большое количество систем ав- томатизации проектирования баз данных (Сomputer-Аided Software Engineer- ing – CASE-средств), обеспечивающих автоматизированное преобразование диаграммных концептуальных схем баз данных, представленных в той или иной семантической модели данных, в реляционные схемы данных конкрет- ной СУБД (подраздел 4.1). Все CASE-системы имеют развитые средства до- кументирования процесса разработки, автоматические генераторы отчетов по- зволяют подготовить отчет о текущем состоянии проекта с подробным описа- нием объектов БД и их отношений, что существенно облегчает ведение проек- та.

 

 

1.2  Проектирование базы данных «Университет»

1.2.1  Инфологическое проектирование

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

Пусть в результате системного анализа установлена необходимость от- разить в БД сведения о студентах вуза.

При этом БД должна содержать данные о каждом студенте: СТУ- ДЕНТ(Номер зачетной книжки, Фамилия, Имя, Отчество, Номер группы, Номер факультета, Наименование, Декан, Номер специальности, Наименова- ние специальности, Стоимость, Дата рождения, Курс, Коммерческий).

Определим функциональные зависимости в исходном отношении (рис. 14).

 

Рисунок 14 – Функциональные зависимости в исходном отношении СТУДЕНТ Следовательно, инфологическая модель предметной области будет

иметь вид, показанный на рис. 15.

Рисунок 15 – Инфологическая модель предметной области Модель содержит не только информационные объекты, но и взаимо-

связи между ними. Так, связь типа «один ко многим» устанавливается:

·        между объектами ГРУППА и СТУДЕНТ по их общему атрибуту Номер группы;

·        между объектами ГРУППА и ФАКУЛЬТЕТ по их общему атрибуту Номер факультета;

·        между объектами ГРУППА и СПЕЦИАЛЬНОСТЬ по их общему ат- рибуту Номер специальности.

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

допускает существование некоторой специальности, которая не преподается ни на одном факультете. Естественным желанием при этом является добав- ление связи между объектами ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ. Альтер- нативой этому может быть определение домена для атрибута Номер специ- альности, который будет содержать только «существующие» номера специ- альностей.

1.2.2  Даталогическое проектирование

Выполняется описание логических структур сформированных инфор- мационных объектов, предполагаемых к реализации в базе данных. Описания приведены в табл. 2 – 5.

 

Таблица 2 – Логическая структура информационного объекта СТУДЕНТ

 

Таблица 3 – Логическая структура информационного объекта ГРУППА

Таблица 4 – Логическая структура информационного объекта ФАКУЛЬТЕТ

 

Таблица 5 – Логическая структура информационного объекта

СПАЦИАЛЬНОСТЬ

После описания информационных объектов необходимо установить

правила ссылочной целостности для каждой связи инфологической модели.

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

В ходе физической реализации БД каждой связи будут приписаны триггеры ссылочной целостности (RI-триггеры), которые и обеспечат уста- новленное правило целостности.

Триггеры – это подпрограммы, которые запускаются всякий раз при выполнении команд вставки (INSERT), обновления(UPDATE) и удаления (DELETE).

Допустим, что необходимо удалить один из экземпляров информаци- онного объекта ГРУППА. Экземпляр информационного объекта СТУДЕНТ не может существовать без соответствующего экземпляра объекта ГРУППА. Следовательно, необходимо либо запретить удаление группы, в которой чис- лится хотя бы один студент, либо сразу удалять всех студентов вместе с

группой. Такие правила ссылочной целостности называются RESTRICT и

CASCADE соответственно.

В другой ситуации, когда, например, экземпляр информационного объек- та СТУДЕНТ может существовать без ссылки на номер группы в объекте ГРУППА, при удалении какой -либо группы информация о ней должна остать- ся в объекте СТУДЕНТ. Такое правило называется SET NULL. При этом значе- ние атрибута Номер группы объекта СТУДЕНТ принимает значение NULL.

Правило SET DEFAULT устанавливает атрибуту значение по умолча- нию. Например, при «удалении» группы все студенты, которые в ней учи- лись, зачисляются в другую группу (значению атрибута Номер группы объ- екта СТУДЕНТ присваивается значение по умолчанию).

Наконец, правило NONE не меняет значение атрибута. При «удалении» группы запись о ней «повисает в воздухе», т. е. экземпляр объекта СТУДЕНТ ссылается на несуществующую уже запись о группе.

1.2.3  Физическое проектирование

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

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