Сибилев В.Д. Модели и проектирование баз данных

Подождите немного. Документ загружается.

Однако, если мы попытаемся удалить из отношения S какой-то

кортеж, на который есть ссылка в SPJ, то это приведет к проблеме.

Пусть есть в S кортеж

‘S1’, ‘Иван’, 150, ‘Яя’,

а в SPJ – кортеж

‘S1’, ‘P3’, ‘J12’ 1000.

Удалив первый, мы нарушим требование ссылочной

целостности, т.к. в SPJ останется кортеж, содержащий значение ‘S1’,

которого нет во множестве значений S.S#.

Аналогичная ситуация возникает при попытке обновить

значение ссылочного ключа. Если понадобится изменить в S значение

‘S1’ на ‘S11’, то что делать с соответствующим значением SPJ. S# ?

Существует, по крайней мере, две возможности.

 Отложить удаление/обновление ссылочного ключа до тех

пор, пока в БД не останется ни одного ссылающегося на него значения

внешнего ключа. Кортеж из S, содержащий значение S.S# = ‘S1’,

может быть удален только после того, как в SPJ не останется ни

одного кортежа, содержащего значение SPJ.S# = ‘S1’.

 Каскадировать удаление/обновление, т.е. удалить или

обновить значение внешнего ключа во всех кортежах, ссылающихся на

удаляемый/обновляемый родительский ключ. Например, удалить

кортеж со значением S.S# = ‘S1’ и все кортежи SPJ со значением

SPJ.S# = ‘S1’.

Таким образом, операции удаления/обновления родительского

ключа затрагивают, по крайней мере, два отношения – ссылочное и

ссылающееся.

Для того чтобы система могла поддерживать ссылочную

целостность при выполнении этих операций, нужно сообщить ей, что

она должна делать с кортежами-потомками удаляемого кортежа-

родителя, т.е. определить правило внешнего ключа.

Правило реализуется в виде хранимой процедуры – триггера

ссылочной целостности. Триггер связывается в системном каталоге с

внешним ключом потомка при обработке строки объявления внешнего

ключа в предложении определения отношения (см. п. 2.4.2). Он

запускается при любой попытке удаления/обновления значения

родительского ключа.

Мы говорили о двух видах триггеров ссылочной целостности –

ОТЛОЖИТЬ и КАСКАДИРОВАТЬ. Они наиболее часто

используются на практике, поэтому РСУБД обычно имеют системные

триггеры отложенного и каскадного удаления/обновления. Но

возможные варианты действий не ограничиваются этими правилами.

Вообще говоря, правила внешнего ключа могут быть какими

угодно. Например, система может:

 предложить пользователю самостоятельно решить вопрос о

том, что делать со ссылающимися кортежами;

 заменить значения внешнего ключа, ссылающиеся на

удаляемое значение родительского, значениями по умолчанию;

 удалить ссылающиеся кортежи из отношения-потомка и

занести их в некое архивное отношение и т.п.

Как правило, в БД, даже относительно простых, большинство

отношений являются и ссылочными и ссылающимися. Правила

внешних ключей устанавливаются для каждого из них индивидуально.

При этом могут возникать сложные ситуации.

Например, пусть R

, R

– связанные отношения: R

 R



. Для R

определено каскадное удаление. Сделана попытка удаления

кортежа R

, на который есть ссылки в R

. Следует удалить все кортежи

, ссылающиеся на удаляемый кортеж R

. Однако на эти кортежи есть

ссылки в R

. Если для R

также установлено правило каскадного удаления,

то операция будет выполнена «лавиной». Если же для R

определено

отложенное удаление, то операция удаления из R

не может быть

выполнена, и, следовательно, не может быть выполнена операция удаления

из R

Операции удаления/обновления всегда атомарны. Либо

выполняются все определенные правилами изменения в группе

отношений, затронутых операцией, либо не выполняется ни одно,

и состояние БД остается неизменным.

2.3.7 Резюме. БД называется целостной в некоторый момент

времени, если ее текущее состояние можно интерпретировать как

состояние ПО.

Состояние БД может быть целостным, но не соответствущим

истинному состоянию ПО. Целостность данных может контролировать

СУБД. Истинность данных должен обеспечивать пользователь.

В РСУБД возможность контроля целостности обеспечивается

правилами или ограничениями целостности (ОЦ). ОЦ – это

совокупность условий, которым должны удовлетворять целостные

данные. Каждая БД подчинена конкретной системе ограничений

целостности. Ее можно понимать как систему предикатов,

выражающих смысл отношений и их взаимосвязей. Посредством ОЦ в

БД представляется семантика данных. Текущее состояние БД

целостно, если все предикаты отношений на всех существующих в

настоящий момент кортежах принимают значение «истина».

РМД выделяет три типа внутренних ограничений целостности:

целостность домена, целостность сущности, ссылочная целостность.

Внутренние ОЦ являются метаправилами. Они требуют существования

в каждой РБД конкретных правил соответствующего типа, известных

РСУБД. Каждому конкретному правилу должна соответствовать

управляемая системой процедура, вычисляющая соответствующий

предикат и реализующая определенные действия в зависимости от его

значения.

Сообщить системе, какие конкретные правила целостности она

должна поддерживать, можно при определении объектов БД. Для

этого в ЯОД системы должны быть операторы определения домена и

базового отношения.

Операции удаления или обновления значений родительских

ключей затрагивают, как минимум, два отношения. СУБД сможет

поддерживать ссылочную целостность при выполнении этих операций,

если для каждого ссылающегося отношения определены правила

изменения значений внешних ключей при изменении значений

соответствующих родительских ключей. Наиболее распространенные

правила – ОТЛОЖИТЬ и КАСКАДИРОВАТЬ – обычно

поддерживаются стандартными процедурами РСУБД. Все

специфические правила внешних ключей должны быть определены

проектировщиком и реализованы в виде хранимых процедур.

Любая операция обновления БД атомарна. Если она неявно

затрагивает несколько отношений, то может быть выполнена или не

выполнена только целиком.

2.4 Объявление реляционных объектов

Реляционными объектами являются домены, отношения и

процедуры базы данных (хранимые процедуры), обеспечивающие

поддержание целостности данных. Все объекты объявляются

специальными предложениями ЯОД. Определения объектов заносятся

в системный каталог и используются СУБД при управлении данными.

Ниже, следуя [1], мы приводим синтаксис предложений

определения доменов и отношений во входном ЯОД гипотетической

СУБД, поддерживающей все требования РМД.

2.4.1 Объявление домена. Домен на самом деле есть то, что в

современных языках программирования называется «тип данных,

определенный пользователем». К сожалению, большинство

современных СУБД не поддерживает домены как объекты БД.

Определение домена может выглядеть так:

CREATE DOMAIN имя-домена тип [(длина)]

{FOR ALL имя-домена (предикат)}|

{VALUES (список)};

Здесь имя-домена – уникальное имя, под которым домен будет

известен системе и на которое можно ссылаться в определениях

отношений;

тип – один из поддерживаемых системой встроенных типов

данных;

длина – длина поля данных в байтах;

предикат – логическое выражение, использующее имя-

домена в качестве переменной;

список – список значений, разделенных запятыми.

Эта декларация объявляет системе, что она должна внести в

свой каталог имя нового объекта – домена, и указывает ограничения на

значения, принадлежащие домену. Определение сохраняется в

системном каталоге. При любой попытке обновления значения какого-

либо атрибута, определенного на этом домене, будет вычислено

значение предиката. Если оно окажется равным .F., обновление будет

отвергнуто.

Пример 1.

CREATE DOMAIN день CHAR (2)

FOR ALL день (

день = ‘пн’ OR

день = ‘вт’ OR

день = ‘ср’ OR

день = ‘чт’ OR

день = ‘пт’ );

Это же можно записать короче:

CREATE DOMAIN день CHAR (2)

VALUES(‘пн’, ‘вт’, ‘ср’, ‘чт’, ‘пт’);

Если, скажем, в ИС банка на этом домене определен атрибут

рабочий день, то система сможет заблокировать выполнение

банковских операций по субботам и воскресеньям.

Пример 2.

CREATE DOMAIN вес INTEGER

FOR ALL вес (вес  10 AND вес  150 AND mod(вес, 5) =

0);

Каждый атрибут, определенный на этом домене, может

принимать целочисленные значения в интервале [10, 150], причем

только такие, которые делятся на 5 без остатка.

Если есть возможность создать домен, должна быть и

возможность удалить его. Следующая команда

DESTROY DOMAIN имя-домена;

удалит из системного каталога определение домена. Она будет

исполнена, если в схеме БД нет ни одного атрибута, определенного на

удаляемом домене.

Если система поддерживает домены, то в ней есть возможность

выполнения запросов, основанных на доменах. Например, запрос

Какие отношения в БД содержат какую-либо информацию о весе?

в терминах доменов имеет вид:

Какие отношения в БД включают атрибуты, определенные на

домене Вес?

Это запрос к системному каталогу. В системе, не

поддерживающей домены, такие сведения практически невозможно

получить.

2.4.2 Объявление отношения. Можно говорить о переменной-

отношении, заданной схемой отношения, и о значении отношения,

существующем в БД в конкретный момент времени (см. п. 2.2.4).

Определять следует только схему, т.е. переменную. Значения

отношения формируются системой в процессе выполнения запросов

пользователей.

В реляционной БД всегда существует несколько основных

видов отношений.

 Именованное отношение – это отношение, имя и определение

схемы которого сохранены в системном каталоге. Именованное

отношение может быть базовым или производным.

 Производное отношение есть отношение, определенное

посредством реляционного выражения (см. пп. 2.5, 2.6) через

именованные отношения. Производное отношение может быть

именованным или неименованным.

 Базовое отношение – именованное отношение, не являющееся

производным.

Любое производное отношение, в конце концов, выражается

через базовые. Поэтому средства явного определения схемы нужны

только для базовых отношений.

Предложение объявления базового отношения имеет вид:

CREATE BASE RELATION имя-отношения

(список-определений-атрибутов)

список-определений-возможных-ключей

список-определений-внешних-ключей;

Здесь список-определений ... – список разделенных запятыми

строк определений соответствующих элементов схемы отношения.

Строка определения атрибута связывает имя атрибута с его

доменом:

имя-атрибута DOMAIN (имя-домена).

Указанный атрибут принимает значения на указанном домене.

Например, строка определения атрибута We в предложении

определения отношения P (см. рис. 2.3) может иметь вид:

We DOMAIN (вес),

где домен вес определен в п. 2.4.1, пример 2.

Имена атрибутов должны быть уникальны, по крайней мере, в

пределах отношения. Удобно, если имя атрибута совпадает с именем

домена, на котором он определен.

Строка определения возможного ключа имеет две модификации:

PRIMARY KEY (список-атрибутов) |

CANDIDATE KEY (список-атрибутов)

Здесь PRIMARY KEY и CANDIDATE KEY объявляют,

соответственно, первичный и альтернативный ключи отношения;

список-атрибутов – список разделенных запятыми имен

атрибутов, образующих ключ.

Например, первичный ключ отношения SPJ (см. рис. 2.3) будет

объявлен строкой

PRIMARY KEY (S#, P#, J#, Dt),

а альтернативный ключ того же отношения – строкой

CANDIDATE KEY (SPJ#)

Строка определения внешнего ключа имеет вид:

FOREIGN KEY (список-атрибутов)

REFERENCES отношение

DELETE правило-удаления

UPDATE правило-обновления

Здесь список-атрибутов – список разделенных запятыми

имен атрибутов (составного) внешнего ключа, эквивалентный списку

атрибутов родительского ключа;

отношение – имя родительского отношения;

правило ... следует понимать как ссылку на процедуру БД,

реализующую определенное проектировщиком правило внешнего

ключа для операции DELETE или UPDATE соответственно. Это

может быть либо процедура пользователя, либо одна из стандартных

процедур СУБД – Cascade (каскадировать) или Restrict (отложить).

Примеры.

Будем считать, что все необходимые домены определены, и

приведем предложения определения схем отношений ПОСТАВЩИК и

ПОСТАВКА.

Отношение ПОСТАВЩИК не содержит ни альтернативных, ни

внешних ключей и определяется предложением

CREATE BASE RELATION S

( S# DOMAIN (S#),

Sn DOMAIN (Sn),

St DOMAIN (St),

Ci DOMAIN (Ci)

)

PRIMARY KEY (S#);

Определение отношения ПОСТАВКА имеет вид

CREATE BASE RELATION SPJ

( S# DOMAIN (S#),

P# DOMAIN (P#),

J# DOMAIN (J#),

Dt DOMAIN (Dt),

SPJ# DOMAIN (SPJ#),

Qt DOMAIN (Qt)

)

PRIMARY KEY (S#, P#, J#, Dt)

CANDIDATE KEY (SPJ#)

FOREIGN KEY (S#) REFERENCES S

DELETE Restrict

UPDATE Cascade

FOREIGN KEY (P#) REFERENCES P

DELETE Restrict

UPDATE Cascade

FOREIGN KEY (J#) REFERENCES J

DELETE Restrict

UPDATE Cascade;

Здесь кроме составного первичного ключа {S#, P#, J#, Dt}

указан простой альтернативный ключ {SPJ#}, а также внешние ключи

{S#}, {P#}, {J#}. Для внешних ключей определены правила

отложенного удаления и каскадного обновления. Это означает, что

удаление кортежа родителя не может быть выполнено, если в SPJ

существует хотя бы один кортеж, ссылающийся на удаляемое значение

родительского ключа. Удаление родительского кортежа произойдет

автоматически после удаления последней ссылки на него. Если же

пользователь изменит значение какого-либо родительского ключа, то

во всех кортежах SPJ, ссылающихся на старое значение, произойдут

соответствующие изменения.

Базовое отношение может быть уничтожено командой

DESTROY BASE RELATION имя-отношения;

Команда удалит из системного каталога все сведения об

указанном отношении, но будет выполнена, только если тело

отношения пусто. Будут удалены также все производные отношения, в

определениях которых есть ссылки на удаляемое.

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

2.5.1 Общая характеристика. Реляционная алгебра (РА) – один

из имеющихся в РМД механизмов манипулирования данными на

уровне множеств кортежей.

Первый вариант набора операций РА был предложен Э.Коддом

в 1970 г. Он содержал 8 операций. Позднее различными авторами

были предложены различные дополнения этого набора. Мы здесь

познакомимся с операторами, обеспечивающими основные

потребности манипулирования данными.

Операндами операций РА являются отношения. Всякая

операция РА производит отношение, формируя по определенным

правилам схему и тело производного отношения из атрибутов и

кортежей операндов.

Реляционная алгебра замкнута относительно множества

отношений. Из имен отношений, знаков операций РА и скобок можно

строить выражения произвольной степени сложности. Очень сложные

запросы к реляционной БД можно сформулировать в виде одного

выражения РА. Поэтому реляционная алгебра обладает большой

выразительной мощностью.

2.5.2 Операции реляционной алгебры. Поскольку отношения

– это множества, то операции РА основаны на теоретико-

множественных операциях. Однако отношения – множества с особыми

свойствами, поэтому в РА входят также специфические операции,

которые могут быть определены только на множествах отношений.

Выделяют две группы операций РА.

Теоретико-множественные операции:

 объединение;

 разность;

 пересечение;

 расширенное прямое произведение.

Специальные реляционные операции:

 переименование;

 селекция (ограничение, выборка);

 проекция;

 соединение по условию;

 естественное соединение;

 взятие реляционного частного (реляционное деление).

Этот набор операций избыточен, так как некоторые из них

выражаются через другие. Тем не менее, все они включаются в состав

алгебры как элементарные, исходя из интуитивных потребностей

пользователей БД. В этом подразделе приведены формальные

определения операций, а в следующем – синтаксис абстрактного языка

РА.

Специфика отношений накладывает ограничения на операции.

Так, операндами операций объединения, взятия разности и

пересечения могут быть только отношения с эквивалентными схемами.

Определение 1. Говорят, что отношения R

и R

совместимы

по объединению, если R

( ) = R

( ).

Операндами операции расширенного прямого произведения

могут быть только отношения с непересекающимися схемами.

Определение 2. Говорят, что отношения R

и R

совместимы

по взятию расширенного прямого произведения, если