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

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

кортеж отношения S со значением S# = ‘S12’, но в отношении SPJ

нет ни одного кортежа с таким значением S#. Это просто означает, что

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

выполненной этим поставщиком.

Замечание 6. Состав атрибутов внешнего ключа должен

совпадать с составом атрибутов родительского ключа. Точнее:

множества PK и FK пар (домен, атрибут) должны быть

эквивалентны.

Так, атрибут SPJ.S# является внешним ключом отношения

SPJ, ссылающимся на родительский ключ S.S#. Оба атрибута

определены на одном и том же домене и имеют одинаковые имена

Это пример простого внешнего ключа, соответствующего простому

же родительскому ключу.

Если родительский ключ составной, то ссылающийся на него

внешний также составной. Например, пусть наша БД должна хранить

сведения о том, какой служащий какие манипуляции с записями о

поставках проделывал. Тогда схема БД может содержать фрагмент

показанный на рис. 2.4.

î áðàáàòû âàëàñü â

ï î ëó÷àë

Ï Î ÑÒÀÂÊÀ [SPJ]

í î ì åð ï î ñòàâù èêà [S#] (FK)

í î ì åð äåòàëè [P#] (FK)

í î ì åð èçäåëèÿ [J#] (FK)

ÄÎ ÑÒÓÏ Ê ÇÀÏ ÈÑÈ [A_SPJ]

í î ì åð ñëóæàù åãî [Emp#] (FK)

í î ì åð ï î ñòàâù èêà [S#] (FK)

í î ì åð äåòàëè [P#] (FK)

í î ì åð èçäåëèÿ [J#] (FK)

ì åòêà âðåì åí è [Tm]

ÑËÓÆÀÙ ÈÉ [Emp]

í î ì åð ñëóæàù åãî [Emp#]

Вообще говоря, требование одноименности атрибутов излишне.

Здесь и далее несущественные для понимания текста детали схем опускаются.

Рис. 2.4 Составной внешний ключ {S#, P#, J#}

Здесь отношение A_SPJ содержит составной внешний ключ

{S#, P#, J#}, ссылающийся на первичный ключ {S#, P#, J#}

отношения SPJ, и простой внешний ключ {Emp#}, ссылающийся на

первичный ключ {Emp#} отношения Emp.

Замечание 7. Внешний ключ может полностью входить в состав

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

может и не входить в него вообще или входить частично.

Например, пусть в нашей БД хранятся сведения о городах

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

фрагмент схемы БД показан на рис. 2.5. Здесь атрибуты отношений S,

P, J, помеченные символом (FK), – внешние ключи, ссылающиеся на

отношение Ct. Включать их в состав возможных (первичных) ключей

отношений-потомков нет необходимости.

ÄÅÒÀËÜ [P]

í î ì åð äåòàëè [P#]

í àçâàí èå [Ci] (FK)

ÈÇÄÅËÈÅ [J]

í î ì åð èçäåëèÿ [J#]

í àçâàí èå [Ci] (FK)

Ï Î ÑÒÀÂÙ ÈÊ [S]

í î ì åð ï î ñòàâù èêà [S#]

í àçâàí èå [Ci] (FK)

í àçâàí èå [Ci]

ÃÎ ÐÎ Ä [Ct]

Ï Î ÑÒÀÂÊÀ [SPJ]

í î ì åð ï î ñòàâù èêà [S#] (FK)

í î ì åð äåòàëè [P#] (FK)

í î ì åð èçäåëèÿ [J#] (FK)

Рис. 2.5 Внешний ключ *.название не входит в состав первичного

ключа потомка

Замечание 8. Отношение может быть одновременно ссылочным

и ссылающимся.

Так, на рис. 2.5 отношения S, P и J являются ссылочными для

отношения SPJ и ссылающимися на отношение Сt.

Замечание 9. Отношение может ссылаться на себя, т.е. внешний

ключ может быть потомком первичного ключа собственного

отношения.

Например, в БД бюро ЗАГС может существовать отношение,

показанное на рис. 2.6. Здесь атрибут номер паспорта - ссылочный

ключ, а атрибут супруг.номер паспорта – ссылающийся на него

внешний ключ.

ËÈÖÎ

í î ì åð ï àñï î ðòà

ñóï ðóã.í î ì åð ï àñï î ðòà (FK)

ÿâëÿåòñÿ ñóï ðóãî ì

Рис. 2.6 Унарная связь. Отношение ссылается на себя

2.3.5 Внутренние ограничения целостности РМД. Выделяют

три разновидности внутренних ОЦ: целостность домена, целостность

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

2.3.5.1 Целостность домена. Домены являются одной из

важнейших составляющих РМД. Механизм доменов обеспечивает:

 принципиальную возможность ограничения сравнений (см.

п.2.2.2) и блокирования бессмысленных операций в БД;

 принципиальную возможность формального контроля ввода

данных. Если предикат, определяющий домен, принял на вводимом

значении атрибута значение .F., система не должна принимать это

значение атрибута.

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

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

проектировании концептуальной модели очень важно правильно

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

 Правило целостности домена: всякий атрибут может

принимать значения только из своего домена.

Это означает, что в любой РБД для каждого атрибута должно

существовать правило, определяющее допустимость значений.

Правило целостности домена – это метаправило, правило о правилах.

2.3.5.2 Целостность сущности. Правило целостности

сущности часто формулируют как требование уникальности значений

первичного ключа. Однако, на самом деле это не так. Требование

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

отношения должен быть идентифицируем. Иначе говоря, в БД не

должна храниться информация о чем-то таком, что мы не можем

идентифицировать.

Это требование связано с проблемой представления незнания в

БД. В реальной жизни в базу данных нередко приходится включать

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

Например:

 поставщик зарегистрирован, а статус его еще не определен;

 руководство фирмы еще не решило, в каком городе

разместить производство изделия;

 известна дата смерти исторического деятеля, а дата рождения

затерялась в глубине веков и т.п.

В подобных случаях соответствующим атрибутам

присваиваются так называемые Null-значения.

Null – это специальный маркер, показывающий, что значение

данного атрибута в настоящий момент неизвестно и, возможно, будет

введено впоследствии. Null не «ноль», не «пробел», и вообще, Null не

имеет типа. Этим маркером может быть помечен любой атрибут

любого кортежа.

Null обладает следующими свойствами:

 всякое сравнение с участием Null дает результат Null;

 все Null-значения различны;

 отрицание Null – тоже Null.

Если какой-либо из атрибутов, входящих в состав первичного

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

кортежем экземпляр объекта ПО невозможно идентифицировать.

Очевидно, нет смысла хранить в БД такую комбинацию значений.

В самом деле, что означает утверждение: «номер поставщика

неизвестен»? Мы еще не присвоили ему номер? Мы не знаем,

присвоен ему номер или нет? Нам неизвестно, идет ли речь об уже

зарегистрированном в БД поставщике или о каком-то другом? И т.д.

Во всех случаях, прежде чем заносить информацию в БД,

необходимо идентифицировать эту информацию, т.е. задать

определенное значение первичного ключа. Если допустить возможность

неопределенных значений первичного ключа, то будет разрушен

механизм адресации РМД.

 Правило целостности сущности: ни один компонент

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

значение.

Это, как и требование целостности домена, метаправило. Оно

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

первичные ключи всех отношений. Тогда РСУБД не допустит

появления кортежей с Null-значениями соответствующих атрибутов.

2.3.5.3 Ссылочная целостность. Нет никакого смысла хранить

в БД кортежи отношения-потомка, ссылающиеся на кортежи, не

существующие в родительском отношении. Так, если не существует в

текущем значении отношения S кортежа со значением S# = ‘S3’, то

кортеж {‘S3’, ‘P1’, ‘J8’, 500} не имеет права на существование в

текущем значении отношения SPJ. Включающее его состояние БД не

может быть интерпретировано.

 Требование ссылочной целостности: ни в какой

момент времени в базе данных не может быть значений

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

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

Эта формулировка, как, впрочем, и определение внешнего

ключа, неточна. Если строго ей следовать, то окажутся

недопустимыми Null-значения внешних ключей. Это логически

неоправданный запрет. Ситуации, в которых значения атрибутов

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

возникают очень часто.

Так, в примере, показанном на рис. 2.6, не во всех кортежах

отношения ЛИЦО внешний ключ супруг.номер паспорта будет

иметь определенные значения. Бывают ведь и холостяки, и

разведенные.

Разумно не разрешать Null-значения внешнего ключа,

входящего в состав первичного ключа потомка. Этого и не допускает

требование целостности сущности. Но если атрибут внешнего ключа

не входит в состав первичного ключа потомка, то он может принимать

Null-значения.

Имея это в виду, следует сформулировать пункт Б) определения

внешнего ключа (см. п. 2.3.4) так:

 Б) каждое значение FK в текущем значении В всегда

или совпадает со значением РК некоторого кортежа в текущем

значении А, или является Null-значением.

Более точная формулировка требования ссылочной

целостности такова:

 ни в какой момент времени в БД не может быть

определенных (не Null-) значений ссылающегося ключа, которых нет

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

Это, как и предыдущие два требования, метаправило. Оно

означает, что в каждой конкретной РБД должны быть определены

специальные правила (правила внешних ключей), поддерживающие

требование ссылочной целостности.

2.3.6 Поддержание целостности в РБД. Любое состояние РБД,

не удовлетворяющее требованиям целостности, некорректно. На

вопрос о том, как избегать подобных состояний, общего ответа нет. В

каждом конкретном случае это должен решать проектировщик БД.

Определение конкретных правил целостности – его задача. Ниже

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

поддержания целостности РСУБД.

2.3.6.1 Предикаты отношений и целостность данных.

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

базовых отношений (см. п. 2.4.2). Следовательно, с каждым базовым

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

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

обновления текущего значения любого базового отношения.

Всякое отношение имеет некоторую интерпретацию,

передающую смысл представленных в нем данных. Эта интерпретация

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

отношения S в неформальной записи выглядит так:

«ПОСТАВЩИК с определенным номером S# имеет имя Sn

и значение статуса St и располагается в городе Ci и нет двух

ПОСТАВЩИКов с одинаковыми значениями S#».

Этот предикат принимает значение .Т. на тех кортежах, которые

образуют тело отношения S в настоящий момент времени. Новый

кортеж будет вставлен в тело только в том случае, если на нем

предикат отношения принимает значение .Т. Таким образом, предикат

есть критерий возможности (допустимости) обновления. В нашем

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

значение S# принадлежит домену S# И

значение Sn принадлежит домену Sn И

значение St принадлежит домену St И

значение Ci принадлежит домену Ci И

значение S# не встречается среди существующих в отношении

S в настоящий момент.

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

отношения S. Именно их должна проверять система, добавляя кортеж

в это отношение.

Рассмотрим теперь отношение SPJ. Его предикат (в

неформальной записи) таков:

«ПОСТАВЩИК с номером S# поставил для ИЗДЕЛИя с номером

J# ДЕТАЛЬ с номером P# в количестве Qt

И в отношении S существует кортеж со значением S.S# = S#

И в отношении P существует кортеж со значением P.P# = P#

И в отношении J существует кортеж со значением J.J# = J#

И нет двух ПОСТАВок с одинаковыми значениями {S#, P#, J#}».

В этой формуле есть ссылки на отношения S, P и J.

Следовательно, ее значение должно вычисляться не только при

добавлении кортежей в тело SPJ, но и при обновлении хотя бы одного из

ссылочных отношений, затрагивающем множество значений

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

Таким образом, правила целостности для ссылающихся

отношений должны проверяться при обновлении ссылочных

отношений. Только при этом условии может быть обеспечена

целостность состояния БД. Правила реализуются в виде так

называемых хранимых процедур (процедур базы данных). Эти

процедуры связываются с соответствующими отношениями и хранятся

в базе данных вместе с ними. Посмотрим, какие типы хранимых

процедур необходимы для поддержания внутренних ОЦ.

2.3.6.2 Операции обновления и целостность данных.

В любой

реляционной БД имеется три типа операций обновления базовых

отношений:

 INSERT – вставить кортеж в отношение;

 DELETE – удалить кортеж из отношения;

 UPDATE – обновить значение атрибута(ов) в кортеже.

Таблица 2.1 показывает, какие типы ограничений целостности

могут ими нарушаться.

Таблица 2.1



Возможные нарушения ограничений целостности

Целостность

домена

Целостность

сущности

Ссылочная

целостность

INSERT ДА ДА ДА

DELETE НЕТ НЕТ ДА

UPDATE ДА ДА ДА

Таким образом, выполнение операций INSERT и UPDATE

должно сопровождаться (в общем случае) проверками всех трех типов

правил целостности. При выполнении операции DELETE необходимо

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

гипотетическая РСУБД имеет модуль контроля обновлений,

инициируемый любой из команд – INSERT, UPDATE или DELETE, и

запускающий нужные процедуры контроля целостности.

2.3.6.3 Контроль целостности домена. Правило целостности

Этот материал выходит за рамки РМД, но необходим для понимания смысла

предложений определения объектов РБД.

домена должно проверяться при любой попытке ввода/обновления

значения любого атрибута, определенного на этом домене. Для того

чтобы РСУБД могла это делать, правило должно быть

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

предложением ЯОД – предложением объявления домена (см. п. 2.4.1).

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

домена и реализует процедуру вычисления значений предиката.

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

дальнейшего исполнения.

Атрибут связывается со своим доменом строкой предложения

определения базового отношения (см. п. 2.4.2.). Это определение

также сохраняется в системном каталоге. При попытке присваивания

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

находит по каталогу имя соответствующего домена и вычисляет

значение связанного с ним предиката на новом значении атрибута.

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

2.3.6.4 Контроль целостности сущности. Правило

целостности сущности должно проверяться при любой попытке

добавления нового кортежа в базовое отношение (операция INSERT)

или обновления значения первичного ключа (операция UPDATE). Для

этого в РСУБД может быть определена стандартная процедура,

возвращающая логическое значение. Входными данными для нее

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

атрибутов первичного ключа. Процедура возвращает значение .F., если

 хотя бы один атрибут набора принял значение Null или

 значение набора уже существует в текущем множестве

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

Процедура связывается с конкретным отношением в процессе

обработки строки определения первичного ключа в предложении

определения отношения (см. п. 2.4.2). В соответствующий раздел

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

первичного ключа. При попытке выполнить операцию UPDATE

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

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

запускается. Попытка выполнения операции INSERT всегда

инициирует эту процедуру. Обновление отвергается, если процедура

контроля целостности сущности возвратила значение .F.

2.3.6.5 Контроль ссылочной целостности. Требование

ссылочной целостности накладывает ограничения на все три операции

обновления БД (см. табл. 2.1). Рассмотрим эти ограничения.

Операция INSERT. Эта операция затрагивает только одно

отношение. Если вставляется кортеж в отношение, не являющееся

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

нарушена. Просто в БД появится новый кортеж, на который нет

ссылок.

Если добавляется кортеж в отношение-потомок, то ссылочная

целостность может быть нарушена. Кортеж можно включить в БД,

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

существующему в настоящий момент множеству значений

родительского ключа. В РСУБД должна быть системная процедура

проверки, подобная процедуре контроля целостности сущности. Она

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

кортеж в отношение-потомок. Входными данными для нее являются

имя ссылочного отношения и значение набора атрибутов внешнего

ключа. Процедура возвращает значение .F., если вводимое значение

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

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

Процедура связывается с конкретным отношением в процессе

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

определения отношения (см. п. 2.2.4.2). В соответствующий раздел

системного каталога заносятся имя ссылочного отношения и перечень

атрибутов, входящих в состав внешнего ключа потомка. Попытка

выполнения операции INSERT всегда инициирует эту процедуру.

Обновление отвергается, если процедура возвратила значение .F.

Операции DELETE и UPDATE. Удаление кортежа отношения,

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

к нарушению ссылочной целостности. Так, в нашей БД «Поставщик-

Деталь-Изделие» мы можем удалить без всяких последствий любой

кортеж отношения SPJ.