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

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

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

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

Ряд американских компаний - 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++, приходится подвергать данные структурной трансформации при передаче их из/в базу данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время СУБД РОЕТ доступна не только в нескольких вариантах для 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 года объекты будут повсюду. Это обещают три конкурирующих проекта : объектно-ориентированная среда OpenStep (компании Sun, HP, NeXT обещают создать ее к началу 1995 года), объектно-ориентированная среда и файловая система Cairo - объектно-ориентированная версия Windows-NT вместе с новой системой хранения файлов Object File System (фирма Microsoft планирует выпустить рабочую версию к лету 1995 года) и объектно-ориентированная операционная система Taligent (компании IBM, Apple, HP планируют завершить создание системы в 1995-96 годах).

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

Следует обратить серьезное внимание на попытки интеграции реляционного и объектно-ориентированного подхода . Эти попытки заметны как со стороны известных поставщиков реляционных СУБД, так и со стороны компаний-производителей объектно-ориентированных СУБД. Можно ожидать, что такие компании-поставщики реляционных СУБД, как 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" считает целесообразным исследовать применимость объектно-ориентированных СУБД для данной предметной области путем реализации локальных проектов.

Заключение

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

Литература

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

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

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

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

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

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

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

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

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

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

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

Рассматривая особенности чисто объектно-ориентированных СУБД, следует выделить двух систем - ORION и O2.

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

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

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

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

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

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

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

Оъекгно-СУБД

1. 20 лет эволюции программного обеспечения. 3

2. Реляционные базы данных. 4

3. Объектно-реляционные методы. 6

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

4.1 Why ODBMS? 8

4.2 Спорные моменты технологии. 10

4.3 Стандарты объектных баз данных. 13

4.4 Поставщики ООСУБД. 17

5. Заключение. 19

6. Глоссарий 21

2. 20 лет эволюции программного обеспечения.

Управление информацией всегда было основной сферой применения компьютеров и, надо думать, будет играть еще большую роль в будущем. Системы управления базами данных (СУБД, DBMS – Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами. Позволив себе рассуждения в стиле Билла Гейтса, предположим, что результатом будет становление систем управления информацией одной из частей повседневной жизни каждого.

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

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

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

Обьектно-ориентированные СУБД (ООСУБД ) стали разрабатываться с середины 80‑х годов в основном для поддержки приложений САПР. Сложные структуры данных систем автоматизированного проектирования оказалось очень удобно оформлять в виде объектов, а технические чертежи проще хранить в базе данных, чем в файлах. Это позволяет обойтись без декомпозиции графических структур на элементы и записи их в файлы после завершения работы с чертежом, выполнения обратной операции при внесении любого изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки” результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР.

Между тем рынок САПР был быстро насыщен, и в начале 90‑х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (databaseadministrator – DBA), средствами резервного копирования/восстановления и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно сказать, что переход к коммерческим приложениям идет достаточно успешно.

3. Реляционные базы данных.

В реляционных базах данных ( Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – IndexedSequentialAccessMethod (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel(Ingres) и RDO (DigitalEquipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70‑х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSISQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

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

Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом ( primary key) таблицы и часто являются числами. Если одна таблица содержитпервичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом ( foreign key) .

Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько нибудь сложных взаимосвязей в базе данных. Желающим убедится, что это действительно так и не пожалевшим на это определенный отрезок времени, компания POETSoftware любезно предоставляет возможность ознакомиться с примером в своей “белой книге” “POETTechnicalReference”. База данных рядового предприятия общепита (клиенты – Джордж Буш и Эдди Мэрфи) состоит из четырех таблиц.

Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей.

4. Объектно-реляционные методы.

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

· разделение таблиц разными программами;

· развернутый “код возврата” при ошибках;

· высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию);

· сама концепция объектных баз данных довольно сложна и требует от программистов серьезного и длительного обучения;

· относительно высокая скорость при работе с большими объемами данных.

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

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

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

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

Характеристики ООСУБД подразделяются на триопределяющие группы:

- базовые, определяющие принадлежность СУБД кобъектно-ориентированному классу;

- по выбору, позволяющие улучшать ООСУБД, но не являющиесябазовыми,

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

В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД в ее классическом понимании и быть объектно-ориентированной системой (ООС), т.е. в определенной степени она должна быть совместимой с современными объектно-ориентированными ЯВУ.Первый критерий включает следующие пять характеристик, присущих классической СУБД: сохранность и реентерабельность данных, развитое управление внешней памятью, возможность совмещения обработки и поиска данных, поддержка средств восстановления и возможность быстрого доступа к БД по запросу пользователя. Отмеченные характеристики в той или иной мере обсуждались выше.Второй критерий предполагает наличие следующихвосьми характеристик, присущих собственно объектно-ориентированной технологии: понятие сложных объектов, идентичность объектов, инкапсуляция, типы или классы, наследование, настройка (сочетающаяся с отложенным присвоением), расширяемость и вычислительная полнота. Характеристики первого критерия хорошо известны пользователям традиционных СУБД (INGRES, dBase, R:Base, IMS, Reflex и др.), поэтому кратко остановимся на характеристикахвторого критерия, соотнося их с уже рассмотренными вопросами ООП-технологии.

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

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

2. Понятиеидентичности объектов давно существует в языках программирования и относительно недавно вСУБД. Суть данного понятия состоит в том, что существование объектане зависит от его значения. В этом плане существует два понятияэквивалентности объектов:

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

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

3. Понятиеинкапсуляции связано с необходимостью как прояснить различие между спецификацией и реализацией операции, так и с применением модульного принципа организации ПС. Наинкапсуляцию существует две точки зрения: (1) со стороны ЯВУ (именно здесь зародилось это понятие) и (2) адаптированная со стороны СУБД точка зрения. Впервом случае понятие инкапсуляции восходит к абстрактным типам данных, когдаобъект имеет интерфейсную и обрабатывающую части. Интерфейсная часть специфицирует множество операций, которые могут быть выполнены над объектом. Тогда как обрабатывающая часть, в свою очередь, состоит из данных и процедур: данные определяют состояние или представление объекта, а процедуры на некотором ЯВУ (например Turbo-Pascal, C++, SmallTalk и др.) описывают применение к объекту каждой допустимой для него операции.

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

4. В ООС существуют две основные категории, поддерживающие соответственно понятиекласса и типа. К первой категории можно отнести SmallTalk - подобные системы (SmallTalk, Vision, GemStone и др.) и все созданные на основе Zi"sp-языка системы (Flavors, G-Base, Orion, Lore и др.). Тогда как ко второй категории можно отнести такие системы, как: C++, Trellis, VBase, Simula и др. Понятиетипа в ООС суммирует общие черты множества объектов с одинаковыми характеристиками. Оно соответствует понятию типа абстрактных данных. Тип состоит из двух частей: интерфейсной и обрабатывающей. Для пользователя видна толькоинтерфейсная часть, содержащая список допустимых для данного типа операций с их сигнатурой (типы входных параметров и результата). Тогда какобрабатывающая часть скрыта от пользователя и состоит, в свою очередь, также из двух частей: данных и процедур. Частьданных описывает собственно внутреннюю структуру данных объекта и в зависимости от возможностей ООС данная часть может быть более или менее сложной.Процедуры поддерживают выполнение операций из интерфейсной части объекта.

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

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

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

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

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

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

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

9. Современные ООСУБД, представляющие собой четвертое поколение в технологии управления данными, в коммерчески пригодном исполнении появились относительно недавно. Они поддерживают все рассмотренные выше черты и характеристики как традиционных СУБД, так и объектно-ориентированной технологии (ООТ). В плане выразительных возможностей прикладной семантики ООСУБД существенно мощнее традиционных реляционных СУБД. Превосходный сравнительный анализ реляционных СУБД и ООСУБД можно найти в . Первыми разработчиками ООСУБД в 1990 г. явились фирмы Object Design, OBJECT-Sciences, Objectivity, OntoLogic и Servio (США). Наряду с ними ряд разработчиков классических реляционных СУБД расширили свои системы объектно-ориентированными средствами. Среди наиболее удачных разработок можно отметить, в первую очередь, ООСУБД VERSANT фирмы Versant Object Technology, которая поддерживает ряд широко используемых стандартов, а также концепцию ООСУБД, рассмотренную выше. В качестве примера кратко рассмотрим вопросы VERSANT-технологии управления данными, базирующейся на ООСУБД VERSANT, на сегодня являющейся одним из стандартов дефакто для такого типа ООС.

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

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

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

Второй уровень содержит единственную компоненту VERSANT Star системы, осуществляющую интеграцию различных СУБД. Она управляет доступом кобъектам, находящимся в системе БД первого уровня архитектуры. С этой целью она использует набор БД-драйверов, поддерживающих индивидуальные БД-форматы. По этой причине в настоящее время поддерживаютсятолько наиболее популярные СУБД (ORACLE, DB/2, IMS и др.), но данный список постоянно расширяется. Этому способствует и переход к новому единому ASCII-стандарту для реляционных СУБД.

В отличие от некоторых ООСУБД система VERSANT не использует единого языка программирования и не требует от пользователя использования какого-либо конкретного компилятора или транслятора. Она позволяет для работы со своими БД использовать многие как традиционные, так и объектно-ориентированные ЯВУ(третий уровень; смотри рисунок 5.6). Достигается это посредством введения языковых интерфейсов в виде библиотек классов и функций. Посредством использования данных библиотек в своих прикладных программах пользователь получает доступ ко всем ресурсам VERSANT-системы на широком спектре различных ЯВУ. В настоящее время поддерживаются пять базовых языков: Pascal, С, C++, SmallTalk и Object SQL. Последний является расширением SQL-стан-дарта, позволяющим управлять структурами объектно-ориентированных данных. В свою очередь, С-интерфейс может быть использован любым языком программирования, допускающим вызовы внешних С -функций (Pascal, Fortran, Cohol и др.). Это позволяет пользователю писать свои прикладные программы на подходящем ЯВУ, обеспечивая доступ к любой БД, интегрированной в VERSANT-систему. Следующие три уровня архитектуры определяют (ЗхЗ)-матрицу средств, предназначенных для облегчения разработки прикладных программ и администрирования интегрированной ООСУБД VERSANT-системы.

Четвертый уровень содержит средства, расширяющие возможности прикладных программ, написанных на ЯВУ уровня 3 и совместимых с ними. Компонента этого уровня Object Modeler является наиболее многоцелевым средством, позволяющим средствами графического интерфейса на экране определять объектно-атрибутные структуры данных. Затем эти структуры данных могут автоматически транслироваться в С -структуры, {С+SmallTalk} -классы или SQL-таблицы, позволяя существенно сокращать время разработки прикладных программ.

Средство Object Modeler оказывает неоценимую помощь в деле повышения продуктивности пользователя, так как позволяет только один раз определять структуры данных, а затем повторно использовать их во многих различных приложениях безотносительноязыка, на котором они были запрограммированы, или БД, к которым организуется доступ. Вторым важным преимуществом данного средства является то, что оно может непосредственно использоваться системотехниками, воспитанными на традиционной технологии, а не на ООТ. Два других средства уровня 4 обеспечивают поддержку языка запросов SQL-стандарта. Так, на базе средства SQL Gateway (шлюза) пользователь в своих программах на языках C++ и/или SmallTalk может организовывать запросы в SQL-стандарте и автоматически получать результаты запросов в соответствующие объекты программы. Средство же Embedded SQL позволяет использовать предложения языка Object SQL для расширенного доступа к объектно-ориентированным структурам данных.

Пятый уровеньархитектуры (смотри рисунок 5.6) включает средства для администратора БД, предназначенные для настройки и управления распределенными БД. Данные средства пригодны также и для прикладных программистов, но только первое из них обычно ими используется. Средство Designer представляет собой графический инструмент для программистов и администратора БД, позволяющий в рамках VERSANT-баз создавать и управлять иерархиями классов. Средство автоматически генерирует определения классов для языка C++ из их графического представления. Более того. Designer может просматривать БД, позволяя пользователю или администратору проверять (просматривать) определения классов в БД, включая их атрибуты, отношения и методы. С его помощью можно проверять, изменять или удалять (т.е.редактировать} отдельные элементы в БД. Средство Repository Builder позволяет администратору БД определять и обслуживать метаданные из архива данных системы. По функционированию данное средство несколько напоминает предыдущее, но включает ряд специальных возможностей для обеспечения доступа именно к информации архива системы. Наконец,Administrator представляет собой набор средств администратора БД, поддерживающих: командный (оперативный) режим управления пользователями и доступом к БД, операции восстановления, а также выполнять другие стандартные сервисные функции по обслуживанию ООСУБД VERSANT-системы.

Шестой уровень включает средства, предназначенные для быстрой генерации мощных объектно-ориентированных прикладных программ на основе библиотек классов, поддерживаемых системой. Графическое Screen -средство ориентировано на разработку необходимыхграфических интерфейсов для приложений. Наряду с этимScreen имеет развитые средства для управленияшироким набором носителей информации Например, можно вводить диаграммы, производить поиск в БД фотографий, карт или осуществлять другие процедуры (не поддерживаемые традиционными пакетами) по работе с форматированной информацией. Средство Report предназначено для подготовки отчетов и при необходимости может выполнять роль традиционногогенератора отчетов. Наконец, Object 4GL представляет собой ЯВУ программирования БД, который может быть использован для состыковки операций и объектов, созданных другими средствами системы. Следует отметить, что графические интерфейсы, отчеты и процедуры, созданные средствами шестого уровня, сохраняются в архиве системы (Repository) и становятся доступными для всех приложений в среде VERSANT-системы. Более того, по причине определения этих прикладных конструкций в терминах абстрактных категорий и атрибутов, они могут использоваться и с другими типами СУБД.

Седьмой уровень архитектуры (смотри рисунок 5.6) представляютспециализированные приложения (библиотеки классов), специально адаптированные к нуждам той или иной области приложений VERSANT-системы (проектирование, конструирование, производство, строительство, сетевое моделирование и др.). Средства данного уровня стали возможными благодаря принципу многократного использования, поддерживаемому ООТ.

Наконец, навосьмом уровнеархитектуры представлены фактические (конечные) приложения VERSANT-технологии. Используя средства седьмого уровня или создавая свои собственные, пользователь завершает создание конкретного функционально полного приложения VERSANT-системы. На рисунке 5.6 условно показано, какнекоторый интегрированный пакет для проектирования в области разработки и производства интегральных схем (CIM Applications) может быть перенастроен на основе средств седьмого уровня (Engineering, Manufacturing, Finance), используя их функциональные возможности, чтобы быстро связывать изменения проектных решений с производственными затратами и оценивать их влияние на себестоимость конечного изделия. Практическое использование VERSANT-технологии позволяет говорить о ее большихпотенциях для разработчиков АСУП и АСУТП всех уровней.

Первоначально средства VERSANT-технологии были разработаны и эксплуатировались на платформах Sun 3/4, мини-ЭВМ IBM RISC System/6000, DEC -станциях, HP 9000/400, системах Silicon Graphics, InterGraph 6000 и последующих сериях мультипроцессорных ЭВМ. В настоящее время указанныеООС функционируют также на платформах Unix, Windows, OS/2 и Macintosh. Эти реализации делают VERSANT-технологию доступной для широкого круга пользователей IBM-совместимых ПК и существенно расширяют ее возможности для обеспечения распределенной обработки информации в условиях функционирования различного назначения ИИС.

Лекция 7 (2 часа)

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

• деревья (a) и (b), показанные на рис. 4.2 , заменяются одной сетевой структурой, в которой запись СОТРУДНИК входит в два групповых отношения;
• для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК, (см. рис. 4.3). Отметим, что в этой записи может храниться и полезная информация, например, доля данного сотрудника в общем вознаграждении по данному контракту.

Рис. 4.3.

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

Способ упорядочения подчиненных записей:

• произвольный,
• хронологический /очередь/,
• обратный хронологический /стек/,
• сортированный.

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

Режим включения подчиненных записей:

• автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем;
• ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем.

Режим исключения.

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

• Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи -владельца все подчиненные записи автоматически тоже удаляются. В рассмотренном выше примере фиксированное членство предполагает групповое отношение "ЗАКЛЮЧАЕТ" между записями "КОНТРАКТ" и "ЗАКАЗЧИК", поскольку контракт не может существовать без заказчика.
• Обязательное. Допускается переключение подчиненной записи на другого владельца, но невозможно ее существование без владельца. Для удаления записи-владельца необходимо, чтобы она не имела подчиненных записей с обязательным членством. Таким отношением связаны записи "СОТРУДНИК" и "ОТДЕЛ". Если отдел расформировывается, все его сотрудники должны быть либо переведены в другие отделы, либо уволены.
• Необязательное. Можно исключить запись из группового отношения, но сохранить ее в базе данных не прикрепляя к другому владельцу. При удалении записи -владельца ее подчиненные записи - необязательные члены сохраняются в базе, не участвуя более в групповом отношении такого типа. Примером такого группового отношения может служить "ВЫПОЛНЯЕТ" между "СОТРУДНИКИ" и "КОНТРАКТ", поскольку в организации могут существовать работники, чья деятельность не связана с выполнением каких-либо договорных обязательств перед заказчиками.

Операции над данными в сетевой модели БД

Ограничения целостности

Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения - член отношения).

Достоинства и недостатки ранних СУБД

Достоинства ранних СУБД:

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

Недостатки ранних СУБД:

• сложность использования;
• высокий уровень требований к знаниям о физической организации БД;
• зависимость прикладных систем от физической организации БД;
• перегруженность логики прикладных систем деталями организации доступа к БД.

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

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

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

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

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

Структура

Структура объектной модели описывается с помощью трех ключевых понятий:

Целостность данных

Для поддержания целостности объектно-ориентированный подход предлагает использовать следующие средства:

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

Средства манипулирования данными

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

Подведем теперь некоторые итоги

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

В то же время, ОО - модели присущ и ряд недостатков :

• отсутствуют мощные непроцедурные средства извлечения объектов из базы. Все запросы приходится писать на процедурных языках, проблема их оптимизации возлагается на программиста;
• вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES ) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).