ROW с John, J, Jones.NAM£ TYPE, ROW I197 Rose St., Chicago, 4L,

ROWC12345, 6789) : :post jype) : :addr type) ;

Первый оператор : : приводит созданную конструктором запись (состоящую из трех полей) к 1ипу name type, чтобы ее можно было присвоить столбцу name. Остальные два оператора делают то же самое для формирования значения столбца address.

В Oracle принят несколько иной подход к конструированию составных элементов данных и их вставке в столбцы АТД. Когда вы создаете АТД (с помощью инструкции create type), Oracle автоматически определяет метод-конструктор для этого типа. Конструктор можно представить себе как функцию, которая принимает в качестве аргументов отдельные значения атрибутов, объединяет их и возвращает значение соответствующего абстрактного типа. Именованные конструкторы используются в предложении values инструкции insert. Вот как это выглядит на примере таблицы personnel:

insert into personnel

values (1234,

name type{John, J, Jones), ADDR TYPE(197 Rose St., Chicago, il, post type (1234 5, 6789)));

Конструкторы name type, addr type и post type выполняют ту же функцию, что и конструктор row в Informix, плюс осуществляют приведение типов, необходимое для занесения данных в соответствующие столбцы.

Наследование

Поддержка абстрактных типов данных составляет основу объектно-ориентированных расширений реляционной модели. Другой важной составляющей объектной модели является наследование. Путем наследования новый класс объектов может быть определен как конкретная разновидность существующего класса и наследовать его атрибуты и поведение.

На рис. 23.2 представлен пример того, как применяется наследование при построении модели, описывающей иерархию служащих компании. Все служащие являются членами класса personnel и имеют сгавдартные атрибуты этого класса: идентификатор, имя и адрес. Некоторые служащие являются коммерческими представителями и имеют дополнительные атрибуты: плановый объем продаж и идентификатор менеджера по пропажам. Другие служащие являются инженерами и у них иной набор атрибутов- ученая степень, текущий проект, над которым они работают, и т.п. Для каждой из этих категорий служащих определен собственный класс, который является подклассом personnel. Подкласс наследует все характеристики родительского класса (для инженеров и коммерческих представителей должны храниться обычные сведения, связанные с любым служащим). В то же время подкласс может иметь и дополнительные атрибуты, уникальные для его категории объектов. На рис. 23.2 иерархия классов служащих имеет три уровня: инженеры в ней подразделяются на технологов (тип тесн type), разработчиков (тип engr type) и руководителей (тип mgr type).

/коммерческие ( представители \(SALES TYPE)

Служащие (PERS TYPE)

Технологи (TECH TYPE)

Инженеры (ENGR TYPE)

Руководители \ (MGR TYPE) )

Рис. 23.2. Иерархия служащих компании

Механизм наследования в Informix Universal Server обеспечивает очень простой способ определения абстрактных типов, соответствующих иерархии служащих, представленной на рис. 23.2. Предположим, что в базе данных Informix уже создан тип perstype, определение которого мы приводили ранее в этой главе, и на его основе создана типизированная таблица personnel. Тогда, используя механизм наследования, можно создать АТД для других классов нащей иерархии:

АТД, который мы определили для технологов (tech type), является подтипом (подклассом) АТД для инженеров (engr type), поэтому он наследует все поля этого АТД плюс все поля АТД для служащих (pers type) плюс имеет собственные дополнительные поля. В общем случае подтипом некоторого АТД называется тип данных, который расположен ниже в иерархии и наследует все его поля. В определении подтипа должно присутствовать предложение under с указанием наследуемого типа.

Теперь, определив иерархию типов данных, можно легко создать на их основе типизированные таблицы:

CREATE TABLE ENGINEERS

OF TYPE ENGR TYPE;

CREATE TABLE TECHNICIANS

OF TYPE TECH TYPE;

CREATE TABLE MANAGERS

OF TYPE MGR TYPE;

CREATE TABLE REPS

OF TYPE SALES TYPE;

Как видите, с использованием такой иерархии вся сложность модели данных переносится на определения абстрактных типов, а определения таблиц становятся предельно простыми. Разумеется, все остальные характеристики таблиц могут и должны быть заданы в определениях таблиц. Например, таблица reps содержит столбец, который является внешним ключом для таблицы personnel, поэтому в ее определение должно быть включено предложение foreign key:

CREATE TABLE REPS

OF TYPE SALES TYPE

FOREIGN KEY (SLS MGR)

REFERENCES PERSONNEL(EMPL NUM);

Хотя наследование создает связь между структурами таблиц, основанных на одном АТД, однако в отношении самих данных таблицы остаются независимыми. Строка, добавленная в таблицу technicians, не появится автоматически ни в таблице engineers, ни в таблице personnel. Каждая из этих таблиц содержит собственные данные, которые добавляются в нее отдельно. Тем не менее, в Informix можно связать и данные таблиц, для чего в этой СУБД определен еще один тип наследования - табличное наследование, превращающее таблицы в нечто очень близкое к классам объектов.

Табличное наследование - реализация классов

в Informix Universal Server имеется интересная возможность, отдаляющая структуру таблиц базы данных от традиционной реляционной модели и приближающая ее к концепции класса объектов, - это табличное наследование. Посредством данной методики можно создать иерархию типизированных таблиц (классов), подобную изображенной на рис. 23.3. Хотя эти таблицы по-прежнему базируются на созданной нами иерархии АТД, они сами связаны в параллельную иерархию.

Вот набор инструкций create table, создающих эту иерархию:

CREATE TABLE ENGINEERS OF TYPE ENGR TYPE UNDER PERSONNEL; CREATE TABLE TECHNICIANS OF TYPE TECH TYPE UNDER ENGINEERS; CREATE TABLE MANAGERS OF TYPE MGR TYPE UNDER ENGINEERS; CREATE TABLE REPS

OF TYPE SALES TYPE UNDER PERSONNEL;