Анатомия объектно-реляционных баз данных

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

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

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

Другим требованием современных приложений к базам данных является не только хранение данных, но также запись и применение к данным определенных деловых правил. Связывание с данными правил позволяет сделать данные более «активными», позволяя системе управления базами данных автоматически осуществлять контроль достоверности данных, а также автоматизировать многие деловые процедуры. Подобная «активность» данных делает их более ценным ресурсом, так как приложения могут коллективно использовать не только сами данные, но и «поведение» данных. Правила сохраняются в базе данных, поэтому их не нужно кодировать заново для каждого приложения: это позволяет избежать избыточности и обеспечить целостность данных.

Предоставление пользователям возможности определять собственные типы данных и функции, а также возможности определять правила, управляющие поведением активных данных позволяет повысить ценность хранимых данных за счет расширения их семантического содержания (смысла). Тенденция расширения семантического содержания хранимых данных является на сегодняшний день наиболее важным направлением развития в области управления базами данных. В соответствии с требованиями этой новой тенденции системы управления реляционными базами данных расширяются в двух направлениях: (1) за счет введения «объектной инфраструктуры» собственно в систему управления базами данных и (2) за счет добавления «реляционных расширений» поверх этой инфраструктуры, предназначенных для поддержки таких функций специализированных приложений, как извлечение изображения, расширенный текстовый поиск, а также географических приложений. Система, которая включает в себя как объектную инфраструктуру, так и набор реляционных расширений для ее использования, называется «объектно-реляционной» системой управления базами данных.

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

В данной статье мною будут рассмотрены как объектная инфраструктура, так и реляционные расширения, поддерживаемые современной объектно-реляционной системой управления базами данных IBM DB2 for Common Servers. Если явно не указано иное, то под термином «DB2» понимается именно система DB2 for Common Servers, которая реализована для OS/2, Windows NT, AIX и множества других платформ Unix.

ОБЪЕКТНАЯ ИНФРАСТРУКТУРА

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

В DB2 имеется три типа данных для хранения больших объектов: BLOB для двоичных объектов, CLOB для строк символов и DBCLOB для строк, использующих двухбайтовые символы. Каждый из этих типов для хранения больших объектов позволяет сохранять объекты размером до 2 Гбайт. При сохранении больших объектов в столбце таблицы в столбец помещаются «дескрипторы» для каждого из объектов; сами большие объекты хранятся вне таблицы. Такая политика использования памяти не позволяет большим объектам нарушить физическую кластеризацию таблицы, что могло бы значительно увеличить число страниц, выбираемых с носителя в процессе поиска в таблице. Опции оператора CREATE TABLE позволяют создателю таблицы управлять размещением на физическом носителе данных из столбцов, имеющих тип больших объектов.

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

В связи с большим размером объектов очень желательно, чтобы количество операций перемещения или копирования с ними было сведено до минимума. Для этого в DB2 имеется возможность объявить переменную типа указатель («locator»), которая будет представлять значение большого объекта и не включать в себя собственно содержимое объекта. В указателе содержится описание способа, с помощью которого при необходимости может быть получено значение большого объекта. Указатель можно использовать для представления значения большого объекта в любом выражении SQL. Но операции с указателями очень эффективны, так как они осуществляются за счет манипулирования «описаниями» объектов, нежели чем действительными значениями больших объектов. Например, если LOC1 и LOC2 представляют собой переменные типа указатель, то выражение LOC1||LOC2 выполняет конкатенацию описаний, содержащихся в этих переменных, нежели чем конкатенацию самих больших объектов, представляемых этими переменными. С использованием указателей прикладная программа может выполнить серию манипуляций над значением большого объекта, отложив материальное представление результата операций в виде большого объекта до конечного этапа.

Часто бывает необходимо импортировать большой объект в базу данных из файла, или экспортировать его из базы данных в файл. DB2 позволяет прикладным программам обмениваться большими объектами между базой данных и файлами без перемещения этих объектов через программные буферы. В программе можно объявить переменную как «файловую ссылку», которая будет содержать имя конкретного файла. Файловая ссылка может быть использована в операторах SQL как в качестве входной, так и выходной переменной, представляя собой содержимое файла, интерпретируемого как большой объект. С использованием указателей и файловых ссылок приложения очень часто могут обрабатывать большие объекты, даже ни разу не выбирая собственно объекты с носителя в память программы.

Определяемые пользователем функции

DB2 содержит более 100 встроенных функций для выполнения самых различных операций с числами, строками, датами и данными других типов. Кроме того, пользователи могут сами создавать новые функции на С, С++ или Basic. Определяемые пользователем функции (UDF) могут принимать параметры и использоваться в любом выражении SQL, в котором ожидается скалярное значение.

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

После написания и компиляции программы, реализующей новую функцию, пользователь должен зарегистрировать ее с помощью оператора CREATE FUNCTION. Если функция должна использоваться более чем в одной базе данных, то в каждой базе данных ее необходимо зарегистрировать отдельно. Оператор CREATE FUNCTION определяет типы параметров и тип результата функции, сообщает системе, где нужно искать реализующую функцию программу, а также заносит описание функции в таблицы системного каталога. После регистрации функции при каждом ее вызове будет выполняться автоматическая загрузка и выполнение ее исполняемого кода. Очень важно защитить исполняемый файл, реализующий функцию, так как его исполнение производится при вызове функции без последующих проверок системой.

Комбинация имени функции и типов ее параметров носит название «прототипа» функции. Как и большинство современных языков программирования, SQL позволяет «перегружать» имя функции, определяя несколько функций с одинаковым именем и с различными типами параметров. При обработке конкретного вызова функции DB2 активизирует ту функцию, типы параметров которой наиболее точно соответствуют действительным типам аргументов в вызове функции. Например, в страховой компании можно определить две функции для вычисления вероятной продолжительности жизни: LIFE_EXP(DATE, VARCHAR(6)), на основе даты рождения и пола, и LIFE_EXP(INTEGER, VARCHAR(32)), на основе возраста и рода деятельности. При этом вызов LIFE_EXP(DATE("1945-06-15"), "Female") приведет к выполнению первой функции, а вызов LIFE_EXP(60, "Sky Diver") - к выполнению второй.

Определяемые пользователем типы

Встроенные типы данных SQL, такие как Decimal и Double, часто используются для представления данных, имеющих специальное значение. Например, один из столбцов с типом Decimal может содержать суммы в долларах, а другой столбец с тем же типом - суммы в иенах. Аналогично, один из столбцов с типом Double может содержать расстояния в футах, а другой столбец с тем же типом - расстояния в метрах.

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

При использовании только встроенных типов данных DB2 не имеет возможности контролировать специальные правила, которые должны применяться к Вашим данным. Поэтому в системе предусмотрена возможность создавать новые собственные типы данных и определять операции, которые могут быть применимы к ним. В DB2 определяемые пользователем типы данных именуются «distinct type» («особый тип»). Каждый из особых типов имеет общее представление с одним из встроенных типов, который называется «базовым типом» («base type»), но имеет собственный набор допустимых операций.

В следующих двух операторах создаются два особых типа, названные DOLLARS и YEN, каждый из которых основан на встроенном типе Decimal. Фраза WITH COMPARISONS означает, что два значения в долларах могут сравниваться между собой, так же как могут сравниваться два значения в иенах. Однако, значение в долларах не может сравниваться со значением в иенах или со значением, имеющим обычный тип Decimal.

CREATE DISTINCT TYPE DOLLARS AS DECIMAL(10,2) WITH COMPARISONS;
CREATE DISTINCT TYPE YEN AS DECIMAL(10,2) WITH COMPARISONS;

При создании особого типа DB2 генерирует функции для преобразования значения из особого типа в базовый и обратно. Например, создание типа DOLLARS приводит к созданию функции DOLLARS(DECIMAL), возвращающей значение типа DOLLARS, и функции DECIMAL(DOLLARS), возвращающей значение DECIMAL(10,2).

После создания особого типа единственными операторами, которые могут применяться к данным этого типа, являются операторы сравнения с данными того же типа. Например, если столбцы SALARY и BONUS имеют тип DOLLARS, то выражения SALARY=BONUS и SALARY>BONUS являются допустимыми условиями, но выражения SALARY+BONUS и SALARY*BONUS - недопустимы, так как для типа DOLLARS еще не определены арифметические операции.

Можно очень просто указать, какие из операторов базового типа имеют смысл при применении к определенным особым типам. Каждый из операторов, таких как «+», реализован в виде функции, имеющей то же имя, что и оператор. Чтобы разрешить применение оператора к созданному особому типу необходимо просто создать новую функцию, которая имеет то же имя, что и оператор, и принимает и/или возвращает результаты особого типа. В качестве реализации функции-оператора может быть указана как «источник» реализация, предоставленная IBM для встроенного типа, то есть операция с особым типом будет производиться точно так же, как и операция с базовым. В следующих операторах определяется операция «+» для двух долларовых значений, а также операция «*» для целого и долларового значений:

CREATE FUNCTION З+И(DOLLARS, DOLLARS)
RETURNS DOLLARS
SOURCE
	SYSIBM.И+И(DECIMAL(), DECIMAL());
CREATE FUNCTION З*И(INTEGER, DOLLARS)
RETURNS DOLLARS
SOURCE
	SYSIBM.И*И(INTEGER, DECIMAL());

После выполнения этих операторов для столбцов SALARY и BONUS, имеющих тип DOLLARS, действительны, например, операции SALARY+BONUS и 2*SALARY, но операция SALARY*BONUS недействительна, так как оператор умножения для двух долларовых значений не был определен.

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

Конечно, Вам может потребоваться добавить к особым типам данных некоторые дополнительные функциональные возможности помимо предлагаемых операторами, определенными для базового типа. Например, Вы можете создать особый тип ADDRESS на основе встроенного типа VARCHAR(50). Затем Вы можете создать определяемую пользователем функцию TIMEZONE(ADDRESS), которая будет вычислять часовой пояс для каждого адреса. Как и любая определяемая пользователем функция, функция TIMEZONE может быть написана на С, С++ или Basic, и должна быть зарегистрирована в той базе данных, где она будет использоваться.

В объектно-реляционной системе важно отслеживать не только состояние сохраняемых объектов, но и их поведение. В DB2 поведение данных особых типов задается с помощью функций, определяемых для данного типа. Например, такие унарные функции, как TIMEZONE(ADDRESS) и ZIPCODE(ADDRESS) можно рассматривать как «методы», определяющие поведение объектов типа ADDRESS. Таким образом, в DB2 не только сами данные, но и поведение данных представляет собой ресурс, который может коллективно использоваться несколькими приложениями.

Активные данные

Я определяю свойство «активности» данных как механизм, позволяющий операторам SQL выполнять некоторые действия, которые явно не указаны в этом операторе. Свойства активности данных очень полезны для защиты целостности данных, обработки исключительных ситуаций, вырабатывания отсутствующих данных и сохранения контрольных записей об изменениях в базе данных. В общем случае свойства активности данных позволяют указать некоторый ряд правил, исполнение которых будет контролироваться системой. Определение этих правил в самой базе данных, а не в работающих с ней приложениях, позволяет избежать возможной избыточности или несогласованности, а также позволяет упростить работу разработчиков приложений. Активные данные имеют особенно важное значение в среде клиент/сервер, когда приложения разрабатываются разобщенными группами, так как они предоставляют механизм определения глобальных правил, которые будут действовать во всех приложениях.

Свойства активности данных в DB2 можно разделить на две общие категории: «ограничения» и «триггеры». Ограничения представляют собой операторы декларативного характера, которые будут действовать в системе, такие как: «Размеры обуви всегда являются положительной величиной» или «Каждый служащий имеет руководителя». Триггеры представляют собой автоматические действия, которые выполняются всякий раз при наступлении определенного события или условия, таких как: «Когда осталось только 10 карандашей, заказать 100 новых карандашей» или «Вести запись служащих, выполняющих обновления в таблице ACCOUNTS».

DB2 поддерживает следующие типы ограничений:

Ограничения NOT NULL - не допускают появления нулевого значения в определенном столбце
Ограничения UNIQUE - не допускают появления в столбце или в группе столбцов повторяющихся значений
Ограничения PRIMARY KEY - объявляют для столбца или группы столбцов оба ограничения NOT NULL и UNIQUE
Ограничения CHECK - представляют собой предикаты, такие как BONUS вид CHECK опции: относятся к виду и не позволяют вводить или изменять с помощью вида данные, не соответствующие определению вида

Ограничения FOREIGN KEY (известные также как «референциальная целостность») - определяют взаимоотношения между таблицами, называемыми «родительской таблицей» и «дочерней таблицей». Любое отличное от нуля значение с ограничением FOREIGN KEY в дочерней таблице требует наличия соответствующего ключевого значения в родительской таблице.

Тогда как ограничения представляют собой объявление правил, триггеры больше похожи на «джинов», которые просыпаются и выполняют Ваши приказания при наступлении определенного события. Некоторые из опций, поддерживаемых триггерами DB2, включают в себя:

Активизацию триггера операциями вставки, удаления или обновления для заданной таблицы, или обновлением конкретных столбцов в таблице.
Выполнение предусмотренных триггером действий до или после наступления события, активизировавшего триггер.
Выполнение триггера только один раз при активизации оператором SQL, или выполнение один раз для каждой из строк, затронутых оператором SQL (это может быть ноль строк, одна строка или несколько строк).
Вычисление при активизации предиката, называемого «условием триггера». Выполнение основной части триггера производится только при истинности условия триггера.
Включение в основную часть триггера одного или нескольких операторов SQL. В этих операторах можно использовать специальные переменные, относящиеся к значениям «до» и «после» в строке или группе строк, вызвавших активизацию триггера. Если в основной части триггера производится попытка модифицировать базу данных, то авторизация прав на совершение этой операции осуществляется по правам определившего триггер пользователя, а не по правам пользователя, оператор SQL которого привел к активизации триггера. Эта процедура позволяет создателям триггеров «инкапсулировать» в него некоторые полезные привилегии, предоставляемые менее привилегированным пользователям.

В качестве примера рассмотрим применение триггера для автоматического обновления столбца данных. Предположим, что в базе данных имеется таблица STOCKS (товары) со столбцами SYMBOL (наименование), PRICE (цена) и HIGHPRICE (максимальная цена), в которой хранятся данные по различным товарам. Текущая цена товара постоянно записывается в столбец PRICE. Так как цены меняются, Вы хотите отслеживать максимальную цену на каждый из товаров и автоматически записывать ее в столбец HIGHPRICE. Эту задачу можно выполнить с помощью следующего триггера:

CREATE TRIGGER stockhigh
NO CASCADE BEFORE UPDATE ON stocks
REFERENCING NEW AS newrow
FOR EACH ROW MODE DB2SQL
WHEN (newrow.highprice IS NULL OR
newrow.price>newrow.highprice)
SET newrow.highprice = newrow.price;

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

С другой стороны, триггеры являются более мощным средством, чем ограничения, так как они имеют доступ к значениям данных как «до», так и «после» совершения операции. Подобный доступ позволяет с помощью триггера определить такое, к примеру, правило, как «заработная плата не может уменьшаться»; это правило невозможно установить с помощью ограничения. Кроме того, ограничение может выполнять достаточно ограниченный круг предопределенных действий, тогда как в триггере можно выполнить любой оператор SQL или последовательность операторов. Эта возможность позволяет выполнять с помощью триггеров действия, которые невозможно реализовать с помощью ограничений, как, например, обновление базы данных, запись в файл или генерация определенного кода ошибки. В общем случае следует стремиться задать деловое правило в виде ограничения, если это возможно; в противном случае можно использовать триггер.

Согласованное взаимодействие

Большие объекты, определяемые пользователем типы данных и функции, ограничения и триггеры представляют, каждое само по себе, мощные средства. Но действительно мощные объектно-реляционные возможности DB2 проистекают от согласованного взаимодействия этих средств при их совместном использовании. В качестве примера этого согласованного взаимодействия рассмотрим, каким образом объектно-реляционные особенности DB2 могут быть использованы для сохранения в базе данных многоугольников. Многоугольники очень часто используются в компьютерной графике, системах автоматизированного проектирования, муниципального планирования и других прикладных областях.

Так как «многоугольник» («polygon») не является предопределенным типом данных, то в первую очередь необходимо решить, каким образом многоугольники будут представляться в базе данных. Так как многоугольники потенциально могут быть очень большими, для их представления мы воспользуемся одним из типов данных для больших объектов (а именно типом BLOB), но за счет создания особого типа мы будем различать использование типа BLOB для представления многоугольников от любых других вариантов использования. Следующий оператор создает тип POLYGON, каждый из экземпляров которого может включать в себя описание многоугольника объемом до 1 Мбайт:

CREATE DISTINCT TYPE POLYGON AS
BLOB(1M);

Действительное представление многоугольника в типе BLOB можно реализовать по разному. На рисунке 1 показан один из методов, когда многоугольник кодируется в виде последовательности чисел, первое из которых показывает его степень, а последующие являются координатами вершин.

Рисунок 1. Представление многоугольника с помощью типа BLOB.

После создания особого типа и выбора представления многоугольников необходимо создать с помощью набора определяемых пользователем функций, работающих с многоугольниками, желаемую модель его поведения. По крайней мере одна из этих функций должна быть «конструктором», создающим многоугольник из более примитивных типов, таких как POINT (точка) или DOUBLE. Функция-конструктор выполняет упаковку примитивных типов в тип BLOB и преобразование типа BLOB в тип POLYGON с помощью генерируемой системой функции POLYGON(BLOB).

Ниже перечислены некоторые другие определяемые пользователем функции, которые могут быть написаны, например, на С или С++, для моделирования поведения многоугольников:

degree(Polygon) returns Integer; (возвращает целое - степень многоугольника)

area (Polygon) returns Double; (возвращает число с плавающей точкой двойной точности - площадь многоугольника)

perimeter (Polygon) returns Double; (возвращает число с плавающей точкой двойной точности - периметр многоугольника)

rotate (Polygon, Double) returns Polygon; (возвращает значение типа Polygon - многоугольник, повернутый на угол, заданный параметром типа Double)

intersect (Polygon, Polygon) returns Polygon; (возвращает значение типа Polygon - пересечение многоугольников, заданных параметрами)

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

CREATE TABLE properties
(taxid Char(6) PRIMARY KEY, owner Varchar(32), assessment Dollars, parcel Polygon);

Определяемые пользователем функции, моделирующие смысловое содержание многоугольников, можно использовать в запросах; например, в следующем запросе осуществляется поиск владельцев больших участков земли:

SELECT owner, area(parcel)
FROM properties
WHERE area(parcel)>20000;

В этом примере выполняется поиск участков земли, находящихся в частной собственности, площадь которых превышает определенное значение. Наиболее эффективным способом выполнения данного запроса является использование индекса, предоставляющего непосредственный доступ к записям об участках по их площади. Индексы на основе определяемых пользователем функций, таких как AREA(POLYGON), будут реализованы в DB2 в будущем и в настоящее время не поддерживаются. В то же время, аналогичного выигрыша в производительности можно добиться с помощью обычного индекса. Для этого в таблицу PROPERTIES придется добавить дополнительный столбец, который будет содержать заранее вычисленную площадь для каждого участка; заполнение этого столбца можно автоматизировать с помощью триггера. Следующий оператор добавляет столбец AREA, служащий для повышения производительности, в таблицу PROPERTIES:

ALTER TABLE properties
ADD COLUMN area Double;

Для управления значениями в столбце AREA необходимо определить триггеры, которые будут активизироваться выполнением над таблицей PROPERTIES операций INSERT и UPDATE. Следующий пример демонстрирует определение необходимого триггера для операции вставки INSERT:

CREATE TRIGGER insertprop
	NO CASCADE
	BEFORE INSERT ON properties
	REFERENCING NEW AS newrow
	FOR EACH ROW MODE DB2SQL
	SET newrow.area =
	area(newrow.parcel);

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

CREATE INDEX proparea ON
properties(area);

Исходный запрос нашего примера можно теперь переписать в следующей форме, чтобы позволить DB2 использовать индекс для прямого доступа к необходимым участкам собственности:

SELECT owner, area
FROM properties
WHERE area>20000;

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

РЕЛЯЦИОННЫЕ РАСШИРЕНИЯ

Большие объекты, определяемые пользователем типы данных и функции, ограничения и триггеры образуют объектную инфраструктуру, предоставляемую DB2. На основе этой инфраструктуры можно написать реляционные расширения, предназначенные для поддержки определенных прикладных областей. Несколько таких расширений уже реализованы для платформы DB2; со временем IBM и другие производители разработают гораздо больше подобных расширений. Я расскажу о функциональных возможностях одного их этих расширений, а именно Text Extender, а также кратко опишу другие расширения, которые вместе принято называть DB2 Extenders, поставляемые в настоящее время IBM.

Реляционное расширение для работы с текстом Text Extender. Расширение Text Extender поддерживает быстрое извлечение больших текстовых документов на основе их содержания. Оно не требует сохранения документов в специальном формате и может использоваться с документами многих популярных форматов, включая Microsoft Word, Word Perfect и AmiPro. Документы, используемые расширением Text Extender, загружаются в столбец таблицы DB2, имеющий тип данных для больших строк символов CLOB. Расширением Text Extender создается специальный вид индекса для сохраненных документов, а также предоставляется набор функций, использующих индекс для поиска документов, содержащих необходимые комбинации слов и выражений.

Расширение Text Extender позволяет работать с документами на 18 языках, включая английский, французский, испанский, немецкий, итальянский и шведский. С использованием встроенной поддержки этих языков расширение Text Extender индексирует полное содержание сохраненных документов в виде специального лингвистического индекса. Лингвистический индекс исключает незначимые слова, такие как местоимения и союзы, и сокращает все значимые слова до их грамматической основы. Например, слова летать, летает, летают, летели и прилетели представляют собой формы одного и того же глагола и поэтому представляются в индексе единой общей основой. Таким образом, поиск документов по слову «летает» приведет к извлечению проиндексированных документов, содержащих слова «летели» или «прилетели».

Так как документы, используемые вместе с расширением Text Extender, сохраняются в столбце таблицы базы данных DB2, запрос может сочетать в себе условия, касающиеся содержимого документа, с условиями, связанными с другими столбцами таблицы. Например, таблица с журнальными статьями может включать в себя столбцы, содержащие название журнала, его номер, название статьи и полный текст каждой статьи. В запросе можно, например, осуществить поиск статей, опубликованных в журнале Newsweek за 1990 год, содержащих в одном абзаце слова «Iraq» («Ирак») и «embargo» («эмбарго»), используя в касающейся содержимого статей части запроса функции из текстового расширения Text Extender.

Лингвистический индекс расширения Text Extender позволяет осуществлять поиск по содержимому документа независимо от деталей написания, таких как выделение прописными буквами, переносы и ударения. Кроме того, им поддерживается также поиск по синонимам слова или фразы. Например, поиск документов, содержащих слово «airplane», может выдать также документы, содержащие связанные слова, такие как «aircraft», «plane», «airliner» и «jet».

Как и все определяемые пользователем функции, реализованные в расширении Text Extender функции используют обычные операторы SQL. Одной из наиболее важных функций является функция CONTAINS, возвращающая единицу в том случае, если данный документ подходит под указанный шаблон поиска. Шаблон поиска может включать в себя несколько фраз, объединенных символами «&» (и), «|» (или) и NOT (не). В шаблоне могут быть также указаны определенные слова или выражения, которые должны находиться в одном предложении или абзаце документа. Например, следующим запросом выполняется поиск журнальных статей, которые содержат слова «cooking» и любое из слов «Chinese» или «Japanese» в произвольном порядке, но не содержат слова «sushi»:

SELECT magazine, date, title
FROM articles
WHERE CONTAINS(articletext,
	Ф(ЗcookingИ
	& (ЗChineseИ|ИJapaneseИ)
	& NOT ЗsushiИ)Х) = 1;

В дополнение к функции CONTAINS расширение Text Extender поддерживает еще несколько других функций, полезных для выполнения поиска документов по их содержимому. Например, функция NO_OF_MATCHES возвращает количество совпадений указанного шаблона поиска с содержимым документа, а функция RANK возвращает показатель, характеризующий степень соответствия документа указанному шаблону поиска (более высокий показатель получит документ, являющийся относительно коротким, но который содержит в то же время несколько совпадений с указанным шаблоном поиска).

Другие расширения. Помимо расширения Text Extender, в настоящее время IBM поставляются следующие:

Расширение Image Extender позволяет сохранять и извлекать изображения в нескольких популярных форматах, включая GIF, JPEG и BMP, а также преобразовывать изображения из одного формата в другой. Этим расширением выполняется автоматическое извлечение миниатюрного варианта полного изображения для просмотра; кроме того, оно позволяет осуществлять поиск изображений по их содержимому - например, поиск изображений, цвет или текстура которых соответствует указанному образцу.
Расширение Video Extender позволяет сохранять и извлекать видеозаписи в нескольких популярных форматах, включая MPEG1, AVI и Quicktime. Оно позволяет автоматически разбить запись на отрывки на основе обнаружения изменения фона, а также извлечь репрезентативный кадр для каждого отрывка.
Расширение Audio Extender позволяет сохранять и извлекать аудио клипы в нескольких популярных форматах, включая AIFF, MIDI и WAVE. Оно позволяет определять характеристики аудио данных, такие как время проигрывания и количество и название аудио треков, входящих в клип.
Расширение Fingerprint Extender позволяет сохранять и извлекать отпечатки пальцев в специальном формате, а также осуществлять поиск отпечатков пальцев, схожих с представленным образцом.

ИДЕИ НА БУДУЩЕЕ

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

Все функциональные возможности, описанные в данной статье, реализованы в DB2 for Common Servers с июля 1995 года. Со временем IBM планирует реализовать аналогичные функциональные возможности также и для других продуктов из семейства DB2. В то же время, в течение года после выпуска IBM первой объектно-реляционной системы управления базами данных лаборатории IBM работали над разработкой дополнительных объектно-реляционных возможностей, таких как:

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

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

Дональд Д. Чемберлин является членом Ассоциации по вычислительной технике (ACM) и работает в исследовательском центре IBM Almaden Research Center. Он является одним из изобретателей языка баз данных SQL и получил награду Ассоциации по вычислительной технике ACM Software System Award за вклад в разработку и реализацию систем управления базами данных. Имеет степень доктора философии Стенфордского университета и недавно выпустил книгу «Использование новой DB2: объектно-реляционной системы управления базами данных IBM» («Using the New DB2: IBM"s Object-Relational Database System», Morgan Kaufmann, 1996).

Перевод статьи "Anatomy of an Object-Relational Database", Donald Chamberlin, DB2 Magazine, Winter 1996, Vol. 1, No. 1. DB2 Magazine is a Miller Freeman publication (www.db2mag.com). Переведено и опубликовано с разрешения Miller Freeman publication.