внимание на то, что в столбце rep office таблицы salesreps содержится идентификатор офиса, в котором работает служащий Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов офисов, содержащихся в столбце office таблицы offices Узнать, в каком офисе работает Мэри Джонс (Магу Jones), можно, опредетив значение столбца rep office в строке таблицы salesreps для Мэри Джонс (число 11) и затем отыскав в таблице offices строку с таким же значением в столбце office (это строка для офиса в Нью-Йорке) Таким же образом, чтобы найти всех служащих нью-йоркского офиса, следует запомнить значение столбца office для Нью-Йорка (число П), а потом просмотреть таблицу salesreps и найти все строки, в столбце repoffice которых содержится число 11 (это строки для Мэри Джонс и Сэма Кларка (Sam Clark))

Таблица OFFICES

Таблица SALESREPS

Рис 4.p Отношение првдЬк/потомок в реляционной базЬ Данных

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

Внешние ключи

Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним ключом На рис 4 9 столбец rep office представляет собой внешний ключ для таблицы offices Значения, содержащиеся в этом столбце, представляют собой идентификаторы офисов Эти значения соответствуют значениям в столбце office, который является первичным ключом таблицы offices Совокупно первичный и внешний ключи создают между таблицами, в которых они содержатся, такое же отношение предок/потомок, как и в иерархической базе данных

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

Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей На рис 4 10 показаны три внешних ключа таблицы orders из учебной базы данных

столбец cust является внешним ключом для таблицы customers и связывает каждый заказ с клиентом, сделавшим его,

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

столбцы mfr и product совокупно представляют собой составной внешний ключ для таблицы products, который связывает каждый заказ с заказанным товаром

Таблица CUSTOHERS

CUST NUH

COMPANY

Asme Hfg

Таблица SALESREPS

Таблица PRODUCTS

Таблица

Рис 4 /fl Множественные отношения предок/потомок в реляционной базе донных

Отношения предок/потомок, созданные с помощью трех внешних ключей в таблице orders, могут показаться вам знакомыми И действительно, это те же самые отношения, что и в сетевой базе данных, представленной на рис 4 3 Как показывает пример, реляционная модель данных обладает всеми возможностями сетевой модели по части выражения сложных отношений

Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных К сожалению, как и в случае с первичными ключами, поддержка внешних ключей отсутствовала в первых реляционных СУБД Она была реализована в системе DB2 Уегзюп 2, затем добавлена в стандарт ANSI/ISO и теперь имеется во всех коммерческих СУБД

Двенадцать правил Кодда

в статье, опубликованной в журнале ComputerWorld в 1985 году, доктор Кодд сформулировал двенадцать правил, которым должна соответствовать настоящая реляционная база данных Эти правила приведены в табл 4 1 Они являются полуофициальным

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

Таблица 4.1. Двенадцать правил Кодда, которым должна соответствовать реляционная баз,а данных

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

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

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

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

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

- определение данных;

- определение представлений;

- обработку данных (интерактивную и программную);

- условия целостности данных;

- идентификацию прав доступа;

- границы транзакций (начало, завершение и отмена).

6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

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

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

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

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

И. Правило независимости размещения. Реляционная база данных не должна зависеть от особенностей системы, в которой она расположена.

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