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

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

• Реляционная база данных — это база данных, воспринимаемая пользователем как набор нормализованных отношений (т.е. переменных отношений) разной степени.

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

Различие между доменами и (именованными) отношениями также можно не­сколько уточнить. Мы называем именованные отношения переменными, так как их значения изменяются со временем. Как указывалось выше в этой главе, домены не являются переменными в этом смысле. Например, множество всех возможных номе­ров поставщиков, конечно, не изменяется со временем, или если изменяется, то изме­нение носит описательный характер, т.е. происходит на уровне типа, а не экземпляра. Это немного похоже на изменение основного типа данных для номера поставщиков с CHAR(5) на CHAR(7). Обратите внимание, что такое изменение, возможно, повлечет за собой реорганизацию базы данных.

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

4.7. Резюме

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

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

• В них нет одинаковых кортежей.

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

• Атрибуты не упорядочены слева направо,

• Все значения атрибутов атомарные (отношения нормализованы).

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

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

В этой главе также были представлены операторы определения данных гипотети­ческого реляционного языка, который мы будем использовать далее в этой части кни­ги —— CREATE DOMAIN И DESTROY DOMAIN, CREATE BASE RELATICN И DESTROY BASE RELATION. Также были упомянуты операторы 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#-S# уникальна для кортежей отношения). Запишите необ­ходимое определение данных для этой базы данных.

Замечание. Эта база данных будет использоваться в многочисленных упраж­нениях в последующих главах.

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

S

SPJ

S#

SNAME

STATUS

CITY

S#

P#

J#

QTY

S1

Smith

20

London

S1

PI

J1

200

S2

Jones

10

Paris

S1

PI

J4

700

S3

Black

30

Paris

S2

РЗ

J1

400

S4

Dark

20

London

S2

РЗ

J2

200

S5

Adams

30

Athens

S2

РЗ

J3

200

S2

РЗ

J4

500

P

S2

РЗ

J5

600

Р#

PNAME

COLOR

WEIGHT

CITY

S2

РЗ

J6

400

Р1

Nut

Red

12

London

S2

РЗ

J7

800

Р2

Bolt

Green

17

Paris

S2

Р5

J2

100

РЗ

Screw

Blue

17

Rome

S3

РЗ

J1

200

Р4

Screw

Red

14

London

S3

Р4

J2

500

Р5

Cam

Blue

12

Paris

S4

Р6

J3

300

Р6

Cog

Red

19

London

S4

Р6

J7

300

S5

Р2

J2

200

J

S5

Р2

J4

100

J#

JNAME

CITY

S5

Р5

J5

500

J1

Sorter

Paris

S5

Р5

J7

100

J2

Display

Rome

S5

Р6

J2

200

J3

OCR

Athens

S5

PI

J4

100

J4

Console

Athens

S5

РЗ

J4

200

J5

RAID

London

S5

Р4

J4

800

J6

EDS

Oslo

S5

Р5

J4

400

J7

Tape

London

S5

Р6

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.)

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

Статья разделена на две части: "Реляционная модель и нормальная форма" и "Избыточность и непротиворечивость".

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

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

Здесь стоит вкратце обсудить определение отношения, данное в этой статье. В несколько измененном виде это определение гласит следующее: пусть даны множества D1, D2, ..., Dn (не обязательно различные), тогда отношением R на этих п множествах будет множество из n-oк (п кортежей), в каждой из которых первый элемент принадлежит множеству D1, второй— множеству D2, и т.д. (Множество Dj называют j-м доменом отношения R.) Или более кратко: отно­шение R — это подмножество декартова произведения своих доменов.

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

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

2. Затем в соответствии с этим определением отношение упорядочено по до­менам слева направо. И снова далее в своей статье Кодд утверждает, что пользователи не должны иметь дело с отношениями как таковыми, вернее, с "их неупорядоченными копиями доменов" (которые он относит к "отношениям"), но эта тонкость, кажется, ускользнула от внимания некото­рых разработчиков систем баз данных. (В SQL, в частности, весьма неудач­но введено понятие упорядочения столбцов слева направо в таблице.)

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

Возможно, стоит упомянуть еще несколько вопросов, которые могут озада­чить читателя, впервые знакомящегося с этой статьей.

1. Несмотря на название, в статье нигде не приводится сжатого определения термина "реляционная модель" (нет определения также и для термина "модель данных", хотя эта статья была, несомненно, одной из тех, которые вводят это понятие). Наоборот, она, по крайней мере, предполагает, что термин включает лишь аспект "объектов" (т.е. операторы и возможности поддержки целостности исключаются). Также в ней говорится о "некоторой реляционной модели ... для [некоторой базы данных]", а это означает, что термин "реляционная модель" подразумевает абстрактное представление данных в некоторой конкретной базе данных вместо абстрактного представления дан­ных вообще. Оба этих неверных толкования, как это ни прискорбно, очень распространены в литературе по базам данных; первое, в частности (т.е. то, что "реляционная модель является просто структурой", иногда излагается в форме "реляционная модель — это просто плоские файлы"), является основ­ным неверным представлением. В [4.12] предпринимается попытка охаракте­ризовать эту конкретную ошибку при обсуждении "мифа № З".

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, Cob., 1980. (ACM SIGART Newsletter. — 1981 № 74; ACM SIGMOD Record 11. — 1981 № 2; ACM SIGPLAN 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.

Длительное время в конце 1980-х Кодд пересматривал и расширял свою изна­чальную модель (которую теперь называют реляционной моделью первой вер­сии— "the Relational Model Version l", или 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] домены. Приводим выдержку из статьи: "Несмотря на то, что реляционная модель имеет матема­тическую основу, отношения в реляционной модели и отношения в матема­тике — это не одно и то же. В этой статье обсуждаются различия между дву­мя этими понятиями".

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

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/V1) // 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

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

RELATIONS

RELNAME

DEGREE

CARDINALITY

RELTYPE

ATTRIBUTES

RELNAME

ATTRNAME

……………

б) Необходимо новое отношение типа каталога (DOMAINS), содержащее элемент для каждого домена, а также новый атрибут (DOMNAME) в каталоге ATTRIBUTES, предоставляющем лежащий в основе домен для каждого ат­рибута каждого именованного отношения. Структура каталога будет подобна следующей:

DOMAINS

DOMNAME

DATATYPE

…………………….

RELATIONS

RELNAME

DEGREE

CARDINALITY

RELTYPE

ATTRIBUTES

RELNAME

ATTRNAME

DOMNAME

…………………

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

в) ( ATTRIBUTES WHERE DOMNAME = 'ЕМР#' ) [ RELNAME ]

4.2. а) Определение данных:

CREATE DOMAIN Р# 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 оно показано, как содержащее семь кортежей), поскольку, конечно, от­ношение будет пустым, если оно вновь создано.

в) DESTROY BASE RELATION PART_STRUCTURE ;

DESTROY DOMAIN QTY ;

DESTROY DOMAIN P# ;

DOMAINS

DOMNAME	DATATYPE	……
P# QTY	CHAR(6) NUMERIC(9)	…… ……

RELATIONS

RELNAME	DEGREE	CARDINALITY	RELTYPE	……
PART_STRUCTURE	3	0	BASE	……

ATTRIBUTES

RELNAME	ATTRNAME	DOMNAME	……
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

FROM RELATIONS

WHERE RELNAME = 'EMP' ;

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

Следовательно, в большинстве реальных продуктов операции update, delete и insert для каталога или не разрешены вовсе (это обычная практика), или раз­решены лишь для пользователей, наделенных очень высокими правами (возможно, лишь для администратора базы данных). Вместо этого изменение каталога выполняется с помощью операторов определения данных (CREATE DOMAIN, CREATE BASE RELATION, И Т.П.). Например, В результате выполнения оператора create base relation для отношения EMP, во-первых, для него формируется элемент в отношении RELATIONS и, во-вторых, набор из че­тырех элементов, один для каждого из четырех атрибутов отношения EMP, в отношении ATTRIBUTES. (Выполнение этого оператора вызывает и массу других последствий, которых, однако, мы здесь не будем касаться.) Таким образом, операция создания create в некотором смысле является аналогом операции вставки insert для каталога. Также операция удаления объектов destroy является аналогом операции удаления строк delete; а в SQL, который предоставляет различные операторы изменения alter для изменения элемен­тов каталога различными способами, операция alter является аналогом опе­рации обновления update.

Замечание. Как мы уже видели, каталог также включает элементы для самих отношений каталога. Однако эти элементы не создаются явно операцией create. Вместо этого они создаются автоматически самой системой как часть процедуры инсталляции системы. В сущности, они "зашиты" в систему.

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

Домен DOMNAME определен на NAME

RELNAME NAME

ATTRNAME NAME

DATDTYPE 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), а DUM соответствует ложь —false (или по). Упражнения и от­веты в следующих двух главах помогут несколько глубже понять этот мате­риал. Более подробную информацию можно найти в [4.6,4.7].

4.6. CREATE DOMAIN S# 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 J#	CHAR(4) ;
CREATE DOMAIN QTY	NUMERIC (9);

CREATE BASE RELATION S

(S# DOMAIN ( S# ),

SNAME DOMAIN ( NAME ),

STATUS DOMAIN ( STATUS ),

CITY DOMAIN ( CITY ) )

PRIMARY KEY ( S# ) ;

CREATE BASE RELATION P

( P# DOMAIN ( P# ),

PNAME DOMAIN ( NAME ),

COLOR DOMAIN ( COLOR ),

WEIGHT DOMAIN ( WEIGHT ),

CITY DOMAIN ( CITY ) )

PRIMARY KEY ( P# );

CREATE BASE RELATION J

( J# DOMAIN ( J# ),

JNAME DOMAIN ( NAME ),

CITY DOMAIN ( CITY ) ) PRIMARY KEY ( J# ) ;

CREATE BASE RELATION SPJ

( S# DCMAIN ( S# ),

P# DOMAIN ( P# ),

J# DOMAIN ( J# ),

QTY DOMAIN ( CTY ) )

PRIMARY KEY ( S#, P#, J# )

FOREIGN KEY ( S# ) REFERENCES S FOREIGN KEY ( P# ) REFERENCES P

FOREIGN KEY ( J# ) REFERENCES J ;

4.7. Кортеж {<S#:s, P#:p, S#:j, QTY:q} появляется в отношении SPJ тогда и толь­ко тогда, когда удовлетворяются следующие условия:

• Все значения s,p,j, q являются значениями соответствующих доменов.

• Значения s состоят из значений атрибута S# в отношении S; то же самое от­носится и к значениям p и j.

• В отношении SPJ при q'<>q нет кортежей {<S#:s, P#:p, J#:j, QTY:q'>}.

• Данный кортеж не нарушает никаких других применяемых правил целост­ности.

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