4.3. Отношения

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

CREATE BASE RELATION S ... ;

создается переменная отношения с именем s, значение которой в любой момент вре­мени будет определенным значением отношения.(////)

^///////// Если рассматривать отношения как таблицы, то мы могли бы сказать, что, например, переменная от­ношения S в разное время представляет разные таблицы. Однако заметьте, что в этих разных таблицах бу­дут разные строки, а столбцы будут одинаковые.///////

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

DECLARE QTY INTEGER ... ;

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

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

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

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

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

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

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

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

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

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

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

отношения R.

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

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

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

( S#, SNAME, STATUS, CITY )

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

{ < s# :s# >,

< SNAME :NAME >,

< STATUS :STATUS >,

< CITY :CITY > }

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

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

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

( S1, Smith, 20, London )

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

{ < S# : “ S1” >,

< SNAME : 'Smith' >,

< STATUS : 20 >,

< CITY : 'London' > }

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

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

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

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

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

в этой главе приводится дальнейшее обсуждение данного вопроса.

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

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

CRЕАТЕ BASE RELATION S . .. ;

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

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

DECLARE CITY INTEGER . . . ;

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

Теперь пусть R — переменная отношения; переменная R будет иметь разные зна­чения в разное время. Однако все возможные значения переменной R будут иметь одинаковые заголовки. Например, все возможные значения базового отношения S будут иметь заголовок {S#,SNAME,STATUS,CITY} .(/////)

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

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

Как мы уже объясняли, количество атрибутов в данном отношении называется степенью (иногда называют арностью) отношения. Отношение первой степени на­зывается унарным, отношение степени 2 — бинарным, отношение степени 3 — тер­нарным ... и отношение степени п — п-арным. (В общем случае в реляционной моде­ли рассматриваются n-арные отношения, где п — произвольное неотрицательное це­лое число.) В базе данных поставщиков и деталей отношения S, Р и SP имеют степень 4, 5 и 3, соответственно.

Иногда возникает неясность из-за схожести понятий домена и унарного отноше­ния (ведь домен выглядит как раз как таблица с одним столбцом). Однако заметьте, что существует довольно существенная разница между этими двумя понятиями: до­мены статичны, а отношения динамичны (здесь под отношением мы понимаем пе­ременную отношения). Другими словами, содержимое (переменной) отношения из­меняется со временем, а содержимое домена — нет (вспомним, что домен содержит все возможные значения подходящего типа). Более подробное обсуждение этого во­проса смотрите в [4.8].

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

Вернемся вновь к определению отношения: обратите внимание, что лежащие в осно­ве отношения домены не обязательно все различны. Это значит, что несколько атри­бутов в отношении могут иметь основой один домен. Пример такого отношения по­казан на рис. 4.4. (Это отношение названо PART_STRUCTURE.)

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

PART STRUCTURE
	MAJOR Р#	MINOR P#	OTY
	PI	P2	2
	PI	P3	4
	P2	P3	1
	P2	P4	3
	P3	P5	9
	P4	P5	8
	P5	P6	3

Рис. 4.4. Отношение PART.STRUCTURE

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

Вот синтаксис оператора 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-list— это синтаксическая единица, которая состоит из последовательности единиц xyz, количество которых больше либо равно нулю, причем каждые две единицы xyz между собой разделены по крайней мере одним пробелом.

• Если xyz — синтаксическая единица, то xyz-commalist — это синтаксическая еди­ница, которая состоит из последовательности единиц xyz, количество которых больше либо равно нулю, причем каждые две единицы xyz между собой разделе­ны запятой (и возможно, одним или несколькими пробелами).

Так, например, список определения атрибутов attribute-defenition-commalist со­стоит из последовательности единиц attribute-defenition (т.е. определений атрибу­тов), каждая из которых, за исключением последней, отделяется от следующей запятой, а список определения потенциальных ключей candidate-key-definition-list состоит из последовательности единиц candidate-key- -definition (т.е. оп­ределений потенциальных ключей), каждая из которых, за исключением последней, отделяется от следующей по крайней мере одним пробелом. То же самое можно ска­зать о списке определения внешних ключей foreign-key -definition -list.

Замечание. Здесь и далее мы будем опускать дефисы из таких выражений, как "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. При рассмотрении самой реляционной модели, конечно, ника­ких предположений делать не надо.)

Важным следствием того факта, что не существует одинаковых строк, является то, что всегда существует первичный ключ(/////). Так как кортежи уникальны, то по крайней мере комбинация всех атрибутов будет обладать свойством уникальности, а значит, при необходимости может служить первичным ключом. На практике, конечно, обыч­но нет необходимости использовать все атрибуты — подходит комбинация из не­скольких атрибутов. В главе 5 будет дано определение первичного ключа, как не включающего в себя атрибуты, излишние с точки зрения уникальности; поэтому, на­пример, комбинация {S#,CITY} хотя и "уникальна", но она не является первичным ключом, так как мы можем убрать атрибут CITY, не нарушив уникальности. (Однако заметьте, что первичные ключи могут быть составными. Примером тому может слу­жить отношение SP.)

/////// Точнее, всегда существует по крайней мере один потенциальный ключ. Мы предполагаем, что один из потенциальных ключей выбран как первичный. Дальнейшее обсуждение этого вопроса приведено в главе 5.//////

2. Кортежи не упорядочены (сверху вниз).

Это свойство также следует из того, что тело отношения — это математическое множество, а простые множества в математике не упорядочены. Например, на рис. 4.1 кортежи отношения S могли быть расположены в противоположном порядке — это было бы тем же самым отношением. Поэтому в отношении нет поня­тий "пятого кортежа", "97-го кортежа" или "первого кортежа"; т.е. нет понятия пози­ционной адресации и понятия "последовательности"(////). В статье [4.11], которая уже упоминалась в связи со свойством "нет одинаковых кортежей", показано, почему свойство "кортежи не упорядочены" также имеет важное значение (в действительно­сти эти свойства взаимосвязаны).

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

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

3. Атрибуты не упорядочены (слева направо).

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

Заметим, что вопрос порядка атрибутов — это еще одна область, где конкретное представление отношения в виде таблицы предполагает неверные факты: столбцы таблицы упорядочены слева направо, а атрибуты отношения — нет.

4. Все значения атрибутов атомарные.

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

BEFORE

S#

PQ

AFTER

S#

P#

QTY

Sl S2 S3

Sl Sl Sl Sl Sl Sl 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#

QTY

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 называется нормализацией. Как показано в этом примере, получить нормализованную форму из ненормализованной довольно просто, однако о процессе нормализации следует ска­зать еще многое, и это еще будет обсуждаться далее в книге.

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

1. Записать новую информацию о поставке для поставщика S5 деталей Р5 в количе­стве 500.

2. Записать новую информацию о поставке для поставщика S4 деталей Р5 в количе­стве 500.

Для отношения AFTER нет существенной разницы в выполнении этих двух опе­раций, каждое из них требует вставки одного кортежа в отношение. А для отношения BEFORE первая задача требует такой же вставки кортежа в отношение, но вторая за­дача требует существенно отличную операцию, а именно: вставку новой записи в на­бор записей (т.е. группу повторения) внутри существующего кортежа. Поэтому для поддержки ненормализованных операций нужны два совершенно разных оператора "insert". По аналогичным причинам также понадобятся два различных оператора "update", два различных оператора "delete" и т.д. Обратите внимание, что эти замеча­ния касаются не только операторов обработки данных, но и всех операторов системы; например, нужны дополнительные операторы обеспечения безопасности данных, нужны дополнительные операторы обеспечения целостности данных и т.п. (И вообще, можно считать аксиомой то, что если у нас есть п путей представления дан­ных, то нам потребуется п наборов операций.) Итак, ответ из одного слова на вопрос "Почему мы настаиваем на нормализации?" — это простота', простота объектов, с которыми мы работаем, что приводит к упрощению всей системы.