Модели представления данных. Реляционная модель

Далее, как отразить факт, что некоторый  поставщик, например Петров, временно прекратил поставки деталей? Если мы удалим все кортежи, в которых  хранится информация о поставках  этого поставщика, то мы потеряем данные о самом Петрове как потенциальном  поставщике. Выйти из этого положения, оставив в отношении кортеж типа (2, Петров, NULL, NULL, NULL) мы не можем, т.к. атрибут "Номер детали" входит в состав потенциального ключа и не может содержать null-значений. То же самое произойдет, если некоторая деталь временно не поставляется никаким поставщиком. Получается, что мы не можем хранить информацию о том, что есть некий поставщик, если он не поставляет хотя бы одну деталь, и не можем хранить информацию о том, что есть некоторая деталь, если она никем не поставляется.

Подобные проблемы возникают потому, что мы смешали в одном отношении  различные объекты предметной области - и данные о поставщиках, и данные о деталях, и данные о поставках  деталей. Говорят, что это отношение  плохо нормализовано (просто нормализованным  оно является хотя бы потому, что  оно есть отношение и, следовательно, автоматически находится в 1НФ).

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

Эти фразы отражают различные типы взаимосвязей. Чтобы более точно  отразить предметную область, можно  иначе переформулировать фразы: "Один Поставщик может выполнять  несколько Поставок", "Одна Деталь может поставляться несколькими  Поставками". Это пример взаимосвязи  типа "один-ко-многим". Взаимосвязь между "Поставщиками" и "Деталями" можно переформулировать так: "Несколько Деталей может поставляться несколькими Поставщиками". Это пример взаимосвязи типа "много-ко-многим".

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

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

Пусть дано отношение. Подмножество атрибутов  отношения будем называть внешним ключом, если:

Существует отношение (и не обязательно  различны) с потенциальным ключом.

Каждое значение в отношении  всегда совпадает со значением для некоторого кортежа из, либо является null-значением.

Отношение называется родительским отношением, отношение называется дочерним отношением.

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

Внешний ключ, как правило, не обладает свойством уникальности. Так и  должно быть, т.к. в дочернем отношении  может быть несколько кортежей, ссылающихся  на один и тот же кортеж родительского  отношения. Это, собственно, и дает тип  отношения "один-ко-многим".

Если внешний ключ все-таки обладает свойством уникальности, то связь  между отношениями имеет тип "один-к-одному". Чаще всего такие отношения объединяются в одно отношение, хотя это и не обязательно.

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

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

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

На самом деле приведенные правила  целостности сущностей и внешних  ключей прямо следуют из определений  понятий "потенциальный ключ" и "внешний ключ".

Действительно, в определении потенциального ключа требуется, чтобы потенциальный  ключ обладал свойством уникальности. Это фактически означает, что мы должны уметь различать значения потенциальных ключей, т.е. при сравнении  двух значений потенциального ключа  мы всегда должны получать значения либо ИСТИНА, либо ЛОЖЬ. Но любое сравнение, в которое входит null-значение, принимает  значение U - НЕИЗВЕСТНО, откуда следует, что атрибуты потенциального ключа  не могут содержать null-значений.

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

Тем не менее, явная формулировка правил целостности имеет определенный практический смысл. В большинстве  серьезных СУБД за выполнением этих ограничений следит сама СУБД, если, конечно, пользователь явно объявил  потенциальные и внешние ключи. Но, во-первых, для некоторых систем можно допустить, чтобы эти ограничения  не выполнялись, а во-вторых, некоторые  системы просто не поддерживают понятия  целостности, например, некоторые "настольные" СУБД типа FoxPro 2.5. В этих случаях за целостностью данных должен следить сам пользователь, или программист, разрабатывающий приложение для пользователя.

Явная формулировка правил целостности  помогает четко понять, какие опасности  несет в себе пренебрежение этими  правилами.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Операции, могущие нарушить ссылочную целостность

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

Для родительского отношения

Вставка кортежа в родительском отношении. При вставке кортежа  в родительское отношение возникает  новое значение потенциального ключа. Т.к. допустимо существование кортежей в родительском отношении, на которые  нет ссылок из дочернего отношения, то вставка кортежей в родительское отношение не нарушает ссылочной  целостности.

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

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

Для дочернего отношения

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

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

Удаление кортежа в дочернем отношении. При удалении кортежа  в дочернем отношении ссылочная  целостность не нарушается.

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

• Обновление кортежа в родительском отношении.
• Удаление кортежа в родительском отношении.
• Вставка кортежа в дочернее отношение.
• Обновление кортежа в дочернем отношении.
• Стратегии поддержания ссылочной целостности

Существуют две основные стратегии  поддержания ссылочной целостности:

1. RESTRICT (ОГРАНИЧИТЬ)- не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем в родительском отношении.
2. CASCADE (КАСКАДИРОВАТЬ)- разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении. В реализации этой стратегии имеется одна тонкость, заключающаяся в том, что дочернее отношение само может быть родительским для некоторого третьего отношения. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между кортежами родительского и дочернего отношений. Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.

Можно рассмотреть дополнительные стратегии поддержания ссылочной  целостности:

SET NULL (УСТАНОВИТЬ В NULL) - разрешить  выполнение требуемой операции, но все возникающие некорректные  значения внешних ключей изменять  на null-значения. Эта стратегия имеет  два недостатка. Во-первых, для нее  требуется допустить использование  null-значений. Во-вторых, кортежи дочернего  отношения теряют всякую связь  с кортежами родительского отношения.  Установить, с каким кортежем  родительского отношения были  связаны измененные кортежи дочернего  отношения, после выполнения операции  уже нельзя.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - разрешить выполнение требуемой  операции, но все возникающие  некорректные значения внешних  ключей изменять на некоторое  значение, принятое по умолчанию.  Достоинство этой стратегии по  сравнению с предыдущей в том, что она позволяет не пользоваться null-значеними. Недостатки заключаются в следующем. Во-первых, в родительском отношении должен быть некий кортеж, потенциальный ключ которого принят как значение по умолчанию для внешних ключей. В качестве такого "кортежа по умолчанию" обычно принимают специальный кортеж, заполненный нулевыми значениями (не null-значениями!). Этот кортеж нельзя удалять из родительского отношения, и в этом кортеже нельзя изменять значение потенциального ключа. Таким образом, не все кортежи родительского отношения становятся равнозначными, поэтому приходится прилагать дополнительные усилия для отслеживания этой неравнозначности. Это плата за отказ от использования null-значений. Во-вторых, как и в предыдущем случае, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения.

В некоторых реализация СУБД рассматривается  еще одна стратегия поддержания  ссылочной целостности:

IGNORE (ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения  ссылочной целостности. 

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

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

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