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

СУБД РОЕТ - пример реализации объектно-ориентированной технологии

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

Объектно-ориентированный системный анализ

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

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

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

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

Наиболее широкое применение объектно-ориентированные базы данных нашли в таких областях, как системы автоматизированного конструирования/производства (CAD/CAM), системы автоматизированной разработки програмного обеспечения (CASE), системы управления составными документами - словом, в областях не вполне традиционных для баз данных. Особенно заметно присутствие объектноориентированных СУБД в сфере CAD/CAM [5].

Ряд американских компаний - Auto-trol Tecnology, STEP Tools, DEC и другие - используют объектно-ориентированные СУБД (например, ObjectStore производства компании Object Design) для работы со сложноконструированными данными, соответствующими стандарту STEP (Standart of Exchange of Product Model Data - Стандарт обмена данными моделей продуктов). Этот стандарт идет гораздо дальше своих предшественников, таких как IGES, поскольку, помимо информации о геометрии детали, он должен включать информацию о версиях, спецификациях материалов, допусках, о том, как отдельные детали соединяются в агрегаты.

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

Компания Enterprise Integration Tecnologies предлагает продукт MKS (Manufacturing Knowledge System - система знаний о производстве). В рамках этого продукта возможно интегрировать разработку технологических процессов, разработку оборудования, управление предприятием, проектирование производственных помещений, диагностику, мониторинг, моделирование и планирование. Основная применения продукта - заводы по производству микросхем, хотя он пригоден для управления производством во многих отраслях. В качестве СУБД системы, хранящей информацию о всех составляющих производственного процесса, используется Objectivity/DB. Вполне естественно задаться вопросом, почему приходится отказываться от зарекомендовавшей себя реляционной технологии и пробовать не вполне проверенные временем объектно-ориентированные подходы.

Ограничения реляционно технологии, или почему ООБД

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

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

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

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

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

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

2. Затруднительно должным образом смоделировать свойства данных. Чтобы естественно смоделировать структуру сложных данных, пользователь должен иметь возможность определять свои типы данных, не ограничиваясь типами данных, предоставляемыми определенной СУБД.

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

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

5. Усложненный доступ к базе данных. Интерфейс между языком программирования и языком баз данных обычно усложнен, поскольку каждый язык имеет свой набор типов и свою модель вычислений. Организуя обращение к базе данных из прикладной программы, написанной, например, на C++, приходится подвергать данные структурной трансформации при передаче их из/в базу данных.

Технология объектно-ориентированных СУБД

Создание базы данных, как правило, включает несколько этапов [3]. Среди них можно выделить:

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

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

3. Физическое конструирование. На этом этапе прорабатываются вопросы, связанные с реализацией модели данных во внешней памяти, - кластеризации, разбиения (partitioning), индексирования.

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

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

2. Подклассы и суперклассы - экземпляры некоторого класса могут образовывать подмножество другого класса. Так, классы "студент" или "преподаватель" могут рассматриваться как подкласс класса "человек". Для "студента" и "преподавателя" "человек" является суперклассом.

3. Подклассы наследуют атрибуты и поведение своих суперклассов (например, "студент" и "преподаватель" наследуют у "человека" такие атрибуты, как "имя", "пол", "возраст" и т.д.).

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

5. Агрегирование - по зволяет создать сложные объекты из объектов-компонентов, определять отношения типа "часть-целое".

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

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

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

СУБД РОЕТ - пример реализации объектно-ориентированной технологии

Уже сейчас на рынке программных средств имеется более дюжины первоклассных систем, поддерживающих работу с объектно-ориентированными базами данных (см. Объектно-ориентированные базы данных - компании и разработки). Остановимся подробнее на разработке компании BKS Software - СУБД РОЕТ. Система РОЕТ - это типичный пример объектно-ориентированной СУБД (следуя нотации Питера Коада и Эдварда Йордона [2]), которая является многопользовательской, переносимой и интегрируемой, обеспечивающей двухступенчатый механизм транзакций и блокировку конкурентного доступа к обрабатываемым объектам.

В настоящее время СУБД РОЕТ доступна не только в нескольких вариантах для UNIX платформ, но и для систем Windows 3.1, NT, OS/2, Мас System 7 и NextStep.

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

Использование СУБД РОЕТ позволяет разработчикам баз данных:

1. свести к минимуму барьеры между стадиями разработки информационной системы;

2. работать с данными практически любых типов;

3. использовать стандартный С++ интерфейс для разработки как самих баз данных, так и для интеграции баз данных с другими системами (графический интерфейс с пользователем, например).

Структура служебных классов СУБД РОЕТ схематически изображена на Рисунке 1. Эта упрощенная схема (на самом деле, взаимосвязи между классами намного сложнее) позволяет оценить основные возможности системы. Центральное место системы занимает класс PtObject, который является базовым для всех классов базы данных (например, класс "клиент", "заказ" и т.п.). Подклассы, образованные от класса PtObject, для работы со строками, датами, временем могут использовать классы PtString PtDate, PtTime. Для агрегирования объектов используется класс PtSet - своеобразный контейнер классов PtObject. Например, человек может иметь несколько имен, и, таким образом, подкласс "человек" класса PtObject содержит в себе класс PtSet - набор классов "имя", образованных от класса PtObject, которые, в свою очередь, для хранения имен, отчеств и фамилий содержат строковые объекты, образованные от класса PtString.

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

1. Описать все типы и структуры данных, используя POET/C++ нотацию. В результате получается *.hcd файл описания структуры базы данных.

2. Написать интерфейс для работы с базой данных (ввод, просмотр, поиск объектов и т.п.), используя, например, язык С++.

3. Откомпилировать составные части разрабатываемой системы.

На рисунке 3 схематически представлена структура объектов, описывающая данные о работниках, которые трудятся над проектами, и рядом представлен фрагмент соответствующего .hcd файла. Каждый работник связан с одним проектом. Над проектом может трудиться несколько человек. Работник (класс Person) может быть программистом (класс Programmer). Программист отличается от обычного работника знанием языков программирования, и, следовательно, класс Programmer содержит не только дополнительные данные (language), но и разные методы ввода и вывода.

Проблемы и перспективы

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

Неясным пока остается положение со стандартами объектно-ориентированной технологии. Борьба идет между стандартами OLE 2.1 (Object Linking and Embedding, фирма Microsoft) и CORBA 2 (Common Object Request Broker Architecture, группа OMG - Object Management Group, объединяющая компании IBM, HP, Sun, Novell, ВЕС и др.). За спиной Microsoft стоят тысячи независимых разработчиков программного обеспечения для ПК, которые, как предполагается, с появлением системы Cairo перейдут на технологию Distributed OLE. Группа OMG отстаивает стандарт, ориентированный на все платформы и предназначенный для всех производителей, включая и Microsoft. Ясно, что отсутствие компромисса и война стандартов на модели объектов и способы обслуживания объектов всего лишь заставит производителей программного обеспечения на неопределенное время занять выжидательную позицию.

Тем не менее, современное системное программное обеспечение (операционные системы и средства разработки) становится всерьез объектно-ориентированным, и возможно, что к концу 1995 года объекты будут повсюду. Это обещают три конкурирующих проекта [4]: объектно-ориентированная среда OpenStep (компании Sun, HP, NeXT обещают создать ее к началу 1995 года), объектно-ориентированная среда и файловая система Cairo - объектно-ориентированная версия Windows-NT вместе с новой системой хранения файлов Object File System (фирма Microsoft планирует выпустить рабочую версию к лету 1995 года) и объектно-ориентированная операционная система Taligent (компании IBM, Apple, HP планируют завершить создание системы в 1995-96 годах).

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

Следует обратить серьезное внимание на попытки интеграции реляционного и объектно-ориентированного подхода [7]. Эти попытки заметны как со стороны известных поставщиков реляционных СУБД, так и со стороны компаний-производителей объектно-ориентированных СУБД. Можно ожидать, что такие компании-поставщики реляционных СУБД, как Oracle, Informix, SyBase, ASK Group (СУБД Ingres), IBM (СУБД DB2) в течение 1994-1996 годов в той или иной мере начнут поддерживать объектно-ориентированные технологии в своих продуктах. Большие надежды при этом возлагаются на язык запросов SQL-3, находящийся пока в стадии рассмотрения, который должен включать объектные расширения. Со своей стороны, производители объектно-ориентированных баз данных пытаются интегрировать в свои продукты элементы реляционной технологии. Так, фирма Objectivity Inc. включила в третью версию своего продукта поддержку ANSI-стандарта языка SQL. Ряд продуктов, так или иначе интегрирующих реляционный и объектно-ориентированный подходы, включают OpenODB (производитель - компания Hewlett-Packard), семейство продуктов UniSQL, производимых одноименной компанией, Montage, производства компании Montage Software, Inc. Остается, однако, вопросом, насколько глубоко и естественно можно интегрировать реляционную и объектно-ориентированную технологии. На данном этапе журнал "Datamation" считает целесообразным исследовать применимость объектно-ориентированных СУБД для данной предметной области путем реализации локальных проектов.

Заключение

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

Литература

[1] Andleigh P.K., Grelzinger M.R. Distributed Object-Oriented Data Systemss Design. - Prentice Hall, 1992.

[2] Coad Р., Yourdon E. Object-Oriented Analysis. - Prentice Hall, 1991.

[3] Navathe S.B. Evolulion of Data Modelling for Databases // Communications of the ACM. - 1992. - September. - p.112-123.

[4] Semich W.J. What's the Next Step after Client/Server // Dalamation. - 1994. - March, 15. - p.26-34.

[5] Rasmus D.W. Relating to Objects // Byte. - 1992. - December. - p. 161-165.

[6] Stone C.M., Hentchel D. Database Wars Revisited. - Byte. - 1990. - December. - p.233-244.

[7] The Lee Wedding Bells Sound for Objects And Relational Data // Datamation. - 1994. - March, 1. - р.49-52.

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

Идеология объектно-ориентированного программирования получила развитие в рамках разработки таких языков, как SmallTalk или С++.

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

В основе объектной идеологии, естественно, лежит понятие объекта.

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

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

3. Полиморфизм - различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения. Например, объект класса "линия" отреагирует на сообщение "нарисовать" рисованием линии, тогда как объект класса "окружность" - рисованием окружности.

Объектно-ориентированный системный анализ

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

Основной принцип системного анализа - декомпозиция. Исторически сперва использовалась функциональная декомпозиция с построением иерархий функций. Взаимосвязи функций во времени представлялись потоками функций. Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются наиболее статичным элементом. Действительно, типы паспортных данных о человеке остаются (имя, фамилия, год рождения и т.п.), а способы их обработки, виды запросов могут меняться относительно часто. Поэтому получили развитие такие методы системного анализа, как диаграммы потоков данных - DFD (Data Flow Diagram). Развитие реляционных баз данных подтолкнуло к совершенствованию методик построения моделей данных, в частности, ER-диаграмм (Entity Relationship Diagram). Однако, ни функциональная декомпозиция, ни потоки данных, ни модели данных, являясь мощными инструментами, дающими срез исследуемой предметной области, не позволяют получить естественное формальное представление системы в целом.

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

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

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