ТЕОРИЯ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

ЦЕЛИ ПРОЕКТИРОВАНИЯ

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

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

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

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

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

Рассмотрим некоторый искусственный пример. Использовавшаяся ранее в примерах база данных ПОСТАВКА ТОВАРОВ включала информацию о поставщиках (Номер поставщика — sld, Имя поставщика — sName, Место дислокации — city), товарах (Номер товара — pld, Название — pName, Стоимость — price) и поставках (какой поставщик поставляет тот или иной товар и в каком Количестве — qty).

Можно все данные разместить в одном отношении, в котором совокупность атрибутов sld и pld составляет первичный ключ. Схема данного отношения (в дальнейшем изложении оно будет использоваться постоянно):

ПОСТАВКА ИЗДЕЛИЙ (sld. sName, city, old. pName, price, qty). Но тогда возникают определенные проблемы:

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

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

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

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

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

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

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

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

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

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