Часть II

РЕЛЯЦИОННАЯ МОДЕЛЬ

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


    Глава 4 

    Реляционные объекты данных: домены и отношения 

    4.1. Вводный пример 

    Как отмечалось в главе 3, реляционная модель делится на три части, в 
которых рассматриваются соответственно объекты, целостность и операторы. Во 
всех трех частях есть свои специальные термины. Наиболее важные термины, 
используемые в части "объектов" (предмет настоящей главы), показаны на рис. 
4.1. В качестве иллюстрации взята таблица S из базы данных поставщиков и 
деталей. Речь идет о терминах отношение, кортеж, кардинальное число, атрибут, 
степень, домен и первичный ключ (вы уже должны быть знакомы по крайней мере с 
терминами отношение и первичный ключ). Сейчас мы дадим неформальное объяснение 
каждого термина, а в последующих разделах представим формальные определения. 

    Рис. 4.1. Отношение поставщиков S 

    Итак, вкратце: 
    Отношение соответствует тому, что мы до сих пор называли таблицей. 
    Кортеж соответствует строке этой таблицы, а атрибут — столбцу. Количество 
кортежей называется кардинальным числом, а количество атрибутов — степенью. 
    Первичный ключ — это уникальный идентификатор для таблицы, т.е. столбец 
или такая комбинация столбцов, что в любой момент времени не существует двух 
строк, содержащих одинаковое значение в этом столбце или комбинации столбцов. 
    И наконец, домен — это общая совокупность значений, из которой берутся 
настоящие значения для определенных атрибутов определенного отношения. 
Например, домен, обозначенный S# на рис. 4.1 — это множество всех допустимых 


    Первичный   ключ 

    S-*(S#)   SNAME   STATUS     CITY 
    SI      Smith	20        London 

Отношение                  S2      Jones               10         
Paris                  J 53      Blake	30        Paris      4

Кортежи  с 
    54      Clark	20        London    S5 
     Adams           30        Athens   
 
    Атрибуты Степень Атрибуты  Степень


    Глава 4. Реляционные объекты данных: домены и отношения     79 


значений номера поставщика, а множество значений S# в отношении S в любой
момент времени является подмножеством этого множества. Точно так же множе-
ство значений S# в отношении SP в любой момент времени является подмножест-
вом этого множества.

На рис. 4.2 представлен обзор этих терминов. Этот рисунок требует некоторых
пояснений.

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

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

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

Формальный реляционный термин	Неформальный эквивалент

Отношение 				Таблица 
Кортеж 				Строка или запись 
Кардинальное число 		Количество строк 
Атрибут 				Столбец или поле 
Степень 				Количество столбцов 
Первичный ключ 			Уникальный идентификатор 
Домен					Общая совокупность допустимак значений



Рис. 4,2. Реляционные объекты данных: терминология

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

4.2. Домены

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

Замечание. Мы мимоходом заметили, что понятие "атомарности скалярных зна-
чений" довольно расплывчатое [4.8, 4.15]. Однако дальнейшее обсуждение этого во-
проса отложено для следующих глав книги; а сейчас будем полагать, что это понятие
интуитивно понятно.

    80 Часть II. Реляционная модель

    Теперь можно определить домен как именованное множество скалярных значений 
одного типа. Например, домен номеров поставщиков — это множество всех 
возможных номеров поставщиков; домен количества деталей для поставок — это 
множество всех целых чисел, больших нуля и меньших, скажем, 10 000. Итак, 
домены являются общими совокупностями значений, из которых берутся реальные 
значения атрибутов. Точнее, каждый атрибут должен быть определен на 
единственном домене (или на основе одного домена); это значит, что значения 
атрибута должны браться из этого домена. Например, атрибут номера детали для 
отношения Р и атрибут номера детали для отношения SP определены на домене 
номера детали (потому что эти два атрибута, бесспорно, представляют номера 
деталей). Другими словами, в любой момент времени каждое значение Р# в 
отношении Р должно быть значением из домена номера детали, то же верно для 
значения Р# в отношении SP. Иными словами, в любой момент времени набор 
значений Р# в отношении Р является некоторым подмножеством множества значений 
домена номера детали, и то же верно для значения Р# в отношении SP. 
    Между прочим, обратите внимание, что обычно в любой момент времени в 
домене будут значения, не являющиеся значением ни одного из атрибутов, 
соответствующих этому домену. Например, если значение Р8 — допустимое значение 
детали, то оно входит в домен номера детали, даже если в нашем отношении Р из 
примера базы данных поставщиков и деталей нет детали Р8, т.е. в данный момент 
не существует такой детали. 

    Сравнения, ограниченные доменом 

    В чем состоит значение доменов? Один из наиболее важных ответов на этот 
вопрос следующий: домены ограничивают сравнения. Поясним сказанное. Рассмотрим 
два запроса SQL к базе данных поставщиков и деталей (заметьте, что оба запроса 
используют соединение): 

    SELECT   ..... FRCM         Р,     SP WHERE    P.P# = SP.P#  ; 

    SELECT   ..... FROM         Р,     SP   WHERE    P.WEIGHT = SP.QTY 

    Один из этих запросов, а именно левый, возможно, имеет смысл, тогда как 
правый, скорее всего, — нет. Откуда это известно? С формальной точки зрения 
ответ заключается в том, что запрос слева использует сравнение между 
атрибутами Р.Р# и SP.P#, которые (как уже упоминалось) определены на одном и 
том же домене, в то время как запрос справа использует сравнение между 
атрибутами P.WEIGHT и SP.QTY, которые, вероятно, определены на разных доменах. 
(Мы здесь говорим "вероятно", поскольку, хотя вес и количество являются 
числами, это числа разного "сорта". Не имеет смысла сравнивать вес и 
количество. Поэтому домены веса и количества должны быть различными.) 
    Следовательно, в соответствии с предыдущими рассуждениями, если значения 
двух атрибутов взяты из одного и того же домена, тогда сравнения, а отсюда и 
соединения, объединения и многие другие операции, использующие такие два 
атрибута, тоже, вероятно, будут иметь смысл, так как в них сравнивается 
подобный атрибут с подобным. И наоборот, если значения двух атрибутов взяты из 
различных доменов, тогда сравнения и другие операции, наверное, не будут иметь 
смысла. Поэтому преимущество системы поддержки доменов заключается в том, что 
такая система способна предотвратить грубые ошибки. Обратите внимание, что 
здесь легко допустить механическую ошибку, например набрав S# вместо Р#. Если 
пользователь попробует выполнить операцию, использующую сравнение значений 
разных доменов, система прервет свою работу и сообщит пользователю о возможной 
ошибке. (Мы говорим "возможной", поскольку могут быть обстоятельства, при 
которых такое сравнение не является ошибкой. Но об этом в следующих частях книги.) 

    Глава 4. Реляционные объекты данных: домены и отношения	81 

    Между прочим, следует отметить, что хотя все примеры, которые мы 
приводили, были выражены в терминах языка SQL, этот язык на самом деле не 
поддерживает доменов в том смысле, который мы им придаем. Оба указанных выше 
запроса допустимы в SQL. Однако второй, конечно же, даст бессмысленный ответ. 

    Определение данных 

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

    CREATE DOMAIN domain data-type ; 

    Здесь domain— это имя нового домена, a data-type соответствует типу 
данных, например CHARM или NUMERIC (л). Замечание. Далее в книге мы обсудим 
некоторые дополнительные компоненты оператора CREATE DOMAIN, не показанные выше. 
    На рис. 4.3 (такой же рисунок уже приводился в главе 3) показано, как с 
помощью этого языка можно определить базу данных поставщиков и деталей. 
Обратите внимание, что в этом примере наряду с операторами CREATE DOMAIN 
используются операторы CREATE BASE RELATION. 
    ПоЛНОС ОПИСЗНИС Оператора CREATE BASE RELATION ДЗНО НИЖС В ЭТОЙ главе; 
здесь мы лишь отметим, что каждое определение атрибута в операторе CREATE 
 BASE RELATION ВКЛЮЧЗСТ ССЫЛКу НЗ СООТВСТСТВуЮЩИЙ ДОМСН. 
    При создании нового домена с помощью оператора CREATE DOMAIN СУБД создает 
запись в каталоге с описанием этого нового домена. (Чтобы вспомнить, что такое 
каталог, обратитесь еще раз к главе 3.) Точно так же при создании нового 
отношения с помощью оператора CREATE BASE RELATION СУБД создает запись в 
каталоге с описанием этого нового отношения. 
    Замечание о названиях. Для определенности будем предполагать следующие 
ограничения на названия: 
    •  Домены имеют уникальные имена в базе данных. 
    •  Именованные отношения имеют уникальные имена в базе данных. 
    •  Атрибуты имеют уникальные имена в содержащем их отношении (даже если 
содержащее их отношение не именовано!). 
    Вообще говоря, атрибут может иметь как имя, совпадающее с именем 
соответствующего домена, так и отличное от него имя. Очевидно, чтобы избежать 
двусмысленности, следует использовать разные имена (в частности, если два 
атрибута в одном отношении основаны на одном домене). Однако в общем 
желательно называть атрибуты таким же именем, что и лежащий в основе домен, 
или, по крайней мере, называть так, чтобы, например, в имени атрибута 
содержалась ключевая часть имени домена. Мы следуем этому указанию и в примере 
на рис. 4.3. 
    Можно дополнительно придерживаться другого общего соглашения и полностью 
опускать ссылку к основному домену из определения любого атрибута, который 
имеет то же самое имя, что и домен. Например, оператор CREATE BASE RELATION 
для базового отношения S может быть упрощен: 

    82	Часть II, Реляционная модель 

    CREATE BASE RELATION S 
    { S#, SNAME DOMAIN (NAME), STATUS, CITY ) PRIMARY KEY ( SI ) ; 

    CREATE DOMAIN Sit	CHAR(5) ; 
    CREATE DOMAIN NAME	CHAR(20) ; 
    CREATE DOMAIN STATUS	NUMERIC (5) ; 
    CREATE DOMAIN CITY	CHAR(15) ; 
    CREATE DOMAIN P#	CHAR(6) ; 
    CREATE DOMAIN COLOR	CHAR(6) ; 
    CREATE DOMAIN WEIGHT	NUMERIC (5) ; 
    CREATE DOMAIN OTY	NUMERIC (9) ; 

    CREATE BASE RELATION S 
    ( SI	DOMAIN ( SI ), SNAME DOMAIN ( NAME ), STATUS DOMAIN ( STATUS ), 
CITY DOMAIN ( CITY ) ) PRIMARY  KEY  ( SI ) ; 

    CREATE BASE RELATION P 
    ( PI	DOMAIN ( PI ), PNAME DOMAIN ( NAME ), COLOR DOMAIN ( COLOR ), WEIGHT  
     DOMAIN ( WEIGHT ), CITY         DOMAIN ( CITY ) ) PRIMARY KEY ( PI ) ; 

    CREATE BASE RELATION SP 
    ( SI	DOMAIN ( SI ), 
    PI	DOMAIN ( PI ), 
    QTY	DOMAIN ( QTY ) ) 
    PRIMARY KEY	( SI, PI ) 

    FOREIGN KEY	( SI ) REFERENCES S 

    FOREIGN KEY	( PI ) REFERENCES P ; 


    Рис. 4.З. База данных поставщиков и деталей (определение данных) 

    Удаление доменов. Мы уже знаем, как создать новый домен. Должна также быть 
возможность удалить существующий домен, если мы больше в нем не нуждаемся: 

    DESTROY DOMAIN domain ; 

    Здесь domain— это имя удаляемого домена. С помощью этой операции удаляется 
элемент каталога, описывающий домен, поэтому такой домен становится 
неизвестным для системы. (До особого указания будем подразумевать, что 
операция DESTROY DOMAIN просто не будет выполняться, если какое-нибудь базовое 
отношение в этот момент еще включает атрибут, который определен на указанном домене.) 
    Запросы, основанные на доменах. Вот другой пример практического значения 
доменов. Рассмотрим запрос, который формулируется так: 
    "Какие отношения в базе данных содержат какую-либо информацию, имеющую 
отношение к поставщикам?" 
    Этот вопрос может быть сформулирован более точно: 
    "Какие отношения в базе данных включают атрибут, который определен на 
домене поставщика?" 
    В системе, поддерживающей понятие домена, такой запрос, как видим, 
транслируется в простой запрос к каталогу. В системе, которая не поддерживает 
домены, очевидно, невозможно обратиться с запросом к каталогу относительно 
доменов. Можно обратиться только через атрибуты. Запрос по атрибутам достигнет 
указанной цели лишь в том случае, если разработчик базы данных следует 
рекомендациям по наименованиям, приведенным выше (другими словами, если он 
соблюдает в базе данных порядок по отношению к доменам). 

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

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

    Глава 4. Реляционные объекты данных: домены и отношения 83 

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

    type Day = { Sun, Mon, Tue, Wed, Thu, Fri, Sat ) ; var Today : Day ; 

    Здесь мы имеем определенный пользователем тип, названный "Day" (имеющий в 
точности семь допустимых значений), и переменную, названную "Today", 
принадлежащую этому типу данных (а значит, ограниченную этими семью 
значениями). Очевидно, что эта ситуация полностью аналогична ситуации в 
реляционной базе данных, когда мы имеем домен, названный "Day", и атрибут, 
названный "Today". Более того, существуют языки программирования, например 
SIMULA 67, MODULA-2 или Ada (однако Pascal в их число не входит), которые 
поддерживают некоторые или даже все функции, обычно приписываемые доменам в 
реляционной модели [4.8]. 
    Исходя из того, что домен в своей основе является просто типом данных, 
было бы неверно утверждать, что СУБД вовсе не поддерживают доменов. В 
действительности системы поддерживают домены в очень примитивном смысле, так 
же как они предоставляют определенные встроенные (т.е. определенные системой) 
примитивные типы данных, такие как тип целых чисел или тип чисел с плавающей 
точкой. Но, если говорить о поддержке доменов в контексте реляционных систем, 
мы имеем в виду нечто большее, чем такая примитивная поддержка, а именно то, 
что система должна обеспечивать возможность пользователю создавать свои, более 
сложные типы данных, такие как "номера поставщиков", "номера деталей", 
"названия городов", "цвета" и т.д., а также обеспечивать все возможности для 
работы с этими типами. 
    Что же включают в себя возможности для работы с этими типами? Конечно, это 
не только описанные выше сравнения, ограниченные доменами. На самом деле 
понятие домена значительно сложнее, чем может показаться с первого взгляда 
(именно поэтому многие современные системы и не поддерживают его). Однако 
из-за большого объема материала мы некоторое время не будем касаться 
дальнейших следствий. Поэтому пока будем предполагать, что поддержка доменов 
означает только одно: если два скалярных значения можно сравнивать, то они 
принадлежат одному домену. Нужно понимать, что это весьма существенное 
упрощение, и мы прибегли к нему, чтобы упростить общее изложение. Дальнейшее 
обсуждение этого вопроса приводится в следующих частях книги. 

    4.3. Отношения 

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

    CREATE BASE RELATION S ... ; 

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

    DECLARE OTY INTEGER  . . .   ; 

то эту переменную мы будем называть не целым числом, а переменной целого 
типа. В действительности целыми числами являются значения этой переменной; 
иначе говоря, 
    ' Если рассматривать отношения как таблицы, то мы могли бы сказать, что, 
например, переменная отношения S в разное время представляет разные таблицы. 
Однако заметьте, что в этих разных таблицах будут разные строки, а столбцы 
будут одинаковые. 

    84	Часть II. Реляционная модель 

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

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

    Вот определение термина "отношение" (специфически обозначающего значение отношения): 
    •   Отношение R, определенное на множестве доменов Dl, D2,..., Dn (не 
обязательно различных), содержит две части: заголовок и тело. (Если 
представить отношение в терминах таблиц, заголовок — это строка заголовков 
столбцов, а тело — это множество строк данных.) 
1.  Заголовок содержит фиксированное множество атрибутов или, точнее, пар 
<имя-атрибута:имя-домена>: 

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

причем каждый атрибут Aj соответствует одному и только одному из лежащих в 
основе доменов Dj (j= 1,2,..., ri). Все имена атрибутов Al, А2,..., An разные. 
    2.  Тело содержит множество кортежей. Каждый кортеж, в свою очередь, 
содержит множество пар <имя-атрибута:значение-атрибута>: 
    {  <Al:vil>,  <A2:  vi2>,   ...,  <Ап:  vin> } 
    (/ = 1, 2, ..., т, где т— количество кортежей в этом множестве). В каждом 
таком кортеже есть одна такая пара <имя-атрибута:значение-атрибута>, т.е. 
<Aj:vij>, для каждого атрибута Aj в заголовке. Для любой такой пары <Aj:vij> 
vij является значением из уникального домена Dj, который связан с атрибутом Aj. 
    Значения т и п называются соответственно кардинальным числом и степенью 
отношения R. 
    В качестве примера давайте рассмотрим таблицу S из рис. 4.1 (мы умышленно 
сейчас не называем ее отношением), чтобы проверить, как она соответствует 
этому определению. 
    •   Во-первых, в этой таблице есть четыре основных домена, а именно: домен 
номеров поставщиков (S#), домен имен (NAME), домен значений статуса (STATUS) и 
домен наименований городов (CITY). (Изображая отношение как таблицу на листе 
бумаги, мы обычно не заботимся о том, чтобы показать лежащие в основе домены, 
но должны понимать, что, по крайней мере концептуально, они всегда есть.) 
    •  Далее, в таблице непременно есть две части: строка заголовков столбцов, 
а также множество строк данных. Рассмотрим вначале строку заголовков столбцов: 

    (  S#,   SNAME,   STATUS,   CITY  ) 

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

    { < S#	:S#	>, 
    < ЗМДМЕ	:NAME	>, 
    < STATUS	:STATUS	>, 
    < CITY	:CITY	> } 

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

    Глава 4. Реляционные объекты данных: домены и отношения	85 

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

    ( SI, Smith, 20, London ) 

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

    { < S#	:	'SI1 
    < ЗМЙМЕ	:	'Smith1 
    < STATUS	:	20     >, 
    < CITY	:	1Londonl > } 

    Первый компонент каждой пары — это имя атрибута, второй компонент — 
соответствующее значение атрибута. Часто в неформальном описании опускают 
имена атрибутов, так как известно, что каждое отдельное значение в таблице в 
действительности является значением атрибута, имя которого находится сверху 
соответствующего столбца; кроме того, мы знаем, что значение принадлежит 
лежащему в основе этого атрибута домену. Например, значение "S1" — это 
значение атрибута S#, и оно взято из соответствующего лежащего в основе 
домена, а именно домена номера поставщика (который также называется S#). Таким 
образом, можно условиться, что каждая строка представляет кортеж в 
соответствии с определением. 
    Исходя из вышесказанного, мы можем согласиться, что таблицу S на рис. 4.1 
можно рассматривать как изображение отношения в смысле определения, если мы 
условились, как "читать" такое изображение (т.е. если у нас есть определенные 
правила интерпретации таких изображений). Иначе говоря, мы должны условиться, 
что есть некоторые, лежащие в основе домены; каждый столбец соответствует 
только одному из этих доменов; каждая строка представляет кортеж; каждое 
значение атрибута принадлежит соответствующему домену и т.д. Если мы приняли 
все эти "правила интерпретации", то тогда и только тогда можно говорить, что 
таблица — это приемлемое изображение отношения. 
    Теперь можно сказать, что отношение и таблица — это действительно не одно 
и то же (даже хотя в предыдущих главах и предполагалось обратное). Отношение — 
это в соответствии с данным ранее определением довольно абстрактный вид 
объекта, а таблица — это конкретное изображение (обычно на бумаге) этого 
абстрактного объекта. Конечно, они очень близки... и по крайней мере в 
неформальном контексте обычно их отождествляют. Но когда мы хотим говорить 
более формально и более точно (а теперь мы, конечно, хотим быть более 
точными), то должны признать, что эти два понятия не являются в точности идентичными. 
    (Ведь тот же набор значений отношения можно представить и не в виде 
таблицы, а например, в виде перечисляющегося списка. Например, в отделе А 
работают Иванов, Петров и Сергеев, а в отделе Б — Григорьев и Николаев. Такое 
перечисление не является таблицей (во всяком случае в данном контексте), хотя 
эти значения и составляют некое отношение служащих и отделов. — Прим. ред.) 
    Замечание. Если у вас возникли затруднения с пониманием идеи некоторых 
различий между отношением и таблицей, вам может помочь следующее. Во-первых, 
одним из неоспоримых преимуществ реляционной модели является то, что ее 
основной абстрактный объект (т.е. отношение) имеет простое представление на 
бумаге (т.е. представление в виде таблицы); именно такое представление делает 
реляционные системы простыми в использовании и простыми для понимания, а также 
облегчает понимание их поведения. Однако, к сожалению, табличное представление 
предполагает некоторые неверные факты. К примеру, оно явно предполагает, что 
строки таблицы (т.е. кортежи отношения) расположены в определенном порядке 
сверху вниз, хотя это неверно. Ниже в этой главе приводится дальнейшее 
обсуждение данного вопроса.	

    86	Часть II. Реляционная модель 

    Переменные отношений 

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

    CREATE BASE RELATION S   ...   ; 

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

    DECLARE QTY INTEGER  . . .   ; 

то переменную OTY мы будем называть не "изменяющимся со временем" целым 
числом, а переменной целого типа. Поэтому в данной книге будет использоваться 
термин "переменная отношения"; однако читатель должен знать о существовании и 
другого термина. 
    Теперь пусть R — переменная отношения; переменная R будет иметь разные 
значения в разное время. Однако все возможные значения переменной R будут 
иметь одинаковые заголовки. Например, все возможные значения базового 
отношения S будут иметь заголовок {S#,SNAME,STATUS,CITY}.1 

    И еще о терминологии 

    Как мы уже объясняли, количество атрибутов в данном отношении называется 
степенью (иногда называют арностью) отношения. Отношение первой степени 
называется унарным, отношение степени 2 — бинарным, отношение степени 3 — 
тернарным ... и отношение степени п — п-арным. (В общем случае в реляционной 
модели рассматриваются и-арные отношения, где п — произвольное неотрицательное 
целое число.) В базе данных поставщиков и деталей отношения S, P и SP имеют 
степень 4,5 иЗ, соответственно. 
    Иногда возникает неясность из-за схожести понятий домена и унарного 
отношения (ведь домен выглядит как раз как таблица с одним столбцом). Однако 
заметьте, что существует довольно существенная разница между этими двумя 
понятиями: домены статичны, а отношения динамичны (здесь под отношением мы 
понимаем переменную отношения). Другими словами, содержимое (переменной) 
отношения изменяется со временем, а содержимое домена — нет (вспомним, что 
домен содержит все возможные значения подходящего типа). Более подробное 
обсуждение этого вопроса смотрите в [4.8]. 

    "Не различные домены" 

    Вернемся вновь к определению отношения: обратите внимание, что лежащие в 
основе отношения домены не обязательно все различны. Это значит, что несколько 
атрибутов в отношении могут иметь основой один домен. Пример такого отношения 
показан на рис. 4.4. (Это отношение названо PART_STRUCTURE.) 
    1 Для читателей, знакомых с языком SQL, отметим, что в SQL существует 
возможность добавлять новый столбец или удалять существующий столбец из 
базовой таблицы посредством оператора ALTER TABLE. Однако эту операцию лучше 
рассматривать не как изменение существующей таблицы, а как уничтожение 
существующей таблицы и создание новой с тем же именем и новым заголовком. 

    Глава 4. Реляционные объекты данных: домены и отношения	87 

    Если один и тот же домен используется более одного раза в одном и том же 
отношении, то, как указывалось ранее, нельзя дать всем атрибутам имена, 
совпадающие с именами лежащих в их основе доменов. На рис. 4.4 показан 
рекомендуемый в такой ситуации подход: называть атрибуты по-разному, так, 
чтобы в качестве префикса у этих имен было "ролевое" имя атрибута, а в 
качестве суффикса — имя домена. Действительно, если условиться всегда 
следовать этому правилу, а также всегда использовать одинаковые символы 
разделения (например, такие как символ подчеркивания), чтобы отделять ролевое 
имя (если оно есть) от имени домена, то нам при определении атрибута никогда 
не понадобится в явном виде спецификация "DOMAIN (domain)" (об этом подробнее 
в следующем разделе). 

    PART STRUCTURE 

    MAJOR_Pt	MINOR_P#	QTY 

    PI		P2		2 
    PI		P3		4 
    P2		P3		1 
    P2		P4		3 
    P3		P5		9 
    P4		P5		8 
    P5		P6		3 

    Рис. 4.4. Отношение PARTSTRUCTURE 


    Определение данных 

    Вот синтаксис оператора CREATE BASE RELATION: 

    CREATE BASE RELATION base-relation ( attribute-definition-commalist ) Candidate-key-definition-list 
	foreign-key-definition-list ; 

    При выполнении этого оператора создается новое базовое отношение с именем 
base-relation, а также указанные атрибуты, потенциальные и внешние ключи. 
Отношение создается пустым (т.е. не содержит кортежей). Несколько примеров 
использования этого оператора вы найдете на рис. 4.3. Ниже приводятся 
некоторые пояснения к оператору. 
    1. Термины list (список) и commalist (список, разделенный запятыми) удобно 
использовать при описании операторов (они будут использоваться здесь и далее в 
книге). В общем они значат следующее: 
    • Если xyz — синтаксическая единица, то xyz-iist — это синтаксическая 
единица, которая состоит из последовательности единиц xyz, количество которых 
больше либо равно нулю, причем каждые две единицы xyz между собой разделены по 
крайней мере одним пробелом. 
    • Если xyz— синтаксическая единица, то xyz-comalist— это синтаксическая 
единица, которая состоит из последовательности единиц xyz, количество которых 
больше либо равно нулю, причем каждые две единицы xyz между собой разделены 
запятой (и возможно, одним или несколькими пробелами). 
    Так, например, СПИСОК определения атрибутов 
attribute-defenition-comraalist СОСТОИТ из последовательности единиц 
attribute-defenition (т.е. определений атрибутов), каждая из которых, за 
исключением последней, отделяется от следующей pапятой, а СПИСОК Определения 
ПОТеНЦИалЬНЫХ КЛЮЧеЙ Candidate-key-defini-tion-list СОСТОИТ ИЗ 
ПОСЛСДОВаТСЛЬНОСТИ еДИНИЦ candidate-key-definition (т.е. ОПределений 
потенциальных ключей), каждая из которых, за исключением последней, отделяется 
от следующей по крайней мере одним пробелом. То же самое можно сказать О 
СПИСКе определения внешних КЛЮЧеЙ foreign-fcey-definition-list. 

    Часть II. Реляционная модель 88 

    Замечание. Здесь и далее мы будем опускать дефисы из таких выражений, как 
"candidate key definition" (за исключением формального синтаксиса), конечно, 
если при этом не возникает неясности. 
    2.  Определение атрибута имеет следующую форму: 
    attribute DOMAIN ( domain ) 
    Если опустить спецификацию "DOMAIN ( domain )", то считается, что атрибут 
основан на домене с тем же именем. 
    3.  Определение потенциальных ключей подробно объясняется в следующей 
главе. А пока будем просто предполагать, что в каждом операторе CREATE BASE 
RELATION есть только одно определение в следующей форме: 
    PRIMARY KEY  (  attribute-commalist ) 
    4.  Определения внешних ключей также объясняются в следующей главе. 
    Удаление базовых отношений. Вот синтаксис оператора удаления существующего 
базового отношения: 

    DESTROY BASE RELATION base-relation ; 

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

    Свойства отношений 

    У отношений есть определенные свойства, все они являются непосредственными 
свойствами данного ранее определения отношения, и все они имеют очень важное 
значение. Мы сначала кратко укажем эти свойства, а затем подробно их обсудим. 
Речь идет о перечисленных ниже четырех свойствах. В любом отношении 
    •  нет одинаковых кортежей; 
    •  кортежи не упорядочены сверху вниз; 
    •  атрибуты не упорядочены слева направо; 
    •  все значения атрибутов атомарные. 
1. Нет одинаковых кортежей. 
    Это свойство следует из того факта, что тело отношения — это 
математическое множество (кортежей), а множества в математике по определению 
не содержат одинаковых элементов. 
    Между прочим, первое свойство служит хорошей иллюстрацией того, что 
отношение и таблица — это не одно и то же, так как таблица (в общем случае) 
может содержать одинаковые строки при отсутствии правил, запрещающих это, в то 
время как отношение не может содержать одинаковых кортежей. (Потому 
"отношение", содержащее одинаковые кортежи, не будет отношением по 
определению!) К большому сожалению, стандарт SQL допускает, чтобы таблицы 
содержали одинаковые строки. Здесь было бы неуместным обсуждать все причины 
того, почему одинаковые строки — это ошибка (развернутое обсуждение этого 
вопроса приводится в [4.5, 4.11]); для наших целей достаточно остановиться на 
том, что реляционная модель не допускает одинаковых строк; здесь и далее в 
этой книге мы также предполагаем, что одинаковые строки не допустимы. (Это 
замечание касается в основном обсуждения языка SQL в главе 8. При рассмотрении 
самой реляционной модели, конечно, никаких предположений делать не надо.) 

    Глава 4. Реляционные объекты данных: домены и отношения	89 

    Важным следствием того факта, что не существует одинаковых строк, является 
то, что всегда существует первичный ключ. Так как кортежи уникальны, то по 
крайней мере комбинация всех атрибутов будет обладать свойством уникальности, 
а значит, при необходимости может служить первичным ключом. На практике, 
конечно, обычно нет необходимости использовать все атрибуты -— подходит 
комбинация из нескольких атрибутов, В главе 5 будет дано определение 
первичного ключа, как не включающего в себя атрибуты, излишние с точки зрения 
уникальности; поэтому, например, комбинация {S#,CITY} хотя и "уникальна", но 
она не является первичным ключом, так как мы можем убрать атрибут CITY, не 
нарушив уникальности. (Однако заметьте, что первичные ключи могут быть 
составными. Примером тому может служить отношение SP.) 
    2. Кортежи не упорядочены (сверху вниз). 
    Это свойство также следует из того, что тело отношения — это 
математическое множество, а простые множества в математике не упорядочены. 
Например, на рис. 4.1 кортежи отношения S могли быть расположены в 
противоположном порядке — это было бы тем же самым отношением. Поэтому в 
отношении нет понятий "пятого кортежа", "97-го кортежа" или "первого кортежа"; 
т.е. нет понятия позиционной адресации и понятия "последовательности".2 В 
статье [4.11], которая уже упоминалась в связи со свойством "нет одинаковых 
кортежей", показано, почему свойство "кортежи не упорядочены" также имеет 
важное значение (в действительности эти свойства взаимосвязаны). 
    Как уже отмечалось в этом разделе, второе свойство отношений также служит 
иллюстрацией того факта, что отношение и таблица — это не одно и то же, так 
как строки таблицы упорядочены сверху вниз, в то время как кортежи отношения — нет. 
    3. Атрибуты не упорядочены (слева направо). 
    Это свойство следует из того факта, что заголовок отношения также 
определен как множество (атрибутов). Например, на рис. 4.1 атрибуты отношения 
S могли быть представлены, скажем, в таком порядке: SNAME, CITY, STATUS, S# — 
это было бы то же самое отношение, по крайней мере с точки зрения реляционной 
модели. Поэтому не существует понятий "первого атрибута" или "последнего 
атрибута" (и т.д.), не существует "следующего атрибута" (опять же нет понятия 
"последовательности"); иначе говоря, атрибут всегда определяется по имени, а 
не по расположению. Это позволяет избежать некоторых ошибок и неясности при 
написании программ. Например, не существует (или не должно существовать) 
возможности сбоя системы из-за "залезания" одного атрибута на другой. Эта 
ситуация отличается от ситуации во многих системах программирования, где можно 
использовать физическую смежность логически дискретных элементов (умышленно 
или случайно) различными методами, потенциально способными повредить систему. 
    Заметим, что вопрос порядка атрибутов — это еще одна область, где 
конкретное представление отношения в виде таблицы предполагает неверные факты: 
столбцы таблицы упорядочены слева направо, а атрибуты отношения — нет. 
    4. Все значения атрибутов атомарные. 
    Последнее свойство является следствием того, что все лежащие в основе 
домены содержат только атомарные значения. Это свойство можно выразить и иначе (довольно 

    1 Точнее, всегда существует по крайней мере один потенциальный ключ. Мы 
предполагаем, что один из потенциальных ключей выбран как первичный. 
Дальнейшее обсуждение этого вопроса приведено в главе 5. 
    2 Понятие "последовательности" требуется для интерфейса между реляционной 
базой данных и базовым языком, таким как С или COBOL. Но это требование для 
базовых языков, а не для реляционной модели. В сущности, эти языки требуют, 
чтобы неупорядоченные множества были преобразованы в упорядоченные таким 
образом, чтобы могли выполняться операции типа "вызвать следующий кортеж". 
Заметьте также, что такие возможности составляют часть прикладного 
программного интерфейса — они не видны конечному пользователю. 

    90	Часть II. Реляционная модель 



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

    BEFORE						AFTER 

    S#	PQ					S#	P#	QTY 
    SI S2 S3 S4						SI SI SI SI SI SI S2 S2 S3 S4 S4 S4	PI P2 P3 P4 P5 P6 PI 
P2 P2 P2 P4 P5	300 200 400 200 100 100 300 400 200 200 300 400 
    P#	QTY 
    PI P2 P3 P4 P5 P6	300 200 400 200 100 100 
    
    
    P#	QTY 
    PI P2	300 400 
    
    
    
    P#	OTY 
    P2	200 
    
    
    P#	QTY 
    P2 P4 P5	200 300 400 
    
    Рис. 4.5. Пример нормализации 

    Сказанное означает, что с точки зрения реляционной модели все отношения 
нормализованы. Это значит, что термин "отношение" всегда означает 
"нормализованное отношение" в контексте реляционной модели. Но дело в том, что 
математическое отношение вовсе не обязано быть нормализованным. Рассмотрим 
отношение BEFORE, изображенное на рис. 4.5. С математической точки зрения 
BEFORE является отношением степени два, в одном из доменов этого отношения 
значениями являются отношения. 
    Следовательно, элементы этого домена сами являются отношениями, а не 
простыми скалярами. В этом примере атрибут PQ определен на основе домена со 
значениями-отношениями, элементами которого являются бинарные отношения; эти 
бинарные отношения определены, в свою очередь, на основе двух доменов со 
скалярными значениями, а именно доменов Р# и QTY. Реляционная модель не 
допускает доменов со значениями-отношениями (это еще будет обсуждаться далее в 
этой книге). 
    Отношение, подобное отношению BEFORE, не допустимо в реляционной базе 
данных. Оно должно быть заменено нормализованным отношением, содержащим ту же 
самую информацию. Таким отношением является отношение AFTER на рисунке (в 
действительности это уже знакомое нам отношение SP). Степень отношения AFTER 
равна трем, и в его основе лежат три домена со скалярными значениями. Как уже 
объяснялось, отношение, подобное отношению AFTER, называется нормализованным; 
отношение, подобное отношению BEFORE, называют ненормализованным; а процесс 
преобразования отношения BEFORE в отношение AFTER называется нормализацией. 
Как показано в этом примере, получить нормализованную форму из 
ненормализованной довольно просто, однако о процессе нормализации следует 
сказать еще многое, и это еще будет обсуждаться далее в книге. 

    Глава 4. Реляционные объекты данных: домены и отношения 91 

    Причина, по которой требуется нормализация всех таблиц, состоит в 
следующем. С математической точки зрения нормализованное отношение имеет более 
простую структуру. Вследствие этого требуется меньше операторов для работы с 
нормализованными отношениями и они проще. Например, рассмотрим две задачи. 
    1. Записать новую информацию о поставке для поставщика S5 деталей Р5 в 
количестве 500. 
    2.  Записать новую информацию о поставке для поставщика S4 деталей Р5 в 
количестве 500. 
    Для отношения AFTER нет существенной разницы в выполнении этих двух 
операций, каждое из них требует вставки одного кортежа в отношение. А для 
отношения BEFORE первая задача требует такой же вставки кортежа в отношение, 
но вторая задача требует существенно отличную операцию, а именно: вставку 
новой записи в набор записей (т.е. группу повторения) внутри существующего 
кортежа. Поэтому для поддержки ненормализованных операций нужны два совершенно 
разных оператора "INSERT". По аналогичным причинам также понадобятся два 
различных оператора "UPDATE", два различных оператора "DELETE" и т.д. Обратите 
внимание, что эти замечания касаются не только операторов обработки данных, но 
и всех операторов системы; например, нужны дополнительные операторы 
обеспечения безопасности данных, нужны дополнительные операторы обеспечения 
целостности данных и т.п. (И вообще, можно считать аксиомой то, что если у нас 
есть п путей представления данных, то нам потребуется « наборов операций.) 
Итак, ответ из одного слова на вопрос "Почему мы настаиваем на нормализации?" 
— это простота: простота объектов, с которыми мы работаем, что приводит к 
упрощению всей системы. 

    4.4. Виды отношений 

    В этом разделе мы определим некоторые из видов отношений, встречающихся в 
реляционных системах (однако обратите внимание, что не все системы 
поддерживают каждый из этих видов). 
    1. Прежде всего, именованное отношение — это переменная отношения, 
определенная в СУБД посредством операторов CREATE BASE RELATION, CREATE VIEW и 
CREATE SNAPSHOT (в используемом нами синтаксисе). Об операторе CREATE VIEW 
рассказывалось в главе 3, а об операторе CREATE SNAPSHOT речь пойдет далее в 
этой главе. 
    2.  Базовым отношением называется именованное отношение, которое не 
является производным (т.е. базовое отношение является автономным). На практике 
базовые — это те отношения, которые считаются достаточно важными (среди 
рассматриваемых в базе данных), и проектировщик базы данных счел нужным дать 
им название и сделать их непосредственной частью базы данных, в отличие от 
менее важных временных отношений (таких как, например, результат запроса). 
    3. Производным отношением называется отношение, определенное (посредством 
реляционного выражения) через другие именованные отношения и, в конечном 
счете, через базовые отношения. 
    Предостережение. Помните, что некоторые авторы под "производным" 
подразумевают "выражаемое" (смотрите следующий пункт). 
    4.  Выражаемым отношением называется отношение, которое можно получить из 
набора именованных отношений посредством некоторого реляционного выражения. 
Конечно, каждое именованное отношение является выражаемым отношением, но не 
наоборот. Базовые отношения, представления, снимки (об этом ниже), 
промежуточные и окончательные результаты отчетов — все это выражаемые 
отношения. Иначе говоря, множество всех выражаемых отношений — это в точности 
множество всех базовых отношений и всех производных отношений. 

    92	Часть И. Реляционная модель 

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

    CREATE SNAPSHOT SC AS 
    ( ( S JOIN SP ) WHERE P# = 'P21 ) [ S#, CITY ] REFRESH EVERY DAY ; 

    Создание снимка похоже на выполнение запроса, за исключением того, что 
результат такого запроса сохраняется в базе данных под определенным именем (SC 
в нашем примере) как отношение, доступное только для чтения, и периодически (в 
нашем примере — каждый день) снимок "обновляется", т.е. его текущее значение 
сбрасывается, запрос выполняется снова и его результат становится новым 
значением снимка. Применение снимков будет обсуждаться в следующих частях книги. 
    7.  Результатом запроса называется неименованное производное отношение, 
служащее результатом некоторого определенного запроса. База данных не 
обеспечивает постоянного существования для результатов запросов (чтобы 
сохранить результат запроса, его можно присвоить некоторому именованному отношению). 
    8.  Промежуточным результатом называется неименованное производное 
отношение, являющееся результатом некоторого реляционного выражения, 
вложенного в другое, большее выражение. Например, рассмотрим такое выражение: 

    (   (  S JOIN SP  )   WHERE Ptt =   'P2'   )    [  S#,   CITY ] 

    Отношение, являющееся результатом выражения s JOIN SP, будет промежуточным 
результатом; назовем его TEMPI. Тогда отношение, являющееся результатом 
выражения TEMPI WHERE p# = 'Р21, также будет промежуточным результатом; 
назовем его ТЕМР2. А отношение, являющееся результатом выражения ТЕМР2 [s#, 
CITY], будет окончательным результатом. База данных не обеспечивает 
постоянного существования для промежуточных результатов, как и для 
окончательных результатов (в действительности, как уже упоминалось в главе 3, 
они могут не существовать в виде полной материализованной таблицы как таковой). 
    9.  И наконец, хранимым отношением называется отношение, которое 
поддерживается в физической памяти "непосредственным" образом (конечно, при 
подходящем определении "непосредственности"; более подробное обсуждение этого 
вопроса выходит за рамки данной главы). 
    В заключение добавим, что хранимое отношение не всегда совпадает с базовым 
отношением. Набор хранимых отношений должен быть таким, чтобы все базовые 
отношения, а значит, и все выражаемые отношения можно было произвести из него; 
но при этом не требуется, чтобы все хранимые отношения были базовыми 
отношениями, и не требуется, чтобы все базовые отношения были хранимыми. Более 
подробное обсуждение этого вопроса было приведено в главе 3. 

    4.5. Отношения и предикаты 

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

    Глава 4. Реляционные объекты данных: домены и отношения	93 

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

    S# =  'SI'  SNAME =  'Smith'  STATUS = 20 CITY =  'London' 

    получим высказывание, являющееся истиной. А при подстановке 

    S# =  'SI'  SNAME =  'Abbey'  STATUS = 45 CITY =  'Tucson' 

    получим высказывание, являющееся ложью (потому что поставщик с номером S1 
имеет имя не Abbey, статус не 45 и располагается не в Туксоне). И в любой 
момент времени отношение содержит в точности те кортежи, при которых предикат 
является истиной. 
    Из вышесказанного следует, что (например) кортеж, представленный в 
качестве кандидата для вставки в некоторое отношение, будет принят СУБД только 
в том случае, если он не противоречит соответствующему предикату (т.е. 
соответствующее высказывание не будет ложью). Вообще предикат данного 
отношения составляет критерий возможности обновления для этого отношения; т.е. 
критерий для решения, является ли некоторое обновление допустимым (или по 
крайней мере "правдоподобным") для данного отношения. 
    Для того чтобы система могла определить допустимость обновления данного 
отношения, ей должен быть известен предикат этого отношения. Конечно, сейчас 
СУБД не может в точности знать предикат для данного отношения. Например, в 
случае отношения S СУБД не может знать точно, что предикат для кортежа 
(Sl,Smith,20,London) будет истиной, а для кортежа (Sl,Abbey,45,Tucson) — нет.1 
Однако СУБД считает кортеж приемлемым, если выполнены следующие условия: 
    •	Значение S# принадлежит домену номеров поставщиков. 
    •	Значение SNAME принадлежит домену имен. 
    •	Значение STATUS принадлежит домену значений статуса. 
    •	Значение CITY принадлежит домену названий городов. 
    •	Значение S# должно быть уникальным среди всех значений отношения. 
    Иначе говоря, для базового отношения, такого как S, в СУБД используются 
определенные, объявленные для этого отношения, правила целостности, такие как 
правило о том, что значение S# уникально и принадлежит домену номеров 
поставщиков. Поэтому формально мы можем определить "значение" (известное СУБД) 
данного базового отношения как логическое умножение (логическая операция И) 
всех известных СУБД применяемых к этому отношению правил. И именно в этом 
смысле СУБД будет проверять допустимость обновления данного отношения. 
    Мы будем еще несколько раз возвращаться к значению отношения в последующих главах. 

    4.6. Реляционные базы данных 

    Исходя из обсуждений и объяснений этой главы, можно дать более формальное 
определение (более формальное, чем данное выше в этой главе) термина 
"реляционная база данных". Перефразировав определение, данное Коддом в [4.1], 
получим следующее: 

    1 Здесь мы используем очевидное сокращение, согласно которому выражение 
(Sl,Smith,20,London) соответствует кортежу {<S#:'S1'>, <SNAME:'Smith'>, 
<STATUS:20>, <CITY:'London'>}. 

    94	Часть II. Реляционная модель 

    •  Реляционная база данных — это база данных, воспринимаемая пользователем 
как набор нормализованных отношений (т.е. переменных отношений) разной степени. 
    Как отмечалось ранее, выражение "воспринимаемая пользователем" является 
решающим: идея реляционной модели применяется к внешнему и концептуальному 
уровням системы, а не к внутреннему уровню. Можно сказать и иначе — 
реляционная модель представляет систему баз данных на уровне абстракции, 
несколько удаленном от подробностей лежащей в основе этой системы машины; так 
же как, например, язык Pascal представляет систему программирования на уровне 
абстракции, несколько удаленном от подробностей лежащей в основе этой системы 
машины. В действительности реляционную модель можно рассматривать как язык 
программирования, специально ориентированный на приложения баз данных. 
    Различие между доменами и (именованными) отношениями также можно несколько 
уточнить. Мы называем именованные отношения переменными, так как их значения 
изменяются со временем. Как указывалось выше в этой главе, домены не являются 
переменными в этом смысле. Например, множество всех возможных номеров 
поставщиков, конечно, не изменяется со временем, или если изменяется, то 
изменение носит описательный характер, т.е. происходит на уровне типа, а не 
экземпляра. Это немного похоже на изменение основного типа данных для номера 
поставщиков с CHAR(5) на CHAR(7). Обратите внимание, что такое изменение, 
возможно, повлечет за собой реорганизацию базы данных. 
    Итак, можно сказать, что в традиционных терминах отношение соответствует 
файлу (логическому, а не физическому), кортеж — записи (экземпляру, а не 
типу), атрибут полю (типу, а не экземпляру). Однако это соответствие в лучшем 
случае приблизительное. Отношение следует рассматривать не как "просто файл", 
а как файл, подчиняющийся определенным правилам, это отражается в значительном 
упрощении структуры объектов данных, с которой сталкивается пользователь, и, 
как следствие, в упрощении операторов, необходимых для работы с этими 
объектами. Если говорить точнее, все данные в реляционной системе 
представляются одним и только одним способом, а именно явными значениями (это 
свойство иногда называют "основным принципом реляционной модели", а также 
"информационным принципом"). В частности, этими явными значениями 
представляются логические связи в отношении и между отношениями; не существует 
видимых для пользователя указателей на файлы или записи, не существует 
видимого для пользователя порядка записей, не существует видимых для 
пользователя групп повторения и т.д. 

    4.7. Резюме 

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

    Глава 4. Реляционные объекты данных: домены и отношения	95 

    •   Атрибуты не упорядочены слева направо. 
    •   Все значения атрибутов атомарные (отношения нормализованы). 
    Для каждого отношения есть связанная с ним интерпретация, или предикат, 
составляющий критерий возможности обновления для этого отношения. И в любой 
момент времени отношение содержит в точности те кортежи, при которых предикат 
является истиной. 
    Именованное отношение является в действительности переменной (его 
заголовок фиксирован, но значение тела изменяется со временем). Примеры 
именованных отношений — это базовые отношения, представления и снимки. 
Неименованное отношение— это результат вычисления некоторого реляционного 
отношения; оно обычно существует недолго в отличие от именованного отношения, 
и его тело не изменяется в процессе существования. Примеры неименованных 
отношений— это промежуточные и окончательные результаты запросов. 
    В этой главе также были представлены операторы определения данных 
гипотетического реляционного языка, который мы будем использовать далее в этой 
части книги — CREATE DOMAIN И DESTROT ВСМАШ, CREATE BASE RELATION И DESTROY 
BASE KEIATICN. (ТЗКЖС  были упомянуты операторы CREATE и DESTROY для представлений 
и снимков; к ним мы вернемся позже, в следующих частях книги.) 

    Упражнения 

    4.1. Обратитесь к рис. 3.4 главы 3 (схематически изображенная структура 
каталога для базы данных отделов и служащих): а) назовите отдельные части 
этого каталога, используя формальную реляционную терминологию, представленную 
в этой главе; б) укажите, как должна быть расширена структура каталога с 
учетом доменов; в) запишете запрос к этому расширенному каталогу для 
нахождения всех именованных отношений, в которых используется домен ЕМР#. 
    4.2. а) Запишите оператор CREATE BASE RELATION и соответствующий набор 
операторов CREATE DOMAIN для отношения PART_STRUCTURE, изображенного на рис. 
4.4; б) предполагая, что это отношение включается в базу данных отделов и 
служащих из упр. 4.1, укажите, какие обновления система должна ввести в 
каталог с учетом вашего ответа на пункт (а); в) запишите набор операторов 
DESTROY, необходимых для отмены изменений, внесенных в каталог в пункте (б). 
    4.3. Как мы убедились, операторы определения данных, такие как CREATE 
DOMAIN и DESTROY DOMAIN, CREATE BASE RELATION И DESTROY BASE 
RELATION, ПрИВОДЯТ К ИЗМСНению каталога. Но каталог — это всего лишь набор 
отношений, как и обычные пользовательские данные; так можно ли применять обычные 
реляционные операторы (такие как INSERT, UPDATE, DELETE языка SQL) для 
соответствующего изменения каталога? Обсудите это. 
    4.4. На каких доменах основаны отношения каталога? 
    4.5. Отношение имеет по определению множество атрибутов и множество 
кортежей. Пустое множество в математике рассматривается как вполне приемлемое; 
обычно желательно, чтобы теоремы, результаты и т.п., которые выполняются для 
множества из п элементов, выполнялись и для множества из п=0 элементов. Может 
ли отношение иметь нуль кортежей? А нуль атрибутов? 
    4.6. На рис. 4.6 показаны примеры значений данных для расширенной формы 
базы данных поставщиков и деталей, которая называется базой данных 
поставщиков, деталей и проектов. Поставщики (S), детали (Р) и проекты (J) 
однозначно определяются номером поставщика (S#), номером детали (Р#) и номером 
проекта (J#) соответственно. Значение кортежа отношения SPJ (отношение 
поставок) следующее: определенный поставщик поставляет определенную деталь для 
определенного проекта в определенном количестве (и комбинация S#-P#-J# 
уникальна для кортежей отношения). Запишите необходимое определение данных для 
этой базы данных. 

    96	Часть II, Реляционная модель 

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

    S											SPJ 

    s#	SNAME		STATUS	CITY					S#	P#	J#	QTY 
    SI	Smith		20		London				SI	PI	Jl	200 
    S2	Jones		10		Paris					SI	PI	J4	700 
    S3	Black		30		Paris					S2	P3	Jl	400 
    S4	Clark		20		London				S2	P3	J2	200 
    S5	Adams		30		Athens				S2	P3	J3	200 
    											S2	P3	J4	500 
    											S2	P3	J5	600 

    р	
    P#	PNAME		COLOR		WEIGHT	CITY			S2	P3	J6	400 
    PI	Nut		Red		12		London		S2	P3	J7	800 
    P2	Bolt		Green		17		Paris			S2	P5	J2	100 
    P3	Screw		Blue		17		Rome			S3	P3	Jl	200 
    P4	Screw		Red		14		London		S3	P4	J2	500 
    P5	Cam		Blue		12		Paris			S4	P6	J3	300 
    P6	Cog		Red		19		London		S4	P6	J7	300 
    35	P2	J2	200 
    S5	P2	J4	100 

    J	
    J#		JNAME		CITY						S5	P5	J5	500 
    Jl		Sorter	Paris						S5	P5	J7	100 
    J2		Display	Rome						S5	P6	J2	200 
    J3		OCR		Athens					S5	PI	J4	100 
    J4		Console	Athens					35	P3	J4	200 
    J5		RAID		London					35	P4	J4	800 
    J6		EDS		Oslo						35	P5	J4	400 
    J7		Tape		London					35	P6	J4	500 
    
    
    Рис. 4.6. База данных поставщиков, деталей и проектов (значения для примера) 
    4.7. Укажите предикат для отношения SPJ из предыдущего упражнения. 

    Список литературы 

    Большинство перечисленных ниже ссылок касается не только аспекта "объектов 
данных", а всех трех аспектов реляционной модели. 
    4.1. Codd E.F. A Relational Model of Data for Large Shared Data Banks // 
CACM. — 1970. — 13, № 6. (Переиздано: Milestones of Research — Selected Papers 
1958-1982 // CACM. — 1983. — 26, № 1.) 
    С этой статьи все и началось. И хотя прошло более четверти века, она 
остается актуальной и стоит того, чтобы ее перечитывали. Конечно, некоторые 
идеи были несколько улучшены со времени публикации этой статьи, но по своей 
природе это были эволюционные, а не революционные изменения. Кроме того, в 
статье есть некоторые идеи, следствия которых до сих пор полностью не 
исследованы . 
    Статья разделена на две части: "Реляционная модель и нормальная форма" и 
"Избыточность и непротиворечивость". 

    Глава 4. Реляционные объекты данных: домены и отношения 97 
   4 Введение в системы баз данных 

    1.  В первую часть включено обсуждение независимости данных (в особенности 
недостатка независимости в системах того времени), реляционных объектов данных 
(отношений и доменов), нормализации (первой нормальной формы), лингвистических 
аспектов, а также базовых отношений, представлений и других видов отношений, 
    2.   Во второй части представлено вводное описание нескольких реляционных 
операций — проекции, соединения и т.д. Эти операции используются в качестве 
базиса для обсуждения различных видов избыточности и непротиворечивости в 
реляционной базе данных. Множество отношений называется сильно избыточным, 
если оно включает по крайней мере одно отношение, имеющее проекцию, полученную 
из другого отношения этого множества. Между прочим, обратите внимание на то, 
что множество именованных отношений, доступное пользователю определенной базы 
данных, может быть сильно избыточным в этом смысле, так как оно может включать 
как базовые отношения, так и представления, производные от этих базовых отношений. 
    Здесь стоит вкратце обсудить определение отношения, данное в этой статье. 
В несколько измененном виде это определение гласит следующее: пусть даны 
множества Dl, D2, ..., Dn (не обязательно различные), тогда отношением R на 
этих п множествах будет множество из я-ок (п кортежей), в каждой из которых 
первый элемент принадлежит множеству D1, второй — множеству D2, и т.д. 
(Множество Dj называют у'-м доменом отношения R.) Или более кратко: отношение 
R — это подмножество декартова произведения своих доменов. . 
    Это безупречное с математической точки зрения определение можно 
подвергнуть критике с точки зрения баз данных по нескольким пунктам. 
    1.  Во-первых, в определении не проведено четкого различия между доменами 
и атрибутами. (Далее в своей статье Кодд использует термин "активный домен", 
называя им множество значений некоторого домена, присутствующих в базе данных 
в определенный момент времени, но понятие активного домена не эквивалентно 
атрибуту в том смысле, в котором этот термин сейчас используется.) В 
результате получилась неразбериха в доменах и атрибутах, которая существует и 
по сей день. 
    2.  Затем в соответствии с этим определением отношение упорядочено по 
доменам слева направо. И снова далее в своей статье Кодд утверждает, что 
пользователи не должны иметь дело с отношениями как таковыми, вернее, с "их 
неупорядоченными копиями доменов" (которые он относит к "отношениям"), но эта 
тонкость, кажется, ускользнула от внимания некоторых разработчиков систем баз 
данных. (В SQL, в частности, весьма неудачно введено понятие упорядочения 
столбцов слева направо в таблице.) 
    3.  И наконец, в определении не учитывается в достаточной мере различия 
между статическими и динамическими (или зависимыми и независимыми от времени) 
аспектами переменных отношений (то, что мы называем "телом" и "заголовком"), 
хотя это различие очевидно следует из дальнейших разделов статьи. Это упущение 
стало причиной многих последующих недоразумений. 
    Возможно, стоит упомянуть еще несколько вопросов, которые могут озадачить 
читателя, впервые знакомящегося с этой статьей. 
    1.  Несмотря на название, в статье нигде не приводится сжатого определения 
термина "реляционная модель" (нет определения также и для термина "модель 
данных", хотя эта статья была, несомненно, одной из тех, которые вводят это 
понятие). Наоборот, она по крайней мере предполагает, что термин включает лишь 
аспект "объектов" (т.е. операторы и возможности поддержки целостности 
исключаются). Также в ней говорится о "некоторой реляционной 

    98	Часть II, Реляционная модель 

модели ... для [некоторой базы данных]", а это означает, что термин 
"реляционная модель" подразумевает абстрактное представление данных в 
некоторой конкретной базе данных вместо абстрактного представления данных 
вообще. Оба этих неверных толкования, как это ни прискорбно, очень 
распространены в литературе по базам данных; первое, в частности (т.е. то, что 
"реляционная модель является просто структурой", иногда излагается в форме 
"реляционная модель — это просто плоские файлы"), является основным неверным 
представлением. В [4.12] предпринимается попытка охарактеризовать эту 
конкретную ошибку при обсуждении "мифа № 3". 
    2.   В соответствии со статьей в отношении может быть любое количество 
первичных ключей; т.е. в статье термин "первичный ключ" используется для 
обозначения того, что мы бы сейчас назвали потенциальным ключом. Также к 
такому первичному (т.е. потенциальному) ключу не предъявляется требования 
неизбыточности. Однако далее в статье говорится, что "если в отношении есть 
два или более [неизбыточных] первичных ключа, произвольно ьыбирается один из 
них и называется основным первичным ключом данного отношения". 
    3.  Определение, данное для внешнего ключа, неоправданно ограничивает 
рамки понятия, в нем не допускается, чтобы первичный ключ (или потенциальный 
ключ? — смотрите предыдущий пункт) отношения был внешним ключом, и в нем не 
рассматривается случай null-значения внешнего ключа. В главе 5 приводится 
подробное обсуждение внешних ключей вообще и null-значений внешних ключей в частности. 
    4.2. Codd E.F. Derivability, Redundancy, and Consistency of Relations 
Stored in Large Data Banks // IBM Research Report RJ599 — 1969. 
    Предварительная версия статьи [4.1]. Эти две статьи несколько отличаются в 
деталях (в частности, в терминологии), и наиболее существенное отличие 
заключается в том, что в [4.1] выдвигается и обосновывается идея, что все 
отношения должны быть нормализованы. Эти вопросы еще будут осуждаться далее в 
данной книге. 
    4.3. Codd E.F. Data Models in Databases Management // Proc. Workshop on 
Data Abstraction, Database and Conceptual Modelling (Michael L. Brodie and 
Stephen N. Zilles, eds.). — Pingree Park, Colo., 1980. (ACM SIGART 
Newsletter.— 1981 №74; ACM SIGMOD Record 11. — 1981 № 2; ACM S1GPLAN Notices. 
—1981 —16, № 1). 
    В статье впервые было дано полное определение модели данных. Несколько 
перефразировав его, можно сказать, что модель данных — это совокупность, 
состоящая из трех компонентов: 
    1. Набора типов объектов данных, формирующего основные блоки, на которых 
строится любая база данных, отвечающая модели. 
    2.  Набора общих правил целостности, которые ограничивают множество 
экземпляров этих типов объектов, допустимых в такой базе данных. 
    3.  Набора операторов, которые применяются для обработки (выборки и др.) 
этих экземпляров объектов. 
    Далее в статье обсуждается назначение модели данных в общем (и в 
реляционной модели в частности), также представлены доводы в пользу того, что 
реляционная модель в действительности (вопреки распространенному мнению) 
должна быть определена сначала на абстрактном уровне; так называемые 
иерархическая и сетевая (дореляционные) модели были определены на абстрактном 
уровне на базе уже существующих реальных реализаций. 
    4.4. Codd E.F. The Relational Model for Database Management Version 2. — 
Reading, Mass.: Addison-Wesley, 1989. 

    Глава 4. Реляционные объекты данных: домены и отношения	99 

    Длительное время в конце 1980-х Кодц пересматривал и расширял свою 
изначальную модель (которую теперь называют реляционной моделью первой версии— 
"the Relational Model Version 1", или RM/V1), в результате чего появилась эта 
книга. В ней описывается так называемая реляционная модель второй версии — 
"the Relational Model Version 2", или RM/V2. Основное различие между этими 
двумя версиями состоит в следующем: первая создавалась как абстрактный план 
для определенного аспекта общей проблемы баз данных (по большей части аспекта 
основ), а вторая — как абстрактный план для всей системы. Поэтому, в то время 
как первая версия разделена только на три части — объекты или структуры, 
операторы или обработка и поддержка целостности данных, модель RM/V2 содержит 
18 частей, которые включают не только три оригинальных части, что само собой 
разумеется, но и части, касающиеся представлений, каталогов, прав доступа, 
наименований, распределенной базы данных и различных других аспектов 
управления базой данн ых. Однако идеи, опубликованные в этой книге, отнюдь не 
имели широкого распространения. 
    4.5. Darwen H. The Duplisity of Duplicate Rows // C.J. Date and Hugh 
Darwen. Relational Database Writings 1989-1991. — Reading, Mass.: 
Addison-Wesley, 1992. 
    Эта статья была написана для подкрепления аргументов, уже представленных в 
статье [4.11], в пользу известного требования реляционной модели— таблицы не 
должны содержать одинаковых строк. В статье не только предоставлены новые 
версии этих аргументов, но и выдвинуты дополнительные аргументы. Основной 
вопрос состоит в следующем: для того чтобы конструктивно обсуждать совпадение 
двух объектов, необходим критерий идентичности для рассматриваемого класса 
объектов. Иначе говоря, что значит для двух объектов быть "одним и тем же". 
    4.6. Darwen H. The Nullologist in Relationland // Ibid. 
    Нулология — это (согласно Дарвену) "учение об абсолютном ничто" — или 
иначе говоря, учение о пустых множествах. Множества в реляционной теории 
вездесущи, поэтому вопрос о том, что будет, если одно или несколько из этих 
множеств окажутся пустыми, возник не случайно. На самом деле в нескольких 
случаях пустые множества играют фундаментальную роль. С темой настоящей главы 
(реляционными объектами данных) связан раздел 2 этой статьи ("Таблицы без 
строк") и раздел 3 ("Таблицы без столбцов"). 
    4.7. Darwen H. (writing as Andrew Warden). Adventures in Relationland // 
C.J. Date. Relational Database Writings 1985-1989. — Reading, Mass.: 
Addison-Wesley, 1992. 
    Подборка небольших статей о различных аспектах реляционной модели в 
оригинальном, развлекательном и информативном стиле. 
    4.8. Date C.J. What Is a Domain? // Ibid, 1990. 
    Систематическое и обстоятельное пособие по концепции реляционного домена. 
В статье доказывается, что домен является не чем иным, как типом данных, 
который либо встроен, либо определен пользователем. Дальнейшее обсуждение 
этого вопроса будет продолжено в следующих частях настоящей книги. 
    4.9. Date C.J. Defining Data Types in Database Language // Ibid. 
    Статья, дополняющая предыдущую и описывающая, что используется при 
добавлении новых типов данных в язык базы данных. В качестве примера детально 
рассматривается специфический случай поддержки дат и времени в SQL (на момент 
написания этой статьи SQL не включал поддержки дат и времени). 
    4.10. Date C.J. What Is a Relation? // C.J. Date and Hugh Darwen. 
Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992. 
    Эта статья так же описывает отношения, как статья [4.8] домены. Приводим 
выдержку из статьи: "Несмотря на то что реляционная модель имеет 
математическую основу, отношения в реляционной модели и отношения в математике 
— это не одно и то же. В этой статье обсуждаются различия между двумя этими понятиями." 

    100	Часть II, Реляционная модель 

    В частности, в статье подчеркивается, что хранимые и базовые отношения не 
обязательно должны быть абсолютно идентичны, хотя в большинстве случаев, 
конечно, хранимые и базовые отношения чаще соотносятся между собой как один к одному. 
    4.11. Date C.J. Why Duplicate Rows Are Prohibited // C.J. Date. Relational 
Database Writings 1985-1989. —Reading, Mass.: Addison-Wesley, 1990. 
    Представлены многочисленные аргументы с примерами в пользу требования, 
чтобы таблицы в реляционной модели не содержали никаких дублируемых строк. В 
частности, в статье показано, что дублируемые строки являются главным 
препятствием для оптимизации. 
    4.12. Date C.J. Some Relational Myths Exploded // C.J. Date. Relational 
Database: Selected Writings. —Reading, Mass.: Addison-Wesley, 1986. 
    Рассматриваются 26 неверных представлений, касающихся реляционных систем 
управления базами данных. 
    4.13. Date C.J. Further Relational Myths // C.J. Date. Relational Database 
Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990. 
    Продолжение [4.12], рассматриваются восемь дополнительных "реляционных мифов". 
    4.14. Date C.J. Relational Database: Further Misconceptions Number Three 
// C.J. Date and Hugh Darwen. Relational Database Writings 1989-1991.— 
Reading, Mass.: Addison-Wesley, 1992. 
    Продолжается обсуждение "реляционных мифов". 
    4.15. Date C.J. Notes Toward a Reconstituted Definition of the Relational 
Model Version 1 (RM/Vl)//Ibid. 
    Приводится критика и резюме к реляционной модели Кодца "RM/V1" и дается 
альтернативное определение. Подразумевается, что крайне важно получить 
правильную версию 1, прежде чем обсуждать переход к какой-то версии 2. 
    4.16. Date C.J. A Critical Review of Relational Model Version 2 (RM/V2) // 
Ibid. Приводится критика и резюме к реляционной модели Кодда "RM/V2". 
    4.17. Date C.J. Series of articles in Database Programming & Design (under 
the generic title According to Date). Beginning with 5. — 1992. — № 9. 
    Неформальная серия статей по различным проблемам, связанным с базами 
данных. Фактически охвачены многие темы, рассматриваемые в настоящей книге, но 
изложены в менее строгой форме. Основная тема— "теория и практика!", т.е. о 
том, что профессионалы информационных технологий на свой собственный риск 
игнорируют теоретические аспекты в своей области. 
    4.18. McLeod D.J. High Level Definition of Abstract Domains in a 
Relational Database System // Computer Languages 2. — Pergamon Press, 1977. 
    Одна из первых статей, в которой подробно исследуется понятие домена. 

    Ответы к некоторым упражнениям 

    4.1. а) Очевидные изменения даны ниже: 

    TABLES	Заменяется на    RELATIONS 
    COLUMNS	ATTRIBUTES 
    TABNAME	RELNAME 
    COLCOUNT	DEGREE 
    ROWCOUNT	CARDINALITY (CARD) 
    COLNAME	ATTRNAME 

    Глава 4. Реляционные объекты данных: домены и отношения	101 

    Обратите внимание, что RELATIONS здесь действительно означает именованное 
отношение. На самом деле отношение RELATIONS должно иметь еще один атрибут 
(RELTYPE), значения которого указывают тип (базовое отношение, представление 
или снимок) соответствующего именованного отношения. Поэтому структура 
каталога будет выглядеть таким образом: 
    RELATIONS    I RELNAMEI DEGREE    I CARDINALITY  I RELTYPE   I . ..        I 
    ATTRIBUTES     RELNAME    ATTRNAME 
    б) Необходимо новое отношение типа каталога (DOMAINS), содержащее элемент 
для каждого домена, а также новый атрибут (DOMNAME) в каталоге ATTRIBUTES, 
предоставляющем лежащий в основе домен для каждого атрибута каждого 
именованного отношения. Структура каталога будет подобна следующей: 
    DOMAINS       DCMNAME      DATATYPE 
    RELATIONS      RELNAME      DEGREE   CARDINALITY     RELTYPE 
    ATTRIBUTES     RELNAME      ATTRNAME DCMNAME 
    В качестве вспомогательного упражнения читатель мог бы, вероятно, учесть, 
что для дальнейшего расширения каталога может потребоваться представить 
информацию относительно первичных и внешних ключей. 
    B) ( ATTRIBUTES WHERE DCMNAME = 'ЕМР#' ) [ RELNAME ] 
    4.2. а) Определение данных: 
    CREATE DOMAIN P# CHAR(6)   ; CREATE DOMAIN QTY NUMERIC (9)   ; 
    CREATE BASE RELATION PART_STRUCTURE ( MAJOR__P# DOMAIN   (  P#  ), 
MINOR_P# DOMAIN   (  P#  ), QTY	DOMAIN   (  QTY )   ) PRIMARY KEY   (  
MAJOR_P#,   MINOR_P#   )   ; 
    Замечание. Если бы отношение PART_STRUCTURE было частью базы данных 
поставщиков и деталей, нам были бы нужны дополнительные спецификации 
    FOREIGN KEY ( RENAME MAJOR_P# AS P# ) REFERENCES P FOREIGN KEY ( RENAME 
MINOR__P# AS P# ) REFERENCES P 
    в определении отношения (эти спецификации еще будут поясняться в главе 5). 
    б) Мы показали лишь новые элементы каталога (рис. 4.7); обратите внимание, 
что элемент CARDINALITY в отношении RELATIONS для самого отношения RELATIONS 
должен быть увеличен на единицу. Мы показали кардинальное число отношения 
PART_STRUCTURE равным 0, а не 7 (несмотря на то что на рис. 4.4 оно показано, 
как содержащее семь кортежей), поскольку, конечно, отношение будет пустым, 
если оно вновь создано. 
    B) DESTROY BASE RELATION PART_STRUCTURE ; DESTROY DOMAIN QTY ; DESTROY 
DOMAIN P# ; 

    102	Часть II, Реляционная модель 

    DCMA RELA ATTR	INS 
    DCMNAME	DATATYPE 
    P# QTY	CHAR(6) NUMERIC (9) 
    TIONS 
    RELNAME		DEGREE	CARDINALITY			RELTYPE 
    PART_STRUCTURE		3	0			Base 
    IBUTES 
    RELNAME		ATTRNAME		DCMNAME 
    PART STRUCTURE PART_STRUCTURE PART STRUCTURE		MAJOR_P# MINOR_P# QTY		P# P# QTY 
    
    
    Рис. 4.7. Элементы каталога для отношения PART_STRUCTURE 

    4.3. Изменение каталога можно выполнять с помощью обычных средств, т.е. 
операций INSERT, UPDATE И DELETE. ОднаКО ВОЗМОЖНОСТЬ ИСПОЛЬЗОВаНИЯ 
ТЗКИХ ОПСраций могла бы быть потенциально очень опасной, поскольку это могло бы 
легко разрушить всю информацию в каталоге (по небрежности или по иным 
причинам), а поэтому система не смогла бы далее корректно функционировать. 
Предположим, например, что операция языка SQL DELETE 

    DELETE 
    FRCM 
    RELATIONS 
    WHERE     RELNAME = 'BMP' ; 

допустима для каталога отделов и служащих. В результате ее выполнения мог 
бы быть удален кортеж, описывающий отношение ЕМР из отношения RELATIONS. С 
точки зрения системы отношение ЕМР больше бы не существовало, т.е. система не 
имела бы никаких сведений об этом отношении. Поэтому все последующие попытки 
обращения к этому отношению были бы безуспешными. 
    Следовательно, в большинстве реальных продуктов операции UPDATE, DELETE и 
INSERT для каталога или не разрешены вовсе (это обычная практика), или 
разрешены лишь для пользователей, наделенных очень высокими правами (возможно, 
лишь для администратора базы данных). Вместо этого изменение каталога 
выполняется с помощью операторов определения данных (CREATE DCMAIN, CREATE 
BASE RELATION, и т.п.). Например, в результате выполнения оператора CREATE 
BASE RELATION для отношения ЕМР, во-первых, для него формируется элемент в 
отношении RELATIONS и, во-вторых, набор из четырех элементов, один для каждого 
из четырех атрибутов отношения ЕМР, в отношении ATTRIBUTES. (Выполнение этого 
оператора вызывает и массу других последствий, которых, однако, мы здесь не 
будем касаться.) Таким образом, операция создания CREATE в некотором смысле 
является аналогом операции вставки INSERT для каталога. Также операция 
удаления объектов DESTROY является аналогом операции удаления строк DELETE; а 
в SQL, который предост авляет различные оператор изменения ALTER для изменения 
элементов каталога различными способами, операция ALTER является аналогом 
операции обновления UPDATE. 
    Замечание. Как мы уже видели, каталог также включает элементы для самих 
отношений каталога. Однако эти элементы не создаются явно операцией CREATE. 
Вместо этого они создаются автоматически самой системой как часть процедуры 
инсталляции системы. В сущности, они "зашиты" в систему. 

    Глава 4. Реляционные объекты данных: домены и отношения 103 

    4.4. Очевидно, что невозможно дать однозначный ответ на этот вопрос. Вот 
некоторые приемлемые предложения: 

    Домен      DCMNAME      определен на        NAME 
    RELNAME	МАМЕ 
    ATTRNAME	NAME 
    DATATYPE	DATATYPE 
    DEGREE	CARDINALS CARDINALITY                       CARDINALS 
    RELTYPE	RELTYPE 

    Эти домены, в свою очередь, подразумеваются определенными как указано ниже: 
    • NAME — это множество всех допустимых имен. 
    • DATATYPE — это множество всех встроенных скалярных типов данных 
(CHAR(n), NUMERIC(n), и т.д.). Для работы с параметром п требуется некоторая 
дополнительная работа по проектированию. 
    • CARDINALS — это множество всех неотрицательных целых чисел, не 
превышающих некоторой определенной на этапе реализации границы. 
    • RELTYPE — это множество { "Base", "View", "Snapshot"}. 
    Обратите внимание, что здесь мы (частично) нарушили наш принцип, в 
соответствии с которым каждый атрибут должен иметь такое же имя, что и лежащий 
в основе домен. Это упражнение служит иллюстрацией тому, что такие нарушения 
будут случаться, если отношения проектируются до того, как они связаны с 
каким-то доменом (конечно, это замечание относится ко всем базам данных, а не 
только к каталогу). 
    4.5. Отношение с пустым множеством кортежей имеет вполне разумный смысл и 
в действительности является обычным отношением (это аналог файла, у которого 
нет записей). В частности, естественно, каждое базовое отношение имеет пустое 
множество кортежей, когда оно только создано. Такое отношение принято 
называть, хотя это и немного неточно, пустым отношением. 
    Но совсем невероятным, возможно, является то, что отношение с пустым 
множеством атрибутов тоже имеет вполне разумный смысл! На самом деле такие 
отношения исключительно важны, почти так же, как пустые множества 
исключительно важны в общей теории множеств. Чтобы рассмотреть это понятие 
несколько подробнее, вначале необходимо обсудить вопрос о том, могут ли 
отношения, не имеющие атрибутов, иметь какие-то кортежи. В действительности 
такие отношения могут иметь не больше, чем один кортеж, а именно 0-кортеж 
(т.е. кортеж, не имеющий совсем значений атрибутов). Таких кортежей не может 
быть более одного, поскольку все 0-кортежи дублируют друг друга. Поэтому 
имеется ровно два отношения (точнее, значений отношения) степени нуль: одно, 
которое содержит ровно один кортеж, и одно, которое не содержит кортежей 
совсем. Эти два отношения настолько важны, что, следуя Дарвену (Darwen) [4-6, 
4.7], мы называем их "ласковыми" именами: первое отношение — TABLE DEE, второе 
— TABLE_DUM, или для краткости DEE и DUM (DEE имеет 0-кортеж , a DUM не имеет). 
    Мы не имеем возможности углубиться далее в детали этого вопроса в данный 
момент и удовлетворимся следующим утверждением: значение этих отношений так 
важно еще и потому, что отношению DEE соответствует истина — true (или yes), a 
DUM соответствует ложь —false (или по). Упражнения и ответы в следующих двух 
главах помогут несколько глубже понять этот материал. Более подробную 
информацию можно найти в [4.6, 4.7]. 
    4.6. CREATE DOMAIN S#	CHAR(5) ; 

    104	Часть II, Реляционная модель 

    CREATE DCMMN NAME	CHAR(20) ; 
    CREATE DOMAIN STATUS	NUMERIC (5) ; 
    CREATE DOMAIN CITY	CHAR (15) ; 
    CREATE DCMAIN Ptt	CHAR(6) ; 
    CREATE DCMAIN COLOR	CHAR (6) ; 
    CREATE DCMAIN WEIGHT	NUMERIC (5) ; 
    CREATE DCMAIN J#	CHAR(4) ; 
    CREATE DCMAIN QTY	NUMERIC(9) ; 
    CREATE BASE RELATION S 
    ( Stt    DCMAIN ( Stt ), SNAME DCMAIN ( NAME ) , STATUS DCMAIN ( STATUS ), 
CITY  DCMAIN ( CITY ) ) PRIMARY KEY ( S# ) ; 
    CREATE BASE RELATION P 
    ( P#    DCMAIN ( P# ), PNAME DCMAIN ( NAME ), COLOR DCMAIN ( COLOR ), 
WEIGHT DCMAIN ( WEIGHT ), CITY  DCMAIN ( CITY ) ) PRIMARY KEY ( Ptt ) ; 
    CREATE BASE RELATION J 
    ( Jtt   DCMAIN ( Jtt ), JNAME DCMAIN ( NAME ), CITY DCMAIN ( CITY ) ) 
PRIMARY KEY ( Jtt ) ; 
    CREATE BASE RELATION SPJ 
    ( Stt  DCMAIN ( Stt ), 
    Ptt  DCMAIN ( Ptt ), 
    J#  DCMAIN ( Jtt ) , 
    QTY    DCMAIN   (  CfTY  )   ) PRIMARY KEY   (  Stt,   Ptt,   Jtt   ) 
FOREIGN KEY   (  Stt   )   REFERENCES S FOREIGN KEY   (  Ptt   )   REFERENCES 
P FOREIGN KEY   (  Jtt   )   REFERENCES J ; 
    4.7. Кортеж {<S#:s, P#:p, l#:j, QTY:g>} появляется в отношении SPJ тогда и 
только тогда, когда удовлетворяются следующие условия: 
    • Все значения s,p,j, q являются значениями соответствующих доменов. 
    • Значения s состоят из значений атрибута S# в отношении S; то же самое 
относится и к значениям р и/ 
    • В отношении SPJ при q'^q нет кортежей {<S#:s, P#:p, J#'j, QTYig^}. 

    Глава 4. Реляционные объекты данных: домены и отношения	105 

    • Данный кортеж не нарушает никаких других применяемых правил целостности. 
    И наконец (неформально), поставщик s поставляет деталь р для проекта j в 
количестве q. Это неформальное определение, конечно, не является частью 
понятия отношения с точки зрения СУБД. 

    106 Часть II. Реляционная модель 

