Главная » SQL, Базы данных » ОТНОШЕНИЯ И ПЕРЕМЕННЫЕ ОТНОШЕНИЯ

0

Если предположить, что реляционная база данных — это по существу просто  база данных, в которой данные представлены в виде таблиц (а это так и есть), то возникает резонный вопрос: почему же мы называем такую базу данных именно реляционной, а не, скажем, табличной? Ответ прост (фактически он был дан еще в главе 1): термин "relation" (отношение) — это формальное название таблицы (точнее, определенного вида таблиц; подробности будут приведены в главе 6). Например, можно сказать, что база данных отделов и служащих, представленная на рис. 3.1, содержит два отношения.

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

■     Как уже отмечалось, реляционные системы основаны на реляционной модели. Ре ляционная модель, в свою очередь, — это абстрактная теория данных, основанная на некоторых областях математики (в основном на теории множеств и логике пре дикатов).

■     Принципы реляционной  модели были сформулированы  в   1969 и   1970 годах Е.Ф. Коддом (E.F. Codd), который в то время работал в корпорации IBM. В конце 1968 года Кодд, математик по образованию, впервые пришел к выводу, что для внедрения в сферу управления базами данных строгих и точных принципов можно использовать математические дисциплины. В то время данной области недостава ло именно этих качеств. Идеи Кодда впервые подробно были изложены в статье "A Relational Model of Data for Large Shared Data Banks", ставшей классической (см. [6.1] в главе 6).

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

В теории реляционной модели, с того времени, как она была первоначально сформулирована Коддом, умышленно применялись лишь определенные, тщательно подобранные термины. Например, вначале сам термин отношение в сфере информационных технологий практически не использовался, хотя такое  понятие иногда употреблялось в других областях. Суть заключалась в том, что многие распространенные тогда термины были очень нечеткими — им не хватало точности, необходимой для такой формальной теории, которую предложил Кодд. Например, рассмотрим термин запись. В разное время и в различных контекстах он мог означать экземпляр записи или тип записи, логическую запись или физическую запись, хранимую запись или виртуальную запись, а возможно, и еще что-нибудь. Поэтому в формальной реляционной модели термин запись не используется вообще — вместо него применяется термин кортеж (tuple), точное определение которого дал сам Кодд, когда ввел его впервые. Мы не станем приводить здесь это определение (оно дано в главе 6), а лишь отметим, что термин кортеж приблизительно соответствует понятию строки (так же, как термин отношение приблизительно соответствует понятию таблицы). Аналогичным образом, в реляционной модели не используется

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

При дальнейшем изучении теоретических аспектов реляционных систем в части II мы

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

такими как строка и столбец. Однако один формальный термин — отношение — мы всетаки будем использовать довольно часто.

Снова обратимся к базе данных отделов и сотрудников, представленной на рис. 3.1. Заметим, что таблицы DEPT И ЕМР В базе данных фактически являются переменными отношения, т.е. их значения — это значения отношения (т.е. отношения принимают различные значения в разное время). Предположим, например, что таблица ЕМР в данный момент имеет значение (значение отношения), которое показано на рис. 3.1, и далее допустим, что мы удалили строку о сотруднике с фамилией Saito (его номер — Е4).

DELETE ЕМР WHERE ЕМР# = ЕМР# (‘Е4′) ;

Результат выполнения этой операции показан на рис. 3.3.

Рис. 3.3. Переменная отношения ЕМР после удаления строки сотрудника с кодом Е4

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

ЕМР := ЕМР WHERE NOT ( ЕМР# = ЕМР# ( ‘ Е4 ‘ ) ) ;

Как и при любом присваивании, здесь с концептуальной точки зрения  сначала  вычисляется выражение, расположенное справа от знака присваивания, а затем результат присваивается переменной, которая записана перед знаком присваивания (по определению перед знаком присваивания может стоять, естественно, только переменная). В целом, как уже отмечалось, задача заключается в том, чтобы заменить "старое" значение отношения ЕМР "новым".

Примечание. Как первоначальный оператор DELETE, так и равносильный ему оператор

присваивания записаны на языке Tutorial D, который широко используется в данной книге.

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

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

приводит к путанице. Поэтому в дальнейшем мы будем четко различать переменные отношения и сами отношения. Следуя примеру публикации [3.3], для переменной отношения (relation variable) будем использовать термин переменная отношения (сокращенный английский вариант — relvar), и только этот термин, во всех случаях, когда речь будет идти не об отношении, а о переменной отношения3. Обратите внимание на то, что с этого момента неуточненный термин отношение будет применяться именно для описания значения отношения (по такому же принципу, как, например, неуточненный термин целое число применяется исключительно для описания целочисленного значения), хотя время от времени мы будем также использовать уточненный термин значение отношения, чтобы

подчеркнуть его отличие от переменной отношения.

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии