A) Цели проектирования

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

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

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

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

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

- какие отношения включать в состав БД,

- сколько отношений включить в состав БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

РМД поддерживает следующие внутренние ограничения:

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

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

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

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

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

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