3.2 Объектные расширения в стандарте SQL :1999

В этом разделе мы кратко изложим существо объектных расширений, которые включены в стандарт SQL :1999. В этом изложении мы основываемся не на официальном тексте стандарта (он очень формален и скучен), а на книге Джима Мелтона [12], которая, по сути, является неформальным описанием семантики (rationale ) соответствующей части языка. В указанной книге объектным расширениям языка SQL посвящено более 200 страниц. Естественно, наше изложение будет несравненно более кратким (в частности, за счет отказа от приведения синтаксических правил).

Объектная модель SQL

Объектная модель SQL ⁶⁹ не является тождественной объектным моделям какого-либо объектно-ориентированного языка программирования или какой-либо объектно-ориентрованной системы баз данных (включая модель ODMG – см. разд. 2). Однако при определении объектной модели SQL участники процесса стандартизации тщательно проанализировали ряд других языков и систем с целью выяснения достоинств и недостатков их объектных моделей⁷⁰. По мнению авторов стандарта SQL :1999, выработанная ими объектная модель похожа на объектную модель языка Java , но при этом адаптирована к природе языка SQL как языка СУБД с наличием стабильно хранимых метаданных и данных ⁷¹.

Объектная модель SQL :1999 включает два основных отличительных компонента – структурные, определяемые пользователями типы данных (User Defined Type – UDT )и типизированные таблицы (Typed Table ). Первый компонент позволяет определять новые типы данных, которые могут быть гораздо более сложными, чем встроенные типы данных языка SQL . При определении структурного UDT требуется специфицировать не только содержащиеся в нем элементы данных, но и семантику типа данных, т.е. его поведение на основе интерфейса вызовов методов. Второй компонент – типизированные таблицы – позволяет определять таблицы, строки которых являются экземплярами (или значениями) UDT , с которым явно ассоциируется таблица.

В стандарте SQL :1999 определены два пакета объектных свойств – минимальный (PKG 006) и полный (PKG 007), которым должны удовлетворять SQL -ориентированные ОРСУБД, претендующие на соответствие стандарту. Ниже мы перечислим свойства, включенные в каждый из пакетов, но смысл этих свойств будет понятен только на основе последующих подразделов.

Пакет PKG 006 включает всего пять свойств:

свойство S 023 (“Basic structured types ”) – возможность определять UDT и их методы с ограниченными возможностями;
свойство S 041 (“Basic reference types ”) – возможность определять и использовать ссылки на экземпляры UDT , входящие в типизированные таблицы;
свойство S 051 (“Create table of type ”) – возможность создания типизированных таблиц;
свойство S 151 (“Type predicate ”) – возможность определения точного типа (в иерархии типов) экземпляра UDT ;
свойство Т041 (“Basic LOB data type support ”)– возможность определения LOB -типов в смысле SQL (с необязательной поддержкой операций, кроме операций сохранения и полной выборки).

Пакет PKG 007 содержит девять дополнительных свойств:

свойство S 024 (“Enhanced structured types ”) – добавляет к свойству S 023 ряд развитых возможностей, в число которых входят возможности кодирования методов на языках, отличных от SQL , сравнения экземпляров UDT и передача экземпляров UDT в качестве параметров различных процедур;
свойство S 043 (“Enhanced reference types ”) – расширяет свойство S 041 возможностями определения ссылок с областью действия, автоматической проверки законности ссылок и т.д.;
свойство S071 (“SQL-paths in function and type name resolution”) – позволяет использовать путевые выражения SQL (SQL-path) в алгоритме разрешения типа;
свойство S 081 (“Subtables ”) – расширяет возможности свойства S 051, допуская организацию иерархии таблиц, аналогичной иерархии типов соответствующих UDT ;
свойство S 111 (“ONLY in query expressions ”) –обеспечивает возможность выборки только экземпляров указанного типа, без экземпляров любого из его подтипов;
свойство S 161 (“Subtype treatment ”) – дает возможность информировать среду SQL о том, что некоторый экземпляр UDT в действительности является экземпляром указанного подтипа;
свойство S 211 (“User -defined cast functions ”) – разрешает определять подпрограммы, преобразующие экземпляры UDT к другим типам;
свойство S 231 (“Structured type locators ”) – способствует доступу к экземплярам UDT из прикладных программ;
свойство S 023 (“Transform functions ”) – позволяет определять подпрограммы, преобразующие значения UDT в значения предопределенных типов данных и наоборот.

Конструируемые типы данных

Важность обеспечения конструируемых типов данных отмечалась и в Первом, и во Втором манифестах. В SQL :1999 обеспечиваются соответствующие (хотя и ограниченные) возможности.

Типы коллекций

Начиная с SQL :1999, в языке поддерживается возможность использования типов данных, значения которых являются коллекциями значений некоторых других типов. Обычно под термином коллекция понимается одно из следующих образований: массив, список, множество и мультимножество. В варианте SQL :1999, принятом в 1999 г., специфицированы только типы массивов. Любой возможный тип массива получается путем использования конструктора типов ARRAY . При определении столбца, значения которого должны принадлежать некоторому типу массива, используется конструкция

dt ARRAY [ mc ] , где dt специфицируетнекоторый допустимый в SQL тип данных (отличный от типа массива), а mc является литералом некоторого точного числового типа с нулевой длиной шкалы и определяет максимальное число элементов в значении типа массива (в терминологии SQL :1999 это значение называется максимальной кардинальностью массива). Тем самым, в текущей версии стандарта SQL :1999 не поддерживаются многомерные массивы и массивы массивов.

Элементам каждого значения типа массива соответствует их порядковый номер, называемый индексом. Значение индекса всегда должно принадлежать отрезку [1, mc ]. Значениями типа массива dt ARRAY [ mc ] являются все те массивы, состоящие из элементов типа dt , максимальное значение индекса которых cs не превосходит значения mc . При сохранении в базе данных значение типа массива занимает столько памяти, сколько требуется для сохранения cs элементов. Обеспечивается доступ к элементам массива по их индексам. В частности, можно объявить столбец типа INTEGER ARRAY [10] и при вставке строки в соответствующую таблицу задать значение только пятого элемента массива. Тогда в строку будет занесен массив из пяти элементов, причем первые четыре элемента будут содержать неопределенное значение (NULL ).

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

Анонимные строчные типы⁷²

Анонимный строчный тип – это конструктор типов, позволяющий производить безымянные типы строк (кортежей). Любой возможный строчный тип получается путем использования ROW . При определении столбца, значения которого должны принадлежать некоторому строчному типу, используется конструкция ROW ( fld ₁, fld ₂, …, fld _n), где каждый элемент fld_i , определяющий поле строчного типа, задается в виде тройки fldname , fldtype , fldoptions . Подэлемент fldname задает имя соответствующего поля строчного типа. Подэлемент fldtype специфицирует тип данных этого поля. В качестве типа данных поля строчного типа можно использовать любой допустимый в SQL тип данных, включая другие строчные типы. Необязательный подэлемент fldoptions может задаваться для указания применяемого по умолчанию порядка сортировки, если соответствующий подэлемент fldtype указывает на тип символьных строк, а также должен задаваться, если fldtype указывает на ссылочный тип (см. ниже). Степенью строчного типа называется число его полей.

Определяемые пользователями типы

Думаю, что не стоит снова обосновывать потребность в UDT . Об этом много говорилось ранее в этой статье. Поэтому сразу перейдем к сути предложений SQL :1999. Как отмечалось выше, в стандарте поддерживается возможность определения пользователями двух разновидностей UDT – структурных типов (structured type ) и индивидуальных типов (distinct types ).

Индивидуальные типы

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

Пусть заданы следующие определения индивидуальных типов:

CREATE TYPE EMP_NO AS INTEGER FINAL;

CREATE TYPE DEPT_NO AS INTEGER FINAL;

CREATE TYPE PRO_NO AS INTEGER FINAL;

Тогда таблицу EMP можно определить следующим образом:

CREATE TABLE EMP (

     EMP_ID   EMP_NO,
     EMP_NAME VARCHAR(20),
     DEPT_ID DEPT_NO,

PRO_ID PRO_NO ) ;

Такое определение таблицы, приведет к тому, что хотя все три индивидуальных типа определены на одном и том же базовом типе INTEGER , попытка выполнить запрос

SELECT EMP_NAME
FROM EMP
WHERE EMP_ID > DEPT_ID ;

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

SELECT EMP_NAME
FROM EMP
WHERE CAST(EMP_ID TO INTEGER) > CAST(DEPT_ID TO INTEGER) ;

У читателей могут возникнуть законный вопрос: что означает ключевое слово FINAL в приведенных примерах определения индивидуальных типов?

Ответ может быть довольно неожиданным. С формальной точки зрения индивидуальный тип данных является частным случаем структурного типа данных. Обе разновидности UDT определяются единым синтаксисом. В частности, ключевое слово FINAL играет важную роль в определении структурного типа, указывая тот факт, что этот тип может быть использован только для создания объектов, а не для порождения новых типов на основе механизма наследования. При определении индивидуальных типов механизм наследования не используется и поэтому в определении любого индивидуального типа должно присутствовать ключевое слово FINAL .⁷³ Далее, поскольку индивидуальный тип является частным типом структурного типа, для индивидуального типа можно определять методы.

В книгах Джима Мелтона [12-13] неоднократно подчеркивается семантическое сходство понятий индивидуального типа данных и домена в смысле SQL . Более того, утверждается, что в следующих версиях стандарта SQL использование доменов будет сначала объявлено нежелательным, а потом и вовсе будет запрещено. По мнению автора этой статьи, это сделать совсем непросто. Напомним, что в случае использования SQL -домена:

(a) в определении домена указывается базовый встроенный тип данных и, возможно, ограничение допустимых значений, которое распространяется на любой столбец, определенный на данном домене;

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

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

(a) в определении индивидуального типа указывается только базовый тип данных; если столбец определяется на индивидуальном типе данных, то для него обязательно придется специфицировать собственное ограничение целостности;

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

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

Определение структурных типов

Имя определяемого пользователем типа данных имеет, в общем случае, традиционную для SQL трехзвенную архитектуру – имя_каталога.имя_схемы.имя_типа . Определение структурного UDT может содержать раздел подтипизации. Если этот раздел присутствует в определении UDT , то в нем указывается имя ранее определенного UDT , атрибуты и методы которого будут наследоваться определяемым структурным типом.

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

Заметим, что раздел представления может отсутствовать. В этом случае должен присутствовать раздел подтипизации, и представление заново определяемого структурного типа полностью наследуется из определения структурного UDT , имя которого указано в разделе подтипизации.

Имя определяемого атрибута должно отличаться от имен всех других атрибутов определяемого типа, включая имена атрибутов, наследуемых от супертипа, и имена атрибутов типа данных определяемого атрибута. Тип данных может быть любым допустимым в SQL типом данных (включая конструируемые типы ARRAY и ROW и UDT ), кроме определяемого структурного типа и его супертипов.

Для атрибута можно объявить значение по умолчанию. Если типом данных атрибута является встроенный тип данных, то значение атрибута объявляется в том же синтаксисе, что и значение столбца по умолчанию в определении таблицы. Если типом данных атрибута является UDT (индивидуальный или структурный), тип ROW или ссылочный тип (см. следующий подраздел), то единственным допустимым значением по умолчанию является неопределенное значение (NULL ). Если же типом данных атрибута является тип ARRAY , то значением по умолчанию может быть NULL или пустое значение-массив (указывается как ARRAY [] ).

Для каждого определения атрибута, в котором типом атрибута является структурный тип, система автоматически генерирует пару методов, имена которых совпадают с именем атрибута. Первый метод является наблюдателем (observer ). Он вызывается без явных параметров и выдает значение указанного атрибута в значении того структурного типа, к которому применяется. Второй метод является мутатором (mutator ). Он вызывается с одним явным параметром – значением типа аргумента, применяется к некоторому местоположению (столбцу, переменной или параметру), где находится значение определяемого структурного типа, и этот вызов приводит к тому, что значение заменяется новым значением того же типа с измененным соответствующим образом значением данного аргумента.

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

Можно определить инстанциируемый (instantiable ) или неинстанциируемый (not instantiable ) структурный тип. Для неистанциируемого типа не определяется конструктор, и поэтому невозможно создать значение этого типа.⁷⁶ Поэтому такие типы применимы только для определения инстанциируемых подтипов. Назначение неинстанциируемых типов состоит в моделировании абстрактных концепций, на которых основываются более конкретные концепции. Неинстанциируемые типы могут быть типами атрибутов других структурных типов, типами столбцов, переменных и т.д. Однако в соответствующих местоположениях всегда должно находиться либо значение инстанциируемого подтипа данного неинстанциируемого типа, либо неопределенное значение.

Обязательный раздел окончательности определения указывает на возможность или невозможность определения подтипов определяемого структурного типа. При определении индивидуального типа всегда требуется указывать FINAL . При определении структурного типа в SQL :1999 требуется указание NOT FINAL . Это требование не обосновано, и в следующих версиях стандарта SQL будет разрешено определять структурные типы, от которых невозможно наследование.

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

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

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

Раздел преобразования типов может присутствовать только в определении индивидуального типа. Спецификации раздела обеспечивают возможности преобразования значений индивидуального типа в значения базового встроенного типа и наоборот.

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

Исходный метод может быть определен как метод экземпляра, статический метод или метод-конструктор. Методы экземпляра действуют над экземплярами определяемого типа. Статические методы не используют экземпляры типа и не влияют на них; такие методы действуют над самим типом. Наконец, методы-конструкторы используются для инициализации экземпляров типа. Поскольку у неинстанциируемого типа не может быть экземпляров, для него могут быть определены только статические методы. Если при определении первичного метода не указывается его разновидность, этот метод считается методом экземпляра.

В сигнатуре метода указывается имя, по которому этот метод будет вызываться (вызывное имя – invocable name ). Кроме того, можно указать точное имя метода (specific name ), которое может быть использовано для уникальной идентификации метода, если его вызывное имя перегружено. Если у метода имеются какие-либо параметры, отличные от неявного параметра SELF , то в определении должен присутствовать заключенный в скобки список пар <имя_параметра, тип_параметра>, разделяемых запятыми. Поскольку методы являются функциями, требуется указать тип возвращаемого значения. Методы могут возвращать значения любого допустимого в SQL типа, даже структурного типа, ассоциированного с методом.

Наконец, у каждого метода имеется набор характеристик метода. Методы могут быть написаны на языке SQL или на любом из языков программирования, поддержка которых предусмотрена в стандарте SQL (Ada , C , COBOL , Fortran , MUMPS ⁷⁷, Pascal , PL /1). Язык Java поддерживается в стандарте несколько в иной манере, чем другие языки. Список параметров метода может быть определен в стиле, более соответствующем стилю SQL -подпрограмм (каждый параметр может принимать неопределенное значение, и не требуется параметр кода возврата). Для этого в качестве характеристики метода нужно указать PARAMETER STYLE SQL . Можно определить список параметров в стиле, более близком стилю различных языков программирования (параметру, который может принимать неопределенное значение, должен быть придан дополнительный параметр-индикатор, и должен быть явно определен выходной параметр кода ответа). В этом случае метод должен иметь характеристику PARAMETER STYLE GENERAL . Наконец, для методов, тела которых будут писаться на языке Java , нужно указать характеристику PARAMETER STYLE JAVA .

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

У каждого метода имеется характеристика, указывающая связь этого метода с SQL . Можно указать следующие варианты:

метод не содержит операторов SQL (NO SQL );
метод содержит операторы SQL , но не обращается к базе данных (CONTAINS SQL );
метод может производить выборку из базы данных, но не обновляет базу данных (READS SQL DATA );
в методе допускаются обновления базы данных (MODIFIES SQL DATA ).

По умолчанию принимается характеристика CONTAINS SQL . Наконец, для каждого метода можно определить его реакцию на аргументы, являющиеся неопределенными значениями. Если указывается RETURN NULL ON NULL INPUT , то метод всегда возвращает неопределенное значение, если значение любого из его аргументов является неопределенным. Если же указывается CALLED ON NULL INPUT (или если характеристика явно не задана), то метод всегда явно выполняется при вызове с любым набором аргументов.

Типизированные таблицы

В предыдущем подразделе уже упоминалась возможность определения типизированных таблиц, основанных на некотором структурном типе. Здесь мы приведем и поясним понятие иерархии типизированных таблиц и связь этой иерархии с иерархией структурных типов, а также обсудим соотношение понятие строки типизированной таблицы с понятием объекта в ООБД.

Определение типизированной таблицы

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

Далее, при определении типизированной таблицы можно объявить ее подтаблицей некоторой другой типизированной таблицы (имя супертаблицы указывается в разделе UNDER ). Супертаблица должна быть ассоциирована со структурным типом, являющимся непосредственным супертипом определяемой подтаблицы. Каждый столбец указанной супертаблицы наследуется подтаблицей; наследуются и характеристики столбцов супертаблицы – значения по умолчанию, ограничения целостности и т.д. Эти столбцы называются унаследованными столбцами подтаблицы, и они соответствуют атрибутам UDT подтаблицы, унаследованным от UDT супертаблицы. Кроме того, подтаблица будет содержать по одному столбцу для каждого собственного атрибута ассоциированного структурного типа. Такие столбцы подтаблицы называются заново определенными.

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

В определении типизированной таблицы разрешается указывать табличные ограничения целостности. Если определяемая таблица является подтаблицей некоторой супертаблицы, то в ней не допускается определение ограничения первичного ключа (PRIMARY KEY ). Однако, если определяется максимальная супертаблица, то в ее определении допускается спецификация PRIMARY KEY (с указанием одного или нескольких столбцов) или спецификация ограничения UNIQUE (с указанием одного или нескольких столбцов) в комбинации с указанием NOT NULL . В определении типизированной таблицы могут также содержаться спецификации ссылочных ограничений целостности. Ссылки (по значению) могут вести как на типизированную, так и на обычную таблицу.

В определении максимальной супертаблицы должна присутствовать спецификация “самоссылающегося” (self -referencing ) столбца, и самоссылающийся столбец, определенный в максимальной супертаблице, наследуется любой ее подтаблицей. Эта спецификация не может входить в определение подтаблицы. Семантика самоссылающихся столбцов обсуждается в этом подразделе ниже.

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

Ссылочные значения и REF -типы

Понятия ссылочных значений и ссылочных (REF ) типов являются по существу неразделимыми. В SQL :1999 ссылочный тип может использоваться в качестве типа данных столбцов обычных таблиц, атрибутов структурных типов и т.д. – словом, везде, где можно использовать другие типы данных SQL . Значения местоположений ссылочного типа всегда являются ссылочными значениями строк типизированных таблиц (т.е. значениями самоссылающихся столбцов этих строк).

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

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

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

Если для некоторого структурного типа выбран вариант пользовательской генерации ссылочных значений, то ответственность за поддержание уникальности таких значений лежит на пользователе. Конечно, ограничения PRIMARY KEY или UNIQUE , определенные на уровне максимальной супертаблицы семейства типизированных таблиц, могут гарантировать отсутствие в любой таблице этого семейства дублирующих ссылочных значений, но в SQL :1999 отсутствуют какие-либо средства, предотвращающие повторное использование ссылочных значений из удаленных строк в самоссылающихся столбцах новых строк.

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

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

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

Самоссылающиеся столбцы всегда имеют REF -тип. Конкретный REF -тип зависит от двух факторов:

структурного типа, ассоциированного с типизированной таблицей: REF -тип всегда связан с некоторым структурным типом;
от выбранного способа генерации ссылочных значений; эта информация задается в определении структурного типа и не присутствует в спецификации ссылочного типа.

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

В необязательном разделе указания области действия значений ссылочного типадолжно задаваться имя типизированной таблицы, ассоциированным структурным типом которой является referenced _type REF -типа, в спецификации которого содержится этот раздел. Ассоциированный структурный тип таблицы, на строки которой указывают значения REF -типа, должен быть в точности тем же, что и referenced _type этого REF -типа. Но можно объявить REF -тип, у которого referenced _type является ассоциированным структурным типом подтаблицы, хотя самоссылающийся столбец этой подтаблицы необходимо наследуется от максимальной супертаблицы семейства таблиц.

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

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

Если же указывается потребность в проверке, то каждый раз при сохранении значения в определяемом столбце система обращается к указанной таблице, чтобы убедиться в том, что в ней имеется строка, значение самоссылающегося столбца которой совпадает с сохраняемым ссылочным значением. Кроме того, в этом случае можно также указать ссылочное действие, которое должно выполняться при удалении строки, идентифицируемой ссылочным значением. Возможными ссылочными действиями являются RESTRICT , CASCADE , SET NULL и NO ACTION . Если ссылочное действие явно не указывается, по умолчанию принимается NO ACTION .

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

Выборка данных из типизированных таблиц

Приведем несколько примеров операций выборки данных из типизированных таблиц, а также операций обновления таких таблиц. Для этого сначала определим структурные типы EMP _ T , PROGRAMMER _ T и DEPT _ T , а также соответствующие типизированные таблицы (упрощенный вариант).

CREATE TYPE EMP_T AS (
EMP_NAME VARCHAR(20),
EMP_BDATE DATE,
EMP_SAL SALARY,
DEPT REF (DEPT) )
INSTANTIABLE
NOT FINAL
REF IS SYSTEM GENERATED
INSTANCE METHOD age ()
RETURNS DECIMAL (3,1)

CREATE TYPE PROGRAMMER_T UNDER EMP_T AS (
PROG_LANG VARCHAR (10) )
INSTANTIABLE
NOT FINAL

CREATE TYPE DEPT_T AS (
DEPT_NO INTEGER,
DEPT_NAME VARCHAR(200),
DEPT_MNG REF (EMP) )

INSTANTIABLE
NOT FINAL

CREATE TABLE EMP OF EMP_T
( REF IS DEPT_ID SYSTEM GENERATED,
DEPT WITH OPTIONS SCOPE DEPT )

CREATE TABLE PROGRAMMER OF PROGRAMMER_T UNDER EMP

CREATE TABLE DEPT OF DEPT_T

( REF IS EMP_ID SYSTEM GENERATED,
DEPT_MNG WITH OPTIONS SCOPE EMP )

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

Пример 3.1. Найти имена всех служащих, размер заработной платы которых меньше 20000.00.

SELECT EMP_NAME
FROM EMP
WHERE EMP_SAL < 20000.00

В соответствии с семантикой SQL :1999, при выполнении запроса из прим. 3.2 сначала будет произведена выборка имен служащих, удовлетворяющих условию, из таблицы EMP , затем – из таблицы PROGRAMMER , и эти промежуточные результаты будут скомбинированы в окончательный результат путем применения операции объединения ( UNION ). Но предположим, что нас интересуют только те служащие, получающие зарплату, меньшую 20000.00, которые не являются программистами (пример 3.2). Тогда можно применить формулировку запроса, в которой присутствует спецификация ONLY :

SELECT EMP_NAME
FROM ONLY ( EMP )
WHERE EMP_SAL < 20000.00

Естественно, в запросах к типизированным таблицам можно использовать ссылки.

Пример 3.3. Найти имена и названия отделов всех служащих, размер заработной платы которых меньше 20000.00.

SELECT EMP_NAME, DEPT -> DEPT_NAME
FROM EMP
WHERE EMP_SAL < 20000.00

В SQL :1999 операция “ -> ” называется операцией разыменования , но в обиходе можно считать ее операцией перехода по ссылке (в нашем примере DEPT ссылается на DEPT _ NAME ). Можно неформально трактовать ссылочные значения как указатели на строки типизированных таблиц.

Может показаться неожиданным, что запрос из прим. 3.3 выбирает значения из таблицы DEPT , хотя она даже не упоминается в разделе FROM этого запроса. Дело в том, что выполнение операции разыменования фактически приводит к выполнению соединения таблиц EMP и DEPT , делая “видимым” в запросе столбец DEPT _ NAME .

Конечно, в запросе допускаются многократные переходы по ссылкам, так что можно сформулировать следующий запрос:

Пример 3.4. Найти имена служащих и имена руководителей их отделов для служащих, получающих зарплату, меньшую 20000.00.

SELECT EMP_NAME, DEPT -> DEPT_MNG -> EMP_NAME
FROM EMP
WHERE EMP_SAL < 20000.00

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

Пример 3.5. Найти имя и возраст руководителя отдела 605.

SELECT DEPT_MNG -> EMP_NAME, DEPT_MNG -> age ()
FROM DEPT
WHERE DEPT_NO = 605

Наконец, имеется возможность полностью выбрать экземпляр структурного типа, идентифицируемый ссылочным значением (в SQL :1999 это называется разрешением ссылки – reference resolution ).

Пример 3.6. Получить полные данные о руководителе отдела 605.

SELECT DEREF ( DEPT_MNG )
FROM DEPT
WHERE DEPT_NO = 605

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

Операции обновления типизированных таблиц выполняются очевидным образом. Операция INSERT вставляет указанные строки в указанную таблицу. Операции DELETE и UPDATE удаляют или модифицируют строки в иерархии таблиц, корнем которой является указанная таблица, если в операции не содержится ONLY . Если же специфицировано ONLY , то удаляются или модифицируются только строки указанной таблицы.

Типизированные представления

Наряду с типизированными базовыми таблицами в SQL :1999 поддерживаются типизированные представления, иначе называемые представлениями, на которые можно ссылаться ( referenceable views ). Иногда такие представления также называют объектными представлениями, поскольку данные, видимые через представление, соответствуют строкам типизированных таблиц, поведение которых во многом похоже на поведение объектов в объектно-ориентированных системах. Между типизированными базовыми таблицами и типизированными представлениями имеется большое сходство, но есть и несколько отличий, связанных с врожденными различиями базовых таблиц и представлений.

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

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

Типизированное представление можно определить как подпредставление другого типизированного представления. В этом случае структурный тип, ассоциированный с определяемым представлением, должен являться непосредственным подтипом структурного типа, ассоциированного со специфицируемым в разделе UNDER суперпредставлением. Базисная таблица определяемого представления должна являться собственной подтаблицей или собственным подпредставлением – не обязательно непосредственным – базисной таблицы непосредственного суперпредставления определяемого представления.

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

[Назад] [Оглавление] [Вперед]