Правила внешних ключей

03.07.2010 | Автор: admin

Для обеспечения ссылочной целостности или, как иногда говорят, для поддержки внешних ключей, у пользователя базы данных должна быть возможность определить набор операций по связи между Primary Key и Foreign Key, которые ему разрешены и которые ему запрещены. Прежде всего такая ситуация возникает, когда необходимо выполнить операцию Delete (что делать, если в главной таблице удаляется родительская запись).

В общем случае тут могут быть следующие операции: 1. Restrict – запретить удаление из главной, если есть подчиненные. 2. Cascade – каскадно удалить все подчиненные записи. 3. Set Null – установить значение внешних ключей подчиненных записей в нулевое значение (Null – значение). 4. Set Default – установить значение вешних ключей в предопределенное, начальное значение. 5. No Action – ничего не делать.

В Desktop по умолчанию No Action. Если рассматривать простую таблицу – родители и дети – «Если умирает родитель, это не означает, что детей тоже надо убивать… Запретить умирать тоже нельзя». Какое значение установить в подчиненных записях –«детях» – в каждом контексте решает сам пользователь(Set Null и т.д.). В данном случае операции Restrict и Cascade применять нельзя.

Вторая операция здесь – это Update.(что делать, если мы обновляем, меняем Primary Key в главной таблице). Возникает вопрос, что делать с Foreign Key в данном случае. В общем случае, все ранее названные операции для Delete здесь тоже могут быть. Все также зависит от контекста – e.g. при смене названия улицы, необходимо обновить названия в паспортах, табличках и т.д.. Но чаще всего применяют операцию Restrict – запретить обновление.

Каждая из операций так или иначе требует определенного кода, чтобы ее выполнить. К исключениям можно отнести лишь No Action. Во всех остальных случаях необходимо наличие кода. На практике это решается, условно говоря, одним способом, но двумя реализациями. Используется триггеры, являясь процедурой, она запускается на сервере баз данных, т.е. пользователь сам такой триггер явно запустить не может. Такого рода триггеры могут быть созданы на три операции – Insert (добавление), Delete,Update. Две реализации триггеров:

1. Триггер создается вручную, т.е. программист сам пишет код, при этом используя различные программные конструкции, учитывает все нюансы и т.д.

2. В простейшем случае, без учета всех тонкостей, СУБД сама может создать стандартный триггер, который реализует простое каскадное обновление или удаление и т.д. Как правило, он откомпилирован и посмотреть код такого триггера невозможно.

33.34.36.36.37.38. Реляционная алгебра

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

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

• объединения отношений;

• пересечения отношений;

• взятия разности отношений;

• прямого произведения отношений.

Специальные реляционные операции включают:

• ограничение отношения;

• проекцию отношения;

• соединение отношений;

• деление отношений.

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