Наследование типов объектов в Oracle

В.В.Пржиялковский,
ВЦ РАН, Interface Ltd

Если бы мне принадлежал весь этот край, я бы
отдал его за то, чтобы сама королева Англии лежала в моих объятиях.
Carmina Burana, если верить Карлу Орфу

Введение

Наследование типов объектов - важнейшее свойство объектного подхода. В Oracle оно появилось с опозданием "на 1,2 версии", то есть в версии 9.2, а не сразу в 8.0. Но в конце концов его реализация оказалась достаточно полной. Это единичное (не множественное) наследование, и некоторые подробности его исполнения в Oracle иллюстрируются на примере ниже.

Типы в поликлинике

Предположим, имеется поликлиника, в здании которой могут находиться сотрудники и посетители. У тех и других есть для учета имена, но у сотрудников к тому же табельные номера, а у посетителей - номер регистрационной карты. Классическую ситуацию "типы-подтипы" можно в Oracle разрешить объектными средствами, например так:

CREATE TYPE person_typ AS OBJECT ( name VARCHAR2(30) ) 
NOT FINAL
/

CREATE TYPE employee_typ UNDER person_typ ( empid NUMBER ) 
NOT FINAL
/

CREATE TYPE visitor_typ UNDER person_typ ( regid NUMBER ) 
NOT FINAL
/

Если бы фраза NOT FINAL в определении PERSON_TYP отсутствовала, не удалось бы создать подтипы EMPLOYEE_TYP и VISITOR_TYP. У подтипов же эта фраза оставлена на всякий случай, который сейчас представится. Например, пусть нужно среди сотрудников отличать врачей от обслуживающего персонала:

CREATE TYPE doctor_typ UNDER employee_typ 
  ( speciality VARCHAR2(30)
  , phone VARCHAR2(7) ) 
/

CREATE TYPE stuff_typ UNDER employee_typ ( job VARCHAR2(30) ) 
/

Данные о взаимозависимостях типов можно посмотреть в USER_TYPES:

SELECT supertype_name, type_name 
FROM user_types 
ORDER BY 1, 2;

Люди у проходной

И посетители, и сотрудники проходят через проходную, где отмечаются в таблице CHECKPOINT:

CREATE TYPE checkpoint_typ AS OBJECT
   ( entrytime DATE
   , person person_typ )
/

CREATE TABLE checkpoint OF checkpoint_typ;

Вот как они могут "проходить":

INSERT INTO checkpoint VALUES
   ( SYSDATE
   , employee_typ ( 'Scott', 1111 ) );

INSERT INTO checkpoint VALUES
   ( SYSDATE
   , visitor_typ ( 'Adams', 333 ) );

INSERT INTO checkpoint VALUES
   ( SYSDATE
   , doctor_typ ( 'Smith', 2222, 'Therapeutist', '7778899' ) );

INSERT INTO checkpoint VALUES
   ( SYSDATE
   , stuff_typ ( 'Alice', 4444, 'Office-cleaner' ) );

Можно проверить, кто прошел:

SELECT * FROM checkpoint;

Обратите внимание на использованное упрощение: никто не запретил пройти через проходную просто сотруднику (Scott), то есть не врачу и не обслуживающему персоналу. Желание запретить такого рода вставки в таблицу во многих случаях возникает вполне законно. Для запрета следовало было описать тип EMPLOYEE_TYP (а заодно и PERSON_TYP) как "абстрактный" (это термин объектно-ориентированного подхода):

CREATE TYPE employee_typ UNDER person_typ ( empid NUMBER ) 
NOT FINAL
NOT INSTANTIABLE
/

Просмотр входивших

Пример просмотра (SELECT * …) уже приводился. Однако для получения данных в табличном виде запрос придется усложнить. Проблема, которую придется учитывать в таком запросе - наличие в поле PERSON разных строк одной и той же таблицы значений разных типов. Бороться с проблемой позволяет специальное расширение SQL:

SELECT TREAT (person AS person_typ).name FROM checkpoint;

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

Обратите внимание, что столбец для выдачи можно формировать, трактуя поле PERSON отправной таблицы и как, например, EMPLOYEE_TYP, несмотря на то, что в CHECKPOINT имеются и строки другого типа:

SELECT TREAT (person AS employee_typ).empid FROM checkpoint;

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

Отбор входивших персон конкретного типа можно сформулировать во фразе WHERE, для которой придуманы другие специальные конструкции:

SELECT * FROM checkpoint WHERE person IS OF (employee_typ);

Обратите внимание, что выдались строки с данными типа EMPLOYEE_TYP и всех его подтипов. Если же строки с данными подтипов выдавать не нужно, можно указать следующее:

SELECT * FROM checkpoint WHERE person IS OF (ONLY employee_typ);

Вот как можно объединить два приведенные выше варианта отбора - строк по типам во фразе WHERE и столбцов с атрибутами, возможно других, типов:

SELECT 
      SYSDATE, 
      c.person.name, 
      TREAT (c.person AS doctor_typ).phone  
FROM checkpoint c 
WHERE person IS OF (employee_typ);

Обратите внимание, что по синтаксису, принятом в Oracle написать во фразе SELECT выдачу C.PERSON.PHONE, наподобие C.PERSON.NAME, не получится. Не получится даже написать SELECT c.person.empid …, несмотря на то, что фразой WHERE отбираются сотрудники, которые имеют табельный номер EMPID. Для обращения к свойствам подтипов вам все равно придется написать SELECT TREAT (c.person AS doctor_typ).empid …, указав явно подтип, где возникло это свойство. Для свойства NAME приведения типа не требуется, так как оно задано для ("основного") типа столбца PERSONS, то есть PERSONS_TYP, а не для подтипов PERSONS_TYP.

Плата за свободный проход или эволюция типов

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

Выше упоминалась содержательно некорректная возможность добавить в таблицу CHECKPOINT сотрудника Scott, для которого не указано, то ли он доктор, то ли принадлежит обслуживающему персоналу. Говорилось, как можно исправить ситуацию, придав типу EMPLOYEE_TYP свойство NOT INSTANTIABLE. Если мы захотим сделать это сейчас, то у нас ничего не выйдет:

SQL> ALTER TYPE employee_typ NOT INSTANTIABLE;
ALTER TYPE employee_typ NOT INSTANTIABLE
*
ERROR at line 1:
ORA-22327: cannot change a type to NOT INSTANTIABLE if 
it has dependent tables

К сожалению дело не в том, что в таблице CHECKPOINT отмечен сотрудник, противоречащий изменению свойства типа EMPLOYEE_TYP. Сообщение об ошибке говорит, что изменение свойства типа INSTANTIABLE на NOT INSTANTIABLE возможно лишь при отсутствии таблиц с полями этого типа. Увы, но нам придется пожертвовать таблицей:

DROP TABLE CHECKPOINT;

ALTER TYPE employee_typ NOT INSTANTIABLE CASCADE;

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

К счастью обратное изменение свойства типа, с NOT INSTANTIABLE на INSTANTIABLE, не потребует никаких жертв и срабатывает всегда.

В жизни сложнее

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