Проектирование структуры реляционных баз данных

1. Модели баз данных

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

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

2. Реляционная модель данных

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э.Кодд, опубликовавший в 1970 г. статью A Ralational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин «реляционная модель данных», что и положило начало реляционным базам данных. Теория реляционных баз данных, разработанная доктором Э.Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных.

Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных, и все операции над базой сводятся к манипуляции с таблицами. Таблица состоит из столбцов (колонок, полей) и строк (записей). Таблица отражает тип объекта реального мира (сущность), а каждая ее строка – конкретный объект.

В качестве примера рассмотрим таблицу ПРОДАЖИ, которая содержит:

• сведения о покупателях;

• дату заказа и количество заказанного товара;

• дату выполнения заказа и количество проданного товара;

• характеристику проданного товара (наименование, стоимость, категория).

Таблицу ПРОДАЖИ можно рассматривать как однотабличную базу данных.

Рис.1.1. Однотабличная база данных ПРОДАЖИ.

Проблемы избыточности данных

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

1. Потребуется значительное время на ввод повторяющихся данных.

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

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

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

Теория нормализации

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

Первичный ключ

В таблице ПРОДАЖИ поле КодПокуп может быть выбран в качестве первичного ключа (primary key, РК). Значению поля КодПокуп соответствуют:

• единственные значения полей Фамилия, Имя, Отчество, Телефон, Индекс, Страна, Область, Город, Адрес, Предпр, Руководит, Кредит;

• N значений полей КодТов, ДатаЗаказ, Заказано, ДатаПрод, Продано, Цена, Категория, НаимТов (где N - количество заказов у данного покупателя).

1НФ

Отношение имеет первую нормальную форму (1НФ), если оно удовлетворяет следующим требованиям:

1. отношение должно иметь уникальный первичный ключ;

2. должна иметься однозначная зависимость каждого атрибута отношения от первичного ключа;

3. должны отсутствовать повторяющиеся группы атрибутов.

Для устранения повторяющихся групп (каждый покупатель может иметь N заказов) разобьем таблицу ПРОДАЖИ на две таблицы (Рис.1.2):

• таблицу ПОКУПАТЕЛЬ, каждая строка которой содержит сведения об одном из покупателей;

• таблицу ЗАКАЗ, каждая строка которой содержит сведения об одном из N заказов каждого из покупателей.

N

Рис.1.2. База данных "Продажи" в 1НФ

Для таблицы ПОКУПАТЕЛЬ создается простой первичный ключ, основанный на поле КодПокуп. Для исключения повторяющихся записей в таблице ЗАКАЗ следует образовать составной первичный ключ, содержащий поля КодПокуп, КодТовара и ДатаЗаказ.

2НФ

Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных функциональных зависимостей (ФЗ). Неполная ФЗ - это две зависимости:

1. ключ таблицы определяет некоторый ее неключевой атрибут;

2. часть ключа определяет этот же неключевой атрибут.

Из определения следует, что понятие 2НФ применимо только к отношениям, имеющим составной ключ.

Таблица ЗАКАЗ, имеющая составной ключ, не находится в 2НФ, поскольку неключевые поля НаимТов, Цена и Категория однозначно определяются частью составного ключа КодТовара (рис. 2.3). Т.е. имеется неполная ФЗ.

Для приведения таблицы к 2НФ выделим из таблицы ЗАКАЗ таблицу ТОВАРЫ, которая будет содержать информацию о товарах каждого типа.

3 НФ

Отношение имеет третью нормальную форму (3НФ), если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные ФЗ. Транзитивные ФЗ - это две зависимости:

1. ключ отношения определяет некоторый неключевой атрибут;

2. этот неключевой атрибут определяет другой неключевой атрибут.

В таблице ПОКУПАТЕЛЬ (рис. 2.4) неключевое поле Руководит содержит имена руководителей компаний, которые однозначно определяются другим неключевым полем Предпр. Т.е. существует транзитивная ФЗ. Для приведения таблицы ПОКУПАТЕЛЬ к 3НФ создается новая таблица КОМПАНИЯ.

Рис.1.4. База данных "Продажи" в 3НФ

Требование нормализации всех таблиц в реляционной базе данных не является обязательным. Разбить таблицу на более мелкие (теоретически - свести ее к 3НФ) практически может потребоваться в следующих случаях:

• некоторая информация из этой таблицы используется не очень часто;

• нельзя давать доступ к некоторым данным любым желающим

В

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

Рис.1.5. Многотабличная база данных с эффективной структурой

Внешний ключ (foreign key, FK) - это поле в таблице, которое соответствует первичному ключу в другой таблице. Поскольку у каждого клиента может быть несколько заказов, а каждый заказ принадлежит только одному клиенту, то между таблицами ПОКУПАТЕЛЬ и ЗАКАЗ устанавливается связь один-ко-многим. Поскольку каждый товар может присутствовать в нескольких заказах, а каждый заказ связан только с одним товаром, то между таблицами ТОВАРЫ и ЗАКАЗ также устанавливается связь один-ко-многим. Между таблицами ПОКУПАТЕЛЬ и КОМПАНИЯ существует связь один-к-одному, поскольку компания, в которой работает покупатель, имеет одно определенное руководство.

Использование внешних ключей обеспечивает эффективность работы приложений:

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

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

• реляционная база данных не позволит удалить из таблицы строку с первичным ключом, если в базе с этим же значением имеется соответствующий внешний ключ, например, в таблице ПОКУПАТЕЛЬ нельзя удалить запись о покупателе, у которого имеются заказы - т.е. имеются соответствующие ему строки в таблице ЗАКАЗ.

2. Задаваемые при создании таблиц связи первичных ключей с внешними ключами используются для объединения данных из нескольких таблиц. Внешний ключ позволяет реализовать операцию поиска парных строк между таблицами. Например, объединяя таблицы ПОКУПАТЕЛЬ и КОМПАНИЯ с помощью внешнего ключа Предпр, можно получить полную информацию о покупателе.