Реляционные модели данных

      Что произойдет, если изменилось наименование поставщика? Т.к. наименование поставщика повторяется во многих кортежах отношения, то это наименование нужно одновременно изменить во всех кортежах, где оно встречается, иначе данные станут противоречивыми. То же самое с наименованиями деталей. Значит, данные хранятся в нашем отношении с большой избыточностью.

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

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

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

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

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

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

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

      Таким образом, наш пример с поставщиками и поставляемыми деталями должен выглядеть следующим образом, см. приложение В.[3]

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

      Дадим точное определение.

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

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

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

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

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

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

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

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

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

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

6. Целостность внешних ключей

 

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

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

Заключение 

      Современные СУБД допускают использование null-значений, т.к. данные часто бывают неполными или неизвестными. Споры о допустимости использования null-значений ведутся до сих пор. Использование null-значения связано с применением трехзначной логики (three-valued logic, 3VL).

      Средством, позволяющим однозначно идентифицировать кортежи отношения, являются потенциальные ключи отношения.

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

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

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

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

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

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

      Связи типа "много-ко-многим" реализуются использованием нескольких отношений типа "один-ко-многим".

      В любой реляционной базе данных должны выполняться два ограничения:

Целостность сущностей 

Целостность внешних ключей

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

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

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

        
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Глоссарий 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Список  использованных источников 
 

1.  А.Шуленин. Microsoft SQL Server.  2004.-С.254

2.  И.Игнатович. Семейство реляционных баз данных IBM DB2. 2003.-С.-132

3.  О.Твердова. СУБД Progress.  2007.-С.26.

4  Э. В. Фуфаев. Эксплуатации удаленных баз данных. М: ЛОРИ. 2007.-С.94

5.  В.Шнитман. Серверы баз данных: проблемы оценки конфигурации системы. 2003

6.  А.Тандоев. Sybase SQL Anywhere Pofessional.2006.-С.215.

7.  А.Тандоев. Архитектура Sybase System 2003-С.238.

8.  М.Грабер. Введение в SQL. М: ЛОРИ. 2004.-С.45

9.  Р.Ахаян, А.Горев, С.Макашарипов. Эффективная работа с СУБД. С-П: ПИТЕР. 2006.-С.53

10. К.Пьянзин. Сетевые ОС в гетерогенной среде. LAN Magazine 2005.-с.59 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Приложение А. 

      Отношение "Сотрудники"  

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      Приложение  Б. 

      Отношение "Поставщики и  поставляемые детали"