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

Запись больших объектов в базу данных. Поскольку размер больших объектов может достигать десятков и сотен мегабайтов, программы не могут хранить их в своих буферах целиком. Они обрабатывают данные типа blob по частям (например, отдельные страницы текстового документа или отдельные кадры видеоклипа). Однако встроенный SQL и традиционные программные интерфейсы SQL осуществляют обработку наборов записей, занося в таблицу с помощью инструкций insert и update все поля записи за один раз. Для записи данных в столбец типа blob по частям используются специальные технологии, позволяющие многократно вызывать одну и ту же API-функцию для одного столбца.

Ш Извлечение больших объектов из базы данных. Здесь проблема та же, что и в случае с их записью, только наоборот. Встроенный SQL и традиционные программные интерфейсы SQL поддерживают только инструкции select и fetch, извлекающие данные из всех полей записи за один раз. Однако поскольку объект типа blob может иметь размер в десятки и сотни мегабайтов, большинство программ не могут сохранить его в своем буфере целиком. Поэтому разработаны специальные технологии для извлечения таких объектов по частям, чтобы приложение могло их обрабатывать.

Протоколирование транзакций. Для поддержки транзакций большинство СУБД ведет специальные журналы, куда записываются копии данных до и после модификации. Однако из-за размера объектов типа blob их запись в журнал транзакций может сильно тормозить всю работу. По этой причине многие СУБД не протоколируют изменения больших объектов или же позволяют включать и отключать режим протоколирования.

В некоторых СУБД этот вопрос решается с помощью дополнительных API-функций, специально предназначенньгх для управления большими объектами. Они предоставляют приложениям произвольный доступ к отдельным сегментам этих объектов. Например, в OracleS можно извлекать и записывать фрагменты объектов типа lob (символьных и двоичных) в хранимых процедурах, написанных на PL/SQL. Подобные возможности предоставляют и другие объектно-реляционные СУБД, например Informix Universal Server

Когда хранимая процедура Oracle извлекает из таблицы объект типа lob, Oracle на самом деле возвращает не его содержимое, а локатор lob (в объектной терминологии - дескриптор). Локатор используется совместно с набором из девяти специальных функций, с помощью которых хранимая процедура может манипулировать данными, хранящимися в столбце типа lob. Вот краткое описание этих функций:

dbms lob, read (локатор, длина, смеш,ение, буфер) - извлекает в буфер PL/SQL указанное количество байтов/символов из идентифицируемого локатором большого объекта, начиная с заданного смещения;

dbms lob.write (локатор, длина, смещение, буфер) - записывает находящееся в буфере PL/SQL указанное количество байтов/символов в идентифицируемый локатором большой объект, начиная с заданного смещения;

dbms lob.append (локатор!, локатор!) - добавляет все содержимое большого объекта, идентифицируемого вторым локатором, в конец большого объекта, идентифицируемого первым локатором;

dbms lob.erase (локатор, длина, смещение) - удаляет указанное количество байтов/символов из большого объекта, идентифицируемого локатором, начиная с заданного смещения; для символьных объектов на место удаленных данных записываются пробелы, а для двоичных объектов - нули;

dbms lob.copy {локатор!, локатор2, длина, смещение!, смещение) - копирует указанное количество байтов/символов большого объекта, идентифицируемого вторым локатором, начиная со второго смешения, в большой объект, идентифицируемый первым локатором, начиная с первого смещения;

dbms lob. trim {локатор, длина) - усекает большой объект, идентифицируемый локагором, до заданной длины (в байтах/символах);

dbms lob.substr {локатор, длина, смещение) - возвращает в виде текстовой строки указанное количество байтов/символов из большого объекта, идентифицируемого локатором, начиная с заданного смещения;

dbms lob. getlength {локатор) - возвращает в виде целого числа длину (в байтах/символах) большого объекта, идентифицируемого локатором;

dbms lob.compare {локатор], локатор2, длина, смещение], смещение2) - сравнивает указанное количество байтов/символов большого объекта, идентифицируемого первым локатором, начиная с первого смещения, и большого объекта, идентифицируемого вторым локатором, начиная со второго смещения; возвращает ноль, если заданные фрагменты объектов одинаковы, и ненулевое значение в противном случае;

dbms lob. instr {локатор, щаблон, смещение, /) - возвращает в виде целого значения позицию i-ro вхождения шаблона в большой объект, идентифицируемый локатором, начиная с заданного смещения.

Oracle накладьшает еще одно ограничение на обновление и модификацию больших объектов, выполняемые посредством описанных функций. Поскольку большие объекты чересчур громоздки, чтобы участвовать в транзакциях, Oracle обычно не блокирует их при выборке строки таблицы приложением или хранимой процедурой PL/SQL. Чтобы обновить большой объект, его сначала нужно явно заблокировать. Для этого в инструкцию select, возвращающую локатор lob, включается предложение for update. Вот фрагмент хранимой процедуры PL/SQL, которая извлекает из таблицы большой объект, содержащий текстовый документ, и обновляет 100 символов этого документа:

declare

lob CLOB;

textbuf varchar(255);

begin

/* Помещаем в буфер текст, подлежащий вставке */

/* Получаем локатор большого объекта и блокируем

этот объект для обновления */ select document lob into lob from documents where document id = 34218 for update;

/* Записываем в объект новые 100 байтов текста */ dbms lob.write(lob, 100, 500, textbuf);

commit; end;

Абстрактные (структурированные) типы данных

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

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

В Informix Universal Server для поддержки АТД используется концепция записи (тип данных row). Запись можно рассматривать как структурированный набор элементов, называемых полями. Ниже приведена инстуэукция create table, создающая таблицу personnel, В которой ДЛЯ хранения имени и адреса используются вложенные записи:

CREATE TABLE PERSONNEL ( EMPL NUM INTEGER, NAME ROW(

F NAME VARCHAR(15), M INIT CHAR(l) , L NAME VARCHAR(20)) , ADDRESS ROW(

STREET VARCHAR(35), CITY VARCHAR(15), STATE CHAR(2), POSTCODE ROW(

MAIN INTEGER, SFX INTEGER)));

В этой таблице три столбца. Первый, empl num, содержит целые числа. Следующие два, name и address, содержат записи, на чго указывает ключевое слово row, за которым в скобках следует список полей. Записи в столбце name состоят из трех полей, а в столбце address - из четырех. Последнее из полей столбца address само является записью, состоящей из двух полей. Таким образом, в нашем простом примере создается двухуровневая иерархия, однако глубина иерархии полей может быть (и часто бьшает) большей.

Для доступа к отдельным полям столбца используется точечная нотация, такая же, как при записи полных имен столбцов. Вот пример инструкции select, извлекающей идентификаторы, имена и фамилии служащих с заданным почтовым ш-щексом:

SELECT EMPL NUM, NAME.F NAME, NAME.L NAME HROM PERSONNEL WHERE ADDRESS. POSTCODE. MAIN = Ч2345;