2.2.3.Отношение предок/потомок
Одним из отличий реляционной модели от навигационных было то, что в ней отсутствовали явные указатели, используемые для реализации отношений предок/потомок в иерархической модели данных. Но такие отношения существуют и в реляционных базах данных. Например, в нашей учебной базе каждый из служащих закреплен за конкретным офисом, поэтому ясно, что между строками таблицы OFFISY и таблицы SLUZHASCHIE существует отношение. Не приводит ли отсутствие явных указателей в реляционной модели к потере информации?
Ответ на этот вопрос будет отрицательным. На Рис. 1.1. изображено несколько строк из таблиц OFFISY и SLUZHASCHIE. Обратите внимание на то, что в столбце ID_OFC таблицы SLUZHASCHIE содержится идентификатор офиса, в котором работает служащий. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов офисов, содержащихся в столбце ID_OFC таблицы OFFISY.
|
Рис. 1.1. Реализация отношения предок/потомок в реляционной базе данных |
Узнать, в каком офисе работает Иванов Иван, можно, определив значение столбца ID_OFC в строке таблицы SLUZHASCHIE для Иванов Иван (число 11), а затем отыскав в таблице OFFISY строку с таким же значением в столбце ID_OFC (это строка для офиса в Буинске). Таким же образом, чтобы найти всех служащих Буинского офиса, следует запомнить значение ID_OFC для Буинска (число 11), а потом просмотреть таблицу SLUZHASCHIE и найти все строки, в столбце ID_OFC которых содержится число 11 (это строки для Иванова Ивана и Уткина Дениса).
Отношение предок/потомок, существующее между офисами и работающими в них людьми, в реляционной модели не потеряно; просто оно реализовано в виде одинаковых значений данных, хранящихся в двух таблицах, а не в виде явного указателя. Все отношения, существующие между таблицами реляционной базы данных, реализуются таким способом. Одним из главных преимуществ языка SQL является возможность извлекать данные, связанные между собой, используя эти отношения.
2.2.4.Внешние ключи
Столбец одной таблицы, значения в котором совпадают со значениями столбца, являющегося первичным ключом другой таблицы, называется внешним (вторичным) ключом. На Рис. 1.1. столбец ID_OFC представляет собой внешний ключ для таблицы OFFISY. Значения, содержащиеся в этом столбце, представляют собой идентификаторы офисов. Эти значения соответствуют значениям в столбце ID_OFC, который является первичным ключом таблицы OFFISY. Совокупно первичный и внешний ключи создают между таблицами такое же отношение предок/потомок, как и в иерархической базе данных.
|
Рис. 1.1. Множественные отношения предок/потомок в реляционной базе данных |
Внешний ключ, как и первичный, тоже может быть составным (состоящим из нескольких столбцов). На практике внешний ключ всегда будет составным, если он ссылается на составной первичный ключ в другой таблице. Очевидно, что количество столбцов и их типы данных в первичном и внешнем ключах совпадают.
Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей. На Рис. 1.1. показаны три внешних ключа таблицы ZAKAZY из учебной базы данных:
столбец ID_CLN является внешним ключом для таблицы CLIENTY и связывает каждый заказ с клиентом, сделавшим его;
столбец ID_SLZH является внешним ключом для таблицы SLUZHASCHIE и связывает каждый заказ со служащим, принявшим его;
столбцы ID_MFR и ID_PRD совокупно представляют собой составной внешний ключ для таблицы TOVARY, который связывает каждый заказ с заказанным товаром.
Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют отношения между таблицами базы данных.