Предположим, что в базе данных имеется еше одна таблица, managers, в которой есть столбец name точно такой же структуры, как и в таблице personnel. Тогда следующий запрос возврашает идентификаторы служащих, которые являются менеджерами.

SELECT EMPL NUM

FROM PERSONNEL, MANAGERS WHERE PERSONNEL.NAME = MANAGERS.NAME;

В первом из этих двух запросов из столбца name извлекаются значения отдельных полей. Второй запрос демонстрирует ситуацию, когда удобнее оперировать этим же столбцом как записью (всеми тремя полями) - мы использовали этот способ для сравнения данных. Очевидно, что гораздо удобнее попросить СУБД сравнить два столбца целиком, вместо того чтобы сравнивать все их поля по отдельности Эти примеры демонстрируют преимущества типа row, обеспечивающего доступ к полям на любом уровне иерархии

При добавлении данных в таблицу столбцы типа row требуют специальной обработки Поскольку в таблице personnel три столбца, в предложении values предназначенной для нее инструкции insert должно быть три элемента. Для столбцов типа row используется специальный конструктор записи, который фуппирует отдельные значения полей, формируя из них корректную запись. Вот пример инструкции insert для таблицы personnel, иллюстрируюший применение конструктора:

INSERT INTO PERSONNEL VALUES (1234,

ROW С John, J, Jones), ROW(197 Rose St. , Chicago, IL, ROW(12345, 6789)));

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

Использование данных типа row в таблицах Informix имеет один недостаток: структура записи определяется для каждого столбца в отдельности. Если же в двух таблицах понадобятся столбцы одинакового типа, придется определять его дважды. Это противоречит одному из ключевых принципов объектно-ориентированного проектирования - повторному использованию определений объектов. Вместо того чтобы определять структуру каждого конкретного объекта (в данном случае столбца каждой из двух таблиц), разработчик базы данных должен иметь возможность сначала сформировать тип записи, а потом использовать его при последующем создании столбцов. СУБД Informix Universal Server обеспечивает такую возможность, позволяя создавать именованные записи. (Записи, о которых рассказывалось в предьщущем парафафе, были безымянными.)

Именованная запись создается с помощью инструкции create row type:

CREATE ROW TYPE NAME TYPE ( F NAME VARCHAR (15) , M INIT CHAR(l) , L NAME VARCHAR(20));

CREATE ROW TYPE POST TYPE ( MAIN INTEGER, SFX INTEGER);

CREATE ROW TYPE ADDR TYPE (

STREET VARCHAR(35),

CITY VARCHAR(15),

STATE CHAR(2),

POSTCODE POST TYPE);

Обратите внимание на то, что в определении именованной записи может использоваться другой, ранее созданный тип записи. Например, последнее из полей записи addr type имеет тип post type. Теперь все три созданных нами типа могут использоваться не только в определении таблицы personnel, но и, самое главное, в определении любых других таблиц, где нужны столбцы для хранения адресов, имен и почтовых индексов. Абстрактные типы данных очень помогают унифицировать структуру информации в ОРБД. Вот как выглядит новое определение таблицы personnel с использованием созданных выше абстрактных типов данных:

CREATE TABLE PERSONNEL ( EMPL NUM INTEGER,

NAME NAME TYPE, ADDRESS ADDR TYPE);

Ha рис. 23.1 приведен пример такой таблицы, отражающий иерархическую структуру ее столбцов.

Та6ли!(а PFRSONNFI

Рис. 23. J. Использование абстрактных типов данных в таблице PERSONNEL

Oracle также поддерживает абстрактные типы данных, но использует несколько иной синтаксис Вот как выглядит в Oracle инструкция create type, создающая такие же типы данных, что в предыдущем примере:

CREATE TYPE NAME TYPE AS OBJECT ( F NAME VARCHAR(15), M INIT CHAR(l), L NAME VARCHAR(20));

CREATE TYPE POST TYPE AS OBJECT ( MAIN INTEGER, SFX INTEGER);

CREATE TYPE ADDR TYPE AS OBJECT ( STREET VARCHAR(35), CITY VARCHAR(15), STATE CHAR(2), POSTCODE POST TYPE);

в Oracle абстрактные типы данных называются объектами. Фактически, определенный таким образом тип данных функционирует подобно классу объектов, если придерживаться традиционной объектно-ориентированной терминологии. Распространяя эту терминологию и на состав объектов, Oracle называет отделънъ1е компоненты АТД (соответствующие полям в Informix) атрибутами Например, у типа данных addr type четыре атрибута. Последний из них, postcode, сам является абстрактным типом данньк.

И в Oracle, и в Informix для доступа к отдельным элементам АТД применяется точечная нотация. Например, поле main почтового индекса в таблице personnel идентифицируется так:

personnel.address.postcode.main

Если бы таблица принадлежала другому пользователю, например Сэму, полное имя атрибута было бы еще длиннее:

sam.personnel.address.postcode.main

Informix допускает еще более щирокое использование абстрактных типов данных - они могут служить шаблонами не только для отдельных столбцов, но и для целых таблиц. Например, создав такой АТД:

create row type PERS TYPE ( empl num integer,

name NAME TYPE, address ADDR TYPE);

МОЖНО определить таблицу personnel следующим образом:

create table personnel of type pers type;

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

Использование абстрактных типов данных

к сожалению, синтаксис обновления и добавления данных структурированных типов достаточно сложен. С безымянными записями в Informix Universal Server особых сложностей не возникает. Значения, записываемые в столбец типа row, должны просто иметь соответствующее количество полей правильных типов. Для их формирования используется конструктор записи, который объединяет отдельные поля в единую запись.

К именованным типам данных предъявляются более строгие требования. Данные, которые записываются в столбец АТД, должны иметь в точности тот же тип. Для этого в инструкции insert или update необходимо вьшолнить явное приведение типа сконструированной записи к типу данных столбца. Вот как это выглядит для нашей таблицы personnel:

insert into personnel values (1234,