Лекция 22. Обектно-ориентированные СУБД

Лекция 22. Обектно-ориентированные СУБД

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

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

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

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

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

Тематика ООБД очень широка, объем этой лекции не позволяет рассмотреть все вопросы. Тем не менее, мы постараемся в систематической манере проанализировать наиболее важные аспекты ООБД.

22.1. Связь обектно-ориентированных СУБД с общими понятиями обектно-ориентированного подхода

• 
  обекта и идентификатора обекта;
  
• 
  атрибутов и методов;
  
• 
  классов;
  
• 
  йерархии и наследования классов.
  

Всеки обект имеет состояние и поведение. Состояние обекта - набор значений его атрибутов. Поведение обекта - набор методов (програмный код), оперирующих над состоянием обекта. Значение атрибута обекта - это тоже някоиый обект или множество обектов. Состояние и поведение обекта инкапсулированы в обекте; взаимодействие обектов се извършва на основе передачи сообщений и изпълнении съответствующих методов.

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

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

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

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

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

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

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

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

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

22.2. Обектно-ориентированные модели от данни

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

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

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

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

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

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

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

За иллюстрации текущего положения дел мы кратко рассмотрим особенности конкретной модели от данни, применяемой в обектно-ориентированной СУБД O2 (это, конечно, тоже не модель от данни в классическом смысле).

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

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

Обекти и значения могут быть именованными. С именованием обекта или значения свързана долговременность его хранения (persistency): любые именованные обекти или значения долговременны; любые обект или значение, входящие как часть в другой именованный обект или значение, долговременны.

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

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

В модели O2 поддържася множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Възможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Обект подкласса является обектом каждого суперкласса, на основе которого порожден данный подкласс.

Поддържася предопределенный класс "Оbject", являющийся корнем решетки классов; любой другой класс является неявным наследником класса "Object" и наследует предопределенные методы ("is_same", "is_value_equal" и т.н.).

Специфической особенностью модели O2 является възможность объявления дополнительных "исключительных" атрибутов и методов за именованных обектов. Это означает, что конкретный именованный обект-представитель класса может обладать типом, являющимся подтипом типа класса. Конечно, с такими атрибутами не работают стандартные методы класса, но специально за именованного обекта могут быть определены дополнительные (или переопределены стандартные) методы, за които дополнительные атрибуты уже достъпны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному обекту, а к имени, за которым в разные моменты времени могут стоять вообще говоря разные обекти. За реализации исключительных атрибутов и методов требуется развитие техники позднего связывания.

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

22.3. Езики програмирования обектно-ориентированных баз от данни

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

22.3.1. Потеря съответствия между езиками програмирования и езиками заявките в релационных СУБД

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

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

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

22.3.2. Езики програмирования ООБД как обектно-ориентированные езики с поддержкой стабильных (persistent) обектов

К настоящему моменту нам неизвестен какой-либо език програмирования ООБД, который был бы спроектирован целиком заново, начиная с нуля. Естественным подходом к построению такого езика было използование (с необходимыми расширениями) някоиого съществуващего обектно-ориентированного езика. Начало расцвета направления ООБД совпало с пиком популярности езика Smalltalk-80. Этот език оказал большое влияние на разработку первых систем ООБД, и, в частности, използовался в качестве езика програмирования. Во многом опирается на Smalltalk и известная коммерчески достъпная система GemStone.

Трудности с эффективной практической реализацией езика Smalltalk побудили разработчиков систем ООБД к поиску альтернативных базовых езиков. Известная близость обектно-ориентированного и функционалного подходов к програмированию позволяет достатъчно успешно опираться на Функционални езики програмирования. В частности, език Лисп (Common Lisp) является основой проекта ORION. В этом проекте Лисп является и инструментальным езиком, и базой обектно-ориентированного езика програмирования в среде ORION.

Потребности в еще более эффективной реализации заставляют използовать в качестве основы обектно-ориентированного езика езики более низкого уровня. Например, в системе VBASE наряду со специально разработанным езиком TDL, предназначенным за определения типов, използуется обектно-ориентированное расширение езика Си - COP (C Object Processor). В уже упоминавшемся проекте O2 наряду с функционалным обектно-ориентированным езиком програмирования използуются два обектно-ориентированных расширения езиков Бейсик и Си. При этом, насколько можно судить по публикациям, наибольшее разпространение среди потребителей этой системы (она уже коммерчески достъпна) получил език CO2, являющийся расширением езика Си. Възможно это свързано лишь с широкой (и все более возрастающей) популярностью езика Си (и его обектно-ориентированного потомка Си++), ставшего поистине девизом "настоящих програмистов". Може да бъде причины более глубинны (например, езики более высокого уровня слишком ограничительны за програмистов-профессионалов; недаром большинство современных реализаций езиков более высокого уровня выполняются именно на езике Си). Тем не менее, современная ситуация именно такова, и мы считаем полезным привести краткое описание основных особенностей езика CO2.

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

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

Имя любого обекта трактуется как указатель на значение этого обекта; разименование се извършва с помощью обикновеного оператора Си '*'. Достъп к значению обекта възможен только из метода его класса, ако только при перечислении методов оператор '*' не объявлен явно публичным.

Поддържася операция порождения нового обекта указанного класса. В отличие от езика Си++ в CO2 невъзможно совместить създавание нового обекта с его инициализаций (понятие метода-конструктора начального значения обекта в CO2 не поддържася). За инициализации необходимо либо явно обратиться к съответствующему методу класса с указанием вновь създаванного обекта (поддържася съответствующий механизм "передачи сообщений", означающий на самом деле извикване функции), либо воспользоваться оператором '*' и явно присвоить новое значение, ако '*' - публичный оператор за данного класса.

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

Основой манипулирания обектами, хранимыми в БД, является расширенное по сравнению с езиком Си средство итерации. Итератор применим к значениям-множествам или спискам. Фактически он означает последовательное применение оператора-тела цикла ко всем елементам множества или списка. Ако мы вспомним, что долговременно хранимому классу обектов неявно съответствуют одноименное значение-множество с елементами-обектами данного класса, то становится понятно, что итератор езика CO2 обеспечивает явную навигацию в классах обектов. Единственное, что остается от привычных потребителям СУБД езиков заявките, - это ограниченная възможность указания характеристик требуемых в цикле обектов (это делается путем използования оператора разименования и явного указания условий на атрибуты; конечно, за этого нужно, чтобы оператор '*' был объявлен публичным в данном классе).

Разработчики O2 подчеркивают, что они умышленно сделали CO2 более бедным по възможностям, чем, например, език Си++, потому что многое по части управления обектами берет на себя общий менеджер обектов системы, явно вызываемый из рабочей програмы.

22.4. Езики заявките обектно-ориентированных баз от данни

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

22.4.1. Явная навигация как следствие преодоления потери съответствия

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

22.4.2. Ненавигационные езики заявките

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

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

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

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

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

Език заявките системы Iris находится в значительной степени под влиянием релационной парадигмы. Даже название этого езика OSQL отражает его тесную связь с релационным езиком SQL. По сути дела, OSQL - это релационный език, рассчитанный на работу с ненормализованными отношениями. Естественно, при таком подходе в OSQL нарушается инкапсуляция обектов.

На наш взгляд, особый интерес представляет декларативный език заявките системы O2 RELOOP. В общих словах, это декларативный език заявките с SQL-ори-ентированным синтаксисом, основанный на специально разработанной за модели O2 алгебре обектов и значений. (Кстати, это не единственная работа в направлении построения алгебры за обектно-ориентированных моделей от данни.) Особенно впечатляющим качеством езика RELOOP является естественность его построения в общем контексте модели O2. Запрос задается всегда на значении-множестве или списке. Ако мы вспомним, что долговременному классу в O2 съответствует одноименное значение-множество, то тем самым можно определить запрос на любом хранимом классе. Резултатом запроса может являться обект, значение-множество или значение-список. При этом елементами значений-множеств могут являться обекти (простая выборка), либо значения-кортежи с елементами-обектами разных классов (например). В совокупности эти особенности езика позволяват формулировать заявки над несколькими классами (специфическое соединение, порождающее не новые обекти, а кортежи из съществуващих обектов), а также употреблять вложенные подзаявки.

22.4.3. Проблемы оптимизации заявките

Как обикновено, основной целью оптимизации запроса в системе ООБД является създавание оптимального плана изпълнения запроса с използованием примитивов достъпа к внешней памети ООБД.

Оптимизация заявките хорошо изследваа и разработана в контексте релационных БД. Известны методы синтактической и семантической оптимизации на уровне непроцедурного представления запроса, алгоритмы изпълнения елементарных релационных операций, методы оценок стойности планов заявките.

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

На самом деле похожая ситуация съществует и в РСУБД при оптимизации запроса над представлением БД. В этом случае условия также формулируются в терминах внешних атрибутов (атрибутов представления), и в целях оптимизации запроса эти условия должны быть преобразованы в условия, определенные на атрибутах хранимых отношений. Хорошо известным методом такой "предоптимизации" является подстановка представлений, которая часто (хотя и не всегда в случае използования езика SQL) обеспечивает требуемые преобразования. Альтернативным способом изпълнения запроса над представлением (иногда единственным възможным) является материализация представления.

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

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

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

Стъпка А: Преобразовать логическую формулу условия к конъюнктивной нормалной форме (КНФ). Мы не останавливаемся на способе выбора конкретной КНФ, но естественно, должна быть выбрана "хорошая" КНФ (например, съдържащая максимальное число атомарных конъюнктов).

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

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

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

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

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

22.5. Примеры обектно-ориентированных СУБД

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

Рассмотрим особенности организации двух из них - ORION и O2.

22.5.1. Проект ORION

Проект ORION осъществлялся с 1985 по 1989 г. фирмой MCC под ръководством известного еще по работам в проекте System R Вона Кима. Под названием ORION на самом деле скрывается семейство трех СУБД: ORION-1 - однопотребительская система; ORION-1SX, предназначенная за използования в качестве сървъра в локальной мрежа рабочих станций; ORION-2 - напълно разпределеная обектно-ориентированная СУБД. Реализация всех систем производилась с използованием езика Common Lisp на рабочих станциях (и их локалних сетях) Symbolics 3600 с ОС Genera 7.0 и SUN-3 в среде ОС UNIX.

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

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

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

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

22.5.2. Проект O2

Проект O2 выполнялся французской компанией Altair, образованной специально за целей проектирования и реализации обектно-ориентированной СУБД. Начало проекта датируется сентябрем 1986 г., и он был рассчитан на пять лет: три года на прототипирование и два года на разработку промышленного образца. После успешного завершения проекта за сопровождения системы и ее дальнейшего развития была организирана новая чисто коммерческая компания O2.

Прототип системы функционировал в режиме клиент/сървър в локальной мрежа рабочих станций SUN c съответствующим разделением функций между сървъром и клиентами.

Основными компонентами системы (не считая развитого набора интерфейсных средств) являются интерпретатор заявките и подсистемы управления схемой, обектами и дисками. Управление дисками, т.е. поддержание базовой среды постоянного хранения обеспечивает система WiSS, которую разработчики O2 перенако в окружение ОС UNIX.

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

• 
  управление сложными обектами, включая създавание и унищожение обектов, выборку обектов по именам, поддержку предопределенных методов, поддержку обектов со внутренней структурой-множеством, списком и кортежем;
  
• 
  управление передачей сообщений между обектами;
  
• 
  управление транзакциями;
  
• 
  управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной мрежа Ethernet);
  
• 
  отслеживание долговременно хранимых обектов (напомним, что в O2 обект хранится во внешней памети до тех пор, пока достижим из какого-либо долговременно хранимого обекта);
  
• 
  управление буферами оперативной памети (аналогично ORION, представление обекта в оперативной памети отличается от его представления на диске);
  
• 
  управление кластеризацией обектов во внешней памети;
  
• 
  управление индексами.
  

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

Компонент управления схемой БД реализован над подсистемой управления обектами: в системе поддерживаются няколко невидимых за програмистов классов и в том числе классы "Class" и "Method", экземплярами които являются, съответственно, обекти, определяющие классы, и обекти, определяющие методы. (Как видно, ситуация напоминает релационные системы, в които тоже обикновено поддерживаются служебные отношения-каталоги, описывающие схему БД.) Удаление класса, который не является листом йерархии классов или използуется в другом классе или сигнатуре какого-либо метода, запрещено.

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

Каталог: tadmin -> upload -> storage
storage -> Литература на факта. Аналитизъм. Интерпретативни стратегии. Въпроси и задачи
storage -> Лекция №2 Същност на цифровите изображения Въпрос. Основни положения от теория на сигналите
storage -> Лекция 5 система за вторична радиолокация
storage -> Толерантност и етничност в медийния дискурс
storage -> Ethnicity and tolerance in media discourse revisited Desislava St. Cheshmedzhieva-Stoycheva abstract
storage -> Тест №1 Отбележете невярното твърдение за подчертаните думи
storage -> Лекции по Въведение в статистиката
storage -> Търсене на живот във вселената увод
storage -> Еп. Константинови четения – 2010 г някои аспекти на концептуализация на богатството в руски и турски език

Изтегляне 1.71 Mb.

Сподели с приятели: