5.6. Резюме

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

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

ставления (в том числе ТНЕ_псевдопеременная). Поддерживаются явные преобразова- ния типов, однако не поддерживается неявное приведение типов. Для скалярных типов можно дополнительно определить любое количество операторов, при этом для каждого типа обязательно должен быть определен оператор равенства (с требуемой семантикой).

Перейдем теперь к отношениям. Здесь следует различать значения отношений и пе- ременные отношений. Отношение состоит из двух частей — заголовка и тела. Заголо- вок — это набор атрибутов, а тело — это набор кортежей, соответствующий заголовку. Количество атрибутов называется степенью, а количество кортежей — кардинально- стью отношения. Каждое отношение принадлежит типу отношений, а именно — типу RELATION^}, где Н — соответствующий заголовок. Отношение можно представить себе как таблицу, столбцы которой являются атрибутами, а строки— кортежами, но это только приблизительное представление. Отношения обладают четырьмя очень важными свойствами.

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

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

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

• Каждый кортеж содержит ровно одно значение для каждого атрибута (т.е. отноше- ния нормализованы или, что то же самое, заданы в первой нормальной форме)

Как говорилось в главе 3, заголовок отношения иногда называют предикатом, а кор- тежи— истинными утверждениями, полученными из предиката в результате подста- новки значений параметров (или местодержателей) предиката. Допущение замкнутости мира гласит, что если заведомо корректный кортеж (т.е. удовлетворяющий заголовку отношения) не содержится в теле отношения, то можно предположить, что соответст- вующее ему утверждение ложно.

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

Существуют две разновидности переменных-отношений — базовые отношения и представления. Мы научились определять базовые отношения на языке Tutorial D, ко- торый используется в этой книге для иллюстрации излагаемого материала.

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

И наконец, мы вкратце рассмотрели, как в языке SQL определяются "домены" и базо- вые таблицы. В частности, следует отметить следующее.

• "Домены" языка SQL не являются типами.

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

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

SELECT * FROM S, Р ;

Упражнения

5.1. Пусть каталог имеет структуру, которая представлена на рис. 3.6 в главе 3 для базы данных отделов и служащих.

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

б) Как должна быть расширена структура каталога с учетом типов (доменов)?

в) Напишите запрос к этому расширенному каталогу для поиска всех именован- ных переменных-отношений, в которых используется атрибут типа EMPi.

г) Как будет выглядеть запрос п. в, записанный на языке SQL, но без использова- ния типов данных, которые определены пользователем?

2. На каких доменах основаны сами переменные-отношения каталога?

3. Для базового отношения PART_STRUCTURE (см. рис. 4.6 в главе 4) выполните следующее.

а) Используя рассмотренные в этой главе средства языка Tutorial D, определите базовую переменную-отношение, а также соответствующие типы.

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

в) Используя язык Tutorial D, напишите набор операторов DROP, необходимых для того, чтобы отменить изменения, которые были внесены в каталог в п. б.

4. Используя язык Tutorial D, напишите набор необходимых определений для базы данных поставщиков, деталей и проектов, представленной на рис. 4.5. (см. упраж- нения в главе 4).

5. Как отмечалось в разделе 5.2, говорить, что объем некоторой поставки равен, на- пример, 100 деталям, некорректно (объем поставки — это значение типа QTY, а не INTEGER). В этом смысле рис. 4.5, например, несколько неаккуратен, так как, глядя на него, можно предположить, что объемы поставок принадлежат типу INTEGER. Используя ваш ответ к упр. 5.4, покажите, как следует называть различные скаляр- ные значения, представленные на рис. 4.5.

6. Используя ответ к упр. 5.4, ответьте, какие из следующих скалярных выражений корректны. Укажите тип результата выполнения каждого корректного выражения. Для остальных выражений напишите корректный вариант выражений, которые бу- дут давать предполагаемый результат.

а) J.CITY = P.CITY

б) JNAME || PNAME

в) QTY *100

1ЯП

Части П Рспяиипинпя мпЛрпь

г) QTY + 100

д) STATJS + 5

е) J.CITY < S.CITY

ж) COLOR = P.CITY

з) J.CITY=P.CITY || 'burg'

5.7. Дайте все возможные определения скалярного типа CIRCLE (типа, описывающего произвольные круги на плоскости). Какие операторы выбора и операторы ТНЕ_ применяются к этому типу? Кроме того, выполните следующее.

а) Определите набор операторов чтения для вычисления диаметра, длины окруж- ности и площади заданного круга.

б) Определите оператор обновления, удваивающий радиус заданного круга (точнее, модифицирующий заданную переменную CIRCLE так, чтобы ее значение остава- лось неизменным, за исключением радиуса, который будет увеличен в два раза).

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

9. По определению отношение имеет множество атрибутов и множество кортежей. Пустое множество в математике рассматривается как вполне приемлемое. Обычно для теорем, формул и т.д. желательно, чтобы, если они выполняются для множест- ва из п элементов, они выполнялись и для множества из п = 0 элементов. Может ли отношение иметь пустое множество кортежей? Может ли оно иметь пустое множество атрибутов?

10. Иногда базовые переменные-отношения рассматриваются как обычные файлы, в которых в качестве записей выступают "кортежи", а в качестве полей— • "атрибуты". Обсудите этот тезис.

11. Как мы уже видели, операторы определения данных вызывают изменение содержания каталога. Но каталог — это всего лишь набор переменных-отношений, как и остальная часть базы данных. Можно ли применять обычные реляционные операторы INSERT, UPDATE и DELETE для соответствующего изменения каталога? Обоснуйте свой ответ.

12. Используя язык Tutorial D, напишите набор операторов DROP, необходимый для удаления из базы данных поставщиков, деталей и проектов всей информации, оп- ределенной пользователем.

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

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

5.1. Codd E.F. A Relational Model of Data for Large Shared Data Banks // CACM. — June, 1970.— 13, № 6. (Переиздано: Republished in Milestones of Research. — Selected Papers 1958-1982 // CACM. — January, 1983. — 26, M 1. См. также более раннее издание: Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks // IBM Research Report RJ599. — August, 1969. — № 19. Замечание. Это ран- нее издание является первой публикацией Кодда (Codd) о реляционной модели.)

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

Необходимо сделать несколько замечаний относительно терминологии. В своей статье вместо термина "переменная-отношение" Кодд использует термин "отношение, изменяющееся во времени". Однако этот термин не очень удачен. Во- первых, отношения как таковые являются значениями и не изменяются во времени (математике неизвестны отношения, принимающие разные значения в разное вре- мя). Во-вторых, если на каком-либо языке программирования мы пишем DECLARE N INTEGER

то мы не называем N целым числом, изменяющимся во времени; мы называем ее переменной целого типа. В этой книге используется собственный термин "переменная-отношение" и не используется термин "изменяющееся во времени", однако необходимо просто помнить о существовании этого устаревшего термина. 5.2. Codd E.F. The Relational Model for Database Management Version 2.— Reading, Mass.: Addison-Wesley, 1990.

Длительное время в конце 1980-х годов Кодд пересматривал и расширял свою изна- чальную модель (которую теперь называют реляционной моделью первой версии — "the Relational Model Version 1" или RM/V1), в результате чего появилась эта книга. В ней описывается так называемая реляционная модель второй версии — "the Rela- tional Model Version 2" или RM/V2. Основное различие между версиями состоит в следующем. Первая версия создавалась как абстрактный план для определенных ас- пектов общей проблемы баз данных (по большей части, наиболее фундаментальных аспектов), а вторая — как абстрактный план для всей системы. Поэтому, в то время как первая версия разделена только на 3 части (структуры, манипулирование и под- держка целостности), модель RM/V2 содержит 18 частей, которые включают не только 3 исходные части, что само собой разумеется, но и части, касающиеся пред- ставлений, каталогов, прав доступа, наименований, распределенных баз данных и других аспектов управления базами данных. Для удобства ссылок ниже приводится полный перечень этих 18 частей.

А	Права доступа	М	Обработка
В	Основные операторы	N	Наименование
С	Каталог	Р	Защита
D	Принципы разработки СУБД	Q	Классификаторы
Е	Команды администратора базы данных	s	Структуры
F	Функции	т	Типы данных
I	Поддержка целостности данных	V	Представления
J	Индикаторы	X	Распределенные базы данных
L	Принципы разработки языка	Z	Дополнительные операторы

Тем не менее идеи, опубликованные в этой книге, отнюдь не имели широкого рас- пространения. (См., в частности, статьи [5.7], [5.8] автора этой книги.) Приведем небольшой комментарий к этой статье. Как уже говорилось в настоящей главе, до-

мены ограничивают сравнения. Например, для базы данных поставщиков и дета- лей сравнение S.Si = P.Pi будет некорректным, поскольку сравниваемые величи- ны принадлежат разным типам. Следовательно, связать поставщиков и детали пу- тем сопоставления их номеров не удастся. Кодд, тем не менее, предложил свой ва- риант некоторых операторов реляционной алгебры — так называемые операторы DCO (Domain Check Override). Они выполняются, даже если при этом сравнива- ются значения разных типов. Так, например, DCO-версия оператора, рассмотрен- ного выше, позволяет связать поставщиков и детали несмотря на то, что атрибуты S.Si и P.Pi принадлежат разным типам (предполагается, что соединение произво- дится путем сопоставления не типов, а их представлений).

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

THE_Si ( Si ) = THE_Pt ( Pt )

Здесь обе части равенства принадлежат типу CHAR. Таким образом, мы утверждаем, что предложенный в разделе 5.2 механизм обеспечивает нас всеми необходимыми средст- вами очевидным и систематизированным образом. В частности, отпадает необходи- мость загромождать реляционную модель новыми операторами наподобие DCO JOIN.

5.3. Darwen Н. The Duplisity of Duplicate Rows // Relational Database Writings 1989— 1991. — Reading, Mass.: Addison-Wesley, 1992.

Эта статья была написана для подтверждения аргументов, уже представленных в [4.11], в пользу известного требования реляционной модели: в таблицах не должно содержаться одинаковых строк. В статье не только представлены новые версии этих аргументов, но и выдвинуты дополнительные аргументы. Основной вопрос состоит в следующем: для того чтобы конструктивно обсуждать совпадение двух объектов, необходим критерий идентичности для рассматриваемого класса объ- ектов (иначе говоря, что означает для двух объектов, будь это строки в таблице или что-нибудь еще, понятие "быть одним и тем же").

4. Darwen Н. Relation-Valued Attributes // Relational Database Writings 1989-1991.— Reading, Mass.: Addison-Wesley, 1992.

5. Darwen H. The Nullologist in Relationland // Relational Database Writings 1989— 1991. — Reading, Mass.: Addison-Wesley, 1992.

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

С темой настоящей главы (реляционными объектами данных) связаны раздел 2 этой статьи ("Таблицы без строк") и раздел 3 ("Таблицы без столбцов"). (См. также ответ к упр. 5.9.)

5.6. Date C.J. Why Duplicate Rows Are Prohibited // Relational Database Writings 1985— 1989. — Reading, Mass.: Addison-Wesley, 1990.

Представляются многочисленные аргументы (с примерами) в пользу требования реляционной модели того, чтобы в таблицах не было дублирующихся строк. В ча- стности, в статье показано, что дублирующиеся строки являются главным препят- ствием для оптимизации (см. главу 17, а также [5,3]).

5.7. Date CJ. Notes Toward a Reconstituted Definition of the Relational Model Version 1 (RM/V1) // Relational Database Writings 1989-1991. — Reading, Mass.; Addison-Wesley, 1992. Приводятся критика и резюме к реляционной модели Кодда RM/V1 [5.2] и дается альтернативное определение. Подразумевается, что крайне важно получить верную "версию 1", прежде чем обсуждать переход к какой-то "версии 2".

Замечание. Версия реляционной модели, описанная в настоящей книге, — это, по большей части, "воспроизведенная" версия, кратко описанная в данной статье (а затем уточненная и описанная в [3.3]).

5.8. Date C.J. A Critical Review of Relational Model Version 2 (RM/V2) // Relational Data- base Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992.

Приводятся критика и резюме к реляционной модели Кодда RM/V2 [5.2].

5.9. Date C.J. 30 Years of Relational (сборник из 12 статей) // Intelligent Enterprise!.— October, 1998. — № 1-9. Замечание. Большинство этих статей можно также найти по адресу www. intelligententerprise. com.

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

• Derivbility, Redundancy, and Consistency of Relations Stored in Large Data Banks (первое издание статьи [5.1])

• A Relational Model of Data for Large Shared Banks [5.1]

• Relational Completeness of Data Base Sublanguages [6.1]

• A Data Base Sublanguage Founded on the Relational Calculus [7.1]

• Further Normalization of the Data Base Relational Model [10.4]

• Extending the Relational Database Model to Capture More Meaning [13.6]

• Interactive Support for Nonprogrammers: The Relational and Network Approaches [25.8]

5.10. Mark A.R., Korth H.F., Silberschatz A. Extended Algebra and Calculus for Nested Rela- tional Databases // ACM TODS 13. — December, 1988. —№ 4.

¹³ Некоторые авторы отбрасывают данное определение и определяют NF -отношение как произвольное отношение хотя бы с одним атрибутом, принимающим в качестве значений отно- шения. Однако у нас есть свои причины не соглашаться с этим определением, поскольку факти- чески такое отношение будет записано в первой нормальной форме.

Спустя несколько лет группой исследователей были предложены так называемые "отношения NF²", где NF² = NFNF = "поп first normal form" (не первая нормальная фор- ма). Что подразумевается под термином NF², — не совсем очевидно. Возможно, сле- дующая интерпретация этого термина внесет некоторую ясность. Пусть пг — это NF²- отношение и пусть "атрибут" А отношения пг принадлежит типу Т. Тогда некоторый "кортеж" г "отношения" пг может содержать любое количество значений (возможно, даже нулевое) "атрибута" А и разные "кортежи" могут содержать разное число значений "атрибута" А¹³. (В этом случае А называется атрибутом повторяющейся группы; см. ци-

тэты из предыдущего издания этой книги в разделе 5.3 этой главы.) Обратите внимание на то, что "отношение" пг не нормализовано (оно не содержит ровно по одному значе- нию каждого атрибута в каждом кортеже). В действительности пг вовсе не является от- ношением в контексте реляционной модели. Как бы то ни было, в данной работе рас- сматривается один из вариантов идеи NF². В частности, автор определяет для NF²- отношений исчисление и алгебру (см. главы 6 и 7) и доказывает их эквивалентность. Он также ссылается на другие работы, посвященные этой теме. *"

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

5.1.

а) Очевидные изменения суммированы и даны ниже.

TABLE заменяется на RELVAR

COLUMN ATTRIBUTE

TABNAME RVNAME

COLCOUNT DEGREE

ROWCOUNT CARDINALITY {сокращенно — CARD)

COLNAME ATTRNAME

Обратите внимание, что переменная-отношение TABLE (теперь уже RELVAR) должна иметь еще один атрибут (RVKIND), значения которого указывают ее тип (базовая переменная-отношение или представление). Структура каталога будет выглядеть таким образом.

RELVAR RVNAME DEGREE CARD RVKIND

ATTRIBUTE I RVNAME 1 ATTRNAME | |

б) Нужна новая переменная-отношение каталога (TYPE), содержащая элемент для каждого типа, а также новый атрибут (TYPENAME) в переменной-отношении ATTRIBUTE, представляющий тип каждого атрибута каждой переменной- отношения. Структура каталога будет подобна следующей. TYPE

TYPENAME

RELVAR RVNAME DEGREE CARD RVKIND

ATTRIBUTE RVNAME ATTRNAME TYPENAME

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

в) (ATTRIBUTE WHERE TYPENAME = NAME('EMPi')) {RVNAME}

Здесь обратите внимание на вызов оператора выбора NAME (см. ответ к упр. 5.2).

г) Если системой не поддерживаются типы, определенные пользователем, то оче- видно, что невозможно написать запрос к каталогу относительно этих типов! Можно только написать запрос относительно атрибутов. Вообще говоря, ре-

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

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

дополнительных указаний.

TYPENAME определен на домене NAME

RVNAME NAME

ATTRNAME NAME

DEGREE CARD

RVKIND

NONNEGJNTEGER NONNEG_INTEGER RVKIND

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

• NAME — это множество всех допустимых имен.

• NONNEG_INTEGER — множество неотрицательных целых чисел, не превышающих некоторый верхний предел.

• RVKIND — это, грубо говоря, множество {"Base", "View"}.

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

а) TYPE Pi POSSREP ( CHAR ) ; TYPE QTY POSSREP ( INTEGER ) ;

VAR PART STRUCTURE BASE RELATION { MAJOR Pi Pi,

MIN0R"Pi Pi,

QTY ~ QTY } PRIMARY KEY { MAJ0R_Pt, MIN0R_Pi } ;

б) На рис. 5.4 показаны только новые элементы каталога. Обратите внимание, что элемент CARD в переменной-отношении RELVAR должен быть увеличен на еди- ницу и для самой переменной-отношения RELVAR. Также кардинальность пере- менной-отношения PARTJ5TRUCTURE показана равной 0, а не 7 (несмотря на то, что на рис. 4.6 она содержит семь кортежей), поскольку отношение, конечно же, будет пустым, если оно только что создано.

в) DROP VAR PART STRUCTURE ; DROP TYPE QTY~;

DROP TYPE Pi ;

TYPE

TYPENAME
P# QTY

RELVAR

RVNAME	DEGREE	CARD	RVKIND	...
PART STRUCTURE	CO	0	Base

ATTRIBUTE

RVNAME	ATTRNAME	TYPENAME	...
PART STRUCTURE PART STRUCTURE PART STRUCTURE	MAJOR P# MINOR P# QTY	P# P# QTY	...

POSSREP( POSSREP( POSSREP( POSSREP( POSSREP( POSSREP(

CHAR ) ; CHAR ) ; CHAR ) ; CHAR ) ; RATIONAL CHAR ) ;

TYPE Si TYPE NAME TYPE Pi TYPE COLOR TYPE WEIGHT TYPE Ji TYPE QTY

POSSREP( INTEGER

Рис, 5.4. Элементы каталога для переменной-отношения PART_STRUCTURE 5.4.

VAR S BASE RELATION

{ Si Si,

SNAME NAME, STATUS INTEGER, CITY CHAR }

PRIMARY KEY { Si };

VAR P BASE RELATION

{

Pi

PNAME COLOR WEIGHT CITY

NAME, COLOR, WEIGHT, CHAR }

VAR

PRIMARY KEY { Pi }

J BASE RELATION { Jt Ji, JNAME NAME, CITY CHAR } PRIMARY KEY { Ji }

PRIMARY KEY { St, Pt, Jt } FOREIGN KEY { S# } REFERENCES S FOREIGN KEY { Pt } REFERENCES P FOREIGN KEY { Jt } REFERENCES J;

5.5. Ниже приводятся примеры типичных значений для каждого атрибута. Начнем с переменной-отношения S. ^

St

SNAME

STATUS

CITY

St('Sl') NAME('Smith' 20

'London'

Переменная-отношение P.

PI

PNAME COLOR WEIGHT CITY

P# ( 'PI' ) NAME ( 'Nut' ) COLOR ( 'Red' ] WEIGHT ( 12.0 ; 'London'

Переменная-отношение J.

Jt

JNAME CITY

Jt ( 'Jl' ) NAME ( 'Sorter' 'Paris'

5.6.

а) Корректно; BOOLEAN.

б) He корректно; NAME (THE_NAME(JNAME) || THE_NAME(PNAME)).

Замечание. Идея состоит в том, чтобы соединить два допустимых строковых представления, а затем преобразовать полученную строку обратно в тип NAME. Разумеется, если полученная строка не является корректным именем, преобра- зование выполнено не будет.

в) Корректно; QTY.

г) Не корректно; QTY + QTY(IOO).

д) Корректно; STATUS.

е) Корректно; BOOLEAN.

ж) Не корректно; THE_COLOR(COLOR) = P.CITY.

з) Корректно.

5.7. TYPE LENGTH POSSREP ( RATIONAL ) ;

TYPE POINT POSSREP ( X RATIONAL, Y RATIONAL ) ; TYPE CIRCLE POSSREP ( R LENGTH, CTR POINT ) ;

/* R - длина радиуса окружности, */

/* a CTR - ее центр */

Единственный оператор выбора для типа CIRCLE выглядит следующим образом. CIRCLE (г, ctr)

/* Возвращает окружность с радиусом г и центром ctr*/ Операторы ТНЕ_ будут такими.

THE_R(c)

/* Возвращает длину радиуса окружности с */ THE_CTR(с)

/* Возвращает точку, которая является центром окружности с */

а) OPERATOR DIAMETER ( С CIRCLE ) RETURNS ( LENGTH ) ;

RETURN ( 2 * THE_R ( С ) ) ; END OPERATOR ;

OPERATOR CIRCUMFERENCE ( С CIRCLE ) RETURNS ( LENGTH ) ;

RETURN ( 3.14159 * DIAMETER ( С ) ) ; END OPERATOR ;

OPERATOR AREA ( С CIRCLE ) RETURNS ( AREA ) ;

RETURN ( 3.14159 * ( THE_R ( С ) ** 2 ) ) ; END OPERATOR ;

Мы предполагаем, что результат умножения целого числа на значение типа LENGTH принадлежит типу LENGTH и что результат умножения двух значений ти- па LENGTH принадлежит типу AREA (где AREA — новый тип, определенный поль- зователем).

б) OPERATOR DOUBLE R ( С CIRCLE ) UPDATES ( С ) ;

BEGIN ;

THE R ( С ) := 2 * THE R ( С ) ; RETURN ; END ; END OPERATOR ;

8. Следует отметить, что при определении типа множество соответствующих значений не создается. Концептуально эти значения уже существуют и всегда будут существо- вать (задумайтесь, например, о типе INTEGER). Таким образом, все операторы "определения типов", т.е. операторы TYPE языка Tutorial D, в действительности вво- дят в употребление имя, которое далее будет использоваться для ссылок на это мно- жество значений. Подобным образом оператор DROP TYPE фактически удаляет не со- ответствующие значения, а только имя, установленное соответствующим оператором TYPE. Отсюда следует, что "обновление существующего типа" означает удаление су- ществующего имени типа, а затем повторное присвоение этого же имени другому множеству значений. Разумеется, для упрощения этой процедуры ничто не мешает нам использовать какое-либо сокращение наподобие оператора ALTER TYPE.

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

Чтобы рассмотреть это понятие подробнее, вначале обсудим вопрос о том, могут ли отношения без атрибутов иметь кортежи. В действительности такие отношения мо- гут иметь не более одного кортежа, а именно — 0-кортеж (т.е. кортеж, не имеющий значений атрибутов). Таких кортежей не может быть более одного, поскольку все 0- кортежи дублируют друг друга. Поэтому существует ровно два отношения степени 0: одно, содержащее ровно один кортеж, и одно, совсем не содержащее кортежей. Эти отношения настолько важны, что, следуя Дарвену [5.5], мы называем их ласко- выми именами: первое — TABLE_DEE и второе — TABLE_DUM, или для краткости DEE и DUM (DEE имеет 0-кортеж, a DUM не имеет).

Мы не станем углубляться в детали этого вопроса в данный момент и удовлетво- римся лишь следующим: значение этих отношений так важно еще и потому, что DEE соответствует истине (true, или yes), a DUM соответствует лжи (false, или по). В упражнениях и ответах к ним в главах 6 и 8 предлагается более детальное изло- жение данного материала. Подробная информация приводится в [5.5].

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

11. В принципе, ответ— можно. Изменять каталог можно с помощью обычных средств, т.е. операций INSERT, UPDATE и DELETE. Однако возможность использова- ния таких операций могла бы быть потенциально очень опасной, поскольку она позволяет легко разрушить всю информацию в каталоге (по небрежности или по иным причинам), после чего система уже не сможет корректно функционировать. Предположим, например, что для каталога базы данных отделов и служащих до- пустима следующая операция DELETE.

DELETE RELVAR WHERE RVNAME = NAME ( 'EMP' ) ;

В результате ее выполнения из переменной-отношения RELVAR удаляется кортеж, описывающий переменную-отношение ЕМР. С точки зрения системы переменной- отношения ЕМР больше не существует, т.е. система больше не имеет никаких све- дений об этой переменной-отношении. Значит, все последующие попытки обраще- ния к этой переменной-отношению будут безуспешными.

Поэтому в большинстве реальных продуктов операции UPDATE, DELETE и INSERT для каталога или не разрешены вовсе (это обычная практика), или разрешены лишь для пользователей, наделенных очень высокими правами (возможно, лишь для ад- министратора базы данных). Вместо этих операторов для изменения каталога ис- пользуются операторы определения данных (CREATE DOMAIN, CREATE BASE RELATION и т.п.). Например, в результате выполнения оператора CREATE BASE RELATION для переменной-отношения ЕМР формируется элемент в переменной- отношении RELVAR и набор из четырех элементов (по одному для каждого из четы- рех атрибутов переменной-отношения ЕМР) в переменной-отношении ATTRIBUTE. (Выполнение этого оператора вызывает также множество других последствий, ко-

торых, однако, мы здесь не будем касаться.) Таким образом, операция определения нового объекта (нового типа или базовой переменной-отношения) в некотором смысле является аналогом операции вставки INSERT для каталога. Также операция удаления объектов DROP является аналогом операции удаления строк DELETE. В языке SQL, который предоставляет различные операторы ALTER для изменения элементов каталога различными способами (например, ALTER (base) TABLE), опе- рация ALTER является аналогом операции изменения UPDATE.

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

5.12. DROP VAR SPJ, S, P, J ;

DROP TYPE S#, NAME, P#, COLOR, WEIGHT, JI, QTY ;

Здесь предполагается, что операторы DROP VAR и DROP TYPE могут удалять не- сколько переменных или типов за одно выполнение.

Глава

Реляционная алгебра