в языке SQL3 также имеется оператор, который можно рассматривать как оператор TREAT UP. Приведем, например, следуюш,ую формулировку оператора.

ARfA ( С AS ELLIPSE )

Уточнение AS ELLIPSE обеспечивает вызов версии ELLIPSE для оператора AREA, даже если объявленный тип переменной С будет CIRCLE.

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

В языке SQL3 также поддерживается метод вида X.SPECIFICTYPE, который возвращает наиболее конкретный тип своего аргумента Хкак символьную строку.

В языке SQL3 аналоги операторов вида 18 Г(А) и IS MS r(A) выглядят следующим образом.

X IS OF ( Т )

X IS OF ( ONLY Т )

Б.4. Ссылочные типы

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

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

CREATE TYPE DEPT TYPE AS ( DEPTi CHAR(3), DNAME CHAR(25), BUDGET MONEY ) REF IS SYSTEM GENERATED... ;

CREATE TABLE DEPT OF DEPT TyPE

( REF IS DEPT ID SYSTEM GENERATED, PRIMARY KEY ( DEPTi ), UNIQUE ( DEPT ID ) )... ;

Пояснения

1. Для данного определения структурированного типа Т система автоматически генерирует связанный ссылочный тип ( REF-тип ), обозначаемый как REF( Г). Значения типа REF( Г) представляют собой ссылки на строки типа Т в базовой таблице, которая определена как таблица, относящаяся к ( OF ) типу Г (см. п. 3). Замечание. Тип Г, конечно, может быть использован и в другом контексте, например как объявленный тип для некоторой переменной V или некоторого столбца С. Однако никакие значения REF( Г) не связаны с другими такими его применениями.

2. Предложение REF IS SYSTEM GENERATED в операторе CREATE TYPE означает, что реальные значения связанного REF-типа предоставляются системой. Может использоваться и другая опция REF IS USER GENERATED, но здесь она рассматриваться не будет. Опция REF IS SYSTEM GENERATED применяется по умолчанию.

3. Базовая таблица может быть определена (с помощью оператора CREATE TABLE) как таблица, относящаяся к некоторому структурированному типу. Однако ключевое слово OF здесь не совсем подходит, поскольку ни таблица в целом, ни даже отдельные ее строки на самом деле не относятся к рассматриваемому типу. В частности, для таблицы могут быть определены дополнительные столбцы вдобавок к столбцам (или, скорее, к атрибутам) самого структурированного типа. Фактически должен быть указан по крайней мере один дополнительный столбец, а именно- столбец подходящего REF-типа. Синтаксис для определения такого столбца- это не обычный синтаксис для определения столбца, который выглядит так. REF IS <имя столбца> SYSTEM GENERATED

Дополнительный столбец используется для размещения уникальных идентификаторов ( ссылок ) для строк данной базовой таблицы (подразумевается уточнение UNIQUE (<имя столбца>), хотя оно может указываться и явно, как в нашем примере). Идентификатор присваивается для данной строки, когда она вставляется, и остается связанным с этой строкой, пока она не будет удалена.

Замечание. Повторение уточнения SYSTEM GENERATED, конечно, необходимо. (Возможно, это покажется странным, но генерируемый системой столбец может быть целевым столбцом в операциях INSERT и UPDATE, хотя и используется по особым

Или, возможно, в некотором представлении. Использование представления в это.м приложении не рассматривается.

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

* Здесь присутствует некоторый порочный круг: такая строка может означать лишь строку, которая гшеет конкретный идентификатор . Обратите внимание на смешивание значения и переменной!

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

4. Как отмечалось в разделе Б.2, структурированный тип, например DEPT TYPE, не рассматривается в качестве инкапсулированного, если он используется как основа для определения базовой таблицы, несмотря на то что считается (в определенной степени) таковым во всех других контекстах. Поэтому в данном примере базовая таблица DEPT имеет четыре столбца, а не два, как это было бы, если бы тип DEPT TYPE был инкапсулированным.

5. Столбец DEPTi был описан как первичный ключ для таблицы DEPT. Однако, если строки таблицы DEPT имеют уникальные идентификаторы ( ссылки ), эти идентификаторы могли бы при желании использоваться в качестве значения первичного ключа.

CREATE TABLE DEPT OF DEPT TYPE

( REF IS DEPT ID SYSTEM GENERATED, PRIMARY KEY ( DEPT ID ), UNIQUE ( DEPTi ) )... ;

Теперь расширим пример, представив базовую таблицу ЕМР следующего вида.

CREATE TABLE ЕМР

( EMPi CHAR(5), ENAME CHAR(25), SALARY MONEY,

DEPT ID REF ( DEPT TYPE ) SCOPE DEPT REFERENCES ARE CHECKED ON DELETE CASCADE, PRIMARY KEY ( EMPi ) )... ;

Обычно базовая таблица EMP включает в качестве внешнего ключа столбец DEPTi, который ссылается на отделы с помощью номеров отделов. Здесь, однако, в качестве ссылочного столбца используется столбец DEPT ID, который неявно объявлен в качестве столбца внешнего ключа и который ссылается на отделы с использованием значений ссылок . Предложение SCOPE DEPT указывает соответствующую таблицу для ссылок. Предложение REFERENCES ARE CHECKED означает, что поддерживается контроль целостности; опция REFERENCES ARE NOT CHECKED допускает наличие висящих ссылок (непонятно, зачем кому-либо когда-либо может потребоваться указывать такую опцию). Опциями ON DELETE... задаются правила удаления, аналогичные обычным правилам удаления внешнего ключа (поддерживаются те же самые опции). Однако отметим, что если это в действительности будет случай, когда столбец DEPT ID в базовой таблице DEPT не может быть обновлен (см. п. 3 приведенного выше перечня), то не требуется никакого соответствующего правила ON UPDATE.

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

SELECT EX.DEPT ID -> DEPTi AS DEPTi

FROM EMP EX

WHERE EX.EMPi = ЕГ ;