Лекция №8

ОСНОВЫ проектирования реляционных БД

При проектировании базы данных решаются две основные проблемы.

· Проблема логического проектирования баз данных. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области, и было по возможности, наилучшим (эффективным, удобным и т.д.)?

· Проблем физического проектирования баз данных. Как обеспечить эффективность выполнения запросов к БД, т. е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, какие необходимы дополнительные структуры (например, индексов) и т. д.?

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

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

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

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

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

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

Ограничением первой нормальной формы (1НФ) является необходимость приведения всех атрибутов отношения к атомарному виду. Поскольку требование 1НФ является базовым требованием классической реляционной модели данных, т.е.

· В отношении нет одинаковых кортежей.

· Кортежи не упорядочены.

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

· Все значения атрибутов атомарны.

Будем считать, что исходный набор отношений уже соответствует этому требованию.

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

· первая нормальная форма (1НФ);

· вторая нормальная форма (2НФ);

· третья нормальная форма (3НФ);

· нормальная форма Бойса-Кодда (БКНФ);

· четвертая нормальная форма (4НФ);

· пятая нормальная форма, или нормальная форма проекции-соединения (5НФ или PJ/НФ);

· и другие.

Основные свойства нормальных форм состоят в следующем:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;

· при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

Например. Рассмотрим отношений Деканат следующего вида:

№зк

ФИО

Группа

Предмет

Преподаватель

Кафедра

Оценка

Структура такой схемы может привести к проблемам.

1. Избыточность. Группа, Преподаватель, Кафедра повторяются столько раз, сколько раз сдавались экзамены.

2. Аномалия обновления (UPDATE). Вследствие избыточности можно обновить, например, Преподавателя в одном картеже, оставляя его неизменным в другом.

3. Аномалия включения (INSERT). В БД не может быть занесено ФИО, если студент в настоящее время не сдавал ни одного экзамена. При этом использование пустых значений может привести к дополнительным трудностям, например, таким как поиск и заполнение пустых значений.

4. Аномалия удаления (DELETE). Обратная проблема может возникнуть при необходимости удаления всех ФИО (закончивших ВУЗ), вследствие чего непреднамеренно будет удалена вся информации о Предметах, Преподавателях и т.д.

Причина аномалии - хранение в одном отношении разнородной информации (и о студентах, и о преподавателях, и об успеваемости).

Вывод - структура данных неадекватна требованиям ПрО. БД, основанная на такой структуре, будет работать неправильно.

Дата добавления: 2014-01-07