1. Теория проектирования реляционных баз данных

1. Цели проектирования

Основные цели:

• понизить избыточность данных,

• повысить надежность и достоверность данных (т.е. устранить некоторые аномалии).

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

• какие отношения включать в состав базы данных,

• сколько отношений включить в состав базы данных.

Почему это важно?

Рассмотрим некоторый искусственный пример. Использовавшаяся ранее в примерах база данных

ПОСТАВКА ТОВАРОВ включала информацию о поставщиках (Номер поставщика – S#, Имя поставщика – SNAME, Место дислокации – CITY), товарах (Номер товара – P#, Название – PNAME, Стоимость – PRICE) и поставках (какой поставщик поставляет тот или иной товар, и в каком Количестве – QTY).

Можно все данные разместить в одном отношении, в котором совокупность атрибутов S# и P# составляют первичный ключ. Схема данного отношения (в дальнейшем изложении оно будет использоваться постоянно): ПОСТАВКА ИЗДЕЛИЙ (S#, SNAME, CITY, P#, PNAME, PRICE, QTY).

Но тогда возникают определенные проблемы:

• избыточность информации, так как, например, информация о поставщиках будет повторяться для каждого поставляемого им товара;

• возможны аномалии при выполнении операций:

• обновления; если информация дублируется, то при модификации строк возможны ошибки: например, в одной строке изменили стоимость товара, а в другой, где также присутствует информация об этом же товаре, забыли;

• включения; если нужно хранить информацию, например, о товаре, который еще никто не поставляет, то ее нельзя включить в данное отношение, так как первичный ключ отношения состоит из двух атрибутов – S# и P#, и атрибуты первичного ключа не могут иметь пустое значение;

• удаления; если, например, удаляется информация о некотором товаре, и некоторый поставщик поставляет только один этот товар, вместе с информацией о товаре удалится и информация о поставщике.

Если же базу данных представить тремя отношениями – ПОСТАВЩИК, ТОВАР, ПОСТАВКА, тогда проблемы частично снимаются: аномалии выполнения операций модификации, вставки и удаления снимаются, но некоторая управляемая избыточность информации сохраняется. Но в этом случае, для того чтобы выполнить запрос, включающий в себя полную информацию о поставках товаров, необходимо выполнить операцию соединения отношений, а данная операция является достаточно время емкой.

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

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

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

Реляционная модель данных поддерживает следующие внутренние ограничения:

• категорная целостность – так как ключ уникально идентифицирует и определяет каждый кортеж отношения, то никакой ключевой атрибут не может быть пустым;

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

Явные ограничения, в свою очередь, можно разбить на две группы:

• семантические зависимости – зависимости между атрибутами отношения, определяемые предметной областью, например: сумма бюджетов всех отделов не должна превышать бюджет предприятия;

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

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