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

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

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

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

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

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

В первую очередь, ООСУБД должна удовлетворять двум критериям: быть СУБД в ее классическом понимании и быть объектно-ориентированной системой (ООС), т.е. в определенной степени она должна быть совместимой с современными объектно-ориентированными ЯВУ. Первый критерий включает следующие пять характеристик, присущих классической СУБД: сохранность и реентерабельность данных, развитое управление внешней памятью, возможность совмещения обработки и поиска данных, поддержка средств восстановления и возможность быстрого доступа к БД по запросу пользователя. Отмеченные характеристики в той или иной мере обсуждались выше. Второй критерий предполагает наличие следующих восьми характеристик, присущих собственно объектно-ориентированной технологии: понятие сложных объектов, идентичность объектов, инкапсуляция, типы или классы, наследование, настройка (сочетающаяся с отложенным присвоением), расширяемость и вычислительная полнота. Характеристики первого критерия хорошо известны пользователям традиционных СУБД (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. Современные ООСУБД, представляющие собой четвертое поколение в технологии управления данными, в коммерчески пригодном исполнении появились относительно недавно. Они поддерживают все рассмотренные выше черты и характеристики как традиционных СУБД, так и объектно-ориентированной технологии (ООТ). В плане выразительных возможностей прикладной семантики ООСУБД существенно мощнее традиционных реляционных СУБД. Превосходный сравнительный анализ реляционных СУБД и ООСУБД можно найти в [359-362, 394-398]. Первыми разработчиками ООСУБД в 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 поддерживает многопользовательский/многосерверный режим управления распределенными БД, позволяя сохранять, отыскивать и обновлять объекты в распределенных вычислительных системах.

Рисунок 5.6 – Архитектура ИИС на основе 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 часа)