Объектно-ориентированные СУБД

 

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

 

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

 

3.2.3. Проблемы оптимизации  запросов

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Заключение

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

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

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

В настоящий момент ощущается  настоятельная потребность в  интеграции ООСУБД с существующими инструментальными средствами. Разработчики уже сегодня могли бы продуктивно использовать версии Visual Basic, Power Builder, Forte или

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

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

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

 

Глоссарий

№ п/п	Понятие	Определение
1	Объектно-ориентированная база данных	база данных, в которой данные моделируются в виде объектов,  их атрибутов, методов и классов.
2	Объект	обладающий именем набор данных (полей), физически находящихся в памяти компьютера, и методов, имеющих доступ к ним. Имя используется для доступа к полям и методам, его составляющим. В предельных случаях может не содержать полей или методов, а также не иметь имени.
3	Класс	содержит описание данных и операций над ними. В нем дается обобщенное описание некоторого набора родственных, реально  существующих объектов. Объект – его  конкретный экземпляр.
4	Метод	Свойство  объекта.
5	Инкапсуляция (encapsulation)	это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования. В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый "чёрный ящик". Когда коды и данные объединяются таким способом, создаётся объект (object).
6	Наследование (Inheritance)	Механизм, благодаря которому определения класса распространяется на классы, лежащие ниже его в иерархии обобщения классов. Это позволяет многократно изменять определения, внося по мере необходимости изменения, связанные со специализацией.
7	Перманентность данных	Возможность сохранения
8	DBMS (Database Management System)	совокупность программных  и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных, СУБД
9	Полиморфизм (Polymorphism)	Способность объектов различных  классов и самих классов удовлетворять одним и тем же протоколам или отдельным сообщениям, выполняя при этом различные действия, предписываемые их собственными методами.
10	Транзакция (Transaction)	обработка запроса ¨Выполнение  элементарной целостной операции над данными, в течение которой база данных находится в неустойчивом состоянии.

 

Список использованных источников

 

1	О.И.Авен Я.А.Коган “Управление  вычислительным процессом” М. Энергия 1978
2	А.М.Андреев Д.В.Березкин, Ю.А.Кантонистов «Среда и хранилище: ООБД»  Мир ПК №4 1998 (стр 74-81)
3	М. Аткинсон, Ф. Бансилон и др. «Манифест систем объектно-ориентированных баз данных», СУБД № 4 1995
4	В.Бобров "Объектно-ориентированные  базы данных, мультимедийные типы данных и их обработка" Read.Me №4, 1996
5	Н.П.Брусенцов, В.Б.Захаров  и др. «Развиваемый адаптивный язык РАЯ диалоговой системы программирования ДССП» Москва МГУ 1987
6	Бурцев А.А "Параллельное программирование. Учебное пособие по курсу "Операционные системы" - Обнинск : ИАТЭ, 1994 - 90 с.
7	Бурцев А.А. «Сопрограммный механизм в ДССП как основа для построения мониторов параллельных процессов»
8	Г.Буч «Объектно-ориентированное  проектирование (с примерами применения)»  М.Конкорд 1992
9	К.Дж.Дейт «Введение в системы  баз данных» 1998 Киев Диалектика
10	Мутушев Д.М. Филиппов В.И. "Объектно-ориентированные базы данных" Программирование. - М., 1995 №6 стр. 59-76
11	В.Ремеев «FoxPro. Версия 2.5 для MS-DOS. Описание команд и функций» М. «Мистраль» 1994
12	СУБД № 2 1995 «Системы баз данных третьего поколения: Манифест»
13	СУБД № 1 1996 «Стандарт систем управления объектными базами данных ODMG-93: краткий обзор и оценка состояния» Л.А.Калиниченко
14	СУБД № 1 1996 «ТРЕТИЙ МАНИФЕСТ»  Х.Дарвин, К.Дэйт
15	СУБД № 5-6 1996 “Введение в СУБД часть 9” стр. 136-153 С.Д. Кузнецов
Документы в Internet (http://www.citforum.ru):
16	Л.Калиниченко “Архитектуры и технологии разработки интероперабельных систем”, Институт проблем информатики РАН
17	В. Индриков, АО ВЕСТЬ “Объектно-ориентированный  подход и современные мониторы транзакций”
18	С.Д. Кузнецов "Основы современных  баз данных"
19	С. Кузнецов “Безопасность и целостность, или Худший враг себе - это ты сам”

Приложения

А