Домены и типы данных

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

Здесь мы имеем определенный пользователем тип, названный "Day" (имеющий в точности семь допустимых значений), и переменную, названную "Today", принадлежащую этому типу данных (а значит, ограниченную этими семью значениями). Очевидно, что эта ситуация полностью аналогична ситуации в реляционной базе данных, когда мы имеем домен, названный "Day", и атрибут, названный "Today", Более того, существуют языки программирования, например SIMULA 67, MODULA-2 или Ada (однако Pascal в их число не входит), которые поддерживают некоторые или даже все функции, обычно приписываемые доменам в реляционной модели [4.8].

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

Что же включают в себя возможности для работы с этими типами? Конечно, это не только описанные выше сравнения, ограниченные доменами. На самом деле понятие домена значительно сложнее, чем может показаться с первого взгляда (именно поэтому многие современные системы и не поддерживают его). Однако из-за большого объема материала мы некоторое время не будем касаться дальнейших следствий. Поэтому пока будем предполагать, что поддержка доменов означает только одно: если два скалярных значения можно сравнивать, то они принадлежат одному домену. Нужно понимать, что это весьма существенное упрощение, и мы прибегли к нему, чтобы упростить общее изложение. Дальнейшее обсуждение этого вопроса приводится в следующих частях книги.

Отношения

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

создается переменная отношения с именем s, значение которой в любой момент времени будет определенным значением отношения.^[1][1]

Поэтому обратите внимание, что базовое отношение (или "базовая таблица")— это не совсем точный термин; более точным, хотя и более громоздким, будет термин переменная базового отношения. В конце концов, если мы в некотором языке программирования объявим переменную QTY следующим образом:

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

Значения отношений

Вот определение термина "отношение" (специфически обозначающего значение отношения):

■ ■ Отношение R, определенное на множестве доменов D1, D2,..., Dn (не обязательно различных), содержит две части: заголовок и тело. (Если представить отношение в терминах таблиц, заголовок — это строка заголовков столбцов, а тело — это множество строк данных.)

1. 1. Заголовок содержит фиксированное множество атрибутов или, точнее, пар <имя-атрибута:имя-домена>:

{ <A1:D1>, < A2:D2>,..., <A1:Dn> },

причем каждый атрибут Aj соответствует одному и только одному из лежащих в основе доменов Dj (j= 1,2,..., n). Все имена атрибутов А1, А2,..., An разные.

2. 2. Тело содержит множество кортежей. Каждый кортеж, в свою очередь, содержит множество пар <имя-атрибута:значение-атрибута>:

{ <A1:vi1>, <A2: vi2>,..., <Аn: vin> }

(i = 1,2,..., т, где т — количество кортежей в этом множестве). В каждом таком кортеже есть одна такая пара <имя-атрибута:значение-атрибута>, т.е. <Aj:vij>, длякаждого атрибута Aj в заголовке. Для любой такой пары <Aj:vij> vij является значением из уникального домена Dj, который связан с атрибутом Aj.

Значения т и п называются соответственно кардинальным числом и степенью отношения R.

В качестве примера давайте рассмотрим таблицу S из рис. 4.1 (мы умышленно сейчас не называем ее отношением), чтобы проверить, как она соответствует этому определению.

■ ■ Во-первых, в этой таблице есть четыре основных домена, а именно: домен номеров поставщиков (S#), домен имен (NAME), домен значений статуса (STATUS) и домен наименований городов (CITY). (Изображая отношение как таблицу на листе бумаги, мы обычно не заботимся о том, чтобы показать лежащие в основе домены, но должны понимать, что, по крайней мере концептуально, они всегда есть.)

■ ■ Далее, в таблице непременно есть две части: строка заголовков столбцов, а также множество строк данных. Рассмотрим вначале строку заголовков столбцов:

(S#, SNAME, STATUS, CITY)

Эта строка в действительности представляет набор упорядоченных пар:

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

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

■ ■ Что касается остальной таблицы, то это; конечно, набор строк. Давайте сконцентрируем внимание на какой-нибудь одной строке, скажем, на строке

Эта строка в действительности представляет набор упорядоченных пар:

Первый компонент каждой пары — это имя атрибута, второй компонент — соответствующее значение атрибута. Часто в неформальном описании опускают имена атрибутов, так как известно, что каждое отдельное значение в таблице в действительности является значением атрибута, имя которого находится сверху соответствующего столбца; кроме того, мы знаем, что значение принадлежит лежащему в основе этого атрибута домену. Например, значение "S1" — это значение атрибута S#, и оно взято из соответствующего лежащего в основе домена, а именно домена номера поставщика (который также называется S#). Таким образом, можно условиться, что каждая строка представляет кортеж в соответствии с определением.

Исходя из вышесказанного, мы можем согласиться, что таблицу S на рис. 4.1 можно рассматривать как изображение отношения в смысле определения, если мы условились, как "читать" такое изображение (т.е. если у нас есть определенные правила интерпретации таких изображений). Иначе говоря, мы должны условиться, что есть некоторые, лежащие в основе домены; каждый столбец соответствует только одному из этих доменов; каждая строка представляет кортеж; каждое значение атрибута принадлежит соответствующему домену и т.д. Если мы приняли все эти "правила интерпретации", то тогда и только тогда можно говорить, что таблица — это приемлемое изображение отношения.

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

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

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