14 rows selected.

Это существенно отличается от того, что выдает команда describe. Оказывается, в этой таблице 14 столбцов, а не 4. Они описаны ниже.

SYS NC OID$. Это сгенерированный системой идентификатор объекта для таблицы. Это уникальный столбец типа RAW(16). Для него установлено ограничение уникальности - по нему создан соответствующий уникальный индекс.

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

tkyte@TKYTE816> select sys nc rowinfo$ from people;

SYS NC RONFO$(HAME, DOB, HOME ADSS (CITY, STREET, STATE, ZIP),...

PERSON TYPE(Tom, 45-MAR-65, ADDRESSJTYPE(Leesburg , 4234 Main Street, Va, 20175), ADDRESS TYPE(Reston, 4910 Oracle Way, Va, 20190))

NAME, DOB. Это скалярные атрибуты нашей объектной таблицы. Они, как и можно было предположить, хранятся как обычные столбцы.

HOME ADDRESS, WORK ADDRESS. Это тоже магические функции - они

возвращают набор столбцов в виде единого объекта. Места они не занимают, за исключением признака NULL или NOT NULL для столбца.

SYS NCnnnnn$. Это скалярные реализации встроенных объектных типов. Поскольку тип PERSONJTYPE содержит встроенный тип ADDRESS TYPE, серверу Oracle необходимо место для хранения его атрибутов в виде столбцов соответствующего типа. Сгенерированные системой имена необходимы, поскольку имена столбцов должны быть уникальными, а ничто не мешает использовать один и тот же объектный тип несколько раз, как в нашем примере. Если бы имена не генерировались, столбец ZIP, например, был бы повторен дважды.

Итак, как и в случае вложенных таблиц, за кулисами происходит много чего. Добавлен фиктивный первичный ключ длиной 16 байт, автоматически созданы виртуальные столбцы и индекс. Можно изменить стандартный идентификатор объекта, как будет показано ниже. Сначала давайте рассмотри полный текст подробного оператора SQL, генерирующего нашу таблицу. И в этот раз он сгенерирован с помощью пары утилит ЕХР/IMP:

CREATE TABLE TKYTE . PEOPLE

OF PERSON TYPE OID 36101E4C6B7E4F7E96A8A6662518965C

OIDINDEX (PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 131072 NEXT 131072

MINEXTENTS 1 MAXEXTENTS 4096

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

BUFFER POOL DEFAULT)

TABLESPACE USERS )

PCTFREE 10 PCTUSED 40

INITRANS 1 MAXTRANS 255

LOGGING STORAGE(INITIAL 131072 NEXT 131072

MINEXTENTS 1 MAXEXTENTS 4096

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

BUFFER POOL DEFAULT) TABLESPACE USERS

ALTER TABLE TKYTE . PEOPLE MODIFY

( SYS NC OID$ DEFAULT SYS OP GUID () ) /

Это дает чуть больше информации о том, что происходит на самом деле. Теперь мы четко видим конструкцию OIDINDEX и то, что она сс1лается на столбец SYS NC OID$. Это скрытый первичный ключ таблицы. Функция SYS OP GUID совпадает с функцией SYS GUID. Обе они возвращают глобально уникальный идентификатор, представленный в поле типа RAW(16).

Синтаксис OID <большое шестнадцатиричное число> не описан в документации СУБД Oracle. Он просто гарантирует, что в ходе экспорта и последующего импорта базовый тип PERSONTYPE фактически - один и тот же. Это предотвращает возникновение ошибок если:

создать таблицу PEOPLE;

экспортировать ее;

удалить базовый тип PERSON TYPE;

создать новый тип PERSON TYPE с другими атрибутами;

импортировать старые данные таблицы PEOPLE.

Очевидно, экспортированные данные не могут быть импортированы в новую структуру, поскольку они ей не соответствуют. Эта проверка предотвращает возникновение подобной ситуации. Об особенностях экспорта и импорта объектных таблиц см. в главе 8.

Если помните, я упоминал, что можно изменить объектный идентификатор, присваиваемый экземпляру объекта. Вместо автоматически сгенерированного системой фиктивного первичного ключа можно использовать естественный первичный ключ объекта. Сначала это может показаться бесполезным - столбец SYS NC OID$ все равно входит в определение объекта в таблице словаря SYS.COL$ и, казалось бы, для него требуется больше пространства, чем для сгенерированного системой столбца. Но и в этом

случае происходит чудо . Столбец SYS NC OID$ для объектной таблицы, основанный на первичном ключе, а не сгенерированный системой, является виртуальным и места на диске не занимает. Вот пример, демонстрирующий, что происходит в словаре данных, и то, что физического пространства столбец SYS NC OID$ не занимает. Начнем с анализа таблицы с идентификатором объекта, сгенерированным системой:

TABLE TKYTE . PEOPLE

tkyte@TKYTE816> CREATE

2 OF PERSON TYPE

Table created.

tkyte@TKYTE816> select name, typef, segcollength

2 3 4 5 6 7

NAME

from sys.col$ where obj# = (select object id

from user objects where object name = and name like SYS\ NC\ % escape \

PEOPLE)

TYPE#

SEGCOLLENGTH

SYS NC OID$ SYS NC ROWINFO$

23 121

16 1

tkyte@TKYTE816> insert into people(name) 2 select rownum from all objects;

21765 rows created.

tkyte@TKYTE816> analyze table people compute statistics; Table analyzed.

tkyte@TKYTE816> select table name, avg row len from user object tables; TABLE NAME AVG ROW LEN

PEOPLE

Итак, как видите, средняя длина строки составляет 25 байт, 16 байт занимает столбец SYS NC OID$ и 9 байт - столбец NAME. Теперь давайте создадим такую же таблицу, но используем первичный ключ, столбец NAME, в качестве идентификатора объек-

tkyte@TKYTE816> CREATE TABLE TKYTE . PEOPLE

2 OF PERSON TYPE

3 (constraint people pk primary key (name))

4 object identifier is PRIMARY KEY

Table created.

tkyte@TKYTE816> select name, type#, segcollength

2 from sys.col$

3 where obj# = (select object id