Навигация.

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

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

Получить текущее или первое состояния объекта, а также первое и последнее наблюдение для него Выбрать состояния данного объекта, удовлетворяющие некоторому условию Получить (перебрать) множество всех состояний объекта, актуальных на какой-либо момент или в интервале времени Получить (перебрать) множество идентификаторов всех наблюдений, проведенных в какой-либо интервал времени для данного объекта

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

Получить идентификатор объекта, к которому относится данное наблюдение Получить идентификатор предыдущего наблюдения Получить идентификатор следующего наблюдения

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

Предыдущее или следующее состояние Состояние, отстоящее от заданного на определенный промежуток времени.

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

Небольшие затраты на реализацию.

Реализация поддержки протоколов GIOP/IIOP должна потребовать минимальных затрат как в плане инженерного проектирования, так в плане распространения готовых ORB-ов.

Небольшой субъективный обзор СУБД, встреченных в ОС Linux

Спиричев Вадим.

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

и ограниченный объем этой статьи

Огромный объем стандарта SQL/92 и ограниченный объем этой статьи не позволяют нам описать этот стандарт сколько-нибудь подробно. Кроме того, как отмечалось выше, на сегодняшний день все еще отсутствует какая бы тони было полная реализация SQL/92. Тем не менее мы считаем полезным сравнительно подробно описать стандартные средства динамического SQL (это описание можно использовать хотя бы в качестве эталона при сравнении различных реализаций)и привести сводку основных отличий SQL/92 от SQL/89 (в этом мы будем следовать последнему изданию книги Дейта "Стандарт SQL ").

Необходимость использования OLAP в учетных системах

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

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

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

Этим объясняется интерес к объединению и анализу данных учетной системы с помощью технологии OLAP (On-Line Analytical Processing - оперативная аналитическая обработка). Этот метод позволяет аналитикам, менеджерам и руководителям "проникнуть в суть" накопленных данных за счет быстрого и согласованного доступа к широкому спектру представлений информации. Исходные данные преобразуются таким образом, чтобы наглядно отразить структуру деятельности предприятия.

При этом конечному пользователю предоставляется ряд аналитических и навигационных функций:

расчеты и вычисления по нескольким измерениям, иерархиям и/или членам; анализ трендов; выборка подмножеств данных для просмотра на экране; углубление в данные (drill down), для просмотра информации на более детализированном уровне; переход к детальным данным, лежащим в основе анализа; поворот таблицы отображаемых данных.

NULL значения

Начнем сравнение с реализации NULL-значений в ANSI SQL и Oracle SQL. Согласно ANSI все типы данных должны поддерживать неопределенные или NULL значения. Oracle в полной мере поддерживает это правило для всех типов, за исключением символьных. Для любых символьных данных пустая строка интерпретируется как NULL, например два оператора Oracle SQL:

INSERT INTO TEST(COL1) VALUES(NULL) и INSERT INTO TEST(COL1) VALUES('')

полностью идентичны и вставят в таблицу значения NULL, а не пустые строки.

В Oracle вообще нельзя вставить пустую строку, так как она будет рассматриваться как NULL . Это отклонение особенно актуально при сравнении строк, например пусть есть следующая таблица:

TEST COL1 COL2 1 '' 'Str1' 2 'a' 'Str2'

тогда оператор SELECT * FROM TEST WHERE COL1=''в Oracle будет интерпретироваться как SELECT * FROM TEST WHERE COL=NULL и не вернет НИОДНОЙ строчки, в тоже время в ANSI SQL данный оператор вернет первую строку.

Оператор SELECT * FROM TEST WHERE COL1<>''в Oracle будет интерпретироваться как SELECT * FROM TEST WHERE COL<>NULL и также не вернет НИОДНОЙ строчки, в ANSI SQL данный оператор вернет вторую строку.

Чтобы операторы отработал корректно его следует заменить на:

SELECT * FROM TEST WHERE COL1 IS NULL и SELECT * FROM TEST WHERE COL1 IS NOT NULL.

Таким образом при сравнении величины с пустой строкой в Oracle следует пользоваться предложениями IS NULL и IS NOT NULL.

Об основаниях ненавигационного языка запросов к объектно-ориентированным базам данных

Сергей Кузнецов

1. Введение

Вызывающее интерес все большего числа исследователей и

разработчиков и активно развивающееся направление

объектно-ориентированных баз данных (ООБД) обладает несколькими

специфичными характерными чертами. При том, что практически все

осознают потребность в ООБД, отсутствует какая-либо общая,

повсеместно признанная точка зрения о том, что должны

обеспечивать системы управления ООБД (ООСУБД).

В самых общих словах, на уровне общего согласия, ООБД должна

содержать классы объектов произвольно сложной структуры,

инкапсулирующее поведение. Практически все согласны, что ООСУБД

должна поддерживать систему объектно-ориентированного

программирования, позволяющую как определять новые классы

объектов, так и создавать прикладные системы. Более того, многие

рассматривают это как основную черту ООБД - устранение

несоответствия между языками программирования и языками БД .

Вместе с тем, односторонний взгляд на ООСУБД как на систему

объектно-ориентированного программирования, поддерживающую

долговременное хранение объектов, не отражает специфику таких

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

в некотором смысле противоположна ситуации с реляционными СУБД,

но столь же неудовлетворительна. В случае реляционных систем

имеются мощные средства управления БД - непроцедурные языки

запросов и манипулирования данными, но программирование

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

естественных комбинаций языков программирования и языков БД

(например, языка Си со встроенным SQL). В большинстве

реализованных ООСУБД поддерживается система

объектно-ориентированного программирования, но средства запросов

к ООБД существенно слабее, чем в реляционных системах.

Очевидные недостатки этой ситуации можно объяснять разными

причинами, но прежде всего они кроятся в отсутствии простого и

мощного теоретического основания ООБД.

В этой работе я не претендую на создание такого базиса.

Рассматриваются лишь некоторые аспекты, которые в будущем,

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

запросов к ООБД. Более точно, памятуя о той роли, которую сыграла

реляционная алгебра в истории языков запросов реляционных СУБД, я

предлагаю алгебру классов для ООБД. Основная мысль состоит в том,

чтобы использовать понятие класса для обеспечения замкнутости

алгебры. Подобно тому, как операндами и результатом выражения

реляционной алгебры являются отношения, операндами и результатом

выражения алгебры классов являются классы. В предлагаемой алгебре

используется тот же набор операций, что и в классической

реляционной алгебре. Проблема состояла в том, чтобы разработать

правильную интерпретацию этих операций в контексте ООБД.

Для разработки алгебры объектов потребовалось уточнить базовые

концепции и определения ООБД. Заметим, что ни одно из этих

уточнений не является новым: соответствующие идеи неоднократно

появлялись в публикациях. Мне не приходилось встречать в

публикациях только одну идею - возможность существования в ООБД

нескольких классов однотипных объектов.

При реализации непроцедурных языков ООБД возникает ряд вопросов,

связанных главным образом с трудностями оптимизации запросов. В

существующих системах эта проблема, как правило, решается за счет

отказа от инкапсуляции объектов или путем введения существенных

ограничений на инкапсуляцию. В данной работе предлагается

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

запросов к ООБД без требования ограничения инкапсуляции объектов.

Общая структура статьи следующая. Второй раздел содержит краткий

обзор языков запросов к ООБД и методов оптимизации запросов. В

третьем разделе приводятся некоторые соображения из области

реляционной алгебры, повлиявшие на разработку алгебры классов. В

четвертом разделе содержатся основные определения и формулировка

алгебры классов. Пятый раздел посвящается оптимизации запросов к

ООБД. Шестой раздел - заключение.

2. Языки запросов к ООБД и методы оптимизации

Как отмечают многие исследователи и разработчики (например, ), объектно-ориентированная система БД представляет собой



объединение системы программирования и СУБД (альтернативная, но

не более проясняющая суть дела точка зрения состоит в том, что

объектно-ориентированная СУБД - это СУБД, основанная на

объектно-ориентированной модели данных ).

Мы уже говорили, что основная практическая надобность в ООБД

связана с потребностью в некоторой интегрированной среде

построения сложных информационных систем. В этой среде должны

отсутствовать противоречия между структурной и поведенческой

частями проекта и должно поддерживаться эффективное управление

сложными структурами данных во внешней памяти. С этой точки

зрения языковая среда ООБД - это объектно-ориентированная система

программирования, естественно включающая средства работы с

долговременными объектами. "Естественность" включения средств

работы с БД в язык программирования означает, что работа с

долговременными (хранимыми во внешней БД) объектами должна

происходить на основе тех же синтаксических конструкций (и с той

же семантикой), что и работа со временными, существующими только

во время работы программы объектами.

Эта сторона ООБД наиболее близка родственному направлению языков

программирования БД . Языки программирования ООБД и БД во

многих своих чертах различаются только терминологически;

существенным отличием является лишь поддержание в языках первого

класса подхода к наследованию классов. Кроме того, языки второго

класса, как правило, более развиты как в отношении системы типов,

так и в отношении управляющих конструкций.

Другим аспектом языкового окружения ООБД является потребность в

языках запросов, которые можно было бы использовать в

интерактивном режиме. Если доступ к объектам внешней БД в языках

программирования ООБД носит в основном навигационный характер, то

для языков запросов более удобен декларативный стиль.

Декларативные языки запросов к ООБД менее развиты, чем языки

программирования ООБД, и при их реализации возникают существенные

проблемы. Ниже мы рассмотрим имеющиеся подходы и их ограничения



более подробно. Но начнем с языков программирования ООБД.

К моменту написания данной работы нам неизвестен какой-либо язык

программирования ООБД, который был бы спроектирован целиком

заново, начиная с нуля. Естественным подходом к построению такого

языка было использование (с необходимыми расширениями) некоторого

существующего объектно-ориентированного языка. Начало расцвета

направления ООБД совпало с пиком популярности языка Smalltalk-80.

Этот язык оказал большое влияние на разработку первых систем

ООБД, и, в частности, использовался в качестве языка

программирования . Во многом опирается на Smalltalk и

известная коммерчески доступная система GemStone .

Трудности с эффективной практической реализацией языка Smalltalk

побудили разработчиков систем ООБД к поиску альтернативных

базовых языков. Известная близость объектно-ориентированного и

функционального подходов к программированию позволяет достаточно

успешно опираться на функциональные языки программирования. В

частности, язык Лисп (Common Lisp) является основой проекта ORION

. В этом проекте Лисп является и инструментальным языком, и

базой объектно-ориентированного языка программирования в среде

ORION.

Потребности в еще более эффективной реализации заставляют

использовать в качестве основы объектно-ориентированного языка

языки более низкого уровня. Например, в системе VBASE наряду

со специально разработанным языком TDL, предназначенным для

определения типов, используется объектно-ориентированное

расширение языка Си - COP (C Object Processor). В уже

упоминавшемся проекте O2 наряду с функциональным

объектно-ориентированным языком программирования

используются два объектно-ориентированных расширения языков

Бейсик и Си. При этом, насколько можно судить по публикациям,

наибольшее распространение среди пользователей этой системы (она

уже коммерчески доступна) получил язык CO2, являющийся

расширением языка Си. Возможно это связано лишь с широкой (и все

более возрастающей) популярностью языка Си (и его



объектно-ориентированного потомка Си++), ставшего поистине

девизом "настоящих программистов". Может быть, причины более

глубинны (например, языки более высокого уровня слишком

ограничительны для программистов-профессионалов; недаром

большинство современных реализаций языков более высокого уровня

выполняются именно на языке Си). Тем не менее, современная

ситуация именно такова, и мы считаем полезным привести краткое

описание основных особенностей языка CO2 .

Прежде всего, CO2 не является полностью самостоятельным языком.

Этот язык входит во многоязыковую среду O2 и предназначен для

программирования методов ранее определенных классов. Определение

классов, сигнатур методов (фактически, прототипов функций в

терминологии языка Си) и имен постоянно хранимых значений и

объектов производится с использованием отдельного языка

определения схемы БД.

Имя любого объекта трактуется как указатель на значение этого

объекта; разыменование производится с помощью обычного оператора

Си '*'. Доступ к значению объекта возможен только из метода его

класса, если только при перечислении методов оператор '*' не

объявлен явно публичным.

Поддерживается операция порождения нового объекта указанного

класса. В отличие от языка Си++ в CO2 невозможно совместить

создание нового объекта с его инициализаций (понятие

метода-конструктора начального значения объекта в CO2 не

поддерживается). Для инициализации необходимо либо явно

обратиться к соответствующему методу класса с указанием вновь

созданного объекта (поддерживается соответствующий механизм

"передачи сообщений", означающий на самом деле вызов функции),

либо воспользоваться оператором '*' и явно присвоить новое

значение, если '*' - публичный оператор для данного класса.

CO2 включает средства конструирования значений-кортежей,

множеств, и списков. Понятие значения-кортежа фактически

эквивалентно понятию значения-структуры обычного языка Си (с тем

отличием, что элементами кортежа могут являться объекты,



множества и списки). Для значений-множеств и списков

поддерживаются операции добавления и изъятия элементов, а также

набор теоретико-множественных операций (и конкатенации для

списков).

Основой манипулирования объектами, хранимыми в БД, является

расширенное по сравнению с языком Си средство итерации. Итератор

применим к значениям-множествам или спискам. Фактически он

означает последовательное применение оператора-тела цикла ко всем

элементам множества или списка. Если мы вспомним, что

долговременно хранимому классу объектов неявно соответствует

одноименное значение-множество с элементами-объектами данного

класса, то становится понятно, что итератор языка CO2

обеспечивает явную навигацию в классах объектов. Единственное,

что остается от привычных пользователям СУБД языков запросов, -

это ограниченная возможность указания характеристик требуемых в

цикле объектов (это делается путем использования оператора

разыменования и явного указания условий на атрибуты; конечно, для

этого нужно, чтобы оператор '*' был объявлен публичным в данном

классе).

Разработчики O2 подчеркивают, что они умышленно сделали CO2 более

бедным по возможностям, чем, например, язык Си++, потому что

многое по части управления объектами берет на себя общий менеджер

объектов системы, явно вызываемый из рабочей программы.

Потребность в поддержании в объектно-ориентированной СУБД не

только языка (или семейства языков) программирования ООБД, но и

развитого языка запросов в настоящее время осознается практически

всеми разработчиками. Система должна поддерживать легко

осваиваемый интерфейс, прямо доступный конечному пользователю в

интерактивном режиме. Один из подходов основывается на

поддержании обходчиков . В этом случае конечный интерфейс

обычно является графическим. На экране отображается схема (или

подсхема) ООБД, и пользователь осуществляет доступ к объектам в

навигационном стиле. По мнению Бансилона в этом случае

разумно игнорировать принцип инкапсуляции объектов и предъявлять



пользователю внутренность объектов. В большинстве существующих

систем ООБД подобный интерфейс существует, но всем понятно, что

навигационный язык запросов - это в некотором смысле шаг назад по

сравнению с языками запросов даже реляционных систем. Ведутся

активные поиски подходов к организации декларативных языков

запросов к ООБД.

Беери отмечает существование трех подходов. Первый подход -

языки, являющиеся объектно-ориентированными расширениями языков

запросов реляционных систем. Наиболее распространены языки с

синтаксисом, близким к известному языку SQL . Это связано,

конечно, с общим признанием и чрезвычайно широким

распространением этого языка. В частности, в своем Манифесте

третьего поколения СУБД М. Стоунбрекер и его коллеги по

комитету перспективных систем БД утверждают необходимость

поддержания SQL-подобного интерфейса во всех СУБД следующего

поколения.

Второй подход основывается на построении полного логического

объектно-ориентированного исчисления. По поводу построения такого

исчисления имеются теоретические работы (например, ), но

законченный и практически реализованный язык запросов нам

неизвестен. Видимо, к этому же направлению строго теоретически

обоснованных языков запросов можно отнести и работу Леллани и

Спиратоса , основанную на алгебраической теории категорий.

Наконец, третий подход основывается на применении дедуктивного

подхода. В основном это отражает стремление разработчиков к

сближению направлений дедуктивных и объектно-ориентированных БД.

Примером простого дедуктивного объектно-ориентированного языка

запросов может служить .

Независимо от применяемого для разработки языка запросов подхода

перед разработчиками встает одна концептуальная проблема, решение

которой не укладывается в традиционное русло

объектно-ориентированного подхода. Понятно, что основой для

формулирования запроса должен служить класс, представляющий в

ООБД множество однотипных объектов. Но что может представлять

собой результат запроса? Набор основных понятий



объектно- ориентированного подхода не содержит подходящего к

данному случаю понятия. Обычно из положения выходят, расширяя

базовый набор концепций концепцией множества объектов и полагая,

что результатом запроса является некоторое подмножество

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

поскольку автоматически исключает возможность наличия в языке

запросов средств, аналогичных реляционному оператору соединения.

В конце этого раздела мы коротко изложим собственные (в

достаточной степени предварительные) соображения по этому поводу,

но сначала кратко рассмотрим особенности нескольких конкретных

декларативных языков запросов к ООБД.

В языке запросов объектно-ориентированной СУБД ORION

полностью поддерживается принцип инкапсуляции объектов. В

реализованном варианте языка запросы могут основываться только на

одном классе (хотя в описывается подход к определению

запроса на нескольких классах в стиле расширения семантики

реляционного оператора соединения). Синтаксис языка ориентирован

на SQL. Очень развит набор допустимых предикатов селекции. В

частности, для атрибута, доменом которого является суперкласс,

можно указать имя интересующего пользователя подкласса.

Язык запросов системы Iris находится в значительной

степени под влиянием реляционной парадигмы. Даже название этого

языка OSQL отражает его тесную связь с реляционным языком SQL. По

сути дела, OSQL - это реляционный язык, рассчитанный на работу с

ненормализованными отношениями. Естественно, при таком подходе в

OSQL нарушается инкапсуляция объектов.

На наш взгляд, особый интерес представляет декларативный язык

запросов системы O2 RELOOP . В общих словах, это

декларативный язык запросов с SQL-ориентированным синтаксисом,

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

объектов и значений. (Кстати, это не единственная работа в

направлении построения алгебры для объектно-ориентированных

моделей данных. См., например, .) На наш взгляд, особенно

впечатляющим качеством языка RELOOP является естественность его



построения в общем контексте модели O2. Запрос задается всегда на

значении-множестве или списке. Если мы вспомним, что

долговременному классу в O2 соответствует одноименное

значение-множество, то тем самым можно определить запрос на любом

хранимом классе. Результатом запроса может являться объект,

значение-множество или значение-список. При этом элементами

значений-множеств могут являться объекты (простая выборка), либо

значения-кортежи с элементами-объектами разных классов

(например). В совокупности эти особенности языка позволяют

формулировать запросы над несколькими классами (специфическое

соединение, порождающее не новые объекты, а кортежи из

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

Остановимся теперь на проблемах выполнения запросов к ООБД,

сформулированных на каком-либо декларативном языке. Каким бы не

был этот язык, в конечном счете потребуется по внешнему

представлению запроса сформировать план его выполнения, который

минимизировал бы общие накладные расходы системы, требующиеся для

выполнения запроса. Другими словами, до выполнения запроса

необходимо выполнить его оптимизацию, учитывая в общем случае

необходимость обменов с внешней памятью.

Публикации, касающиеся оптимизации запросов к ООБД, практически

отсутствуют. Это свидетельствует о недостаточной развитости

каких-либо оригинальных подходов.

В большинстве систем по сути дела применяется тот же подход к

оптимизации запросов, который использовался в реляционных

системах: формируется набор альтернативных планов, оценивается

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

стоимостью. (Подробный обзор современных методов оптимизации

запросов в реляционных СУБД и нерешенных проблем можно найти в

.) Возможность применения такого подхода в СУБД ORION и O2

(да и в других) опирается на то, что объекты в этих системах не

полностью инкапсулированы. Наряду с методами, в объектах видны и

некоторые атрибуты, и если условие выборки задано через эти

атрибуты, оптимизатор запросов, которому известны внутренняя



структура объектов и набор существующих индексов, получает

возможность выбора. Если же условие выборки можно формулировать

только через методы, при подходах ORION и O2 единственным

возможным способом выборки объектов класса будет последовательный

просмотр всех объектов этого класса.

Здоник отмечает, что основная проблема с оптимизацией

запросов к ООБД связана с расширяемостью набора типов в такой БД.

Каждый новый тип вводит собственную алгебру, неизвестную

оптимизатору запросов. Например, оптимизатор не имеет информации

о возможной коммутативности двух операций типа и т.д. Здоник

полагает, что возможному решению проблемы оптимизации могло бы

способствовать формальное определение алгебраических свойств

операций типа при его разработке. Примерно такой подход

применяется в оптимизаторах, основанных на наборе правил,

применяемых в расширяемых СУБД (например, ).

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

оптимизации запросов, наибольшее влияние на оптимизаторы систем

ООБД может оказать . Эта работа не связана непосредственно со

спецификой ООБД, но преимущество предлагаемого подхода связано

как раз с максимальной независимостью от особенностей организации

БД. Предлагается не оценивать план выполнения запроса, а

учитывать реальную стоимость уже использованного плана и на этой

основе изменять критерии выбора оптимизатора. Может быть, таким

образом удастся справиться с неизвестной оптимизатору алгеброй

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

3. Взгляд на реляционную алгебру

Классическая реляционная алгебра содержит набор

теоретико-множественных операций (например, объединение,

пересечение и декартово произведение отношений), а также операции

селекции и проекции.

Реляционная алгебра замкнута относительно понятия "отношение",

т.е. операндами и результатами любой операции являются отношения.

При этом можно отметить один факт, на который обычно не обращают

внимания по причине его "очевидности". Существуют два класса



реляционных операций. Теоретико-множественные операции

объединения и пересечения и операция селекции формируют из

операндов-отношений отношение-результат с той же схемой; операции

же декартова произведения и проекции формируют

отношение-результат со схемой, которая в общем случае не

описывалась статически в составе схемы БД. Если рассматривать

схему отношения как тип, то в этой терминологии операции

декартова произведения и проекции формируют не только значение,

но и тип этого значения.

Тем самым, в общем случае при вычислении реляционного выражения

одновременно с вычислением промежуточных отношений происходит

построение некоторой динамической схемы БД. И это не вызывает

никакой двусмысленности, потому что для любой реляционной

операции схему отношения-результата (тип результата) можно

определить в статике до выполнения операции.

Наличие в реляционной алгебре операций, порождающих отношения с

новым типом, не вызывает концептуальных и/или технических

затруднений по той причине, что типы (схемы) отношений очень

просты. Например, можно считать, что два типа отношения

совместимы относительно операций объединения и пересечения, если

эти типы структурно эквивалентны (их наборы доменов совпадают).

Все это легко проверяется, позволяя однозначно интерпретировать

реляционные выражения.

Заметим, что хотя в реляционной модели данных имя схемы отношения

совпадает с именем экземпляра отношения (это очень похоже на то,

как в ООБД имя класса часто пытаются использовать одновременно

как имя типа объекта и имя множества объектов), неявно возникает

понятие типа отношения, которое не обязательно именовать по

причине простоты определения эквивалентных (однотипных) схем

отношений.

4. Основные определения и формулировка алгебры классов

Не будем приводить полный набор концепций и определений. В

основном мы следуем принятым представлениям об ООБД со

множественным наследованием. Затронем только те понятия, которые

существенны для дальнейшего изложения.

Будем опираться на следующее: ООБД представляется как



ациклический граф с корнем (АГК), все вершины которого

представляют собой классы объектов, а дуги соответствуют

отношению наследования ( будем называть этот АГК статическим АГК

ООБД). Каждый объект ООБД обладает типом и непосредственно

принадлежит некоторому классу, принадлежа при этом каждому

суперклассу этого класса. Все объекты одного класса обладают

общим типом и поэтому можно говорить о типе класса. Тип

суперкласса является супертипом типа класса (в частности, тем же

самым типом). Непосредственным типом объекта называется тип

класса, которому непосредственно принадлежит этот объект.

Допускается также наличие в статической решетке классов ООБД

нескольких классов, не связанных отношением класс-суперкласс, с

одним типом. Тип объекта (класса) в нашей трактовке является не

только синтаксической, но и семантической характеристикой. В

частности, если два класса объектов обладают одним и тем же

типом, то осмысленны теоретико-множественные операции объединения

и пересечения для этих классов.

Будем различать статический АГК классов (собственно ООБД) и

динамический АГК классов, возникающий при вычислении

(интерпретации) запроса к БД. В статической решетке классов

каждый объект непосредственно принадлежит только одному классу. В

динамической решетке возможны ситуации, когда один объект

(временно) непосредственно принадлежит нескольким классам, только

один из которых входит в статическую решетку классов. Тем не

менее, при интерпретации запроса известно, какой из классов

является основным, т.е. к какому классу в данный момент относится

данный объект. Заметим, что это никак не влияет на свойство

объекта обладать уникальным идентификатором.

Будем считать, что каждый тип обладает функциональной сигнатурой,

т.е. внешняя спецификация типа задается набором прототипов

функций со специфицированными параметрами. Параметры

типизированы, т.е. если параметром некоторой функции сигнатуры

типа является объект, то указывается его тип, а не класс. В

частности, функции типа могут не иметь параметров и это можно



трактовать как возможность прямого доступа (по чтению) к

атрибутам типа. Подобно этому, функция типа может выдавать в

качестве значения объект некоторого типа; класс этого объекта не

специфицируется.

Разделение понятий класса и типа приводит к тому, что для ООБД

одновременно поддерживаются вообще говоря разные АГК классов и

АГК типов. Разная структура этих графов обуславливается,

во-первых, тем, что допускается существование однотипных классов,

не связанных отношением наследования, и во-вторых, тем, что

подкласс класса не обязательно обладает другим типом.

Исходя из введенного набора понятий, сформулируем правила

интерпретации выражений алгебры объектов, операции которой

определены над классами объектов, вырабатывают классы объектов и

включают операции теоретико-множественного объединения,

пересечения, декартова произведения, а также операции селекции и

проекции. Нашей задачей является для каждой из указанных операций

сформулировать условия ее применимости, тип результирующего

класса и его место в получаемой после выполнения операции

динамической решетке классов.

Объединение классов.

Операция объединения классов является двуместной и естественным

условием ее применения является однотипность обоих классов.

Тип результирующего класса совпадает с типом классов-операндов.

После выполнения операции результирующий класс становится

суперклассом обоих классов-операндов. Обозначим классы-операнды A

и B, а результирующий класс - C. Все объекты классов A и B

непосредственно принадлежат также и классу C.

Пересечение классов.

Операция пересечения классов является двуместной и естественным

условием ее применения является однотипность обоих классов.

Тип результирующего класса совпадает с типом классов-операндов.

После выполнения операции результирующий класс становится

подклассом каждого из классов-операндов. Обозначим

классы-операнды A и B, а результирующий класс - C. Все объекты,

непосредственно принадлежащие классу C, непосредственно

принадлежат также и классам A и B.



Декартово произведение классов.

Операция декартова произведения классов является двуместной

и применима к любым двум классам решетки классов (статической

или динамической).

Сигнатура типа результирующего класса производится путем

объединения сигнатур типов классов-операндов. Возможные коллизии

имен функций разрешаются подобно тому, как это делается в

реляционной алгебре для имен атрибутов. Результирующий класс C,

полученный путем декартова произведения класса A на класс B,

включает множество объектов, полученных путем попарного

"склеивания" объектов классов A и B. Объекты класса C являются

вновь созданными временными объектами ООБД и обладают новыми

идентификаторами. Тип класса C является подтипом типов классов A

и B, но класс C не является подклассом ни A, ни B. В динамической

решетке классов его можно считать подклассом только корневого

суперкласса статической решетки.

Заметим, что даже если в статической решетке классов у классов A

и B имеется общий подкласс с тем же типом, что и у C, нельзя

считать, что это и есть класс C, потому что объекты этого класса

могли порождаться совсем другим образом.

Селекция класса.

Операция селекции класса является двуместной и применима к любому

классу A решетки классов (статической или динамической). Вторым

параметром операции является логическое выражение F, построенное

на основе простых предикатов, включающих вызовы функций сигнатуры

типа класса A.

Результирующий класс C обладает тем же типом, что и класс A,

является его подклассом в динамической решетке классов и

непосредственно включает все объекты класса A, для которых

значение логического выражения F есть true.

Проекция класса.

Операция проекции класса является двуместной и применима к любому

классу A решетки классов (статической или динамической). Вторым

параметром операции является подсигнатура сигнатуры типа класса A

(S), т.е. список имен функций, входящих в сигнатуру типа класса

A.

Тип результирующего класса C является супертипом типа класса A с



сигнатурой, полученной путем удаления из сигнатуры типа класса A

функций, указанных в S. Объекты класса C являются вновь

создаваемыми объектами ООБД и обладают новыми идентификаторами.

Хотя тип класса C является супертипом типа класса A, класс С не

является суперклассом класса A. В динамической решетке классов

его можно считать только подклассом корневого класса динамической

решетки классов.

На основе введенного набора операций можно конструировать

выражения алгебры классов. Поскольку семантика элементарных

операций фиксирована, можно однозначно интерпретировать

выражения, если ввести естественные приоритеты операций: высший

приоритет - у операций селекции и проекции, следующий по

старшинству - у операции декартова произведения и низший

приоритет у операций пересечения и объединения.

Заметим, что в общем случае при интерпретации выражения алгебры

объектов потребуется устанавливать структурную эквивалентность

типов промежуточных классов (чтобы определить, например,

возможность объединения двух таких классов). При использовании

функциональных сигнатур классов, если ограничиться одноуровневой

проверкой структурной эквивалентности, эта задача вполне

разрешима.

Конечно, как и в случае реляционных систем, на основе операций

декартова произведения классов и проекции можно определить

операцию соединения классов.

Заметим, что мы не говорим о реализации операций декартова

произведения и проекции классов. Понятно, что в случае декартова

произведения должен образовываться класс объектов, обладающих

свойствами объектов из обоих классов-операндов. Строятся ли эти

составные объекты простой конкатенацией составляющих объектов,

или применяется какая-либо другая техника - это вопрос

оптимизации. Аналогично, проекцию можно реализовывать путем

простого запрета доступа к части функций объекта, а можно

пытаться сокращать внутреннюю структуру объекта.

5. Оптимизация запросов к ООБД

Обычно считают, что проблема оптимизации запросов к ООБД

находится в противоречии с инкапсуляцией объектов, т.е.


неявно

предполагается, что оптимизатор должен полагаться только на

спецификацию объектов и не затрагивать их реализацию.

Обосновывается это требованием обеспечения позднего связывания

(во время выполнения запроса) с объектами, когда во время

компиляции запроса неизвестна реализация операций.

Конечно, это правильно, если поддерживать возможности

переопределения внутренних структур данных и реализации операций

в подтипах в полном объеме. Заметим, однако, что потребности в

полиморфизме такого рода довольно ограничены и можно, например,

потребовать явного указания при определении типа тех операций,

которые допускается переопределять в подтипах.

Тогда при компиляции запроса (выраженного, например, с помощью

предложенной выше алгебры объектов) по типу каждого

класса-операнда можно определить, какие операции и внутренние

структуры данных являются общими для всех подклассов этого

класса.

Поскольку мы не хотим раскрывать инкапсуляцию объектов при

формулировании запросов, предикаты выборки объектов (это касается

оператора селекции) могут задаваться только с привлечением

операций класса (вернее операций типа этого класса). При

компиляции запроса можно отметить те предикаты, в которых

используются операции-инварианты подклассов данного класса.

После этого можно воспользоваться реализацией этих операций для

упрощения предикатов и сведения их в лучшем случае к предикатам

на внутренних атрибутах объектов. Фактически должно быть

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

параметров логического выражения выборки и внутреннего

представления типа. Конечно, технически эта процедура может быть

выполнимой только в том случае, если в качества языка

программирования типов используется язык достаточно высокого

уровня (например, некоторый чисто функциональный или логический

язык).

Литература

Malkolm Atkinson, Francois Bansilhon, David DeWitt, Klaus

Dittrich, David Maier, Stanley Zdonik. The Object-Oriented

Database System Manifesto // 1st Int.


Conf. Deductive and

Object- Oriented Databases, Kyoto, Japan, Dec. 4-6, 1989

Francois Bancilhon. Query Languages for Object-Oriented

Database Systems: Analysis and Proposal // Datanbanksyst. Buro,

Tech. and Wiss.: GI/SI - Fashtag., Zurich, Marz. 1-3, 1989.- 1-18

А. В. Замулин. Системы программирования баз данных и знаний //

Новосибирск: Наука, 1990.- 352 с.

D. Decouchart. Design of a Distributed Object Manager for the

Smalltalk-80 System // Proc. OOPCLA'86, Portland, Oreg., USA,

Sept. 29 - Oct. 2, 1986.- 444-452

Andrew Straw, Fred Mellender, Steve Riegel. Object Management

in a Persistent Smalltalk System // Software Pract. and Exper.-

19, N 8.- 1989.- 719-737

D. Jacob Penney, Jacob Stein. Class Modification in the

GemStone Object-Oriented DBMS // Proc. OOPCLA'87, Orlando, Fla,

USA, Oct. 4-8, 1987.- 111-117

Won Kim, Jay Banerjee, Hong-Tai Chou, Jorge F. Garca, Darrell

Woelk. Composite Object Support in an Object-Oriented Database

System GemStone Object-Oriented DBMS // Proc. OOPCLA'87, Orlando,

Fla, USA, Oct. 4-8, 1987.- 118-125

Won Kim, Jorge F. Garza, Nathaniel Ballou, Darrell Woelk.

Architecture of the ORION Next-Generation Database System // IEEE

Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 109-124

Tomothy Andrews, Craig Harris. Combining Language and Database

Advances in an Object-Oriented Development Environment GemStone

Object-Oriented DBMS // Proc. OOPCLA'87, Orlando, Fla, USA, Oct.

4-8, 1987.- 430-440

Christophe Lecluse, Philippe Richard, Fernando Velez. O2, an

Object-Oriented Data Model // Proc. ACM SIGMOD Int. Conf. Manag.

Data, Chicago, Ill, USA, June 1-3, 1988, ACM SIGMOD Record.- 17,

N 3.- 1988.- 424-433

F. Velez, G. Bernard, V. Darnis. The O2 Object Manager: An

Overview // 15th Int. Conf. Very Large Data Bases, Amsterdam,

Aug. 22-25, 1989.- 357-366

C. Lecluse, P. Richard. The O2 Database Programming Language

// 15th Int. Conf. Very Large Data Bases, Amsterdam, Aug. 22-25,

1989.- 411-422

O. Deux et al. The Story of O2 // IEEE Trans.


Knowledge and

Data Eng.- 2, N 1.- 1990.- 91-108

Gilles Barbedette. LISPO2: A Persistent Object-Oriented LISP

// Advances in Database Technology - EDBT'90.- Lecture Notes in

Computer Science.- 416, 1990.- 332-347

Francois Bancilhon. Query Languages for Object-Oriented

Database Systems: Analysis and Proposal // Datanbanksyst. Buro,

Tech. and Wiss.: GI/SI - Fashtag., Zurich, Marz. 1-3, 1989.- 1-18

E. Laenens, F. Staes, D. Vermeir. Browsing a la carte in

Object-oriented Databases // Computer J.- 32, N 4.- 1989.-

333-340

Catriel Beeri. A Formal Approach to Object-Oriented Databases

// Data and Knowledge Eng.- 5.- 1990.- 353-382

D. D. Chamberlin, R. F. Boyce. SEQUEL: A Structured English

Query Language // ACM SIGMOD Workshop Data Descr., Access,

Contr., Ann Arbol, Mich., USA, May 1974.- 249-264

The Committee for Advanced DBMS Function (Michael

Stonebraker, Bruce Lindsay, Jim Gray, Make Carey, David Beech).

Third Generation Data Base System Manifesto // Proc. ACM SIGMOD

Int. Conf. Manag. Data, Atlanta City, NJ, USA, May 23-25, 1990,

ACM SIGMOD Record.- 19, N 2.- 1990.- 34-43

M. Kifer, G. Lausen. F-Logic: A Higher-Order Language for

Reasoning about Objects, Inheritance, and Scheme // Proc. ACM

SIGMOD Int. Conf. Manag. Data, Portland, Oreg., USA, 1989, ACM

SIGMOD Record.- 18, N 2.- 1989.- 134-146

S. K. Lellani, N. Spiratos. Towards a Categorical Data Model

Supporting Structured Objects and Inheritance // Proc. 1st Int.

East/West Database Workshop, Kiev, Oct. 1990, Lect. Notes Comput.

Sci.- 540.- 1991

Serge Abiteboul. Towards a Deductive Object-Oriented Database

Language // Data and Knowledge Eng.- 5.- 1990.- 263-287

Won Kim. Object-Oriented Databases: Definition and Research

Directions // IEEE Trans. Data and Knowledge Eng.- 2, N 3.-

1990.- 327-341

W. Kim. A Model of Queries for Object-Oriented Databases //

15th Int. Conf. Very Large Data Bases, Amsterdam, Aug. 22-25,

1989.- 423-432

Peter Lyngbaek, Kevin Wilkinson, Waqar Hasan. The Iris Kernel



Architecture // Advances in Database Technology - EDBT'90.-

Lecture Notes in Computer Science.- 416, 1990.- 348-362

Kevin Wilkinson, Peter Lyngbaek, Waqar Hasan. The Iris

Architecture and Implementation // IEEE Trans. Knowledge and Data

Eng.- 2, N 1.- 1990.- 63-75

Sophie Cluet, Claude Delobel, Christophe Lecluse, Philippe

Richard. RELOOP: An Algebra Based Query Language for an

Object-Oriented Database System // Data and Knowledge Eng.- 5.-

1990.- 333-352

Gail M. Shaw, Stanley B. Zdonik. A Query Algebra for

Object-Oriented Databases // 6th Int. Conf. Data Eng., Los

Angeles, Calif., USA, Febr. 5-9, 1990.- 154-162

С. Д. Кузнецов. Методы оптимизации выполнения запросов в

реляционных СУБД // "Вычислительные науки. Т.1 (Итоги науки и

техники ВИНИТИ АН СССР)". М., ВИНИТИ АН СССР, 1989.- 76-153

Stanley Zdonik. Directions in Object-Oriented Databases //

COMPSAC'89 13th Annu. Int. Comput. Software and Appl. Conf.,

Orlando, Fla, Sept. 20-22, 1989.- 200

J. C. Freytag. A Rule-Based View of Query Optimization //

Proc. ACM SIGMOD Int. Conf. Manag. Data, San Francisco, Calif.,

USA, May 27-29, 1987.- 173-180

F. W. M. Tompa, J. I. Icaza. Adaptive Selection of Query

Execution Strategies by Learning Automata // Inf. Sci. (USA).-

50, N 3.- 1990.- 219-240

Объединение миллионов систем баз данных

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

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

Вторым аспектом федеративных систем баз данных является семантика и выполнение запросов. Пользователь может обратиться к федеративной базе данных с 1000 узлами с запросом типа:

"Найти среднее значение заработной платы для сотрудников всего предприятия."

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

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

"Имеются ли действительно хорошие итальянские рестораны на расстоянии не более 5 миль от моего дома?"

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

К третьему аспекту объединения относятся средства, способствующие самому процессу интеграции. Системному администратору должно быть просто добавить свою систему к более крупной федеративной системе. Если базирующийся на технологии Web продавец одежды решает предложить свою одежду для путешествий оперативно доступному туристическому агенту, то системы заказа одежды и платежа должны быть объединены с системами туристического агенства. Для автоматизации этого процесса интеграции требуется, чтобы база данных приложения и определения интерфейсов базы данных были слиты в согласованное целое с помощью средств, помогающих наладить устанавливаемую систему.Стандарт UML (Unified Modelling Language) консорциума OMG представляет собой шаг для достижения возможности выражения таких определений, но для инструментальных средств, поддерживающих улучшенную автоматизацию, требуется поддержка в компьютеризованном виде большего объема семантической информации.

Объектно-ориентированные базы данных

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

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

Объектно-ориентированные базы данных - основные концепции, организация и управление: краткий обзор

Сергей Кузнецов

1. Введение

Направление объектно-ориентированных баз данных (ООБД)

возникло сравнительно давно. Публикации появлялись уже в

середине 1980-х (например, ). Однако наиболее активно это

направление развивается в последние годы. С каждым годом

увеличивается число публикаций и реализованных коммерческих и

экспериментальных систем.

Возникновение направления ООБД определяется прежде всего

потребностями практики: необходимостью разработки сложных

информационных прикладных систем, для которых технология

предшествующих систем БД не была вполне удовлетворительной.

Конечно, ООБД возникли не на пустом месте. Соответствующий

базис обеспечивают как предыдущие работы в области БД, так и

давно развивающиеся направления языков программирования с

абстрактными типами данных и объектно-ориентированных языков

программирования.

Что касается связи с предыдущими работами в области БД, то на

наш взгляд наиболее сильное влияние на работы в области ООБД

оказывают проработки реляционных СУБД и следующее

хронологически за ними семейство БД, в которых поддерживается

управление сложными объектами . Кроме того,

исключительное влияние на идеи и концепции ООБД и, как

кажется, всего объектно-ориентированного подхода оказал подход

к семантическому моделированию данных (например, , хотя

общее число публикаций по семантическому моделированию

поистине безгранично). Достаточное влияние оказывают также

развивающиеся параллельно с ООБД направления дедуктивных и

активных БД .

Среди языков и систем программирования наибольшее первичное

влияние на ООБД оказал Smalltalk . Этот язык сам по

себе не является полностью пионерским, хотя в нем была введена

новая терминология, являющаяся теперь наиболее

распространенной в объектно-ориентированном программировании.

На самом деле, Smalltalk основан на ряде ранее выдвинутых

концепций. Хороший обзор идей и подходов

объектно-ориентированного программирования представлен,

например, в .

Большое число работ не означает, что все проблемы ООБД

полностью решены. Как отмечается в Манифесте группы ведущих

ученых, занимающихся ООБД, современная ситуация с ООБД

напоминает ситуацию с реляционными системами середины 1970-х.

При наличии большого количества экспериментальных проектов (и

даже коммерческих систем) отсутствует общепринятая

объектно-ориентированная модель данных, и не потому, что нет

ни одной разработанной полной модели, а по причине отсутствия

общего согласия о принятии какой-либо модели. На самом деле,

имеются и более конкретные проблемы (например, ),

связанные с разработкой декларативных языков запросов,

выполнением и оптимизацией запросов, формулированием и

поддержанием ограничений целостности, синхронизацией доступа и

управлением транзакциями и т.д.

Тематика ООБД очень широка, объем настоящего обзора не

позволяет рассмотреть все вопросы. Тем не менее, мы

постараемся в систематической манере проанализировать наиболее

важные аспекты ООБД (критерии отбора тем и источников

полностью субъективны). Обзор построен по следующему плану:

Первый раздел - настоящее введение. Во втором разделе

излагаются основные понятия объектно-ориентированного подхода

и их специфическое преломление в контексте ООБД. В третьем

разделе рассматриваются основные понятия

объектно-ориентированного моделирования данных. Четвертый

раздел посвящен языкам программирования и языкам запросов

ООБД. В пятом разделе кратко обозреваются характерные

представители объектно-ориентированных СУБД - ORION и O2.

Шестой раздел посвящается проблематике выполнения и

оптимизации запросов к ООБД. В седьмом разделе рассматриваются

вопросы синхронизации доступа и управления транзакциями в

ООБД. Восьмой раздел касается связи ООБД и дедуктивных и

активных БД. Наконец, девятый раздел - краткое заключение.

2. Общие понятия объектно-ориентированного подхода и их

преломление в ООБД

В наиболее общей и классической постановке

объектно-ориентированный подход базируется на концепциях:

объекта и идентификатора объекта;

атрибутов и методов;



классов;

иерархии и наследования классов.

Любая сущность реального мира в объектно-ориентированных

языках и системах моделируется в виде объекта. Любой объект

при своем создании получает генерируемый системой уникальный

идентификатор, который связан с объектом во все время его

существования и не меняется при изменении состояния объекта.

Каждый объект имеет состояние и поведение. Состояние объекта -

набор значений его атрибутов. Поведение объекта - набор

методов (программный код), оперирующих над состоянием объекта.

Значение атрибута объекта - это тоже некоторый объект или

множество объектов. Состояние и поведение объекта

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

производится на основе передачи сообщений и выполнении

соответствующих методов.

Множество объектов с одним и тем же набором атрибутов и

методов образует класс объектов. Объект должен принадлежать

только одному классу (если не учитывать возможности

наследования, см. следующий абзац). Допускается наличие

примитивных предопределенных классов, объекты-экземляры

которых не имеют атрибутов: целые, строки и т.д. Класс,

объекты которого могут служить значениями атрибута объектов

другого класса, называется доменом этого атрибута.

Допускается порождение нового класса на основе уже

существующего класса - наследование. В этом случае новый

класс, называемый подклассом существующего класса

(суперкласса) наследует все атрибуты и методы суперкласса. В

подклассе, кроме того, могут быть определены дополнительные

атрибуты и методы. Различаются случаи простого и

множественного наследования. В первом случае подкласс может

определяться только на основе одного суперкласса, во втором

случае суперклассов может быть несколько. Если в языке или

системе поддерживается единичное наследование классов, набор

классов образует древовидную иерархию. При поддержании

множественного наследования классы связаны в ориентированный

граф с корнем, называемый решеткой классов. Объект подкласса

считается принадлежащим любому суперклассу этого класса.



Одной из более поздних идей объектно-ориентированного подхода

является идея возможного переопределения атрибутов и методов

суперкласса в подклассе (перегрузки методов). Эта возможность

увеличивает гибкость, но порождает дополнительную проблему:

при компиляции объектно-ориентированной программы могут быть

неизвестны структура и программный код методов объекта, хотя

его класс (в общем случае - суперкласс) известен. Для

разрешения этой проблемы применяется так называемый метод

позднего связывания, означающий, по сути дела,

интерпретационный режим выполнения программы с распознаванием

деталей реализации объекта во время выполнения посылки

сообщения к нему. Введение некоторых ограничений на способ

определения подклассов позволяет добиться эффективной

реализации без потребностей в интерпретации .

Как видно, при таком наборе базовых понятий, если не принимать

во внимание возможности наследования классов и соответствующие

проблемы, объектно-ориентированный подход очень близок к

подходу языков программирования с абстрактными (или

произвольными) типами данных .

С другой стороны, если абстрагироваться от поведенческого

аспекта объектов, объектно-ориентированный подход весьма

близок к подходу семантического моделирования данных

(даже и по терминологии). Фундаментальные абстракции, лежащие

в основе семантических моделей, неявно используются и в

объектно-ориентированном подходе. На абстракции агрегации

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

которых могут быть другие объекты. Абстракция группирования -

основа формирования классов объектов. На абстракциях

специализации/обобщения основано построение иерархии или

решетки классов.

Видимо, наиболее важным новым качеством ООБД, которое

позволяет достичь объектно-ориентированный подход, является

поведенческий аспект объектов. В прикладных информационных

системах, основывавшихся на БД с традиционной организацией

(вплоть до тех, которые базировались на семантических моделях

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



поведенческой частями. Структурная часть системы

поддерживалась всем аппаратом БД, ее можно было моделировать,

верифицировать и т.д., а поведенческая часть создавалась

изолированно. В частности, отсутствовали формальный аппарат и

системная поддержка совместного моделирования и гарантирования

согласованности этих структурной (статической) и поведенческой

(динамической) частей. В среде ООБД проектирование, разработка

и сопровождение прикладной системы становится процессом, в

котором интегрируются структурный и поведенческий аспекты.

Конечно, для этого нужны специальные языки, позволяющие

определять объекты и создавать на их основе прикладную систему

.

Специфика применения объектно-ориентированного подхода для

организации и управления БД потребовала уточненного толкования

классических концепций и некоторого их расширения . Это

определяется потребностями долговременного хранения объектов

во внешней памяти, ассоциативного доступа к объектам,

обеспечения согласованного состояния ООБД в условиях

мультидоступа и тому подобных возможностей, свойственных базам

данных . В выделяются три аспекта, отсутствующие в

традиционной парадигме, но требующиеся в ООБД.

Первый аспект касается потребности в средствах спецификации

знаний при определении класса (ограничений целостности, правил

дедукции и т.п.) Второй аспект - потребность в механизме

определения разного рода семантических связей между объектами

вообще говоря разных классов. Фактически это означает

требование полного распространения на ООБД средств

семантического моделирования данных. Потребность в

использовании абстракции ассоциирования отмечается и в связи с

использовании ООБД в сфере автоматизированного проектирования

и инженерии . Наконец, третий аспект связан с пересмотром

понятия класса. В контексте ООБД оказывается более удобным

рассматривать класс как множество объектов данного типа, т.е.

одновременно поддерживать понятия и типа и класса объектов.

Как мы отмечали во введении, в сообществе исследователей ООБД



и разработчиков систем отсутствует полное согласие, но в

большинстве практических работ используется некоторое

расширение объектно-ориентированного подхода.

3. Объектно-ориентированные модели данных

Первой формализованной и общепризнанной моделью данных была

реляционная модель Кодда . В этой модели, как и во всех

следующих, выделялись три аспекта - структурный, целостный и

манипуляционный. Структуры данных в реляционной модели

основываются на плоских нормализованных отношениях,

ограничения целостности выражаются с помощью средств логики

первого порядка и, наконец, манипулирование данными

осуществляется на основе реляционной алгебры или равносильного

ей реляционного исчисления. Как отмечают многие исследователи,

своим успехом реляционная модель данных во многом обязана

тому, что опиралась на строгий математический аппарат теории

множеств, отношений и логики первого порядка. Разработчики

любой конкретной реляционной системы считали своим долгом

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

реляционной модели, которая выступала в качестве меры

"реляционности" системы.

Основные трудности объектно-ориентированного моделирования

данных проистекают из того, что такого развитого

математичекого аппарата, на который могла бы опираться общая

объектно-ориентированная модель данных, не существует. В

большой степени поэтому до сих пор нет базовой

объектно-ориентированной модели. С другой стороны, в со

ссылкой на недоступную нам работу Майера утверждается,

что общая объектно-ориентированная модель данных в

классическом смысле и не может быть определена по причине

непригодности классического понятия модели данных к парадигме

объектной ориентированности.

Не приводя доводов в пользу этого утверждения Майера, но и не

оспаривая его, Беери предлагает в общих чертах формальную

основу ООБД, далеко не полную и не являющуюся моделью данных в

традиционном смысле, но позволяющую исследователям и

разработчикам систем ООБД по крайней мере говорить на одном



языке (если, конечно, предложения Беери будут развиты и

получат поддержку). Независимо от дальнейшей судьбы этих

предложений мы считаем полезным кратко их пересказать.

Во-первых, следуя практике многих ООБД, предлагается выделить

два уровня моделирования объектов: нижний (структурный) и

верхний (поведенческий). На структурном уровне поддерживаются

сложные объекты, их идентификация и разновидности связи "isa".

База данных - это набор элементов данных, связанных

отношениями "входит в класс" или "является атрибутом". Таким

образом, БД может рассматриваться как ориентированный граф.

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

понятия значения (позже мы увидим, как много на этом построено

в одной из успешных объектно-ориентированных СУБД O2 ).

Важным аспектом является четкое разделение схемы БД и самой

БД. В качестве первичных концепций схемного уровня ООБД

выступают типы и классы. Отмечается, что во всех системах,

использующих только одно понятие (либо тип, либо класс) это

понятие неизбежно перегружено: тип предполагает наличие

некоторого множества значений, определяемого структурой данных

этого типа; класс также предполагает наличие множества

объектов, но это множество определяется пользователем. Таким

образом, типы и классы играют разную роль, и для строгости и

недвусмысленности требуются одновременное поддержание обоих

понятий.

Автор не представляет полной формальной модели

структурного уровня ООБД, но выражает уверенность, что

текущего уровня понимания достаточно, чтобы формализовать

такую модель. Что же касается поведенческого уровня, предложен

только общий подход к требуемому для этого логическому

аппарату (логики первого уровня недостаточно).

Важным, хотя и недостаточно обоснованным предположением Беери

является то, что двух традиционных уровней - схемы и данных

для ООБД недостаточно. Для точного определения ООБД требуется

уровень мета-схемы (см. также ), содержимое которой должно



определять виды объектов и связей, допустимых на схемном

уровне БД. Мета- схема должна играть для ООБД такую же роль,

какую играет структурная часть реляционной модели данных для

схем реляционных баз данных.

Имеется достаточное количество других публикаций, относящихся

к теме объектно-ориентированных моделей данных , но они либо затрагивают достаточно частные вопросы,

либо используют слишком серьезный для этого обзора

математический аппарат (к числу последних относится работа

Леллани и Спиратоса , в которой объектно-ориентированная

модель данных определяется на основе теории категорий).

Для иллюстрации текущего положения дел мы кратко рассмотрим

особенности конкретной модели данных, применяемой в

объектно-ориентированной СУБД O2 (это, конечно, тоже

не модель данных в классическом смысле).

В O2 поддерживаются объекты и значения. Объект - это пара

(идентификатор, значение), причем объекты инкапсулированы,

т.е. их значения доступны только через методы - процедуры,

привязанные к объектам. Значения могут быть атомарными или

структурными. Структурные значения строятся из значений или

объектов, представленных своими идентификаторами, с помощью

конструкторов множеств, кортежей и списков. Элементы

структурных значений доступны с помощью предопределенных

операций (примитивов).

Возможны два вида организации данных: классы, экземплярами

которых являются объекты, инкапсулирующие данные и поведение,

и типы, экземплярами которых являются значения. Каждому классу

сопоставляется тип, описывающий структуру экземпляров класса.

Типы определяются рекурсивно на основе атомарных типов и ранее

определенных типов и классов с применением конструкторов.

Поведенческая сторона класса определяется набором методов.

Объекты и значения могут быть именованными. С именованием

объекта или значения связана долговременность его хранения

(persistency): любые именованные объекты или значения

долговременны; любые объект или значение, входящие как часть в

другой именованный объект или значение, долговременны.



С помощью специального указания, задаваемого при определении

класса, можно добиться долговременности хранения любого

объекта этого класса. В этом случае система автоматически

порождает значение-множество, имя которого совпадает с именем

класса. В этом множестве гарантированно содержатся все объекты

данного класса.

Метод - программный код, привязанный к конкретному классу и

применимый к объектам этого класса. Определение метода в O2

производится в два этапа. Сначала объявляется сигнатура

метода, т.е. его имя, класс, типы или классы аргументов и тип

или класс результата. Методы могут быть публичными (доступными

из объектов других классов) или приватными (доступными только

внутри данного класса). На втором этапе определяется

реализация класса на одном из языков программирования O2

(подробнее языки обсуждаются в следующем разделе нашего

обзора).

В модели O2 поддерживается множественное наследование классов

на основе отношения супертип/подтип. В подклассе допускается

добавление и/или переопределение атрибутов и методов.

Возможные при множественном наследовании двусмысленности (по

именованию атрибутов и методов) разрешаются либо путем

переименования, либо путем явного указания источника

наследования. Объект подкласса является объектом каждого

суперкласса, на основе которого порожден данный подкласс.

Поддерживается предопределенный класс "Оbject", являющийся

корнем решетки классов; любой другой класс является неявным

наследником класса "Object" и наследует предопределенные

методы ("is_same", "is_value_equal" и т.д.).

Специфической особенностью модели O2 является возможность

объявления дополнительных "исключительных" атрибутов и методов

для именованных объектов. Это означает, что конкретный

именованный объект-представитель класса может обладать типом,

являющимся подтипом типа класса. Конечно, с такими атрибутами

не работают стандартные методы класса, но специально для

именованного объекта могут быть определены дополнительные (или



переопределены стандартные) методы, для которых дополнительные

атрибуты уже доступны. Подчеркивается, что дополнительные

атрибуты и методы привязываются не к конкретному объекту, а к

имени, за которым в разные моменты времени могут стоять вообще

говоря разные объекты. Для реализации исключительных атрибутов

и методов требуется развитие техники позднего связывания.

В приводится достаточно формализованное описание модели

O2, мы для простоты изложения и понимания следовали , где

модель описывается на содержательном уровне. В следующем

разделе мы среди прочего рассмотрим особенности языков

программирования и запросов системы O2, которые, конечно,

тесно связаны со спецификой модели данных.

4. Языки программирования систем ООБД и языки запросов

Как отмечают многие исследователи и разработчики (например,

), объектно-ориентированная система БД представляет

собой объединение системы программирования и СУБД

(альтернативная, но не более проясняющая суть дела точка

зрения состоит в том, что объектно-ориентированная СУБД - это

СУБД, основанная на объектно-ориентированной модели данных

).

Мы уже говорили, что основная практическая надобность в ООБД

связана с потребностью в некоторой интегрированной среде

построения сложных информационных систем. В этой среде должны

отсутствовать противоречия между структурной и поведенческой

частями проекта и должно поддерживаться эффективное управление

сложными структурами данных во внешней памяти. С этой точки

зрения языковая среда ООБД - это объектно-ориентированная

система программирования, естественно включающая средства

работы с долговременными объектами. "Естественность" включения

средств работы с БД в язык программирования означает, что

работа с долговременными (хранимыми во внешней БД) объектами

должна происходить на основе тех же синтаксических конструкций

(и с той же семантикой), что и работа со временными,

существующими только во время работы программы объектами.

Эта сторона ООБД наиболее близка родственному направлению



языков программирования БД . Языки программирования ООБД и

БД во многих своих чертах различаются только терминологически;

существенным отличием является лишь поддержание в языках

первого класса подхода к наследованию классов. Кроме того,

языки второго класса, как правило, более развиты как в

отношении системы типов, так и в отношении управляющих

конструкций.

Другим аспектом языкового окружения ООБД является потребность

в языках запросов, которые можно было бы использовать в

интерактивном режиме. Если доступ к объектам внешней БД в

языках программирования ООБД носит в основном навигационный

характер, то для языков запросов более удобен декларативный

стиль. Декларативные языки запросов к ООБД менее развиты, чем

языки программирования ООБД, и при их реализации возникают

существенные проблемы. Ниже мы рассмотрим имеющиеся подходы и

их ограничения более подробно. Но начнем с языков

программирования ООБД.

К моменту написания данного обзора нам неизвестен какой-либо

язык программирования ООБД, который был бы спроектирован

целиком заново, начиная с нуля. Естественным подходом к

построению такого языка было использование (с необходимыми

расширениями) некоторого существующего

объектно-ориентированного языка. Начало расцвета направления

ООБД совпало с пиком популярности языка Smalltalk-80. Этот

язык оказал большое влияние на разработку первых систем ООБД,

и, в частности, использовался в качестве языка

программирования . Во многом опирается на Smalltalk и

известная коммерчески доступная система GemStone .

Трудности с эффективной практической реализацией языка

Smalltalk побудили разработчиков систем ООБД к поиску

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

объектно-ориентированного и функционального подходов к

программированию позволяет достаточно успешно опираться на

функциональные языки программирования. В частности, язык Лисп

(Common Lisp) является основой проекта ORION . В этом

проекте Лисп является и инструментальным языком, и базой



объектно-ориентированного языка программирования в среде

ORION.

Потребности в еще более эффективной реализации заставляют

использовать в качестве основы объектно-ориентированного языка

языки более низкого уровня. Например, в системе VBASE

наряду со специально разработанным языком TDL, предназначенным

для определения типов, используется объектно-ориентированное

расширение языка Си - COP (C Object Processor). В уже

упоминавшемся проекте O2 наряду с функциональным

объектно-ориентированным языком программирования

используются два объектно-ориентированных расширения языков

Бейсик и Си. При этом, насколько можно судить по публикациям,

наибольшее распространение среди пользователей этой системы

(она уже коммерчески доступна) получил язык CO2, являющийся

расширением языка Си. Возможно это связано лишь с широкой (и

все более возрастающей) популярностью языка Си (и его

объектно-ориентированного потомка Си++), ставшего поистине

девизом "настоящих программистов". Может быть, причины более

глубинны (например, языки более высокого уровня слишком

ограничительны для программистов-профессионалов; недаром

большинство современных реализаций языков более высокого

уровня выполняются именно на языке Си). Тем не менее,

современная ситуация именно такова, и мы считаем полезным

привести краткое описание основных особенностей языка CO2

.

Прежде всего, CO2 не является полностью самостоятельным

языком. Этот язык входит во многоязыковую среду O2 и

предназначен для программирования методов ранее определенных

классов. Определение классов, сигнатур методов (фактически,

прототипов функций в терминологии языка Си) и имен постоянно

хранимых значений и объектов производится с использованием

отдельного языка определения схемы БД.

Имя любого объекта трактуется как указатель на значение этого

объекта; разыменование производится с помощью обычного

оператора Си '*'. Доступ к значению объекта возможен только из

метода его класса, если только при перечислении методов



оператор '*' не объявлен явно публичным.

Поддерживается операция порождения нового объекта указанного

класса. В отличие от языка Си++ в CO2 невозможно совместить

создание нового объекта с его инициализаций (понятие

метода-конструктора начального значения объекта в CO2 не

поддерживается). Для инициализации необходимо либо явно

обратиться к соответствующему методу класса с указанием вновь

созданного объекта (поддерживается соответствующий механизм

"передачи сообщений", означающий на самом деле вызов функции),

либо воспользоваться оператором '*' и явно присвоить новое

значение, если '*' - публичный оператор для данного класса.

CO2 включает средства конструирования значений-кортежей,

множеств, и списков. Понятие значения-кортежа фактически

эквивалентно понятию значения-структуры обычного языка Си (с

тем отличием, что элементами кортежа могут являться объекты,

множества и списки). Для значений-множеств и списков

поддерживаются операции добавления и изъятия элементов, а

также набор теоретико-множественных операций (и конкатенации

для списков).

Основой манипулирования объектами, хранимыми в БД, является

расширенное по сравнению с языком Си средство итерации.

Итератор применим к значениям-множествам или спискам.

Фактически он означает последовательное применение

оператора-тела цикла ко всем элементам множества или списка.

Если мы вспомним, что долговременно хранимому классу объектов

неявно соответствует одноименное значение-множество с

элементами-объектами данного класса, то становится понятно,

что итератор языка CO2 обеспечивает явную навигацию в классах

объектов. Единственное, что остается от привычных

пользователям СУБД языков запросов, - это ограниченная

возможность указания характеристик требуемых в цикле объектов

(это делается путем использования оператора разыменования и

явного указания условий на атрибуты; конечно, для этого нужно,

чтобы оператор '*' был объявлен публичным в данном классе).

Разработчики O2 подчеркивают, что они умышленно сделали CO2



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

что многое по части управления объектами берет на себя общий

менеджер объектов системы, явно вызываемый из рабочей

программы.

Потребность в поддержании в объектно-ориентированной СУБД не

только языка (или семейства языков) программирования ООБД, но

и развитого языка запросов в настоящее время осознается

практически всеми разработчиками. Система должна поддерживать

легко осваиваемый интерфейс, прямо доступный конечному

пользователю в интерактивном режиме. Один из подходов

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

конечный интерфейс обычно является графическим. На экране

отображается схема (или подсхема) ООБД, и пользователь

осуществляет доступ к объектам в навигационном стиле. По

мнению Бансилона в этом случае разумно игнорировать

принцип инкапсуляции объектов и предъявлять пользователю

внутренность объектов. В большинстве существующих систем ООБД

подобный интерфейс существует, но всем понятно, что

навигационный язык запросов - это в некотором смысле шаг назад

по сравнению с языками запросов даже реляционных систем.

Ведутся активные поиски подходов к организации декларативных

языков запросов к ООБД.

Беери отмечает существование трех подходов. Первый подход

- языки, являющиеся объектно-ориентированными расширениями

языков запросов реляционных систем. Наиболее распространены

языки с синтаксисом, близким к известному языку SQL . Это

связано, конечно, с общим признанием и чрезвычайно широким

распространением этого языка. В частности, в своем Манифесте

третьего поколения СУБД М. Стоунбрекер и его коллеги по

комитету перспективных систем БД утверждают необходимость

поддержания SQL-подобного интерфейса во всех СУБД следующего

поколения.

Второй подход основывается на построении полного логического

объектно-ориентированного исчисления. По поводу построения

такого исчисления имеются теоретические работы (например,

), но законченный и практически реализованный язык

запросов нам неизвестен.


Видимо, к этому же направлению строго

теоретически обоснованных языков запросов можно отнести и

работу Леллани и Спиратоса , основанную на алгебраической

теории категорий.

Наконец, третий подход основывается на применении дедуктивного

подхода. В основном это отражает стремление разработчиков к

сближению направлений дедуктивных и объектно-ориентированных

БД. Примером простого дедуктивного объектно-ориентированного

языка запросов может служить .

Независимо от применяемого для разработки языка запросов

подхода перед разработчиками встает одна концептуальная

проблема, решение которой не укладывается в традиционное русло

объектно-ориентированного подхода. Понятно, что основой для

формулирования запроса должен служить класс, представляющий в

ООБД множество однотипных объектов. Но что может представлять

собой результат запроса? Набор основных понятий

объектно-ориентированного подхода не содержит подходящего к

данному случаю понятия. Обычно из положения выходят, расширяя

базовый набор концепций концепцией множества объектов и

полагая, что результатом запроса является некоторое

подмножество объектов-экземпляров класса. Это довольно

ограничительный подход, поскольку автоматически исключает

возможность наличия в языке запросов средств, аналогичных

реляционному оператору соединения. В конце этого раздела мы

коротко изложим собственные (в достаточной степени

предварительные) соображения по этому поводу, но сначала

кратко рассмотрим особенности нескольких конкретных

декларативных языков запросов к ООБД.

В языке запросов объектно-ориентированной СУБД ORION

полностью поддерживается принцип инкапсуляции объектов. В

реализованном варианте языка запросы могут основываться только

на одном классе (хотя в описывается подход к определению

запроса на нескольких классах в стиле расширения семантики

реляционного оператора соединения). Синтаксис языка

ориентирован на SQL. Очень развит набор допустимых предикатов

селекции. В частности, для атрибута, доменом которого является



суперкласс, можно указать имя интересующего пользователя

подкласса.

Язык запросов системы Iris находится в значительной

степени под влиянием реляционной парадигмы. Даже название

этого языка OSQL отражает его тесную связь с реляционным

языком SQL. По сути дела, OSQL - это реляционный язык,

рассчитанный на работу с ненормализованными отношениями.

Естественно, при таком подходе в OSQL нарушается инкапсуляция

объектов.

На наш взгляд, особый интерес представляет декларативный язык

запросов системы O2 RELOOP . В общих словах, это

декларативный язык запросов с SQL-ориентированным синтаксисом,

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

объектов и значений. (Кстати, это не единственная работа в

направлении построения алгебры для объектно-ориентированных

моделей данных. См., например, .) На наш взгляд, особенно

впечатляющим качеством языка RELOOP является естественность

его построения в общем контексте модели O2. Запрос задается

всегда на значении-множестве или списке. Если мы вспомним, что

долговременному классу в O2 соответствует одноименное

значение-множество, то тем самым можно определить запрос на

любом хранимом классе. Результатом запроса может являться

объект, значение-множество или значение-список. При этом

элементами значений-множеств могут являться объекты (простая

выборка), либо значения-кортежи с элементами-объектами разных

классов (например). В совокупности эти особенности языка

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

(специфическое соединение, порождающее не новые объекты, а

кортежи из существующих объектов), а также употреблять

вложенные подзапросы.

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

состоит в том, чтобы попытаться построить алгебру классов

объектов, оставаясь в пределах базового набора концепций

объектно-ориентированного подхода. Для этого достаточно, чтобы

была возможность интерпретации результата выполнения

алгебраической операции над классами в виде класса.

Предлагаемый подход, аналогично модели O2, частично



основывается на семантике включения, т.е. суперкласс как

множество объектов включает все множества объектов подклассов,

хотя некоторые операции не соответствуют этой семантике.

Идея нашего предложения основывается на следующем наблюдении.

Среди операций реляционной алгебры имеются два вида операций:

теретико-множественные операции и операция селекции формируют

из операндов-отношений отношение-результат с той же схемой;

операции же проекции и соединения формируют

отношение-результат со схемой, которая в общем случае не

описывалась статически в составе схемы БД, т.е. в другой

терминологии эти операции формируют не только значение, но и

тип этого значения. И это не вызывает никакой двусмысленности,

потому что схему отношения-результата (тип результата) можно

определить в статике до выполнения операции.

Встает вопрос: почему бы не попытаться распространить подобный

подход на классы объектов? Возможно, например, следующее

неформальное определение алгебры классов объектов. Эта алгебра

включает набор теоретико-множественных операций, а также

операции декартова произведения, селекции и проекции.

Теоретико-множественные операции определяются для "однотипных"

классов, и класс результата помещается в решетку классов схемы

БД в соответствии с семантикой включения. (Во время вычисления

алгебраического выражения одновременно формируется

соответствующий временный вариант решетки классов.) Операция

декартова произведения формирует класс, включающий объединение

наборов методов классов-операндов и являющийся их подклассом.

Операция селекции формирует класс, являющийся подклассом

класса-операнда. Операция проекции формирует класс, включающий

указанное подмножество методов класса-операнда и являющийся

его суперклассом. С использованием операций декартова

произведения и проекции можно определить операцию соединения

классов. Можно расширить алгебру операцией присваивания, и в

этом случае класс, которому присваивается результат

алгебраического выражения должен быть определен в схеме БД



заранее.

Мы не рассматриваем вопрос возможной реализации подобной

алгебры, которая, конечно, вызывает много проблем. (Как,

например, должно отразиться выполнение операции проекции на

внутренней структуре объектов класса-результата?) Но внешняя

семантика операций определяется однозначно. Наши предложения

имеют весьма предварительный характер, но по нашему мнению

заслуживают хотя бы обсуждения.

5. Объектно-ориентированные СУБД

В настоящее время ведется очень много экспериментальных и

производственных работ в области объектно-ориентированных СУБД

. Больше всего университетских работ, которые в

основном носят исследовательский характер. Но уже год назад

отмечалось существование по меньшей мере тринадцати

коммерчески доступных систем ООБД . Среди них уже

упоминавшиеся в нашем обзоре системы O2 (французский

консорциум Altair) , ORION (американская компания MCC)

, GemStone (американская фирма Servio Logic) и

Iris (Hewlett-Packard) . К сожалению, по поводу многих

коммерческих систем практически отсутствуют доступные

публикации, но и имеющейся информации достаточно, чтобы

охарактеризовать типовую организацию современной

объектно-ориентированной СУБД.

Прежде, чем перейти к обсуждению организации некоторых

объектно-ориентированных СУБД, коротко рассмотрим оказавшие на

них влияние предшествующие архитектуры СУБД, а также

архитектуры, не являющиеся в традиционном понимании

объектно-ориентированными, но близкие по прагматике.

Из числа архитектур с традиционной организацией наибольшее

влияние на объектно-ориентированные СУБД оказали реляционные

системы. Многие объектно-ориентированные системы (по крайней

мере в прототипных вариантах) строятся над некоторой

существующей реляционной СУБД . Кроме такого

применения реляционных систем для упрощения разработки

объектно-ориентированной СУБД, развитые в реляционных СУБД

методы применяются и в заново разрабатываемых

объектно-ориентированных системах.

Непосредственным предшественником объектно-ориентированных



СУБД являются системы, поддерживающие организацию сложных

объектов . Эти постреляционные системы большей частью

появились по причине несоответствия возможностей реляционных

СУБД потребностям нетрадиционных приложений (автоматизация

проектирования, инженерия и т.д.). По сути дела, в таких

системах частично поддерживается структурная часть ООБД (без

возможностей наследования). Многие объектно-ориентированные

СУБД (в частности, ORION) разрабатывались на базе предыдущих

работ со сложными объектами.

Другой основой объектно-ориентированных СУБД являются так

называемые расширяемые системы . Основная идея таких

систем состоит в поддержании набора модулей с четко

оговоренными интерфейсами, на базе которого можно быстро

построить СУБД, опирающуюся на конкретную модель данных или

предназначенную для конкретной области применений. В

частности, как показывает опыт системы EXODUS , средства

расширяемых систем хорошо пригодны и для построения

объектно-ориентированной СУБД.

Наконец, коснемся направления третьего поколения СУБД . Как

явствует из Манифеста третьего поколения, сторонники этого

направления придерживаются принципа эволюционного развития

возможностей СУБД без коренной ломки предыдущих подходов и с

сохранением преемственности с системами предыдущего поколения.

Тем не менее, несмотря на отличающуюся терминологию и

смещенные акценты, системы третьего поколения не так уж далеки

от объектно-ориентированных СУБД.

Одной из наиболее известных СУБД третьего поколения является

система POSTGRES , а создатель этой системы М.

Стоунбрекер, по всей видимости, является вдохновителем всего

направления. В POSTGRES реализованы многие интересные

средства: поддерживается темпоральная модель хранения и

доступа к данным и в связи с этим абсолютно пересмотрен

механизм журнализации изменений, откатов транзакций и

восстановления БД после сбоев; обеспечивается мощный механизм

ограничений целостности; поддерживаются ненормализованные

отношения (работа в этом направлении началась еще в среде



INGRES ).

Но одно свойство системы POSTGRES действительно сближает ее с

объектно-ориентированными СУБД. В POSTGRES допускается

хранение в полях отношений данных абстрактных, определяемых

пользователями типов. Это обеспечивает возможность внедрения

поведенческого аспекта в БД, т.е. решает ту же задачу, что и

ООБД, хотя, конечно, семантические возможности модели данных

POSTGRES существенно слабее, чем у объектно-ориентированных

моделей данных.

Перейдем теперь к чисто объектно-ориентированным СУБД. Мы

рассмотрим особенности организации двух таких систем - ORION

и O2 .

Проект ORION осуществлялся с 1985 по 1989 г. фирмой MCC под

руководством известного еще по работам в проекте System R Вона

Кима. Под названием ORION на самом деле скрывается семейство

трех СУБД: ORION-1 - однопользовательская система; ORION-1SX,

предназначенная для использования в качестве сервера в

локальной сети рабочих станций; ORION-2 - полностью

распределенная объектно-ориентированная СУБД. Реализация всех

систем производилась с использованием языка Common Lisp на

рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС

Genera 7.0 и SUN-3 в среде ОС UNIX. Описание реализации

ORION-2 пока не опубликовано, поэтому мы рассмотрим только

ORION-1 и ORION-1SX.

Основными функциональными компонентами системы являются

подсистемы управления памятью, объектами и транзакциями. В

ORION-1 все компоненты, естественно, располагаются в одной

рабочей станции; в ORION-1SX - разнесены между разными

рабочими станциями (в частности, управление объектами

производится в рабочей станции-клиенте). Применение в

ORION-1SX для взаимодействия клиент-сервер механизма

удаленного вызова процедур позволило использовать в этой

системе практически без переделки многие модули ORION-1.

Сетевые взаимодействия основывались на стандартных средствах

операционных систем.

В число функций подсистемы управления памятью входит

распределение внешней памяти, перемещение страниц из буферов

оперативной памяти во внешнюю память и наоборот, поиск и



размещение объектов в буферах оперативной памяти (как принято

в объектно-ориентированных системах, поддерживаются два

представления объектов - дисковое и в оперативной памяти; при

перемещении объекта из буфера страниц в буфер объектов и

обратно представление объекта изменяется). Кроме того, эта

подсистема ответственна за поддержание вспомогательных

индексных структур, предназначенных для ускорения выполнения

запросов.

Подсистема управления объектами включает подкомпоненты

обработки запросов, управления схемой и версиями объектов.

Версии поддерживаются только для объектов, при создании

которых такая необходимость была явно указана. Для схемы БД

версии не поддерживаются; при изменении схемы отслеживается

влияние этого изменения на другие компоненты схемы и на

существующие объекты. При обработке запросов используется

техника оптимизации, аналогичная применяемой в реляционных

системах (т.е. формируется набор возможных планов выполнения

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

выполнения наиболее дешевый) .

Подсистема управления транзакциями обеспечивает традиционную

сериализуемость транзакций, а также поддерживает средства

журнализации изменений и восстановления БД после сбоев. Для

сериализации транзакций применяется разновидность двухфазного

протокола синхронизационных захватов с различной степенью

гранулированности . Конечно, при синхронизации

учитывается специфика ООБД, в частности, наличие иерархии

классов. Журнал изменений обеспечивает откаты индивидуальных

транзакций и восстановление БД после мягких сбоев (архивные

копии БД для восстановления после поломки дисков не

поддерживаются).

Проект O2 реализуется французской компанией Altair,

образованной специально для целей проектирования и реализации

объектно-ориентированной СУБД. Начало проекта датируется

сентябрем 1986 г., и он был рассчитан на пять лет: три года на

прототипирование и два года на разработку промышленного

образца. Текущий прототип системы функционирует в режиме



клиент/сервер в локальной сети рабочих станций SUN c

соответствующим разделением функций между сервером и

клиентами.

Основными компонентами системы (не считая развитого набора

интерфейсных средств) являются интерпретатор запросов и

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

дисками, т.е. поддержание базовой среды постоянного хранения

обеспечивает система WiSS , которую разработчики O2

перенесли в окружение ОС UNIX.

Наибольшую функциональную нагрузку несет компонент управления

объектами. В число функций этой подсистемы входит:

управление сложными объектами, включая создание и

уничтожение объектов, выборку объектов по именам, поддержку

предопределенных методов, поддержку объектов со внутренней

структурой-множеством, списком и кортежем;

управление передачей сообщений между объектами;

управление транзакциями;

управление коммуникационной средой (на базе транспортных

протоколов TCP/IP в локальной сети Ethernet);

отслеживание долговременно хранимых объектов (напомним, что

в O2 объект хранится во внешней памяти до тех пор, пока

достижим из какого-либо долговременно хранимого объекта);

управление буферами оперативной памяти (аналогично ORION,

представление объекта в оперативной памяти отличается от его

представления на диске);

управление кластеризацией объектов во внешней памяти;

управление индексами.

Несколько слов про управление транзакциями. Различаются

режимы, когда допускается параллельное выполнение транзакций,

изменяющих схему БД, и когда параллельно выполняются только

транзакции, изменяющие внутренность БД. Первый режим обычно

используется на стадии разработки БД, второй - на стадии

выполнения приложений. Средства восстановления БД после сбоев

и откатов транзакций также могут включаться и выключаться.

Наконец, поддерживается режим, при котором все постоянно

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

транзакции для увеличения скорости работы прикладной системы.

Компонент управления схемой БД реализован над подсистемой



управления объектами: в системе поддерживаются несколько

невидимых для программистов классов и в том числе классы

"Class" и "Method", экземплярами которых являются,

соответственно, объекты, определяющие классы, и объекты,

определяющие методы. (Как видно, ситуация напоминает

реляционные системы, в которых тоже обычно поддерживаются

служебные отношения-каталоги, описывающие схему БД.) Удаление

класса, который не является листом иерархии классов или

используется в другом классе или сигнатуре какого-либо метода,

запрещено.

Даже приведенное краткое описание особенностей двух

объектно-ориентированных СУБД показывает прагматичность

современного подхода к организации таких систем. Их

разработчики не стремятся к полному соблюдению чистоты

объектно-ориентированного подхода и применяют наиболее простые

решения проблем, которые на самом деле еще не решены. Пока в

сообществе разработчиков объектно-ориентированных систем БД не

видно работы, которая могла бы сыграть в этом направлении

роль, аналогичную роли System R по отношению к

реляционным системам. Правда, и проблемы ООБД гораздо более

сложны, чем решаемые в реляционных системах.

6. Проблемы выполнения и оптимизации запросов к ООБД

В этом разделе мы остановимся на проблемах выполнения запросов

к ООБД, сформулированных на каком-либо декларативном языке.

Каким бы не был этот язык, в конечном счете потребуется по

внешнему представлению запроса сформировать план его

выполнения, который минимизировал бы общие накладные расходы

системы, требующиеся для выполнения запроса. Другими словами,

до выполнения запроса необходимо выполнить его оптимизацию,

учитывая в общем случае необходимость обменов с внешней

памятью.

Публикации, касающиеся оптимизации запросов к ООБД,

практически отсутствуют. Это свидетельствует о недостаточной

развитости каких-либо оригинальных подходов.

Как мы видели на примерах конкретных систем в предыдущем

разделе, в них по сути дела применяется тот же подход к



оптимизации запросов, который использовался в реляционных

системах: формируется набор альтернативных планов, оценивается

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

стоимостью. (Подробный обзор современных методов оптимизации

запросов в реляционных СУБД и нерешенных проблем можно найти в

.) Возможность применения такого подхода в СУБД ORION и

O2 (да и в других) опирается на то, что объекты в этих

системах не полностью инкапсулированы. Наряду с методами, в

объектах видны и некоторые атрибуты, и если условие выборки

задано через эти атрибуты, оптимизатор запросов, которому

известны внутренняя структура объектов и набор существующих

индексов, получает возможность выбора. Если же условие выборки

можно формулировать только через методы, при подходах ORION и

O2 единственным возможным способом выборки объектов класса

будет последовательный просмотр всех объектов этого класса.

Здоник отмечает, что основная проблема с оптимизацией

запросов к ООБД связана с расширяемостью набора типов в такой

БД. Каждый новый тип вводит собственную алгебру, неизвестную

оптимизатору запросов. Например, оптимизатор не имеет

информации о возможной коммутативности двух операций типа и

т.д. Здоник полагает, что возможному решению проблемы

оптимизации могло бы способствовать формальное определение

алгебраических свойств операций типа при его разработке.

Примерно такой подход применяется в оптимизаторах, основанных

на наборе правил, применяемых в расширяемых СУБД (например,

).

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

оптимизации запросов, наибольшее влияние на оптимизаторы

систем ООБД может оказать . Эта работа не связана

непосредственно со спецификой ООБД, но преимущество

предлагаемого подхода связано как раз с максимальной

независимостью от особенностей организации БД. Предлагается не

оценивать план выполнения запроса, а учитывать реальную

стоимость уже использованного плана и на этой основе изменять

критерии выбора оптимизатора.


Может быть, таким образом

удастся справиться с неизвестной оптимизатору алгеброй

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

По нашему мнению, если в системе для программирования методов

применяется язык достаточно высокого уровня (во всяком случае,

не Си), то при компиляции запроса могло бы производиться

частичное вычисление вызываемых в нем методов с последующим

преобразованием запроса к виду, когда условия определены на

атрибутах хранимых классов. После этого можно было производить

обычную оптимизацию запроса. Заметим, что это не было бы

нарушением инкапсуляции объектов, поскольку оптимизатор

является частью системы, для которой внутренняя организация

объектов БД открыта.

7. Особенности управления транзакциями в системах ООБД

Дела с управлением транзакциями в системах ООБД обстоят

примерно аналогично ситуации с оптимизацией запросов: как

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

методы сериализации транзакций, журнализации изменений

объектов, индивидуальных откатов транзакций и восстановления

состояния БД после сбоев. Фактически, как и в случае

оптимизации запросов, такое управление транзакциями

предполагает частичное нарушение инкапсуляции объектов:

синхронизация основывается на знании внутренней структуры

объектов, журнализация и восстановление - на знании природы

методов, изменяющих состояние объекта и т.д.

Какой-либо подход, в котором предлагался бы полный набор

средств управления транзакциями, полностью согласующийся с

парадигмой объектной ориентированностью, нам неизвестен. Одна

из наиболее продвинутых работ, проводимых в этом направлении в

рамках германского проекта VODAK, описывается в .

В основе управления транзакциями в системе VODAK находится

разработанный ранее в контексте инженерных СУБД механизм

транзакций со вложенными подтранзакциями : вызов любого

действия в объекте равносилен образованию новой

подстранзакции. В отличие от традиционного механизма вложенных

подтранзакций в данном случае заранее не определена



максимальная вложенность транзакций. При синхронизации

транзакций используется знание о семантике объектов, в том

числе информация о коммутативности операций. (Аналогичный

подход описан в .)

Не очень понятно, как при таком подходе поступать с

журнализацией изменений. В принципе только сам объект знает,

какая информация может понадобиться для его восстановления, и

только сам объект может выполнить такое восстановление. Может

быть, следует применять технику темпоральных БД, и при каждом

изменении состояния объекта заводить его новую версию. В

общем, как нам представляется, проблема журнализации и

восстановления в ООБД пока остается открытой.

8. Связь ООБД с дедуктивными и активными базами данных

Связь направления ООБД с направлением дедуктивных БД носит

двоякий характер. Во-первых, для структуризации дедуктивных (и

вообще логических) БД в последнее время стремятся использовать

парадигму объектной ориентированности . Это отдельная

тема, для ее рассмотрения было бы необходимо предварительное

введение в концепции дедуктивных БД, что находится за

пределами данного обзора.

Во-вторых, некоторые механизмы дедуктивных БД пытаются

использовать в контексте обычных (может быть, несколько

расширенных семантически) ООБД. Это прежде всего относится к

языкам запросов (как мы отмечали в разд. 4, одно из

направлений развития декларативных языков запросов к ООБД -

дедуктивные языки). На логическом выводе основываются в ряде

проектов доказательство корректности схемы ООБД и динамический

контроль целостности . Видимо, в будущих системах ООБД

логика будет играть еще большую роль.

Работы по интеграции объектно-ориентированных и активных БД

находятся в начальной стадии. Известно, что основной проблемой

систем активных БД является построение эффективного механизма

вычисления на основе поступающих событий условий и вызова при

необходимости соответствующих действий. В описывается

экспериментальная работа, выполненная на базе

объектно-ориентированной СУБД PROBE, в которой активность ООБД



обеспечивается с помощью определения двух специальных классов

объектов "active-object" и "activelist-object". При

возникновении одного из предопределенных в системе событий

вызывается один из методов соответствующего объекта класса

"active-object", в котором в зависимости от состояния и

предписанного набора правил принимается решение о дальнейших

действиях. Основной вывод, который можно сделать на основании

изложенного в материала, - это пригодность основных

средств типовой ООБД и для обеспечения ее активности.

9. Заключение

В этом обзоре мы рассмотрели (очень кратко) далеко не все

вопросы, связанные с ООБД. Совсем не были рассмотрены проблемы

проектирования ООБД и вообще объектно-ориентированного

проектирования БД , вопросы поддержания разнородной

(multi-media) информации в ООБД , подходы к интеграции

неоднородных БД на основе объектно-ориентированного подхода

, проблемы поддержания различных представлений ООБД

и т.д.

Мы стремились показать общее состояние дел (насколько это

возможно в таком кратком обзоре) в наиболее важных областях,

связанных с управлением ООБД. По нашему мнению, практически во

всех этих областях имеется масса нерешенных проблем, и

потребность в развитых объектно-ориентированных СУБД

стимулирует решение этих проблем.

Литература:

Mattbew Rapaport. Object-Oriented Data Bases: The Next Step

in DBMS Evolution // Comp. Lang.- 5, N 10.- 1988.- 91-98

Michael Stonebraker. Future Trends in Database Systems //

IEEE Trans. Knowledge and Data Eng.- 1, N 1.- 1989.- 33-44

Oscar Nierstrasz. A Survey of Object-Oriented Concepts //

In Object-Oriented Concepts, Databases and Applications, ed.

W. Kim, F. Lochovski, ACM Press and Addison-Wesley, 1989.-

3-21

M. A. Garvey, M. S. Jackson. Introduction to

Object-Oriented Databases // Inf. and Software Technol.- 31, N

10.- 1989.- 521-528

Fereidoon Sadri. Object-Oriented Database Systems //

COMPSAC'89 13th Annu. Int. Comput. Software and Appl. Conf.,

Orlando, Fla, Sept. 20-22, 1989.- 195-196



Stanley Y. W. Su. Extensions to the Object-Oriented

Paradigm // COMPSAC'89 13th Annu. Int. Comput. Software and

Appl. Conf., Orlando, Fla, Sept. 20-22, 1989.- 197-199

Stanley Zdonik. Directions in Object-Oriented Databases //

COMPSAC'89 13th Annu. Int. Comput. Software and Appl. Conf.,

Orlando, Fla, Sept. 20-22, 1989.- 200

Malkolm Atkinson, Francois Bansilhon, David DeWitt, Klaus

Dittrich, David Maier, Stanley Zdonik. The Object-Oriented

Database System Manifesto // 1st Int. Conf. Deductive and

Object-Oriented Databases, Kyoto, Japan, Dec. 4-6, 1989

The Committee for Advanced DBMS Function (Michael

Stonebraker, Bruce Lindsay, Jim Gray, Make Carey, David

Beech). Third Generation Data Base System Manifesto // Proc.

ACM SIGMOD Int. Conf. Manag. Data, Atlanta City, NJ, USA, May

23-25, 1990, ACM SIGMOD Record.- 19, N 2.- 1990.- 34-43

R. P. van de Riet. Introduction to the Special Issue on

Deductive and Object-Oriented Databases // Data and Knowledge

Eng.- 5.- 1990.- 255-261

Won Kim. Object-Oriented Databases: Definition and

Research Directions // IEEE Trans. Data and Knowledge Eng.- 2,

N 3.- 1990.- 327-341

D. Woelk, W. Kim. Multimedia Information Management in a

Object-Oriented Database System // 13th Int. Conf. Very Large

Data Bases, Brighton, England, Sept. 1-4, 1987.- 319-330

Won Kim, Nat Ballou, Hong-Tai Chou, Jorge F. Garza,

Darrell Woelk. Integrating an Object-Oriented Programming

System with a Database System // Proc. OOPCLA'88, San Diego,

Calif., USA, Sept. 25-30, 1988.- 142-152

Kyung-Chang Kim, Won Kim, Darrell Woelk. Acyclic Query

Processing in Object-Oriented Databases // Entity-Relationship

Approach: Bridge User: 7th Int. Conf., Rome, Nov. 16-18,

1988.- 329-346

Elisa Bertino, Won Kim. Indexing Techniques for Queries on

Nested Objects // IEEE Trans. Knowledge and Data Eng.- 1, N

2.- 1989.- 196-214

B. Paul Jenq, Darrell Woelk, Won Kim, Wan-Lik Lee. Query

Processing in Distributed ORION // Advances in Database

Technology - EDBT'90.- Lecture Notes in Computer Science.-



416, 1990.- 169-187

Won Kim, Jorge F. Garza, Nathaniel Ballou, Darrell Woelk.

Architecture of the ORION Next-Generation Database System //

IEEE Trans. Knowledge and Data Eng.- 2, N 1.- 1990.- 109-124

D. H. Fishman. An Overview of the Iris Object-Oriented

DBMS // Digest of papers, 33rd CompCon, Spring 1988, Feb. 29 -

Mar. 4, USA.- 177-180

Peter Lyngbaek, Kevin Wilkinson, Waqar Hasan. The Iris

Kernel Architecture // Advances in Database Technology -

EDBT'90.- Lecture Notes in Computer Science.- 416, 1990.-

348-362

Kevin Wilkinson, Peter Lyngbaek, Waqar Hasan. The Iris

Architecture and Implementation // IEEE Trans. Knowledge and

Data Eng.- 2, N 1.- 1990.- 63-75

David Maier, Jacob Stein, Allen Otis, Alan Purdy.

Development of an Object-Oriented DBMS // Proc. OOPCLA'86,

Portland, Oreg., USA, Sept. 29 - Oct. 2, 1986.- 472-482

D. Jacob Penney, Jacob Stein. Class Modification in the

GemStone Object-Oriented DBMS // Proc. OOPCLA'87, Orlando,

Fla, USA, Oct. 4-8, 1987.- 111-117

Won Kim, Jay Banerjee, Hong-Tai Chou, Jorge F. Garca,

Darrell Woelk. Composite Object Support in an Object-Oriented

Database System GemStone Object-Oriented DBMS // Proc.

OOPCLA'87, Orlando, Fla, USA, Oct. 4-8, 1987.- 118-125

Tomothy Andrews, Craig Harris. Combining Language and

Database Advances in an Object-Oriented Development

Environment GemStone Object-Oriented DBMS // Proc. OOPCLA'87,

Orlando, Fla, USA, Oct. 4-8, 1987.- 430-440

Michael Stonebraker, Jeff Anton, Eric Hanson. Extending a

Database System with Procedures // ACM Trans. Database Syst.-

12, N 3.- 1987.- 350-376

L. Rowe, M. Stonebraker. The POSTGRES Data Model // 13th

Int. Conf. Very Large Data Bases, Brighton, England, Sept.

1-4, 1987.- 83-96

M. Stonebraker. The Design of the POSTGRES Storage System

// 13th Int. Conf. Very Large Data Bases, Brighton, England,

Sept. 1-4, 1987.- 289-300

Michael Stonebraker, Lawrence A. Rowe, Machael Hirohama.

The Implementation of POSTGRES // IEEE Trans. Knowlwdge and



Data End.- 2, N 1.- 1990.- 125-141

Christophe Lecluse, Philippe Richard, Fernando Velez. O2,

an Object-Oriented Data Model // Proc. ACM SIGMOD Int. Conf.

Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM SIGMOD

Record.- 17, N 3.- 1988.- 424-433

F. Velez, G. Bernard, V. Darnis. The O2 Object Manager: An

Overview // 15th Int. Conf. Very Large Data Bases, Amsterdam,

Aug. 22-25, 1989.- 357-366

C. Lecluse, P. Richard. The O2 Database Programming

Language // 15th Int. Conf. Very Large Data Bases, Amsterdam,

Aug. 22-25, 1989.- 411-422

O. Deux et al. The Story of O2 // IEEE Trans. Knowledge

and Data Eng.- 2, N 1.- 1990.- 91-108

O. Niestrasz, D. Tsichritzis. An Object-Oriented

Environment for OIS Applications // 11th Int. Conf. Very Large

Data Bases, Stockholm, Aug. 21-23, 1985.- 83-96

D. Decouchart. Design of a Distributed Object Manager for

the Smalltalk-80 System // Proc. OOPCLA'86, Portland, Oreg.,

USA, Sept. 29 - Oct. 2, 1986.- 444-452

Karen E. Smith, Stanley B. Zdonik. Intermedia: A Case

Study of the Differences Between Relational and

Object-Oriented Database Systems // Proc. OOPCLA'87, Orlando,

Fla, USA, Oct. 4-8, 1987.- 452-465

Andrew Straw, Fred Mellender, Steve Riegel. Object

Management in a Persistent Smalltalk System // Software Pract.

and Exper.- 19, N 8.- 1989.- 719-737

Nick Roussopoulus, Hyun Soon Kim. ROOST: A Relational

Object-Oriented System // Lect. Notes Comput. Sci.- 367.-

1989.- 404-420

T. F. Keefe, W. T. Tsai, M. B. Thuraisingham. SODA: A

Secure Object-Oriented Database System // Computers and

Security.- 8, N 6.- 1989.- 517-533

Prasun Dewan, Ashish Vikram, Bharat Bhargava. Engineering

the Object-Oriented Database Model in O-Raid // Lect. Notes

Comput. Sci.- 367.- 1989.- 389-403

Scott E. Hudson, Roger King. Cactis: A Self-Adaptive,

Concurrent Implementation of an Object-Oriented Database

Management System // ACM Trans. Database Syst.- 14, N 3.-

1989.- 291-321

Gilles Barbedette. LISPO2: A Persistent Object-Oriented



LISP // Advances in Database Technology - EDBT'90.- Lecture

Notes in Computer Science.- 416, 1990.- 332-347

Sharma Chakravarthy, Susan Nesson. Making an

Object-Oriented DBMS Active: Design, Implementation, and

Evaluation of a Prorotype. // Advances in Database Technology

- EDBT'90.- Lecture Notes in Computer Science.- 416, 1990.-

393-406

R. Agrawal, N. H. Gehani, J. Srinivasan. OdeView: The

Graphical Interface to Ode // Proc. ACM SIGMOD Int. Conf.

Manag. Data, Atlanta City, NJ, USA, May 23-25, 1990, ACM

SIGMOD Record.- 19, N 2.- 1990.- 34-43

Stefano Ceri, Stafano Crespi-Reghizzi, Roberto Zicari,

Gianfranco Lamperti, Luigi A. Lavazza. Algres: An Advanced

Database System for Complex Applications // IEEE Software.- 7,

N 4.- 1990.- 68-78

Michael L. Nelson, J. Michael Moshell, Ali Orooji. A

Relational Object-Oriented Management System // 9th Annu. Int.

Phoenix Conf. Comput. and Commun.- Scottsdale, Aris., USA,

March 21-23, 1990.- 319-323

Stefan Bottcher. Attribute Inheritance Implemented on Top

of a Relational Database System // 6th Int. Conf. Data Eng.,

Los Angeles, Calif., USA, Febr. 5-9, 1990.- 503-509

Simon Gibbs, Vassilis Prevelakis. Xos: An Overview // In

Object Management, Ed. D. Tsichritzis, Centre Universitaire

d'Informatique, Universite de Geneve, 1990.- 37-61

M.J. Carey, D.J. DeWitt et al. Object and File Management

in the EXODUS Extensible Database System // 12th Int. Conf.

Very Large Data Bases, Kuoto, Japan, Aug. 1986.- 91-100

D. S. Batory, J. R. Barnett, J. F. Garza, K. P. Smith, K.

Tsukuda, T. E. Wise. GENESIS: An Extensible Database

Management System // // IEEE Trans. on Software Eng.- 14, N

11.- 1988.- 1711-1730

Hans-Joerg Schek, Heinz-Bernhard Paul, Marc H. Scholl,

Gerhard Weikum. The DASDBS Project: Objectives, Experiences,

and Future Prospects // IEEE Trans. Knowledge and Data Eng.-

2, N 1.- 1990.- 25-43

Laura M. Haas, Walter Chang, Guy M. Lohman et al.

Starburst Mid-Flight: As the Dust Clears // IEEE Trans.

Knowledge and Data Eng.- 2, N 1.- 1990.- 143-159



Raymond Lorie, Won Kim, Dan McNabb, Wil Plouffe.

Supporting Complex Objects in a Relational System for

Engineering Databases // In Query Processing in Database

Systems, ed. Won Kim, David S. Reiner, Dan. S. Batory,

Springer-Verlag, 1985.- 145-155

Raymond A. Lorie, Jean-Jacques P. Daudenarde. On Extending

the Realm of Application of Relational Systems // In

Information Processing 86, ed. H.-J. Kugler, Elsevir Science

Publishers, 1986.- 889-894

Won Kim, Hong-Tai Chou, Jay Banerjee. Operations and

Implementation of Complex Objects // IEEE Trans. on Software

Eng.- 14, N 7.- 1988.- 985-996

Mohammad A. Ketabchi, Valdis Berzins. Mathematical Model

of Composite Objects and Its Application for Organizing

Engineering Databases // IEEE Trans. on Software Eng.- 14, N

1.- 1988.- 71-84

Anant Jhingran, Michael Stonebraker. Alternatives in

Complex Object Representation: A Performance Persrective //

6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9,

1990.- 94-102

Serge Abiteboul, Richard Hull. IFO: A Formal Semantic

Database Model // ACM Trans. Database Syst.- 12, N 4.- 1987.-

525-565

Joan Peckham, Fred Maryanski. Semantic Data Models // ACM

Comp. Surv.- 20, N 3.- 1988.- 153-189

Shamkant B. Navathe, Mohan K. Pillalamarri. OOER: Toward

Making the E-R Approach Object-Oriented // Entity-Relationship

Approach: Bridge User: 7th Int. Conf., Rome, Nov. 16-18,

1988.- 185-206

Craig Damon, Gordon Landis. Abstract Types and Storage

Types in an OO-DBMS // Digest of papers, 33rd CompCon, Spring

1988, Feb. 29 - Mar. 4, USA.- 172-176

Richard Hull, Katsumi Tanaka, Masatoshi Yoshikawa.

Behavior Analysis of Object-Oriented Databases: Method

Structure, Execution Trees, and Reachibility // Lect. Notes

Comput. Sci.- 367.- 1989.- 372-388

Mojtaba Mozaffari, Yuzuri Tanaka. ODM: An Object-Oriented

Data Model // New. Generat. Comp.- 7, N 1.- 1989.- 4-35

Catriel Beeri. A Formal Approach to Object-Oriented

Databases // Data and Knowledge Eng.- 5.- 1990.- 353-382



Roberto Zicari. Incomplete Information in Object-Oriented

Databases // ACM SIGMOD Record.- 19, N 3.- 1990.- 5-16

Shuguang Hong, Fred Maryanski. Using a Meta Model to

Represent Object-Oriented Data Models // 6th Int. Conf. Data

Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 11-19

A. Cornelio, Shamkant B. Navathe, Keith L. Doty. Extending

Object-Oriented Concepts to Support Engineering Applications

// 6th Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr.

5-9, 1990.- 220-227

Gunter Saake. Descriptive Specification of Database Object

Behaviour // Data and Knowledge Eng.- 6, N 1. 1991.- 47-73

S. K. Lellani, N. Spiratos. Towards a Categorical Data

Model Supporting Structured Objects and Inheritance // Proc.

1st Int. East/West Database Workshop, Kiev, Oct. 1990, Lect.

Notes Comput. Sci.- 540.- 1991

Michael Caruso, Edward Sciore. Meta-Functions and Contexts

in an Object-Oriented Database Language // Proc. ACM SIGMOD

Int. Conf. Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM

SIGMOD Record.- 17, N 3.- 1988.- 56-65

Francois Bancilhon. Query Languages for Object-Oriented

Database Systems: Analysis and Proposal // Datanbanksyst.

Buro, Tech. and Wiss.: GI/SI - Fashtag., Zurich, Marz. 1-3,

1989.- 1-18

W. Kim. A Model of Queries for Object-Oriented Databases

// 15th Int. Conf. Very Large Data Bases, Amsterdam, Aug.

22-25, 1989.- 423-432

A. M. Alashqur, S. Y. W. Su, H. Lam. OQL: A Query Language

for Manipulating Object-Oriented Databases // 15th Int. Conf.

Very Large Data Bases, Amsterdam, Aug. 22-25, 1989.- 433-442

E. Laenens, F. Staes, D. Vermeir. Browsing a la carte in

Object-oriented Databases // Computer J.- 32, N 4.- 1989.-

333-340

Sophie Cluet, Claude Delobel, Christophe Lecluse, Philippe

Richard. RELOOP: An Algebra Based Query Language for an

Object-Oriented Database System // Data and Knowledge Eng.-

5.- 1990.- 333-352

Simon Gibbs. Querying Large Class Collections // In Object

Management, ed. D. Tsichritzis, Centre Universitaire



d'Informatique, Universite de Geneve, 1990.- 63-77

Gail M. Shaw, Stanley B. Zdonik. A Query Algebra for

Object-Oriented Databases // 6th Int. Conf. Data Eng., Los

Angeles, Calif., USA, Febr. 5-9, 1990.- 154-162

А. В. Замулин. Системы программирования баз данных и

знаний // Новосибирск: Наука, 1990.- 352 с.

Andrea H. Skarra, Stanley B. Zdonik. The Management of

Changing Types in an Object-Oriented Database // Proc.

OOPCLA'86, Portland, USA, Sept. 29 - Oct. 2, 1986.- 483-495

J. Banerjee, W. Kim, H.-J. Kim, H. F. Korth. Semantics and

Implementation of Schema Evolution in Object-Oriented Database

// Proc. ACM SIGMOD 1987 Annu. Conf., San Francisco, Calif.,

USA, May 27-29, 1987.- 311-322

W. Kim, H. Chou. Versions of Schema for Object-Oriented

Databases // 14th Int. Conf. Very Large Data Bases, Los

Angeles, USA, Aug. 29 - Sept. 1, 1988.- 148-159

David Beech. Intensional Concepts in an Object Database

Model // Proc. OOPCLA'88, San Diego, Calif., USA, Sept. 25-30,

1988.- 164-175

Serge Abiteboul. Towards a Deductive Object-Oriented

Database Language // Data and Knowledge Eng.- 5.- 1990.-

263-287

Kyuchul Lee, Sukho Lee. An Object-Oriented Approach to

Data/Knowledge Modelling Based on Logic // 6th Int. Conf. Data

Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 289-294

A. M. Alashqur, S. Y. W. Su, H. Lam. A Rule-based Language

for Deductive Object-Oriented Databases // 6th Int. Conf. Data

Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 58-67

Lois M. L. Delcambre, Karen C. Davis. Automatic Validation

of Object-Oriented Database Structures // 5th Int. Conf. Data

Eng., Los Angeles, Calif., USA, Febr. 6-10, 1989.- 2-9

Susan Darling Urban, Lois M. L. Delcambre. Constraint

Analysis for Specifying of Class Objects // 5th Int. Conf.

Data Eng., Los Angeles, Calif., USA, Febr. 6-10, 1989.- 10-17

Kyu-Young Whang. A Seamless Integration in Object-Oriented

Database Systems // 5th Int. Conf. Data Eng., Los Angeles,

Calif., USA, Febr. 6-10, 1989.- 675-676



M. Kaul, K. Drosten, E. J. Neuhold. ViewSystem:

Integrating Heterogeneous Information Bases by Object-Oriented

Views // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA,

Febr. 5-9, 1990.- 2-10

Sandra Heiler, Stanley Zdonic. Object Views: Extending the

Vision // 6th Int. Conf. Data Eng., Los Angeles, Calif., USA,

Febr. 5-9, 1990.- 84-93

Jorge F. Garza, Won Kim. Transaction Management in an

Object-Oriented Database System // Proc. ACM SIGMOD Int. Conf.

Manag. Data, Chicago, Ill, USA, June 1-3, 1988, ACM SIGMOD

Record.- 17, N 3.- 1988.- 37-45

M. A. Rauft, S. Rehm, K. R. Dittrich. How to Share Work on

Shared Objects in Design Databases // 6th Int. Conf. Data

Eng., Los Angeles, Calif., USA, Febr. 5-9, 1990.- 575-583

Michele Cart, Jean Ferrie. Integrating Concurrency Control

into an Object-Oriented Database System // Advances in

Database Technology - EDBT'90.- Lecture Notes in Computer

Science.- 416, 1990.- 363-377

Thomas C. Rakow, Junzhong Gu, Erich J. Neuhold.

Serializability in Object-Oriented Database Systems // 6th

Int. Conf. Data Eng., Los Angeles, Calif., USA, Febr. 5-9,

1990.- 112-120

Kyung-Chang Kim. Parallelism in Object-Oriented Query

Processing // 6th Int. Conf. Data Eng., Los Angeles, Calif.,

USA, Febr. 5-9, 1990.- 209-217

Sushit Jajodia, Boris Kogan. Integrating an

Object-Oriented Data Model with Multilevel Security // IEEE

Symp. Res. Secur. and Privacy, Oacland, Calif., USA, May 7-9,

1990.- 76-85

IEEE Database Engineering, special issue on

Object-Oriented Databases, F. Lochovski, ed., Dec. 1985

B. Stroustrup. The C++ Programming Language //

Addison-Wesley, Reading, Mass., 1986

E. F. Codd. A Relational Model of Data for Large Shared

Data Banks // Commun. ACM.- 26, N 1.- 1970.- 377-387

D. Maier. Why isn't there an Object-Oriented Data Model?

// Technical Report, Oregon Graduate Center, May 1989

D. D. Chamberlin, R. F. Boyce. SEQUEL: A Structured

English Query Language // ACM SIGMOD Workshop Data Descr.,

Access, Contr., Ann Arbol, Mich., USA, May 1974.- 249-264



M. Kifer, G. Lausen. F-Logic: A Higher-Order Language for

Reasoning about Objects, Inheritance, and Scheme // Proc. ACM

SIGMOD Int. Conf. Manag. Data, Portland, Oreg., USA, 1989, ACM

SIGMOD Record.- 18, N 2.- 1989.- 134-146

P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A.

Lorie, T. G. Price. Access Path Selection in a Relational

Database Management System // Proc. ACM SIGMOD Int. Conf.

Manag. Data, Boston, Mass., USA, May 30 - Jun. 1, 1979.- 23-34

Gray J.N., Lorie R.A., Putzolu G.R., Traiger I.L.

Granularity of Locks in a Large Shared Data Base // 1st Int.

Conf. Very Large Data Bases, Framingham, Mass., Sept. 1975.-

C.428-451

H.-T. Chou, D. J. DeWitt, R. H. Katz, A. C. Klug. Design

and Implementation of the Wisconsin Storage System // Software

Pract. Exper.- 15, N 10.- 1985.- 943-962

D. D. Chamberlin, M. M. Astrahan et al. A History and

Evaluation of System R // Commun. ACM.- 24, N 10.- 1982.-

632-646

С. Д. Кузнецов. Методы оптимизации выполнения запросов в

реляционных СУБД // "Вычислительные науки. Т.1 (Итоги науки и

техники ВИНИТИ АН СССР)". М., ВИНИТИ АН СССР, 1989.- 76-153

J. C. Freytag. A Rule-Based View of Query Optimization //

Proc. ACM SIGMOD Int. Conf. Manag. Data, San Francisco,

Calif., USA, May 27-29, 1987.- 173-180

F. W. M. Tompa, J. I. Icaza. Adaptive Selection of Query

Execution Strategies by Learning Automata // Inf. Sci. (USA).-

50, N 3.- 1990.- 219-240

F. Bancilhon, W. Kim, H. Korth. A Model for CAD

Transactions // 11th Int. Conf. Very Large Data Bases,

Stockholm, Aug. 21-23, 1985.- 25-33

Alan Fekete, Nancy Lynch, Machael Merritt, William Weihl.

Commutativity-Based Locking for Nested Transactions // 6th ACM

Symp. Princ. Database Syst., San Diego, Calif, USA, March

25-27, 1987, J. Comput. and Syst. Sci.- 41, N 1.- 1990.-

65-156

"Объектно/реляционная" модель

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

Но это заявление абсурдно! Как мы вместе с Хью Хагеном показали в Третьем манифесте [2], объектная функциональность и реляционная модель полностью ортогональны. Цитирую: "Реляционная модель не нуждается в расширении, коррекции и дополнительных допущениях, и это не противоречит возможности [поддержки объектной функциональности]. Все, что требуется, это должная поддержка доменов отношений (что никогда не делалось в SQL) с пониманием того, что, по своей сути, это абстрактные типы данных (ADT). Другими словами, так называемая O/R модель - это всего лишь реляционная модель, чистая и простая; для нее не требуются какие-либо (истинные) "расширения реляционной модели".

Объектно-реляционные расширения

Принципиальные расширения в поддержке больших объектов и

триггеров INSTEAD-OF могут быть лицензированы отдельно от

основной части сервера Oracle8 в виде Object Option. Что касается

дополнительных встроенных типов данных, то Oracle предлагает

четыре расширенных реляционных типа данных: большие объекты с

улучшенным управлением содержимым; два вида типов данных

коллекции - VARRAY и вложенные таблицы; расширенный тип данных,

реализующий указатели.

Два типа коллекций предназначены для поддержки нескалярных

доменов. Типы категории VARRAY позволяют хранить массивы в

столбцах таблиц; для большинства типов данных Oracle8, включая

объектные типы, их значения могут храниться в VARRAY. Ряд

ограничений в VARRAY затрудняет их применение в некоторых целях.

Например, должен быть объявлен максимальный размер массива, и в

настоящее время такие массивы и их содержимое не полностью

доступны из SQL (хотя доступ к ним возможен из PL/SQL или кода

приложения на 3GL).

Другим типом коллекции являются вложенные таблицы. Как следует из

названия, вложенные таблицы позволяют хранить в столбцах

табличные значения. В отличие от VARRAY, вложенные таблицы

полностью доступны из SQL.

Наконец, имеется расширенный тип данных, реализующий указатели,

которые в Oracle8 называются REF. REF реализуются с

использованием генерируемых системой объектных идентификаторов;

указатели на объекты могут храниться в объектных таблицах, и на

основе указателей возможна навигация. Указателями можно

манипулировать и производить навигацию из SQL с использованием

ключевых слов REF, DEREF и VALUE. Указатели играют важную роль

при выполнении операций объектного кэша клиента.

Объектные типы. Система объектных типов Oracle8 позволяет

определять и хранить именованные структуры данных, например:

CREATE TYPE customer_type AS OBJECT (

name VARCHAR2 (20),

no_of_purchases NUMBER,

MEMBER FUNCTION get_no_of_purchases RETURN NUMBER);

Любой тип Oracle8 может выступать в качестве члена объектного

типа, включая VARRAY, вложенные таблицы и другие объектные типы.

В бета- версиях Oracle8 объектные типы назывались "абстрактными

типами данных" (термин, используемый в проектах SQL3 и в

академических кругах), но позже было решено, что термин

"объектные типы" является более понятным и точным. (На самом

деле, объектные типы Oracle8 представляют собой обобщение

именованных типов строк и абстрактных типов данных SQL3.)

В объектных типах могут определяться методы, реализация которых

может быть представлена на PL/SQL или в виде вызовов функций 3GL.

Методы похожи на хранимые процедуры и могут вызываться из SQL или

PL/SQL для вычисления и получения информации об объектах данного

типа и/или их модификации. Каждый объектный тип имеет по меньшей

мере один метод - конструктор. Это определенная в системе

функция, которая создает объект данного типа. В дополнение к

общим методам, при необходимости могут быть реализованы

специальные методы, меняющие для объектного типа порядок

сортировки и операции сравнения.

Объектные типы можно использовать двумя способами. Во-первых,

с использованием объектного типа можно определить объектные

таблицы, специфицируя тип таблицы целиком:

CREATE TABLE customers OF customer_type

В этом примере каждая строка результирующей таблицы будет

содержать объект типа customer_type с членами-атрибутами,

специфицированными при объявлении этого объектного типа (другими

словами, "name" и "no_of_purchases"). К каждой строке-объекту

Oracle8 добавляет "скрытый" столбец, содержащий генерируемый

системой уникальный идентификатор (ID) объекта. Этот ID можно

использовать в указателях (REF) на объекты таблицы из других

таблиц или реализовывать указатели между объектами этой же

таблицы. При желании столбец ID можно индексировать для более

быстрого поиска REF.

Во-вторых, объектные типы можно использовать для определения

типов столбцов. В этом случае при определении типов столбцов

таблицы имена объектных типов помещаются вместо имен базовых

типов. Например, объявленный выше тип customer_type можно было бы



использовать для определения структурированного столбца

"customer" в обычной таблице. Члены такого "объектного столбца"

доступны из SQL с использованием расширенной точечной нотации,

например, путем выборки my_table.customer.name.

Эти два вида применение объектных типов соответствуют двум

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

схему.

Объектный кэш клиента. В Oracle8 также обеспечиваются

значительные возможности манипулирования объектами на стороне

клиентских приложений. Объектный кэш клиента может быть

реализован и доступен для манипулирования с использованием

вызовов нового интерфейса OCI (Oracle Call Interface), с

применением прекомпилятора C/C++ со встроенным SQL (приобретается

отдельно), либо на основе библиотеки классов C++ и среды

поддержки времени исполнения, управляемой ожидаемым вскоре

продуктом Oracle Object Database Designer (развитие

Designer/2000).

С использованием интерфейса уровня OCI объекты из объектных

таблиц Oracle8 могут быть загружены в кэш поосле выполнения

запроса на расширенном SQL, выбирающего идентификаторы объектов;

после этого возможно манипулирование объектами. Все изменения

могут быть впоследствии вытолкнуты на сервер. OCI также дает

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

которые будут подкачиваться в кэш клиента по мере необходимости.

Поддерживается управляемый уровень упреждающего чтения в кэш

объектов, на которые ссылается базовый объект. Эта возможность

похожа на "листание объектов", которое обеспечивается в некоторых

объектных системах баз данных.

Прекомпилятор предоставляет представление более высокого уровня

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

разработчикам традиционных баз данных. Более детальный интерфейс

OCI более подходит для разработчиков приложений.

В Oracle8 обеспечивается компонент Object Type Translator (OTT),

который может генерировать соответствующий С-структуры для

использования клиентскими приложениями при работе с объектным



кэшем.

Поддержка компанией согласованного многоверсионного чтения

расширяется на кэшированные объектные данные и позволяет улучшить

масштабируемость за счет возможности клиентов объектного кэша

работать без запроса блокировок по чтению в базе данных. Каждый

клиент кэша видит свою собственную частную версию базы данных в

той точке, в которой этот клиент начал манипулировать объектами.

В кэше клиента может поддерживаться несколько нитей (thread),

каждая из которых владеет собственной сессией с базой данных и

видит частную порцию кэша, соответствующую собственной транзакции

нити.

Объектные представления. Oracle8 обеспечивает объектные

представления, которые особенно существенны для постепенного

перехода к использованию возможностей объектно-реляционного

подхода и для новых применений существующих баз данных без

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

традиционные реляционные представления, но в них могут

использоваться строгая типизация, сложные структуры (не в первой

нормальной форме), методы и возможности ссылок на существующие

реляционные данные.

Многотабличные объектные представления могут быть сделаны

обновляемыми за счет наличия нового вида триггера INSTEAD OF,

который перехватывает команды SQL, направленные на обновление

представления, и выполняет соответствующее действие. Осмысленно

применять такие триггеры и для того, чтобы сделать обновляемым

любое традиционное реляционное представление.

Некоторые простые, но полезные объектные представления являются

обновляемыми по своей природе. Например, с помощью объектного

представления можно представить таблицу customers, состоящую из

нескольких столбцов, каждый из которых содержит фрагмент адреса,

как таблицу, к которой один столбец содержит структурированные

объекты address. Поскольку такие структуры являются обновляемыми,

они легко надстраиваются над существующей схемой.

"Виртуальными объектами", определенными с помощью объектного

представления, можно манипулировать и с использованием описанных



раньше возможностей клиентского кэша, так как если бы они были

"реальными" объектами из объектных таблиц. Для создания

пригодных идентификаторов виртуальных объектов в определениях

объектной таблицы должен быть специфицирован соответствующий

уникальный составной ключ для объектного представления.

По причине наличия некоторых незначительных ограничений объектные

представления не полностью эквивалентны объектным таблицам.

Например, обычно невозможно хранить указатели на виртуальные

объекты в объектных представлениях, поскольку такие указатели

должны конструироваться с использованием составного первичного

ключа и могут изменяться (в отличие от генерируемых системой

идентификаторов реальных объектов).

Развитие возможностей в будущем. Пока компания Oracle не объявила

время выпуска и точный набор функциональных возможностей

Oracle 8.1. Однако, если основывываться на истории компании, она

должна объявить следующий общий выпуск во второй половине 1998

г., включив в него поддержку языка Java для выполнения функций

управления базами данных (реализации хранимых процедур и

методов), явную поддержку наследования таблиц, расширенную службу

картриджей баз данных. Картридж для работы с временными рядами

планируется выпустить несколько раньше.

Объектные типы (схемы классов)

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

Рассмотрим два класса - A,В - где В наследуется от А. В пространстве определений типов O-системы данная ситуация выглядит следующим образом.

Обратим внимание на то, что отличает между собой типы А и В. Это некоторая разность

B = В - А. В данном случае B означает, что множество имен атрибутов класса составляющих эту впервые определено в типе В. Можно описать A = A. С другой стороны A=A, B = A+B (или B=A+B что фактически описывает операцию наследования существующую в O-языках; возможен вариант описывающий множественное наследование B=A1+A2+...+Ak+B).

Для того чтобы лучше описать структуру этих таблиц необходимо вернуться к рис.4 изображающему пространство R*O-системы (рис. 8).

Рис 8. проекция R*O-системы на плоскость SC-SR (Классы состоят из

являющихся набором имен сущностей)

Каждый класс может быть представлен как сумма

. В данном случае класс A = A, а класс B = A +B. -ы являются непересающимися подмножествами простанства определения типов классов. Каждая из этих

содержит именованные ( здесь: x1, x2, y1) поля различных сущностей ( здесь: сущности ADDR и LegIn).

Вся эта информация может быть описана с помощью трех отношений.

1.CLASSES - определяет существующие в системе классы.

Столбец	Тип	Ключ	Описание
ClassID	TypeCID	Primary	Идентификатор класса ( и )
ClassName	char[…]		Имя класса

Из того факта, что каждой

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

2.DELTAS - содержит информацию о том из каких Ж состоит класс.

Столбец	Тип	Ключ	Описание
ClassID	TypeCID	Primary, references CLASSes (ClassID)	Идентификатор класса
DeltaID	TypeCID	Primary, references CLASSes (ClassID)	Идентификатор

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

3.ATTRIBUTES - содержит информацию обо всех существующих в системе атрибутах классов, опрелделяет в какие и, соответственно, в какие классы эти атрибуты входит.

Столбец	Тип	Ключ	Описание
SemanticID	TypeSID	Primary	Идентификатор элемента схемы классов
DeltaID	TypeCID	References CLASSes (ClassID)	Идентификатор -ы содержащей его (так же можно рассматривать как идентификатор класса где описан этот атрибут)
Name	Char[…]		Имя поля
TableName	Char[…]		Табличный тип данного поля (имя отношения кортежем которого это поле является)

Здесь каждому атрибуту любого из описанных в системе классов ставится в соответствие уникальный идентификатор SemanticID. Поскольку информация о семантическом значении (наравне с OID) является существенной для любого кортежа R*O-системы, содержащей пользовательские данные, каждый кортеж должен содержать поле SID, в котором это значение будет сохраняться. Это поле должно быть объявлено как внешний ключ ссылающийся на поле SemanticID таблицы SCHEME.

Отношения CLASSes, DELTAs и ATTRIBUTes, являющиеся фактически каталогом классов, вместе с полем SID, существующем во всех таблицах данных, являются механизмом, позволяющим определить семантическое значение (смысл) записи в контексте класса объекта, атрибутом которого эта запись является. Можно также предположить, что спроектированный соответствующим образом каталог классов может сохранять всю информацию о классах (константы, методы и т.д.).

После введения отношения OIDs и каталога классов R-проекция R*O-системы примет следующий вид (рис.9).



Рис. 9. R-проекция после введения отношения T_OID и каталога классов (на рисунке из каталога классов имеется только отношение ATTRIBUTes)

Объекту R*O-системы, имеющего атрибут, являющийся кортежем отношения, тем самый присущ смысл характерный для данного отношения.



Пример: Если объект включает кортеж отношения адрес, то он является адресуемым объектом в самом что ни на есть бытовом смысле этого слова - ему можно направить почтовую корреспонденцию и определить его положение на карте

С другой стороны для каждого кортежа R*O системы определено его семантическое значение (смысл) в контексте содержащего его объекта. Это семантическое значение можно использовать для поиска и выборки информации.

Пример: мы можем получить информацию о фактических адресах клиентов или о юридических адресах фирм.

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

Пример: Описав класс "Клиент" создадим запрос возвращающий информацию о фактических адресах клиентов.

SELECT ... FROM Client.postaddress

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

Объекты.

Система объектов обеспечивает клиента набором сервисов. Клиент способен запросить некоторый сервис. Объект - это нечто, что обеспечивает один или более сервисов, которые клиент может запросить.

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

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

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

Мы вновь возвращаемся к идее о существовании в системе описания данных двух ортогональных компонент, каждая из которых представлена своей, отличной от другой системой типов. Любой тип, описанный в одной из компонент, может рассматриваться в ортогональной компоненте как базовый. Это расширяет предлагаемое Дейтом утверждение, которое звучит следующим образом: класс есть домен атрибута отношение. Поскольку мы говорим о взаимной ортогональности, то, следовательно, можно утверждать также, что отношение есть домен атрибута класса.

Обеспечение информационных систем (ИС)

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

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

Обход дерева

Одно из решений было предложено Joe Celko (см. ). Он рекомендовал добавить в таблицу два дополнительных целочисленных поля: Left и Right, в которые заносятся результаты обхода дерева, начиная с корня. Обход организуется следующим образом: каждый раз, при прохождении какого-нибудь элемента указателем, счетчик увеличивается на единицу; при попадании в терминальный элемент, указатель возвращается в родителя и ищет следующего ребенка. В поле Left записывается значение счетчика при первом прохождении элемента, а в поле Right - при последнем. При таком варианте, наша таблица подразделений выглядела бы следующим образом:

create table Departments ( Id int not null identity primary key, Parent int not null references Departments(Id), Name varchar(32) not null, Left int not null, Right int not null )

Departments
Id	Parent	Name	Left	Right
1	0	A1	1	11
2	1	B1	2	4
3	1	B2	6	10
4	2	C1	3	3
5	3	C2	7	7
6	3	C3	9	9

Комбинируя эти поля и сравнивая их с такими же полями других элементов, такая схема позволяет получить ответы на все поставленные вопросы.

Терминальные элементы заметно сразу - у них Left = Right.

Отношения предок - потомок вычисляются тоже легко: Left потомка всегда больше чем у предка, а Right - меньше.

Информацию об уровне заданного элемента можно узнать, получив количество его предков.

Количество потомков = (Right - Left) / 2.

Главный недостаток этого решения в том, что при изменении в структуре дерева, приходится заново пересчитывать значения полей Left и Right во всей таблице. То есть, такой способ годится только для небольших, редко изменяемых таблиц.

Обязанности администратора

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

Кроме того, администратор должен контролировать рост БД. От него требуется держать руководство в курсе относительно предполагаемого роста БД, с тем чтобы иметь возможность своевременно заказать любое необходимое оборудование.

Настройка также является одной из основных зон ответственности администратора БД. И пользователи, и разработчики за советом будут обращаться именно к нему. В нескольких своих книгах я целые главы посвятил важности первичной настройки аппаратного обеспечения и программной среды Oracle как фундамента для последующей разработки приложений и выявлению скрытых ошибок SQL(см . рисунок).

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

Если возникла проблема, желательно как можно быстрее добраться до ее первопричины, чтобы ее вовремя нейтрализовать.

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

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

Обмен информацией через базы данных

Некоторые участники отмечали потребность на наличии стандартного общего представления данных. Для этого требуются более сложные справочники данных.

Видимо, стандартизация метаинформации все еще остается проблемой.

Общие рекомендации по повышению производительности.

Запускать mysqld с правильно подобранными опциями (. настройка переменных ).

Для ускорения SELECT запросов построить индексы для тех полей, которые участвуют в условии WHERE.

Оптимизировать типы полей. По возможности использовать NOT NULL. (. работу с таблицами ).

В MySQL применяется два способа блокировки таблиц (lock table) - внутренняя и внешняя блокировки. Внутренняя блокировка позволяет делать операции по изменению / данных атомарными ( конфликтующими с другими пользователями ). Внешняя блокировка применяется для одновременного доступа нескольких MySQL серверов к одним и тем же базам данных, а также внешняя блокировка позволяет запускать isamchk без остановки MySQL. Чтобы запретить использование внешней блокировки нужно запускать mysqld с опцией -skip-locking. Запрет внешней блокировки существенно повысит скорость работы, но при этом перед запуском isamchk нужно предварительно сбросить все данные на диск командой mysqladmin flush-tables. Также при запрете внешней блокировки нельзя будет использовать несколько серверов для работы с теми же базами данных.

Задание прав доступа на конкретную таблицу или поле снижает производительность.

Во второй части будет описана работа с блокировкой таблиц при изменении и добавлении данных и как это влияет на скорость работы.

Все замечания и пожелания принимаются по адресу

Общность.

В то время как IIOP изначально определен поверх протокола TCP/IP, сообщения, которыми происходит обмен в рамках протокола GIOP специально разработаны для реализации поверх любого протокола, который базируется на установленном между сервером и клиентом соединении.

Обсуждение

В оставшейся части статьи я возвращаюсь к примеру с участием TABLE_DEE и TABLE_DUM. В связи с этим примером я говорил, что P является предикатом, а на самом деле еще и высказыванием – но так ли это в действительности? По определению, высказывание – это утверждение, которое однозначно является либо истинным, либо ложным. (Более точно, это утверждение, в котором делается предположение, однозначно являющееся истинным или ложным.) Но очевидно, что P не является ни истинным, ни ложным – потому что, если оно истинно, то оно ложно, и наоборот, – так что, возможно, я был не прав, назвав его в предыдущем разделе высказыванием.

Однако более важно то, что, как мне кажется, нам не следует спорить о том, является ли P предикатом, или, более конкретно, высказыванием; нам нужно решить, трактуется ли он в таком качестве в нашей формальной системе – системе, о которой идет речь. Если такая трактовка допускается, мы имеем проблему. Однако заметим следующее:

Эта проблема не является проблемой конкретно языка Tutorial D; на самом деле, я не вижу, каким образом она могла бы быть проблемой этого языка, поскольку в своем примере я вообще не обращался к Tutorial D. Эта проблема не является и проблемой конкретно Третьего Манифеста, поскольку в своем примере я вообще не обращался и к Третьему Манифесту; я пользовался всего лишь тем общеизвестным фактом, что для каждого предиката имеется соответствующее отношение – а именно, то отношение, тело которого содержит те и только те кортежи, которые представляют истинную инстанциацию данного предиката. Эта проблема не является и проблемой конкретно реляционной модели, по существу, по той же причине. Эта проблема не происходит и из того факта, что в Третьем Манифесте требуется (неявно) вычислительная полнота Tutorial D. Я упоминаю этот аспект потому, что именно это является основным источником критики: то, что требование вычислительной полноты «приводит к созданию языка, логические выражения которого … являются, возможно, неразрешимыми» [6].
Замечу, что я не говорю, что это критическое замечание является некорректным; я всего лишь указываю, что отсутствие разрешимости в обсуждаемом примере (разрешимости того, входит ли кортеж в отношение или нет), по моему мнению, не имеет никакого отношения к вычислительной полноте Tutorial D.

Скорее, проблема (если здесь вообще имеется проблема) связана с логикой. Другими словами, либо в логике допускается P в качестве предиката, либо не допускается. Если допускается, то имеется проблема, связанная с логикой. Если не допускается, то нет проблемы в связи с логикой, а проблемы (если они имеются) связаны с реляционной моделью. С большим основанием Третий Манифест и Tutorial D здесь вообще не при чем.

Замечание: Насколько я понимаю, Рассел в своей теории типов был вынужден принять недопустимость P и других подобных утверждений в качестве предикатов. Однако, даже если согласиться с этим, мое утверждение остается неизменным: если в этой области и существует проблема, она является внутренней проблемой – она не связана с какой-либо ошибкой в Третьем Манифесте или Tutorial D.

Обсуждение некоторых критических замечаний в адрес Третьего Манифеста

К. Дж. Дейт
Перевод -

Оригинал: A Discussion of Certain Criticisms Concerning The Third Manifesto

Поскольку эта заметка сама является введением к трем статьям, перевод которых также предлагается вашему вниманию, я ограничусь очень кратким текстом. Мне кажется, что эти статьи Дейта являются очень полезным дополнением к книге Databases, Types, and the Relational Model (про нее см. ниже и в других статьях этой серии). Вместе с тем, мне показалось, что статьи можно с пользой читать и без предварительного знакомства с этой книгой. В любом случае, я надеюсь, что эти статьи дадут вам представление о некоторых проблемах, существующих в области языковых и модельных основ баз данных, и о путях решения этих проблем, предлагаемых Хьюго Дарвеном и Кристофером Дейтом.

С.Д. Кузнецов

Задайте нелепый вопрос, и вы на полпути к уместному ответу

Джейкоб Броновски

Эта заметка является кратким введением в серию из трех отдельных, но взаимосвязанных статей, относящихся к Третьему Манифесту. Третий Манифест – для краткости, просто Манифест – это наше с Хью Дарвеном формальное предложение основания для систем управления данными и базами данных (СУБД). Подобно исходным статьям Кодда, посвященным реляционной модели данных, наш Манифест можно считать абстрактной моделью для разработки СУБД. По сути, он состоит из набора тщательно подобранных принципов, представленных в форме предписаний и запретов, приверженность к которым мы с Хью требуем в гипотетическом языке программирования баз данных, называемом нами языком D. Различные предписания и запреты подробно описаны в нашей книге Databases, Types, and the Relational Model: The Third Manifesto, 3rd edition (Addison-Wesley, 2006), которую я далее буду называть «книгой о Манифесте».

Далее, любая научная попытка почти обязательно подвергается анализу и сомнениям, и в этом отношении Манифест и язык D не являются исключениями. На самом деле, некоторые исправления, которые мы смогли сделать в последние годы, являются прямым результатом критических замечаний, прозвучавших в разное время.
В ряде других случаев мы смогли показать, что по некоторым причинам критика была безосновательной; в некоторых же случаях вопрос еще не решен в том смысле, что остается неясным, требуются ли какие-либо изменения. Три представляемые вашему вниманию статьи связаны с критическими замечаниями, частично или полностью относящимися к этой третьей категории. Эти критические замечания выявились в ходе частной переписки в конце 2005 – начале 2006 гг. между Хью и двумя людьми (имена которых здесь умышленно не приводятся). По существу, эти два критика утверждают следующее:

В языке D допускаются неразрешимые (являющиеся парадоксальными) выражения. От языка D требуется вычислительная полнота. От языка D требуется поддержка переменных отношений (relvar) и операции присваивания отношений.

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

(Gödel, Russell, Codd: A Recursive Golden Crowd) (And Now for Something Completely Computational) (To Be Is to Be a Value of a Variable)

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


Однако я должен предупредить вас, что это мое решение не означает, что материал статей не перекрывается.

Есть еще пара предварительных замечаний, которые мне следует привести в этом введении. Первое относится к тому, что мы называем Tutorial D и его связи с языком D. Название D является родовым – оно используется в книге о Манифесте для обозначения любого языка, соответствующего принципам, которые заложены в Манифесте. Таким образом, может существовать любое число различных языков, оцениваемых как допустимый D. Язык Tutorial D является одним из таких языков; он определяется, более или менее формально, в самой книге о Манифесте и используется во всей книге (и в других публикациях) как базис для примеров. Однако, к сожалению, наши критики часто не проводят должного различия между D и Tutorial D, хотя между ними существует явное логическое различие. В результате иногда трудно сказать, направлена ли критика на Манифест в целом или же на Tutorial D, рассматриваемый как конкретная и, возможно, дефектная попытка определения D. В этой ситуации иногда бывает трудно отвечать на критические замечания.

Что касается второго предварительного замечания, я начну с немного измененной выдержки из самой книги о Манифесте:

Мы должны подчеркнуть, что мы не предлагаем какую-либо разновидность «новой» или «расширенной» реляционной модели. Скорее, мы говорим о том, что можно было бы назвать «классической» версией этой модели; мы стараемся предоставить настолько тщательное и точное описание этой модели, насколько способны на это. Действительно, мы пользуемся возможностью расставить точки над несколькими i и черточки в нескольких t (т.е. немного прибраться там и сям); однако модель в том виде, в котором мы ее описываем, в существенных аспектах не отличается от исходной версии Кодда, зафиксированной [в его ранних статьях] … Идеи Манифеста ни в коей мере не направлены на замену идей реляционной модели; скорее, идеи реляционной модели используются как основа для построения идей Манифеста … По нашему мнению, Манифест соответствует духу исходных работ Кодда и следует заложенному им пути.


Нас интересует эволюция, а не революция.

Причина, по которой я процитировал здесь этот длинный пассаж, объясняется феноменом, наблюдаемом нами в некоторых критических замечаниях по поводу нашей работы, а именно, в тенденции к жалобам на то, что наши предложения в чем-то конфликтуют с собственными статьями Кодда – из чего, вероятно, должна следовать ложность наших предложений. Мы отвергаем существование такого конфликта как возможного повода для критики, и мы отвергаем выводимое из этого следствие. С нашей точки зрения, гений Кодда проявился, прежде всего, в его изобретении реляционной модели, а также в его исключительной серии статей по этому поводу в 1969-1974 гг. Однако из этого не следует, что мы безоговорочно согласны со всем, что написал Кодд о реляционной модели данных. Поэтому, безусловно, в некоторых аспектах Манифеста наши идеи отклоняются от идей Кодда – спешу добавить, что не во многих аспектах, а лишь в некоторых. Показательным примером является поддержка неопределенных значений; Кодд этого требовал (кроме как в ранних статьях о реляционном подходе), а Манифест отвергает.

Заканчивая это введение, я бы хотел поблагодарить Хью Дарвена за его анализ и критику ранних вариантов всех трех статей.

Обучающийся оптимизатор

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

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

Рис. 1. Отложенное обучение

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

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

Механизм замедленного обучения реализован с использованием DB2 Universal Database (UDB) для платформ Linux, Unix и Windows. Эксперименты с прототипом [18] показали, что мониторинг занимает менее 4% всего времени исполнения запроса, в то время как производительность может увеличиться на несколько порядков, особенно в тех случаях, когда оптимизатор «понимает», что нужно использовать метод массивного соединения, а не метод соединения на основе вложенных циклов, по причине большой мощности входных данных.

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

Как правило, время ответа и память являются оптимизированными, если каждая строка полностью обрабатывается и возвращается пользователю конвейерным образом. Но иногда строки промежуточного результата должны быть полностью материализованы в виде отсортированной или не отсортированной временной таблицы (TEMP). Соответствующую точку QEP мы называем точкой материализации. Наличие таблиц TEMP обеспечивает естественную возможность подсчитать число строк и, возможно, повторно оптимизировать план прежде, чем какая-либо строка будет возвращена пользователю.


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

Поскольку повторная оптимизация требует определенных затрат, то когда она оправдана? Как можно эффективно выполнить повторную оптимизацию?

Первый из этих вопросов рассматривается ниже. Что касается второго вопроса, самое очевидное решение — просто еще раз выполнить запрос «с самого начала» по новому плану. Однако при этом придется отказаться от всей (возможно, значительной) работы, которая уже была проделана до точки материализации, сохраненной в таблице TEMP. В большинстве случаев для повторно оптимизированного плана было бы предпочтительнее избежать потребности в повторном выполнении этой работы путем использования готовой TEMP в повторно оптимизированном плане.

Рис. 2. План запроса, который может оптимизироваться динамически

Так, на рис. 2 показан план запроса для простого соединения двух таблиц, в котором группировка/ агрегация таблицы Orders по столбцу Product_Id выполняется до соединения. Для выполнения сортировки, которая может понадобиться для выполнения этой агрегации, необходимо полностью сформировать все входные данные до начала сортировки; эти данные образуют таблицу TEMP. Поскольку большая часть агрегатных функций может вычисляться в инкрементальном режиме, по мере сортировки строк, в своем окончательном виде TEMP будет содержать результат выполнения раздела GROUP BY. Оптимальный алгоритм соединения (соединение методом вложенных циклов, соединение через хеширование или соединение слиянием) для последующего соединения Orders и Products критически зависит от размера результата GROUP BY. Оптимизатор запросов может выбрать неоптимальный алгоритм слияния при переоценке или недооценке размера этого результата.

Однако во время выполнения запроса оптимизатор может отслеживать размер результата GROUP BY и повторно оптимизировать при обнаружении серьезных ошибок оценки, например, изменяя при необходимости алгоритм соединения.


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

Более хороший подход состоит в том, чтобы не оформлять TEMP в виде таблиц, а определять их как материализованные представления [13] (в DB2 их называют Automatic Summary Table [14]) и предоставлять их определения оптимизатору запросов. Тогда оптимизатор может опираться на стандартные методы проверки соответствия представлений [15] для определения того, какие TEMP стоит использовать повторно. Затраты на повторную оптимизацию с использованием дополнительных материализованных представлений практически идентичны затратам на оптимизацию исходного запроса, поскольку от оптимизатора требуется всего лишь рассмотрение одного альтернативного метода доступа к промежуточной таблице для каждого материализованного представления.

Более того, если TEMP определяются в виде материализованных представлений, нет оснований ограничивать их использование только текущим запросом. Материализованные TEMP потенциально могут использоваться во всех последующих запросах таким же образом, как в них используются материализованные представления, определенные пользователями.Конечно, этот подход может привести к лавинообразному росту числа таких представлений, поэтому процессор запросов должен периодически удалять редко используемые представления; это сродни проблеме подвыбора материализованных представлений [16].

Обзор Alpha

Кодд явно устанавливает, что "не считает особенно важным синтаксис Alpha"; однако он вынужден использовать некоторый синтаксис при описании языка, и буду использовать здесь тот же синтаксис. Ключевые слова будут выделяться жирным шрифтом, чтобы выделить их в окружающем тексте.

Следующая сводка обеспечивает некоторое представление о возможностях языка:

Введение и удаление имен доменов: DAMAIN, DROP

Объявление и разрушение отношений: RELATION, DROP

Объявление переменных с областью определения (кортежных переменных): RANGE

Выборка: GET

Вставка: PUT

Обновление: HOLD, UPDATE, RELEASE

Удаление: DELETE

"Конвейерный режим": OPEN, CLOSE

Рассмотрим более пристально каждую из этих возможностей.

Обзор архитектуры CORBA.

Обобщенная Архитектура построения Брокеров Объектных Запросов разработана для поддержки интеграции самых разнообразных объектных систем. Спецификация CORBA устанавливает принципы создания Брокеров Объектных Запросов, которые и допускают такую интеграцию.

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

Обзор протокола GIOP.

Спецификация протокола GIOP состоит из следующих элементов:

Определение Общего Представления Данных (Common Data Representation - CDR). CDR - это способ кодирования типов данных, определенных в IDL в низкоуровневое представление, пригодное для передачи их по имеющимся каналам связи между ORB-ами. Формат сообщения протокола GIOP. Сообщения протокола GIOP обеспечивают нахождение объекта, отработку запросов, а также простейшее управление каналом коммуникации. Предположения о транспорте. Спецификация GIOP описывает общие предположения, которые делаются при рассмотрении любого сетевого транспортного слоя, который может быть использован для обмена сообщениями протокола GIOP. Также описываются общие принципы управления соединением.

Спецификация IIOP добавляет к спецификации протокола GIOP следующий пункт: Транспорт для сообщений протокола IIOP.

Спецификация IIOP описывает, каким образом агенты могут установить соединение по протоколу TCP/IP и использовать его для передачи сообщений протокола GIOP.

Протокол IIOP не является самостоятельной спецификацией - это специализированное отображение протокола GIOP поверх транспортного слоя TCP/IP. Спецификация GIOP (без элементов, специфичных для IIOP) может рассматриваться как самостоятельный документ, являющийся базовым для обеспечения в будущем отображения на новые транспортные протоколы.

Обзор статьи

Конечно, сейчас битва между реляционным и сетевым подходами кажется древней историей. (Победили хорошие парни.) Несмотря на это, статья Кодда -- написанная более 25 лет тому назад -- по-прежнему представляет собой великолепный пример ясных рассуждений. Действительно, замечательным фактом является то, что в то время, когда нормой являлось беспорядочное мышление, Кодд оказался в состоянии разорвать замкнутый круг и сосредоточиться на действительно важных предметах. Позвольте уточнить:

Прежде всего, Кодд понимал, что сравнение весьма конкретных спецификаций CODASYL и гораздо более абстрактной реляционной модели напоминало бы сравнение яблок с апельсинами и привело бы ко множеству недоразумений. Поэтому было необходимо сначала определить абстрактную "сетевую модель". Тогда можно было бы выполнить сравнение в разумной манере.

Исходя из этого, Кодд приступает к определению абстракции такой модели. (И, конечно, после этого он переходит к сравнению этой абстракции с реляционной моделью.)

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

В любом случае, наиболее значительное достижение статьи "Interactive Support for Nonprogrammers: The Relational and Network Approaches", вероятно, состоит в введении понятия существенности, понятия, которое является критическим для правильного понимания моделей данных в целом и различия между отношениями и сетями, в частности. (В действительности, именно главным образом по этой причине мне захотелось поговорить об этой статье в данной серии.)

Помимо введения понятия существенности, в статье Кодда также поднимается ряд вопросов относительно уместности использовния сетевых структур в качестве компонента того, что он называет "принципиальной схемой" - вопросов, на которые, насколько мне известно, до сих пор нет ответов в доступной литературе. Цитирую: "В прошлом многих разработчиков проограммного обеспечения ... смущало различие между двумя совершенно различными понятиями: с одной стороны, расширениями возможностей и, с другой стороны, общностью приложения." Как верно! "Критическим аспектом систем управления базами данных является то, что это богатство возможностей (т.е. их изменчивость) структур данных ... должно поддерживаться принципиальной схемой. Если возможности этих структур данных ... выходят за пределы некоторого минимума, нужно задать следующие вопросы ... "Мне не хочется здесь подробно обсуждать эти вопросы, однако я уже говорил об этом в одной из предыдущих публикаций [3]).

Между прочим, эта цитата напоминает мне другую, которая взята из вводной статьи Кодда о нормализации [4]. "В нескольких существующих системах допускается разнообразие физических представлений заданной логической структуры... Сложность физических представлений, поддерживаемых этими системами, видимо, невозможно понять, поскольку эти представления выбираются в расчете на повышение эффективности... Еще менее понимаема тенденция к все более и более усложняемым структурам данных, с которыми ... непосредственно имеют дело пользователи. Конечно же, при выборе логических структур данных должно присутствовать только одно соображение - удобство большинства пользователей." Опять, как это верно!

Вернемся к "Interactive Support". В статье содержится приложение, в котором сравниваются версии CODASYL/COBOL и relational/Alpha простого приложения управления магазином. Это сравнение убедительно демонстрирует простоту реляционного подхода (конечно, с точки зрения пользователя). Полные подробности сравнения содержатся в реальном программном коде обоих решений.


Я отсылаю вас к исходному тексту статьи; при этом мне хочется повторить некоторые замечания из одной из моих предыдущих статей [5], в которой обсуждался тот же самый пример. Вот некоторая статистика:

	CODASYL	relational
GO TO	15	0
PERFORM UNTIL	1	0
currency indicators	10	0
IF	12	0
FIND	9	0
GET	4	1
STORE / PUT	2	1
MODIFY	1	0
MOVE CURRENCY	4	0
other MOVEs	9	1
SUPPRESS CURRENCY	4	0
total statements	> 60	3

Относительная простота реляционного решения просто поражает. Замечание: реляционное решение может быть сведено к одному оператору PUT; GET и MOVE не являются строго обязательными. Более того (хотя Кодд не упоминает этот факт), решение CODASYL - которое заимствовано из другого источника, а не создано самим Коддом - содержит по меньшей мере две ошибки!

Этот пример проясняет и еще один вопрос. Цитируя Кодда, "Предостерегаем читателя от попытки сравнения [разных] подходов исключительно на основе основных различий в [структурах данных]. Достаточное внимание должно уделяться ... и операторам." И далее он добавляет: "В обсуждениях реляционного подхода часто преобладают аспекты компонента [структур данных] в ущерб [другим компонентам]. Для обоснования этого подхода все ... компоненты должны рассматриваться в одном пакете."

Многие покупатели средств управления базами

Многие покупатели средств управления базами данных не

заинтересованы по-крупному в быстром развитии

объектно-реляционной технологии. До сих пор ни один поставщик не

смог объяснить преимущества этой технологии для пользователей баз

данных основного потока. Более того, во всех ведущих продуктах

управления реляционными базами данных под одной и той же вывеской

объектно-реляционного подхода предлагаются в значительной степени

разные средства. На основе чего пользователи могут сравнить эти

продукты?

Трудно обсуждать природу и значение объектно-реляционной

технологии, поскольку, в отличие от реляционной модели, эта

концепция не является единой и хорошо оформленной.

Объектно-реляционная парадигма является скорее слабо связанным

набором многих отдельных полезных компонентов. Более 120

функциональных аспектов называют "объектно-реляционными", от

наследования и полиморфизма до поддержки больших объектов,

расширяемой индексации и кэширования и кластеризации сложных

объектов. Некоторые из этих аспектов учитываются в процессе

выработки стандарта SQL3, другие (например, кэширование и

кластеризация) - нет. В ведущих продуктах реализуются существенно

разные поднаборы функций.

Поэтому не удивительно, что многие потенциальные пользователи

этой технологии находятся в замешательстве. Аргументы отдельных

поставщиков относительно того, какие части технологии являются

обязательными для "истинных" объектно-реляционных баз данных, не

помогают. Для того, чтобы устранить это замешательство и остаться

в стороне от сражений поставщиков, можно использовать модель,

группирующую объектно-реляционные свойства, базируясь на их

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

внимание реализационные особенности.

Развитая технология баз данных может (и должна) обеспечить

следующие категории свойств:

Приложения обработки данных следующего поколения. Возможность

просто и быстро создавать информационные системы, ориентированные

на использование баз данных, в большей степени удовлетворяющие



потребностям пользователей. К соответствующим свойствам относятся

наследование уровня таблиц, расширенное управление доменами,

строчные типы в духе SQL3 и определяемые пользователями функции.

Управление содержимым. Возможность получать пользу из

смешанной текстовой, документальной и мультимедийной информации с

использованием структурированных данных существующий

информационных систем. К соответствующим свойствам относятся

хорошая поддержка больших объектов и применимость SQL-запросов

для текстового поиска.

Проектирование прилоожений. Более специальные преимущества

реализации приложений, работающих со сложными данными и

транзакциями (CAD, CASE, офисная автоматизация). Это та ниша, в

которой наиболее успешно применялись чистые объектные базы

данных. К требуемым свойствам относятся поддержка нетрадиционных

типов транзакций, идентифицируемость объектов и навигация по

указателям.

Интеграция на основе объектной ориентированности. Преимущество

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

объектной технологии и методов, применяемых пользователями,

включая объектно-ориентированные языки программирования и брокеры

объектных заявок (ORB - Object Request Broker).

Адаптивность. Уменьшение расходов и/или повышение

производительности труда за счет использования систем баз данных,

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

потребности их изменения.

Управляемость. Уменьшение расходов в связи с более простым

управлением системой баз данных и приложениями. Например,

введение нетрадиционных или расширенных типов может затруднить

управление, если только эти расширения не интегрированы должным

образом со средствами администратора баз данных.

"Универсальная" настраиваемость. Возможность добиться

приемлемой эффективности разного рода приложений, основывающихся

на различных архитектурах, путем настройки программного

обеспечения (а не покупая большее количество аппаратуры).

Соответствующие свойства включают расширяемую индексацию,



простоту использования в разных архитектурных средах, кэширование

и кластеризацию сложных объектов.

Простота освоения. Возможность получать пользу от новой

технологии без существенных затрат, переподготовки штата и

модификации существующих приложений. В этом отношении существенны

соответствие стандартам SQL и обеспечение интероперабельности с

унаследованными базами данных и приложениями.

На основе приведенной модели можно оценить функциональные

возможности пяти ведущих поставщиков продуктов управления базами

данных - Oracle8, Informix Universal Server, DB2 Unversal

Database, Sybase Adaptive Server и Microsoft SQL Server (вместе с

OLE DB). Модель можно с тем же успехом применить к чисто

реляционным или чисто объектным базам данных, а также для

иллюстрации связи между разными технологиями и их эволюции.

В приведены диаграммы, иллюстирующие эволюцию

технологии баз данных от базовых СУБД, поддерживающих стандарт

SQL-89, до "идеального" универсального сервера. Кроме того, с

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

ожидаемые характеристики Oracle 8.1.

Один и тот же набор данных может одновременно описываться разными моделями.

Рассмотрим следующий пример. Программа написанная на O-языке, например С++, сохраняет свои данные в виде обьектов в ОЗУ компьютера. ОЗУ, которое является хранилищем данных, описывается некоторой моделью данных (которую можно назвать моделью ОЗУ) и позволяет сохранять данные в виде набора адресуемых элементов памяти. Программа написанная на О-языке, позволяет представить эти же данные в виде идентифицируемых наборов информации (т.е. обьектов) имеющих определенную структуру (определяемую типом класса объекта), из чего следует , что для каждого элемента хранилища (в данном случае ячейки ОЗУ) тем или иным образом определено 1) о каком именно объекте он содержит информацию 2) какое место занимает этот элемент в структуре этого объекта и ( поскольку место в структуре определяется именем и это же имя определяет семантическое значение - или смысл - данного элемента) то, какой смысл имеет данная информация для этого объекта. Можно сказать, что объектом в данном случае является осмысленный и идентифицируемый набор элементов хранилища(ОЗУ).

Что же можно понимать под разными моделями данных? Можно рассмотреть этот вопрос с точки зрнения классификации моделей данных. В настоящее время выделяют три уровня моделирования прикладной области - концептуальный, логический и физический[18,20]. В приведенном примере можно выделить модели концептуального уровня ( объектная модель языка C++) и физического уровня (модель ОЗУ). Таким образом, можно предположить, что разными являются модели относящиеся к разным уровням. Однако такое определение является весьма условным.

Более строго разными моделями данных можно назвать ортогональные модели. Определение ортогональных моделей является весьма нетривиальным. В рамках данной статьи интересным представляется следствие ортогональности (основанное на том, что модель данных можно определить как множество возможных типов данных [2]): любой тип данных определенный в модели М* ортогональной данной модели М, может рассматриваться в данной модели М только как скалярный (базовый) тип[6,8,10,12, 13,15]. В приведенном примере такими скалярными типами, используемыми в объектной модели языка С++, являются базовые типы int, char и т.п. описывающие возможные типы элементов хранилища данных, т.е. определенные в модели ОЗУ. Таким образом можно сказать, что один и тот же набор данных может одновременно описываться несколькими ортогональными моделями.

Ограничение подставляемости для конкретного подтипа

Итак, я могу отключить все уровни подставляемости, но что если необходимо отключить всю подставляемость кроме конкретного подтипа? Предположим, например, что я хочу создать PL/SQL коллекцию десертов, которая может содержать только пирожные. Или я хочу ввести правило в моей таблице meals, что все десерты должны быть пирожными. Oracle предоставляет предложение IS OF для этой цели. Вот новое объявление таблицы meals, в которой существует два различных типа ограничения подставляемости:

CREATE TABLE meal ( served_on DATE, appetizer food_t, main_course food_t, dessert dessert_t ) COLUMN appetizer NOT SUBSTITUTABLE AT ALL LEVELS, COLUMN dessert IS OF (ONLY cake_t) ;

И теперь я смогу добавлять только такие приемы пищи, в которых десерты объявлены как пирожные. Поэтому следующий INSERT отвергается:

SQL> BEGIN 2 -- This will no longer work. 3 INSERT INTO meal VALUES ( 4 SYSDATE, 5 food_t ('Shrimp cocktail', 6 'PROTEIN', 'Ocean'), 7 food_t ('Eggs benedict', 8 'PROTEIN', 'Farm'), 9 dessert_t ('Strawberries and cream', 10 'FRUIT', 'Backyard', 'N', 2001)); 11 END; 12 / BEGIN * ERROR at line 1: ORA-00932: inconsistent datatypes

Оператор IS OF type можно использовать только для того, чтобы ограничить объекты строки и столбца для одного подтипа, не для нескольких. Необходимо также использовать ключевое слово ONLY, даже если это единственная альтернатива, доступная сейчас. Вы можете использовать либо IS OF type, либо NOT SUBSTITUTABLE AT ALL LEVELS для ограничения объектного столбца, но нельзя использовать и то и другое для одного и того же столбца. Очевидно, что эти ограничения можно применять к различным столбцам, как показано раньше.

Ограниченность современной объектной концепции.

Вкратце общее описание современной объектной концепции (в дальнейшем СОК) можно условно свести к нескольким частям:

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

Сразу надо отметить, что фактически в СОК речь идет о разных уровнях моделирования. В первой части говориться о концептуальной модели (концептуальный уровень). В этой модели предметной областью являются сущности реального мира, т.е. под объектом подразумевается набор данных описывающий некоторую сущность (будем называть такой набор данных концептуальным объектом). Вторая и третья часть ОК объясняет организацию данных, то есть по сути дела рассказывает о логической модели (логический уровень). Предметной область в этом случае являются данные, а под объектом подразумевают упорядоченный, определенным образом организованный набор данных (назовем его логический объект).

Заметим также, что в СОК неявно проходят два на первый взгляд очень схожих утверждения. Первое относится к концептуальному уровню. Отталкиваясь от мысли, что в реальном мире всё существует в виде сущностей, СОК декларирует, что вся информация о реальном мире должна быть представлена как набор информационных объектов. Второе, относящееся к логическому уровню, говорит, что любая типизированная переменная является объектом, поскольку все, в том числе и примитивные, типы являются классами. Это утверждение гораздо строже первого - если оно выполняется, то первое также будет обязательно истинным.
Обратное же неверно - если предположить, что атрибут объекта сам объектом не является (т.е. второе утверждение - ложь), то первое останется истинным, поскольку информация содержащаяся в атрибуте по-прежнему будет частью информации описывающей объект.

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

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

В чем же заключается ограниченность СОК? Рассмотрим следующий пример. Пусть существует класс Cars описывающий транспортные средства и пусть у него определен метод getWeight возвращающий вес транспортного средства. Для хранения информации о весе используется атрибут weight предопределенного типа float.

class Cars {... private: float weight; public: int getWeight () { // возвращает значение переменной weight }... ...}



Для того, что бы продолжить наши рассуждения необходимо вспомнить понятия "значение" и "переменная". Они являются очень важными, и в дальнейшем мы часто будем их использовать. Вот, например, как определяет их Дейт: "…Значение - это индивидуальная константа (например, константа "3"). У значения нет своего места во времени и пространстве. Однако значения могут быть представлены в памяти посредством некоторой кодировки и, конечно, у таких кодировок имеется место во времени и пространстве. По определению, значение невозможно модифицировать. Переменная - это держатель кодировки значения. Переменная имеет место во времени и пространстве. Кроме того, переменные, в отличие от значений, конечно, можно модифицировать, т.е. текущее значение данной переменной можно заменить другим значением, возможно, отличным от исходного." Можно сказать проще: значение - это информации, а переменная - это место для хранения этой информации, представленной определенном образом.

Вернемся к примеру. Существуют два автомобиля имеющие одинаковый вес (1000 кг). Описывая эту ситуацию, мы должны создать два объекта o1 и o2 класса Cars и присвоить значение 1000 переменным o1.weght и o2.weght, которые являются атрибутами этих объектов. Если исходить из СОК, где любой объект отличается от любого другого объекта, то переменные o1 и o2, так же как и переменные o1.weght и o2.weght, являются разными объектами. Однако это не очень соответствует повседневному опыту. Да, в реальной жизни про автомобили мы скажем, что они разные, однако про их вес мы скажем, что он один и тот же. Говоря образно, сравнивая автомобили, мы сравниваем их как переменные, несмотря на то, что информация, описывающая их абсолютно одинакова. Сравнивая же веса, мы сравниваем их значения, и в этом случае факт, что эти значения описывают разные автомобили не играет никакой роли.

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


В первую группу будут входить сущности (будем называть их вещами), которые мы сравниваем как переменные. К их числу относятся, например автомобили, дома, люди, телефонные аппараты, страны, фирмы....список можно продолжать до бесконечности. К числу других сущностей относятся те, которые мы сравниваем как значения (будем называть такие сущности значимыми). Значимыми сущностями являются вес, адрес, имя, телефонный номер, географические координаты, индивидуальные номера налогоплательщиков (ИНН).... этот список также ничем не ограничен.

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

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



Ограниченность объектной концепции проявляется и в том, что реально существующие объектные системы и языки программирования в той или иной степени всегда выходят за ее рамки. Речь идет о предопределенных типах, таких как int или float. СОК называет такие типы "примитивными классами" и, в соответствии с этим, переменные этих типов называются "примитивными объектами". Однако никому не приходит в голову сравнивать числа (значения), используя в качестве критерия тот факт, что эти значения хранятся в разных примитивных объектах (переменных), хотя концепция "объект" подразумевает именно такой способ сравнения информации. Другими словами объектная концепция, декларируя некий набор свойств, характерных для абстракции "объект", сразу же допускает, что для некоторых объектов эти свойства могут нарушаться. А может быть проще вообще не называть примитивные переменные объектами и, соответственно, предопределенные типы классами?

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

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

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

OID. Качество "уникальный объект".

Понятие "уникальный объектный идентификатор" (OID) является одним из основных в СОК. Как уже говорилось, именно OID, являясь единственным критерием позволяющим отличить один объект от другого, используется в объектных системах для организации доступа к объектам. Любому объекту oi на всем протяжении его жизни соответствует одно уникальное и неизменное значение OIDi . Множество возможных значений OID образует домен DOID. Следует отметить, что понятие OID служит для описания логической организации данных, то есть относится к логической уровню СОК. Рассмотрим, что же представляет из себя OID с концептуальной точки зрения.

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

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

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

Подобно любому другому, качество "уникальный объект" обладает реляционной природой. Множество значений этого качества можно рассматривать как отношение QOID. Каждому объекту Oi, идентифицируемому соответствующим OIDi, в модели "объект-качество" соответствует один и только один кортеж отношения QOID. Таким образом ранее описанный домен DOID, являющийся множеством возможных значений уникальных идентификаторов объектов, может и должен рассматриваться как домен, на котором определен атрибут отношения QOID , являющийся первичный ключ этого отношения.

Операции.

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

спецификации параметров, требуемых для выполнения операции

спецификации возвращаемого значения

спецификации исключения, которые могут возникнуть во время выполнения операции и типов данных, которые соответствуют этим исключениям

спецификации дополнительной контекстной информации, которая может повлиять на выполнение запроса

индикации семантики, которую клиент должен учитывать при выполнении операции.

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

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

Все операции можно разбить на следующие группы:

Создание объектов и наблюдений Поиск Навигация Администрирование, статистика, утилиты, другие операции

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

Операции манипулирования данными

Выборка: Вот пример выборки на языке Alpha ("Получить имена поставщиков и названия городов для поставщиков, которые поставляют все детали"):

RANGE S SX
RANGE SP SPX
RANGE P PX

GET W1 (SX.SNAME, SX.CITY):
ALL PX SOME SPX (SPX.S# = SX.S# AND SPX.P# = PX.P#)

В этом примере W1 - имя применяемого рабочего пространства; двоеточие можно воспринимать как "где" или "такое, что", а ALL и SOME обозначают кванторы всеобщности и существования соответственно. В действительности, в [2] для ALL и SOME используются стандартные логические символы (как и для связок AND, OR и т.д.); в отличие от этого, в [1] применяются ключевые слова, что я предпочитаю. Согласно [2] кванторы можно переместить в объявления RANGE, например:

RANGE S SX

RANGE SP SPX SOME

RANGE P PX ALL

GET W1 (SX.SNAME, SX.CITY):

SPX.S# = SX.S# AND SPX.P# = PX.P#

Замечание: В [2] никогда не упоминается возможность определения переменной на области значений, являющейся, например, объединением двух базовых отношений, и вообще на чем-то более сложном, чем одно базовое отношение. (Я обсуждал эту возможность в своей заметке в прошлом месяце.) Кроме того, в ранней статье [1] использовалось ключевое слово DUMMY вместо RANGE в тех случаях, когда требуется разновидность "фиктивной" переменной (я также обсуждал это предыдущей заметке).

Операции GET также допускают:

Ссылки на отношения в рабочих пространствах, как если бы они были в базе данных. В таких ссылках используются имена рабочих пространств как если бы они были именами отношений. Спецификация упорядочения результата (аналогично ORDER BY в языке SQL) с использованием ключевых слов UP и DOWN. Спецификация квоты для ограничения числа выбираемых кортежей. Однако в статье не рассматривается вопрос о том, что должно произойти, если результирующее отношение определяется неоднозначно [10]. Использование некоторых истинностных функций (TOP и BOTTON). TOP и BOTTON - это аналоги Alpha описанных в [10] функций IS_NTH_LARGEST и IS_NTH_SMALLEST. Использование некоторых агрегатных функций (COUNT, TOTAL, MAX, MIN, AVERAGE в целевом списке (однако термин "агрегатные функции" не используется).
Замечание: В исходной версии статьи упущен из вида тот факт, что, по крайней мере, для TOTAL и AVERAGE аргументом является мультимножество, а не множество (дубликаты не должны удаляться до выполнения агрегации). Позже Кодд признал эту ошибку [3].

Немного отходя от основной темы, замечу, что в Alpha прямо не допускается использование агрегатных функций в условии выборки; используется сокращенная версия, называемая функциями образов (которые могут также применяться и в списке выборки). Я опускаю здесь детали, хотя, если говорить честно, не думаю, что функции образов относятся к числу лучших идей Alpha. На самом деле, они могли быть источником странного синтаксиса вызова агрегатных функций и в QUEL, и в SQL и сложности обоих языков, связанной с этим неортодоксальным синтаксисом. (Эти сложности порождаются тем фактом, что аргументы функции частично определяются контекстом вместо того, чтобы -- что было бы более ортодоксально -- полностью определяться тем, что содержится в скобках, непосредственно следующих за именем функции [7,8].)

В Alpha также допускается покортежное выполнение выборки в конвейерном режиме (аналогично FETCH через курсор в языке SQL). Например (в предположении тех же, что и раньше определений RANGE):

OPEN GET W1 (SX.SNAME, SX.CITY):

SPX.S# = SX.S# AND SPX.P# = PX.P# UP SX.CITY

GET W1

/* теперь текущая строка обрабатывается программой на основном языке */

.…

CLOSE W1

Здесь при каждом выполнении GET W1 из результата запроса в OPEN выбирается следующий кортеж. (Обратите внимание на спецификация упорядочения UP в этом OPEN.) Конечно, конвейерный режим открывает возможность дискредитации системы, поскольку его можно использовать для выполнения того, что по существу является "ручной навигацией" (вместо автоматической навигации, обычно являющейся предпочтительной в реляционной системе) [4]. Но конвейерный режим или что-то в этом роде является существенным, если язык, как в случае Alpha, - это подъязык данных.

Вставка: Операция PUT пересылает набор кортежей из указанного рабочего пространства в указанное отношение.


Например:

PUT W2 SP

(" Вставить кортежи из рабочего пространства W2 в отношение SP".) Можно также указать и порядок, чтобы дать знать системе, что вставляемые кортежи упорядочены некоторым образом в рабочем пространстве. На самом деле, в связи с этим понятием я ощущаю небольшой дискомфорт; мне кажется, что здесь слишком сильно перемешаны идеи логического и физического уровней.

Возможна также "конвейерная вставка":

OPEN PUT W2 S

….

/* конструирование текущей строки программой на основном языке */

PUT W2

….

CLOSE W2

Обновление: Вот пример обновления данных ("Переместить всех парижских поставщиков в Рим"):

HOLD W3 (SX.S#, SX.CITY): SX.CITY = 'Paris'

/* установить значение 'Rome' столбца CITY в каждом кортеже */
/* рабочего пространства с использованием основного языка */

UPDATE W3

В языке Alpha требуется, чтобы обновляемые строки были сначала выбраны с помощью HOLD. (Отсутствует аналог беззаботного "поискового UPDATE" языка SQL.) Целевой список HOLD должен содержать в точности одну переменную с областью значений, что означает, что UPDATE будет применяться только к одному (базовому) отношению. (Как говорит Кодд, "[ограничение одной переменной с областью определения] позволяет избежать неоправданной сложности". И всего-то!) Если пользователь решит после всего не выполнять UPDATE, то может быть выполнена операция RELEASE W3, чтобы освободить сохраняемые кортежи.

Замечание: Хотя в [2] это не говорится, целевой список HOLD должен включать все атрибуты первичного ключа обновляемого отношения, чтобы система могла узнать, какие кортежи вы обновляете [3]. Сами атрибуты первичного ключа не могут напрямую обновляться с помощью последовательности HOLD…UPDATE, но для достижения аналогичного эффекта можно использовать удаления и вставки.

Для HOLD…UPDATE/RELEASE также возможен конвейерный режим (аналогично UPDATE CURRENT в языке SQL). Странно, что нет аналога DELETE CURRENT. Однако это упущение не является важным, поскольку -- как я утверждаю в [9] -- идея обновления или удаления (а также и вставки) одного кортежа в любом случае является плохой.Операции обновления следует всегда выполнять над множествами.

Вероятно, можно сказать, что части Alpha, связанные с модификацией, не относятся к сильным сторонам языка; действительно приведенное обсуждение порождает много вопросов, которые просто не затрагиваются в статье.

Удаление: Операция DELETE в основном проста, если оставить в стороне приведенную ранее критику, применимую к операциям модификации в целом. Вот пример:

DELETE SX: SX.S# = 'S1'

В своей следующей заметке я завершу обсуждение подъязыка данных Alpha.

Операции определения данных

Начну с доменов. В Alpha упоминались только "простые" домены -- т.е. представляемые в терминах "простых" типов данных, таких как CHAR(5), NUM(4,0). Другими словами, домены не намного отличаются от того, что называется "DISTINCT types" в SQL3, а не являются полными абстрактными типами данных -- ADT -- во всей их красе. (С другой стороны, в статье ничего не говорится по поводу того, что они не могут быть полными ADT!) Вот пример определения (и разрушения) домена на языке Alpha:

DOMAIN CITY CHAR(15)

DROP CITY

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

[role-name] domain-name

где необязательное имя роли является квалификатором, требуемым только в том случае, когда один домен используется в отношении более одного раза. "Одно из важных преимуществ [этой схемы состоит в том, что она допускает] систематическое управление преобразованиями всех вхождений… Примером… является совместное изменение всех номеров деталей независимо от того, где они встречаются…". Как кажется, здесь Кодд, по крайней мере, частично недооценивает ту роль, которую мог бы иметь каталог в процессе такой трансформации -- странное упущение при том, что позже в статье явно упоминается каталог. (Действительно, одним из многих первооткрытий, содержащихся в статье про Alpha, является суждение о том, что сам каталог следует структурировать тем же самым образом, что и другие данные: а именно, как отношения.) Другими словами, я не уверен, что соглашение об именовании атрибутов является хорошим; на самом деле, в нем не принимается во внимание вопрос об именах атрибутов порождаемых отношений.

Обращаясь теперь к отношениям -- более точно, к тому, что Кодд называет "изменяемыми во времени" отношениями -- заметим, что в большей части статьи применяется подразумеваемое предположение, согласно которому все такие отношения являются базовыми; таким вопросам, как определение представлений и в особенности обновление представлений, практически не уделяется внимание (хотя в более ранней статье [1] содержится краткое обсуждение феномена, связанного с представлениями и называемого "миграцией доменов", что я затрону в своей следующей заметке). В определении такого отношения указываются имя отношения, имена атрибутов (и соответствующих доменов) и первичный ключ. Вот пример такого определения (и соответствующего DROP):

RELATION S (S#, SNAME_NAME, STATUS, CITY) KEY S#

DROP S

Операционные системы

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

Я не уверен, что это предсказание сбылось. Большая часть работ в области операционных систем за последние десять лет была связана с переходом на 64-х разрядные архитектуры.

Будут поддерживаться коммуникационные протоколы стека ISO и специализированные протоколы типа NFS.

Конечно, NFS поддерживается во всех вариантах ОС UNIX. Но что касается ISO/OSI, то поддержка этого стека так и не стала повсеместной практикой.

Реструктуризация ОС к виду, имеющему малое ядро с набором сервисов поверх его.

Условно можно считать, что так выглядит Windows NT, хотя далеко не все с этим согласны. Что же касается мира UNIX, то переход на микроядерную архитектуру в широких масштабах так и не произошел.

Существуют потребности встраивания поддержки транзакций в ядро ОС.

Пока примеров таких реализаций нет.

Сохранятся интерфейсы существующих ОС (например, MVS).

Так и случилось.

Оператор DELETE

Оператор DELETE в Oracle полностью соответствует требованиям начального уровня ANSI SQL. Однако имеются некоторые дополнительные возможности:

Ключевое слово FROM не обязательно использование табличных алиасов для ссылок на обновляемую таблицу в подзапросах подзапросы в предложении WHERE могут ссылаться на обновляемую таблицу Оператор DELETE поддерживает удаление из подзапросов

1,2 DELETE emp aaa WHERE sal IN (SELECT AVG(sal) 3 FROM emp bbb WHERE aaa.deptno=bbb.deptno)

1. в предложении DELETE отсутствует ключевое слово FROM

2. таблице emp присваивается алиас aaa для последующей ссылки на обновляемую таблицу в подзапросе

3. делается выборка из таблицы emp, из которой делается удаление этим же оператором

4. Оператор:

DELETE FROM emp WHERE job='управляющий'

аналогичен оператору: DELETE FROM (SELECT * FROM emp) WHERE job='управляющий'

Оператор INSERT

В Oracle имеются следующие дополнительные возможности по сравнению с ANSI SQL:

1. Оператор INSERT поддерживает подзапросы в предложении INTO

Оператор:

INSERT INTO dept VALUES (50,'продукция','Москва')

аналогичен оператору: INSERT INTO (SELECT deptno, ndept, loc FROM dept) VALUES (50,'продукция','Москва')

Оператор SELECT

В операторе SELECT имеются следующие дополнительные возможности по сравнению с ANSI SQL:

NULL в списке выборки Запрос из запроса (SELECT FROM (SELECT….)) Левая часть оператора IN может быть списком выражений в отличии от одиночного выражения в ANSI SQL Не только столбец, а любое выражение может быть использовано с оператором LIKE Любое выражение, а не только отдельный столбец может быть использован в операторах сравнения IS NULL и IS NOT NULL В предложении ORDER BY может быть использовано любое выражение содержащее любые столбцы любых таблиц предложения FROM в отличии от только имен, алиасов, номеров позиций столбцов списка выборки В предложении GROUP BY может быть использовано любое выражение содержащее любые столбцы любых таблиц предложения FROM в отличии от только имен, алиасов столбцов списка выборки Вложенные агрегатные функции MIN(MAX(col1)) (уровень вложенности не более 2) Оператор внешнего соединения (+) Древовидные запросы

1 SELECT ename, job, sal, deptno, NULL FROM 2 (SELECT * FROM emp WHERE deptno=30) 3 WHERE (ename,job) IN (SELECT ename,job FROM …. );

SELECT ename,ename2,sal,sal2 FROM emp 4 WHERE ename LIKE '%'ename2'%' AND 5 sal+sal2IS NOT NULL 6 ORDER BY sal+sal2

в списке выборки присутствует NULL-значение в предложении FROM указан подзапрос слева от оператора IN указан список из двух столбцов, а справа - запрос, возвращающий два столбца с оператором LIKE использовано выражение '%'ename2'%', содержащее ссылку на столбец С оператором сравнения IS NOT NULL используется выражение sal+sal2 Сортировка осуществляется по значению выражения sal+sal2

Оператор UPDATE

Оператор UPDATE в Oracle полностью соответствует требованиям начального уровня ANSI SQL. Однако имеются некоторые дополнительные возможности. Если отбросить возможности предназначенные для работы с объектными таблицами вот они:

использование табличных алиасов для ссылок на обновляемую таблицу в подзапросах подзапросы в правой части предложения SET в отличие от только выражений в ANSI SQL список обновляемых колонок в левой части предложения SET, в отличии от одной колонки в ANSI SQL подзапросы в предложении SET или WHERE могут ссылаться на обновляемую таблицу Оператор UPDATE поддерживает обновление подзапросов

Проиллюстрируем эти возможности на примере:

1 UPDATE emp aaa 2 SET deptno =(SELECT deptno FROM dept WHERE loc='Москва'), 3 SET (sal,comm)=(SELECT 1.1*AVG(sal),1.5*AVG(comm) 4 FROM emp bbb WHERE aaa.deptno=bbb.deptno)

1. таблице emp присваивается алиас aaa для последующей ссылки на обновляемую таблицу в подзапросе

2. значение столбца deptno берется из подзапроса, возвращающего одно значение

3. значение столбцов sal и col ,берется из подзапроса, возвращающего два значения

4. делается выборка из таблицы emp, которая обновляется этим же оператором

5 UPDATE emp SET comm=NULL WHERE job='управляющий'

этот запрос будет аналогичен следующему запросу:

UPDATE (SELECT * FROM emp )SET comm=NULL WHERE job='управляющий'

5. в данном примере Oracle будет обновлять временное представление SELECT * FROM emp. После предложения UPDATE в круглых скобках может следовать любой оператор SELECT. На основе этого оператора строится временное представление. Если это представление удовлетворяет условиям на обновляемые представления Oracle выполнит запрос.

Оператор выборки

Оператор выборки - это отдельный оператор языка SQL/89, позволяющий получить результат запроса в прикладной программе без использования курсора. Поэтому оператор выборки имеет синтаксис, отличающийся от синтаксиса спецификации курсора, и при выполнении оператора возникают ограничения на результат табличного выражения. Фактически, и то и другое диктуется спецификой оператора выборки как одиночного оператора SQL: при его выполнении результат должен быть помещен в переменные прикладной программы. Поэтому в операторе появляется раздел INTO, содержащий список переменных прикладной программы, и возникает то ограничение, что результирующая таблица должна содержать не более одной строки. Соответственно, результат базового табличного выражения должен содержать не более одной строки, если оператор выборки не содержит спецификации DISTINCT, и таблица, полученная применением списка выборки к результату табличного выражения, должна состоять только из строк-дубликатов, если спецификация DISTINCT задана.

Замечание: в диалекте SQL СУБД Oracle имеется расширенный вариант оператора выборки, результатом которого не обязательно является таблица из одной строки. Такое расширение не поддерживается ни в SQL/89, ни в SQL/92.

ORB как часть системы.

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

ORB, основанный на библиотеках.

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

ORB, включаемый в клиентское и серверное приложение.

Если имеется подходящий механизм коммуникаций, то возможна реализация ORB-а в виде набора подпрограмм как со стороны клиента, так и со стороны реализации объекта. Вызовы методов могут транслироваться в работу со средствами взаимодействия процессов (Inter Process Communication - IPC).

ORB, выполненный в виде сервера.

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

Организация проекта

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

Основные компоненты СУБД Cache'

На рис. 1. представлена архитектура Cache'.

Рис.1. Архитектура системы Cache'.

Основными компонентами СУБД Cache' являются следующие:

TMDM. Многомерное ядро системы, ориентирование на работу с транзакциями. Сервер Cache' Objects. Представление многомерных структур данных ядра системы в виде объектов, инкапсулирующих как данные так и методы их обработки. Сервер Cache' SQL. Представление многомерных структур данных в виде реляционных таблиц. Сервер прямого доступа. Предоставление прямого доступа к многомерным структурам данных ядра системы.

Рассмотрим подробнее назначение и функциональные возможности основных компонентов системы.

Основные концепции и подходы при

Автор: Евгений Игумнов, Геокад Плюс (Новосибирск)

Домашняя страничка:

Редактор:

Опубликовано: 31.05.2001

Версия текста: 1.0

Основные понятия диаграмм классов UML

Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке OCL (Object Constraints Language), который является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию. Мы затронем эту тему ниже немного более подробно.

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника. У каждого класса должно иметься имя (текстовая строка), уникально отличающее его ото всех других классов. При формировании имен классов в UML допускается использование произвольной комбинации букв, цифр и даже знаков препинания. Однако на практике рекомендуется использовать в качестве имен классов короткие и осмысленные прилагательные и существительные, каждое из которых начинается с заглавной буквы. Примеры описания классов показаны на рисунке:

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

Класс Человек с указанными именами атрибутов

Имена атрибутов представляются в разделе класса, расположенном под именем класса. Хотя UML не накладывает ограничений на способы формирования имен атрибутов (имя атрибута может быть произвольной текстовой строкой), на практике рекомендуется использовать короткие прилагательные и существительные, смысл которых соответствует смыслу соответствующего свойства класса.
Первое слово в имени атрибута рекомендуется писать с прописной буквы, а все остальные слова – с заглавной буквы.

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

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

Для класса Человек мы определили три операции. Операция “выдатьВозраст” использует значение атрибута “датаРождения” и значение текущей даты. Операция “сохранитьТекущийДоход” позволяет зафиксировать в состоянии объекта сумму и дату поступления дохода данного человека. Операция “выдатьОбщийДоход” выдает суммарный доход данного человека за указанное время. Заметим, что состояние объекта меняется при выполнении только второй операции. Результаты первой и третьей операций формируется на основе текущего состояния объекта.

В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоцирование (association). Для проектирования реляционных БД наиболее важны вторая и третья категории связей. Поэтому по поводу связей-зависимостей мы будет очень кратки.

Связи-зависимости

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


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



Зависимость показывается прерывистой линией со стрелкой, направленной к классу, от которого имеется зависимость. Легко видеть, что связи-зависимости существенны для объектно-ориентированных систем (в том числе и для ООБД). При проектировании реляционных БД непонятно, что делать с зависимостями (как воспользоваться этой информацией в реляционной БД?).

Связи-обобщения

Связью-обобщением называется связь между общей сущностью, называемой суперклассом, или родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями “is a”, имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.

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



Иерархия одиночного наследования классов

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





Пример множественного наследования классов

На этой диаграмме классы Студент и Преподаватель порождены из одного суперкласса ЧеловекИзУниверситета. Но как это часто случается, многие студенты уже в студенческие годы начинают преподавать, так что могут существовать такие два объекта классов Студент и Преподаватель, которым соответствует один объект класса ЧеловекИзУниверситета. Итак, среди объектов класса Студент могут быть преподаватели, а некоторые преподаватели могут быть студентами. Мы можем определить класс СтудентПреподаватель путем множественного наследования от суперклассов Студент и Преподаватель. Объект класса СтудентПреподаватель обладает всеми свойствами и операциями классов Студент и Преподаватель, и может быть использован везде, где могут использоваться объекты этих классов. Так что полиморфизм по включению продолжает работать.

Но множественное наследование, помимо того, что не слишком часто требуется на практике, порождает ряд проблем, из которых одной из наиболее известных является проблема именования атрибутов и операций в подклассе, полученном путем множественного наследования. Например, предположим, что при образовании подклассов Студент и Преподаватель в них обоих был создан атрибут с именем “номерКомнаты”. Очень вероятно, что для объектов класса Студент значениями этого атрибута будут номера комнат в студенческом общежитии, а для объектов класса Преподаватель – номера служебных кабинетов. Как быть с объектами класса СтудентПреподаватель, для которых существенны оба одноименных атрибута? На практике применяется одно из следующих решений:

запретить образование подкласса СтудентПреподаватель, пока в одном из суперклассов не будет произведено переименование атрибута “номерКомнаты”; наследовать это свойство только от одного из суперклассов, так что, например, значением атрибута “номерКомнаты” у объектов класса СтудентПреподаватель всегда будут номера служебных кабинетов; унаследовать в подклассе оба свойства, но автоматически переименовать оба атрибута, чтобы прояснить их смысл; назвать их, например, “номерКомнатыСтудента” и “номерКомнатыПреподавателя”.



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

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

Связи-ассоциации

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

С понятием ассоциации связаны четыре важных дополнительных понятия: имя, роль, кратность и агрегация. Во-первых, ассоциации может быть присвоено имя, характеризующее природу связи. Смысл имени уточняется черным треугольником, располагаемым над линией связи справа или слева от имени ассоциации. Этот треугольник указывает направление, в котором должно читаться имя связи. Пример именованной ассоциации показан на рисунке. Треугольник означает, что именованная ассоциация должна читаться как “Студент учится в Университете”.



Пример именованной ассоциации

Другим способом именования ассоциации является указание роли каждого класса, участвующего в этой ассоциации.


Роль класса задается именем, помещаемым под линией ассоциации ближе к данному классу. На следующем рисунке показаны две ассоциации между классами Человек и Университет, в которых эти классы играют разные роли. Как мы видим, объекты класса Человек могут выступать в роли РАБОТНИКОВ при участии в ассоциации, в которой объекты класса Университет играют роль НАНИМАТЕЛЯ. В другой ассоциации объекты класса Человек играют роль СТУДЕНТА, а объекты класса УНИВЕРСИТЕТ – в роли ОБУЧАЮЩЕГО.



Две ассоциации с разными ролями классов

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

Кратностью (multiplicity) роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации (в UML экземпляр ассоциации называется соединением – link). Наиболее распространенным способом задания кратности роли ассоциации является указание конкретного числа или диапазона. Например, указание “1” говорит о том, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, причем в каждом экземпляре ассоциации может участвовать ровно один объект класса с данной ролью. Указание диапазона “0..1” говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной ассоциации, но в каждом экземпляре ассоциации может участвовать только один объект. Аналогично, указание диапазона “1..*” говорит, что все объекты класса с данной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должен участвовать хотя бы один объект (верхняя граница не задана). Толкование диапазона “0..*” является очевидным расширением случая “0..1”.



В более сложных ( но крайне редко встречающихся на практике) случаях определения кратности можно использовать списки диапазонов. Например, список “2, 4..6, 8..*” говорит, что все объекты класса с указанной ролью должны участвовать в некотором экземпляре данной ассоциации, и в каждом экземпляре ассоциации должны участвовать два, от четырех до шести или более восьми объектов класса с данной ролью.



Ассоциации с указанными кратностями ролей

На диаграмме классов с рисунка показано, что произвольное (может быть, нулевое) число людей являются работниками произвольного числа университетов. Каждый университет обучает произвольное (может быть, нулевое) число студентов, но каждый студент может быть студентом только одного университета.

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



Пример агрегатной ассоциации

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



Бывают случаи, когда связь “части” и “целого” настолько сильна, что уничтожение “целого” приводит к уничтожению всех его “частей”. Агрегатные ассоциации, обладающие таким свойством, называются композитными, или просто композициями. При наличии композиции объект-часть может быть частью только одного объекта-целого (композита). При обычной агрегатной ассоциации “часть” может одновременно принадлежать нескольким “целым”. Графически композиция изображается в виде простой ассоциации, дополненной закрашенным ромбом со стороны “целого”. Пример композитной агрегатной ассоциации показан на рисунке:



Пример композитной агрегатной ассоциации

Любой факультет является частью одного университета, и ликвидация университета приводит к ликвидации всех существующих в нем факультетов (хотя во время существования университета отдельные факультеты могут ликвидироваться и создаваться).

Заметим, что в контексте проектирования реляционных БД агрегатные и в особенности композитные ассоциации влияют только на способ поддержки ссылочной целостности. В частности, композитная связь является явным указанием того, что ссылочная целостность между “целым” и “частями” должна поддерживаться путем каскадного удаления частей при удалении целого. При наличии простой ассоциации между двумя классами предполагается возможность навигации между объектами, входящими в один экземпляр ассоциации. Если известен конкретный объект-студент, то должна обеспечиваться возможность узнать соответствующий объект-университет. Если известен конкретный объект-университет, то должна обеспечиваться возможность узнать все соответствующие объекты-студенты. Другими словами, если не оговорено противное, то навигация по ассоциации может проводиться в обоих направлениях. Однако бывают случаи, в которых желательно ограничить направление навигации для некоторых ассоциаций. В этом случае на линии ассоциации ставится стрелка, указывающая направление навигации. Возможный пример показан на рисунке:



Ассоциация с указанным направлением навигации



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

Ограничения и язык OCL

Как уже отмечалось, в диаграммах классов могут указываться ограничения целостности, которые должны поддерживаться в проектируемой БД. Имеются два способа определения ограничений: на естественном языке и на языке OCL. На рисунке показана простая диаграмма классов Студент и Университет с ограничением, выраженном на естественном языке.



Ограничение, выраженное на естественном языке

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

Более точный и лаконичный способ формулировки ограничений обеспечивает язык OCL (Object Constraint Language). Приведем его сжатое описание.

К заимствованным из UML концепциям относятся, в первую очередь, следующие:

Класс, операция, атрибут Объект (экземпляр класса) Ассоциация Тип данных (включая набор предопределенных типов Boolean, Integer, Real и String) Значение (экземпляр типа данных).

Существенными для понимания языка OCL являются определенные в UML отличия между объектом некоторого класса и значением некоторого типа, обычные для объектных моделей данных.

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



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

В дополнение к скалярным типам данных, заимствованным из UML, в OCL предопределены структурные типы, которые являются разновидностями коллекций (collection):

Математическое множество (set), т.е. неупорядоченная коллекция, не содержащая одинаковых элементов; Мультимножество (bag), т.е. коллекция, которая может содержать повторяющиеся элементы; Последовательность (sequence), т.е. упорядоченная коллекция, которая может содержать повторяющиеся элементы.

В OCL элементами каждого из трех типов коллекций могут быть либо объекты, либо значения.

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

Под инвариантом класса в OCL понимается условие, которому должны удовлетворять все объекты данного класса. Более точно, инвариант класса - это логическое выражение, вычисление которого должно давать true при создании каждого объекта данного класса и сохранять это значение в течение всего времени существования объекта. При определении инварианта требуется указать имя класса и выражение, определяющее инвариант указанного класса. Синтаксически это выглядит следующим образом:

context <class_name> inv: <OCL выражение>

где <class-name> является именем класса, для которого определяется инвариант, inv – ключевое слово, говорящее о том, что определяется именно инвариант, а не другой вид ограничений, и context – ключевое слово, которое говорит о том, что контекстом следующего после двоеточия OCL-выражения являются объекты класса <class-name>, то есть OCL-выражение должно принимать истинное значение для всех объектов этого класса.



Отметим, что OCL является типизированным языком, поэтому у каждого выражения имеется некоторый тип. Естественно, что OCL-выражение в инварианте класса должно быть логического типа.

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

Операции над значениями предопределенных типов данных

Полагая очевидной семантику предопределенных скалярных типов данных и операций над ними, ограничимся лишь их перечислением. OCL поддерживает следующие заимствованные из определения UML скалярные типы данных: Boolean, Integer, Real и String.

Операции над объектами

Над объектами в OCL определены три операции: получение значения атрибута, переход по соединению, вызов операции класса (последняя операция несущественна для целей проектирования реляционных БД). Для записи этих трех операций используется “точечная нотация”.

Например, результатом выражения вида:

<объект>.<имя атрибута>

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

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

<объект>.<имя противоположенной по отношению к объекту роли ассоциации>

Операции над множествами, мультимножествами и последовательностями

В OCL поддерживается богатый набор операций над значениями коллекционных типов данных.


Обсудим только те из них, которые являются наиболее уместными в контексте данной статьи. Синтаксически операции над коллекциями записываются в нотации, аналогичной точечной, но вместо точки используется “®”. Таким образом, общий синтаксис применения операции к коллекции следующий:

® ( )

Операция select

В OCL определены три одноименных операции select, которые воздействуют на заданные множество, мультимножество или последовательность на основе заданного логического выражения над элементами коллекции. Результатом каждой операции является новое множество, мультимножество или последовательность соответственно из тех элементов входной коллекции, для которых результатом вычисления логического выражения является true.

Операция collect

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

Операции exists, forAll, size

В OCL определены три одноименных операции exist над множеством, мультимножеством и последовательностью, дополнительным параметром которых является логическое выражение. Результатом каждой операции является true, если и только если хотя бы для одного элемента входной коллекции значением логического выражения является true.


Операции forAll отличается от операций exist тем, что результатом каждой из них является true, если и только если для всех элементов входной коллекции результатом вычисления логического выражения является true. Операция size применяется к коллекции и выдает число элементов, которые в ней содержатся.

Операции union, intersect, symmetricDifference

Параметрами двуместных операций union, intersect, symmetricDifference являются две коллекции, причем в OCL операции определены почти для всех возможных комбинаций типов коллекции. Не будем рассматривать все определения этих операций и кратко упомянем только две из них. Результатом операции union, определенной над множеством и мультимножеством, является мультимножество, то есть из результата объединения таких двух коллекций дубликаты не исключаются. Результатом же операции union, определенной над двумя множествами, является множество, т.е. в этом случае возможные дубликаты должны быть исключены.

В заключение обзора языка OCL приведем примеры четырех инвариантов, выраженных на этом языке. Будем основываться на диаграмме классов, показанной на рисунке:



Диаграмма классов, используемая для примеров на языке OCL

Первый пример:

context Сотрудник inv: self.возраст >18 and self.возраст < 100

Этот инвариант указывает, что возраст сотрудников должен быть больше 18 и меньше 100, что выражается в виде ограничений на значения атрибута возраст, определенного в классе Сотрудник.

Второй пример:

Выразим на OCL то ограничение, что отделах с номерами больше 5 должны работать сотрудники старше 30 лет.

context Отдел inv: self.номер Ј 5 or self.сотрудник ® select (возраст Ј 30) ® size () = 0

Тот же инвариант можно сформулировать в контексте класса Сотрудник: context Сотрудник inv: self.возраст Ј 30 or self.отдел.номер > 5

Третий пример:

Третий инвариант определяет то ограничение, что у каждого отдела должен иметься менеджер ( между классами Сотрудник и Отдел имеется ассоциация, в которой роль конец класса Сотрудник имеет имя сотрудник), и что любой отдел должен быть основан не раньше основания соответствующей компании (между классами Отдел и Компания имеется ассоциация, в которой роль класса Компания имеет имя компания):



context Отдел inv: self.сотрудники ® exists (должность = “manager”) and self.компания.годОснования Ј self.годОснования

Здесь должность – атрибут класса Сотрудники, а атрибуты с именем годОснования имеются и у класса Отдел, и у класса Компания.

Обратите внимание на выражения self.отдел.номер во втором примере и self.компания.годОснования. Имя отдел является именем роли в ассоциации классов Сотрудник и Отдел, и компания – имя роли в ассоциации классов Отдел и Компания. Но в данном случае в OCL допускается точечная нотация, поскольку кратность обеих этих ролей равна единице (каждый сотрудник работает в одном и только одном отделе, и каждый отдел принадлежит одной и только одной компании), и результатом перехода по соединению в этом случае будет не коллекция, а в точности один объект.

Четвертый пример:

Четвертый инвариант ограничивает максимально возможное количество сотрудников компании числом 1000:

context Компания inv: self.отделы ® collect (сотрудники) ® size ( ) < 1000

Понятны плюсы и минусы использования языка OCL при проектировании реляционных БД. Язык позволяет формально и однозначно (без двусмысленностей, свойственных естественным языкам) определять ограничения целостности БД в терминах ее концептуальной схемы. Скорее всего, наличие проектной документации будет полезным для сопровождения БД даже если придется преобразовывать инварианты OCL в ограничения целостности SQL вручную.

К отрицательным сторонам использования OCL относится, прежде всего, сложность языка и неочевидность некоторых его конструкций. Кроме того, строгость синтаксиса и линейная форма языка в некотором роде противоречат наглядности и интуитивной ясности структурной части UML. Да, в инвариантах OCL используются те же понятия и имена, что и в соответствующей диаграмме классов, но используются совсем в другой манере. И последнее. Я не могу доказать или опровергнуть ни то, что на языке OCL можно выразить любое ограничение целостности, которое можно определить средствами SQL, ни то, что на языке OCL нельзя выразить такой инвариант, для которого окажется невозможным сформулировать эквивалентное ограничение целостности на языке SQL.


Мне неизвестны работы, в которых бы сравнивалась выразительная мощность этих языков в связи с ограничениями целостности реляционных БД.

Получение схемы реляционной базы данных из диаграмм классов

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

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

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

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

Рекомендация 4. В спецификации UML говорится, что, определяя однонаправленные связи, вы можете способствовать эффективности доступа к некоторым объектам. Для технологии реляционных баз данных поддержка такого объявления вызовет дополнительные накладные расходы и тем самым снизит эффективность.

Рекомендация 5. Не злоупотребляйте возможностями OCL.

Диаграммы классов UML – это хороший и мощный инструмент для создания концептуальных схем баз данных, но, как известно, все хорошо в меру.

Основные понятия модели

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

2. Пользователь. Права доступа к ресурсам системы определяются для каждого пользователя. Для каждого проекта по умолчанию создается один пользователь с ролью "Администратор", который обладает всеми правами и один с ролью "Пользователь", которому запрещено выполнять операции, связанные с администрированием.

3. Сеанс. Сеанс - это последовательность всех действий пользователя, начиная с открытия какого-либо проекта до его закрытия. В рамках одного сеанса пользователь может работать только с одним проектом. В каждый момент времени пользователь может работать только в одном сеансе.

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

5. Предопределенные объекты. Будем предполагать, что в любом проекте заранее определено некоторое множество объектов, которые соответствуют числам, строкам и другим распространенным типам данных. В то время как вновь создаваемые объекты обязательно стандартным (независимым от пользователя) образом получают уникальную идентификацию, для предопределенных объектов в качестве их идентификатора используется соответствующая последовательность символов.

6. Параметр (Атрибут). Каждому объекту может быть приписан произвольный набор параметров, описывающий представления пользователей о состоянии и поведении некоторого объекта реального мира. Параметры это то, что можно измерять, наблюдать и изменять в процессе исследований Набор параметров определяется теми задачами, для которых создается проект. Все параметры, использующиеся в проекте, должны быть предварительно объявлены. Каждый объект может иметь, вообще говоря, любой определенный в проекте параметр. В модели предусмотрено некоторое количество предопределенных параметров, которые определены для всех объектов. В качестве примера можно привести параметр "Время Создания", который автоматически фиксируется при проведении любого наблюдения (см. ниже раздел "Операции").

7. Значение. При проведении наблюдения, с рядом параметров объекта, над которым производится наблюдение, связываются значения. Значение является либо идентификатором объекта, либо значением некоторого типа (идентификатором предопределенного объекта). В любой момент времени значением параметра объекта считаются последнее значение либо запрос, присвоенные параметру ранее этого момента. Совокупность значений параметра для данного объекта может представлять собой довольно сложную структуру. Значение параметра может быть неопределенным - все параметры, не определенные для данного объекта имеют зарезервированное значение ^ (или null). Введем еще одно выделенное значение - Т. Если параметр объекта имеет такое значение, то также считается, что значение параметра не определено и, кроме того, значение параметра больше нельзя изменять. Параметр, имеющий значение Т становится "запрещенным" для данного объекта во всех последующих состояниях.

8. Изображения. Каждое значение может быть представлено для пользователя (визуализировано). Это может быть сделано многими способами, - например с помощью форматных преобразований. Рост в метрах может быть записан как 1.5 м, как +1.50 м, как 0.15е+1 м и т.д.



9. Наблюдение (Измерение). В реальном мире мы можем измерять или наблюдать какие-либо характеристики объектов. Для каждого наблюдения определено множество объектов, над которыми оно производится. В качестве значений параметров в контексте какого-либо наблюдения выступают идентификаторы объектов. В этом смысле наблюдение - это просто отношение между объектами, При этом любая связь "Параметр - Объект - Значение" имеет смысл только в контексте какого-либо наблюдения над объектом. Для того чтобы можно было обращаться к результатам наблюдения, это отношение также получает при создании идентификатор, как и любой другой объект. (В некотором смысле понятие объекта - это вырожденное наблюдение, т.е. мы наблюдаем различимость объектов. С другой стороны, наблюдение само может выступать в качестве объекта. Например, мы можем оценивать корректность того или иного наблюдения, делать выводы из значений параметров и т.п., т.е. приписывать наблюдениям какие-либо свойства.) Таким образом, наблюдение позволяет присвоить одному или нескольким параметрам некоторого объекта какие-либо значения (рис.1). Осмысленность параметров и значений для данного объекта остается целиком на совести наблюдателя.

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



Рис. 1.

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



Рис.2.

Рассмотрим теперь перечисленные понятия более подробно.

Особенности и цели протокола.

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

Особенности ПО "двойного назначения"

Вследствие возможности двойного применения, Lotus Domino кажется простым продуктом, готовым к использованию по прямому назначению после простой инсталляции ПО (то есть, что называется Out of the Box). Это довольно распространенное заблуждение. В отличие от ПО первой группы, которое действительно можно использовать после инсталляции для выполнения работы, ПО третьей группы намного сложнее. Даже однопользовательский персональный режим зачастую требует определенных настроек. Что уж говорить о сетевом многопользовательском варианте - по сложности развертывания, конфигурирования и управления Lotus Domino лишь немного уступает большинству представителей второй группы ПО.

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

Да, Lotus Domino дешевле. Но от электронной почты или системы документооборота также зачастую непосредственно зависит успех коммерческой деятельности компании. Да, Lotus Notes имеет "интуитивно понятный интерфейс". Но ведь обучать пользователя надо не тому, на какие кнопки нажимать для выполнения тех или иных действий, а тому, как работать в новой для него информационной среде, обеспечивающей принятую или измененную функциональность.

Таким образом, первый вывод, который можно сделать из вышесказанного, это то, что ПО третьей группы объединяет достоинства (и недостатки) предыдущих в обозначенном делении групп, предоставляя при этом некоторые дополнительные возможности, преимущественно за счет экономии материальных средств. Важно помнить, что эта экономия не так значительна, как может показаться на первый взгляд. Lotus Domino - это далеко не "сетевая СУБД по цене офисного пакета".

---

---