развивались в течение минимум полутора десятков лет, этот путь оказался самым удобным и простым. Не стоит и говорить о том, что это гораздо дешевле, чем начинать с нуля, а кроме того, такая стратегия позволяет использовать огромную базу инсталлированных реляционных систем, предоставшз их пользователям возможность плавного перехода на новые технологии, что выгодно как пользователям, так и производителям Вот каковы основные объектные расширения, уже имеющиеся в современных ОРБД:

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

Структурированные/абстрактные типы данных Реляционные типы данных атомарны и неделимы. Структурированные типы данных позволяют объединять отдельные элементы данных в высокоуровневые структуры, интерпретируемые как самостоятельные сущности.

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

Таблицы в таблицах. Столбцы реляционных баз данных содержат отдельные значения, тогда как в ОРБД столбцы могут содержать такие сложные элементы данных, как структуры или даже целые таблицы. Благодаря этому таблицы могут представлять иерархии объектов.

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

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

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

Поддержка больших объектов

Реляционные СУБД традиционно ориентировались на обработку деловых данных. Единицами хранимой и обрабатываемой информации в них были элементы данных, представляющие денежные суммы, имена, адреса, дату/время и т п. Эти типы данных относительно просты, и для их хранения требуется не много места, от нескольких байтов для целых чисел, представляющих, например, количество заказанных единиц товара или количество товара на складе, до нескольких десятков

байтов для таких символьных данных, как имя клиента, адрес служащего или описание товара. Реляционные СУБД оптимизированы для управления записями, содержащими до нескольких десятков столбцов подобных типов. Технологии, используемые ими для управления дисковой памятью и индексации данных, разработаны с расчетом на то, что записи имеют размеры от нескольких сотен до нескольких тысяч байтов. Программы, которые сохраняют и извлекают подобные данные, легко могут держать в памяти десятки и сотни таких записей, пользуясь буферами разумного размера. Технологии построчной обработки результатов реляционных запросов прекрасно справляются со своей задачей.

Однако многие современные типы данных обладают соверщенно иными характеристиками. Для хранения графического изображения, имеющего высокое разрещение, могут потребоваться сотни и тысячи байтов. Документы текстовых процессоров, такие как контракты или текст этой книги, могут занимать еще больше места. В качестве примеров можно также привести HTML-текст, определяющий содержимое Web-страницы, и файл PostScript с параметрами изображения, подготовленного для вывода на печать. Даже относительно короткая звукозапись высокого качества может занимать миллионы байтов, а для хранения видеоклипов могут требоваться сотни мегабайтов и даже гигабайты памяти. При этом значение мультимедийных приложений все возрастает, пользователи хотят хранить мультимедийную информацию в базах данных и управлять ею наравне с остальными данными. Поэтому именно возможность эффективного управления большими объектами , часто называемыми большими двоичными объектами (binary large objects - BLOB), была одним из первых рекламируемых преимуществ ОРБД.

Большие объекты в реляционной модели

Вначале для поддержки больших объектов реляционные базы данных просто поль-зовадись возможностями операционной системы и ее файловой подсистемы. Каждый большой двоичный объект хранился в отдельном файле, а имя этого файла пометалось в таблицу в виде символьного значения, интерпретируемого как указатель на файл. Когда приложению требовалось получить содержимое большого двоичного объекта, связанного с одной из строк таблицы, оно считьшало имя файла и извлекало из этого файла двоичные данные. За чтение и загшсь файла полностью отвечало приложение. Этот подход работал, но был чреват ошибками и требовал от программиста знания интерфейсов как самой СУБД, так и файловой системы. Недостаточность интеграции между содержимым объекта типа BLOB и базой данных была совершенно очевидна. Например, нельзя было попросить СУБД сравнить два больших двоичных объекта, чтобы выяснить, иде;нтично ли их содержимое, и СУБД не обеспечивала для таких данных даже элементарных возможностей текстового поиска.

Сегодня большинство ведущих СУБД масштаба предприятия обеспечивает непосредственную поддержку одного или нескольких типов больших объектов. Вы можете определить столбец для хранения такого объекта и включать его в SQL-snpocbi. Конечно, на операции с большими объектами все же накладываются некоторые ограничения - например, они не могут использоваться для объединения таблиц или группировки строк.

Sybase Adaptive Server поддерживает два типа больших объектов. В столбцах типа TEXT может храниться до двух миллиардов байтов текста переменной длины. Имеются некоторые средства поиска содержимого таких столбцов (например, оператор LIKE). Второй тип, IMAGE, может вмещать до двух миллиардов байтов произвольных двоичных данных переменой длины. Microsoft SQL Server в дополнение к этим двум

типам поддерживает тип ntext, позволяющий хранитьдо миллиарда символов любых национальных языков в двухбайтовой кодировке.

СУБД DB2 компании IBM поддерживает сходный набор типов данных. В ее столбцах типа clob (character large object) может храниться до двух миллиардов байтов текста. Тип данных dbclob (double-byte character large object) позволяет хранить до миллиарда символов в двухбайтовой кодировке. А тип blob (binary large object) служит для хранения до двух миллиардов байтов двоичных данных.

СУБД Oracle исторически предоставляла два типа больших объектов. Тип данных long вмещал до двух миллиардов байтов текстовых данных, а long raw - столько же двоичных данных. Использование любого из этих типов данных ограничивалось одним столбцом таблицы. С выходом OracleS поддержка больших объектов была существенно расширена:

тип blob позволяет хранить до 4 Гб двоичных данных;

тип clob позволяет хранить до 4 Гб однобайтовых символьных данных;

тип nclob позволяет хранить многобайтовые символьные данные;

тип bfile служит для хранения двоичных данных во внешних (по отношению к базе данных) файлах.

Типы данных blob, clob и nclob широко используются в различных операциях Oracle, в том числе в транзаишях. Что касается данных типа bfile, то управление ими осуществляется посредством хранящихся в базе данных указателей на внешние файлы операционной системы. В транзакциях они использоваться не могут. Для управления данными типа blob, clob и nclob из хранимых процедур используется набор специальных функций PL/SQL, о которых рассказьшается в следующем параграфе.

Похожий набор типов данных поддерживается и в Informix Universal Server В этой СУБД большие объекты подразделяются на простые и сложные :

тип byte служит для хранения простых объектов с двоичными данными;

тип text служит для хранения простых объектов с текстовыми данными;

тип blob служит для хранения сложных объектов с двоичными данными;

тип clob служит для хранения сложных объектов с текстовыми данными.

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

Специализированная обработка больших объектов

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

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