Обратите внимание на операцию paзымeнoвывaния в предложении SELECT (выражение EX.DEPT ID -> DEPTt возвращает значение DEPTt из строки DEPT, на которую указывает данное значение идентификатора DEPT ID). Также обратите внимание, что спецификация AS здесь в определенной степени необходима (если бы она была опущена, результирующий столбец был бы задан с именем, зависящим от реализации ). И наконец, отметим интуитивно непонятный характер построения предложения FROM- получаемое значение DEPTt извлекается из DEPT, а не из ЕМР, но значение DEPT ID извлекается из ЕМР, а не из DEPT.

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

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

SELECT DEREF (EX.DEPT ID ) AS DEPT

FROM EMP EX

WHERE EX.EMPt = El ;

Более того, вызов операции DEREF возвращал бы не значение строки, а инкапсулированное (скалярное) значение.

Вот еще один пример: Получить номера служащих, работающих в отделе D1 (обратите внимание на разыменовывание в предложении WHERE).

SELECT EX.EMPt FROM EMP EX

WHERE EX.DEPT ID -> DEPTt = Dl ;

Ниже приводится пример операции INSERT (вставка сведений о некотором служащем).

INSERT INTO ЕМР ( EMPt, DEPT ID )

VALUES ( E5, ( SELECT DX.DEPT ID FROM DEPT DX WHERE DX.DEPTt = D2 ) ) ;

Б.5. Подтаблицы и супертаблицы

Рассмотрим следующие структурированные типы (описывающие служащего и программиста).

CREATE TYPE ЕМР TYPE

AS ( EMPt ...7 DEPTt ... ) REF IS SYSTEM GENERATED NOT FINAL ... ;

В большинстве языков, в которых поддерживается операция разыменовывания, также поддерживается операция привязки, но в языке SQL3 - нет.

CREATE TYPE PGMR TYPE UNDER EMP TYPE AS ( LANG ... ) NOT FINAL ... ;

Заметим, что определение типа PGMR TYPE не имеет предложения REF IS .... Вместо этого оно фактически наследует такое предложение от своего непосредственного супертипа EMP TYPE.

Теперь рассмотрим следующие определения базовых таблиц.

CREATE TABLE ЕМР OF EMP TYPE

( REF IS EMP ID SYSTEM GENERATED, PRIMARY KEY ( EMPt ), UNIQUE ( EMP ID ) ) ;

CREATE TABLE PGMR OF PGMR TYPE UNDER EMP ;

Обратите внимание на спецификацию UNDER ЕМР в определении базовой таблицы PGMR (также обратите внимание на отсутствие спецификаций REF IS PRIMARY KEY и UNIQUE для этой базовой таблицы). Такие базовые таблицы, как PGMR и ЕМР, называются подтаблицей и соответствующей непосредственной супертаблицей. Таблица PGMR наследует столбцы таблицы ЕМР и имеет один дополнительный собственный столбец LANG. Интуитивно в этом примере утверждается, что не программист имеет лищь некоторую строку в таблице ЕМР, а программист имеет строку в обеих таблицах, поскольку каждая строка в таблице PGMR имеет эквивалент в таблице ЕМР, но обратное неверно.

Операции обработки данных для этих таблиц выполняются следующим образом.

Операция SELECT. Для таблицы ЕМР операция SELECT выполняется так, как обычно, а для таблицы PGMR - как будто в этой таблице PGMR действительно содержатся столбцы таблицы ЕМР и столбец LANG.

Замечание. Уточнение ONLY может использоваться в параметре <ссылочная таблица> для исключения строк, которые имеют эквиваленты в некоторой подтаблице данной таблицы. Поэтому, например, операция SELECT ... FROM ONLY ЕМР выполняется так, как будто в таблицу ЕМР включены только строки, которые не имеют эквивалентов в таблице PGMR.

Операция INSERT. Для таблицы ЕМР операция INSERT выполняется так, как обычно. В результате ее выполнения для таблицы PGMR новые строки вставляются в обе таблицы, PGMR и ЕМР.

Операция DELETE. При выполнении операции DELETE для таблицы ЕМР удаляются строки из таблиц ЕМР и (если эти строки соответствуют программистам) PGMR. Удаление строк из таблицы PGMR приводит к удалению строк из обеих таблиц.

Операция UPDATE. Обновление столбца LANG, обязательно через таблицу PGMR, приводит к обновлению лишь таблицы PGMR. Обновления других столбцов через таблицу PGMR или ЕМР приводят к обновлению обеих таблиц (концептуально).

Укажем на некоторые следствия из предыдущих правил.

Предположим, что служащий Joe стал программистом. Если просто вставить строку для Joe в таблицу PGMR, система попытается вставить строку для Joe также в таблицу ЕМР, что, конечно, приведет к ошибке. Вместо этого необходимо удалить строку служащего Joe из таблицы ЕМР, а затем вставить соответствующую строку в таблицу PGMR.

И наоборот, предположим, что служащий Joe перестал быть программистом. На этот раз необходимо удалить строку Joe из таблицы ЕМР или PGMR (какую бы таблицу мы ни указали, в результате строки будут удалены из обеих таблиц). Затем нужно вновь вставить соответствующую строку в таблицу ЕМР.

А что делать с наследованием типа? Насколько мы можем судить, ответ на этот вопрос - Ямчего , т.е. ничего, кроме того (по соображениям, которые непонятны), что язык SQL3 требует, чтобы подтаблица и ее непосредственная супертаблица были определены через структурированные типы, которые являются подтипом и его непосредственным супертипом соответственно. Подчеркнем, что никакой заменимости эта схема не включает и, кроме того, рассматриваемые типы, совершенно определенно, не инкапсулированы .

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

Б.6. Другие ВОЗМОЖНОСТИ Создание таблиц

в языке SQL3 в предложении CREATE TABLE поддерживается опция LIKE, позволяющая скопировать некоторые или все определения новой базовой таблицы из некоторой существующей именованной таблицы (отметим, что именованная не означает возможность указать произвольное табличное выражение вместо имени таблицы).

Табличные выражения

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

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