Триколор 

Объектно-ориентированные субд. Объектно-ориентированная субд

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

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

    производитель продукт
    Bionic Knight Software, Inc. DEED BKS
    Software, Inc. POET
    ASK Group INGRES Intelligent Database
    Itasca Systems, Inc. Itasca Object Database Management System (ODBMS)
    O2 Technology O2
    Object Databases (ODB) MATISSE
    Object Design, Inc. ObjectStore
    Objectivity, Inc. Objectivity/DB
    ONTOS, Inc. ONTOS DB
    Persistent Data Systems IDB Object Database
    Servio Corp. GemStore
    Symbolics, Inc. UniSQL/X, Database Management System, UniSQL Multidatabase System
    Versant Object Technology Corp. VERSANT Object Database Management System (ODBMS)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    vdbms 20 декабря 2017 в 14:59

    Простая объектная СУБД

    • Алгоритмы ,
    • Анализ и проектирование систем ,
    • Программирование

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

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

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

    Объект данных

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

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

    Априори объект содержит набор значений, которые идентифицируются по их порядковому номеру в наборе. Сам объект свои значения никак не интерпретирует, но «знает», что каждое значение характеризуется длиной в байтах, что позволяет вычислить размер объекта. Набор значений существует в формате кортежа.

    Идентификация и доступ

    Для хранения объектов используется условно бесконечное файловое пространство, логически разбитое на кластеры. В файловом хранилище каждый объект занимает один или более последовательных кластеров. Порядковый номер первого кластера используется в качестве файлового указателя FP (File Pointer) на размещение объекта в хранилище.

    Для долговременного хранения файловых указателей используется таблица аллокации DAT (Data Allocation Table), которая представляет собой простой динамически расширяемый массив целочисленных указателей. Индексы ячеек DAT используются в качестве системных идентификаторов объектов IDO . Когда создается новый объект, ему выделяется очередная свободная ячейка DAT, индекс которой становится постоянным идентификатором объекта. Этот идентификатор является уникальным и глобальным дескриптором объекта в пределах физической базы данных.

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

    Если извлеченное из DAT значение представляет собой файловый указатель, то объект загружается из хранилища в память - Cache объектов , и содержимое ячейки DAT подменяется указателем на память A* . Обратная замена происходит при вытеснении объекта из памяти.

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

    Cache объектов

    Представляет собой непрерывную область памяти, статически выделенную при инициализации системы. Требуемый размер задается опционально.

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

    Состояния и транзакции

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

    Внешнее воздействие, изменяющее состояние базы данных, рассматривается как транзакция .

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

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

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

    Концепция транзакционной целостности общеизвестна - "все, или ничего ".

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

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

    Необходимость соблюдения "состоятельной " целостности данных далеко не столь очевидна.

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

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

    Объекты состояния

    Как минимум одно состояние базы данных - фоновое , актуально всегда. Фоновое состояние образовано полным множеством объектов, непосредственно адресуемых из DAT, из которых часть осталась на диске, а часть загружена в память.

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

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

    Ранее упоминалось, что попытка изменить существующий объект автоматически порождает его новую версию. Таким образом, одновременно в памяти могут находится несколько версий одного и того же объекта. Эти версии связаны в одноименную цепочку. Указатель (A* ) на первый объект в цепочке версий находится в DAT, а сама цепочка позволяет пользователю получить доступ к «правильной» версии объекта в требуемом состоянии. При этом корректной (актуальной с точки зрения пользователя) считается версия с наибольшим номером состояния, не превышающим требуемый.

    Распределение по состояниям объектов, связанных в цепочки состояний и версий, выглядит примерно так:

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

    Для управления многопользовательским доступом, состояниями базы данных и их объектами используется таблица состояний ST (States Table).

    Таблица состояний

    Каждая запись ST содержит указатель (A* ) на первый объект цепочки объектов состояния, идентификаторы пользователя и объекта блокировки, а также счетчик пользователей, использующих это состояние.

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

    Указатель Background State (BS ) содержит номер фонового состояния. При поглощении последующего временного состояния указатель BS инкрементируется. Условием поглощения является нулевое значение счетчиков использования сразу двух состояний: фонового и следующего за ним. Условие проверяется при закрытии любой из сессий, после декремента счетчика использования.

    Указатель Last Available State (LS ) содержит номер самого старшего состояния из доступных. Этот номер предоставляется пользователю при открытии им сессии выборки. Когда очередная транзакционная сессия закрывается, указатель LS инкрементируется, автоматически получая номер этой сессии.

    Указатель Next State (NS ) предоставляет номер состояния пользователю, открывающему транзакционную сессию, после чего инкрементируется. Если открытых транзакционных сессий нет, то значение NS превышает значение LS на 1. Если нет временных состояний, то значения указателей BS и LS совпадают.

    Номер состояния, получаемый пользователем при открытии любой сессии, сохраняется в соответствующей записи таблицы клиентов CT (Client Table). Все обращения пользователя к API сервиса объектов включают в себя идентификатор клиента, а остальные данные извлекаются из соответствующей записи CT.

    Таблица клиентов

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

    Разрешение конфликтов

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

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

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

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

    Нештатные ситуации

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

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

    Зависание сессии выборки будет обнаружено только тогда, когда исчерпаются все свободные записи ST, то есть когда индексы BS и NS сравняются. Зависшее состояние с индексом или будет иметь не нулевое значение счетчика использования.

    Безотносительно причины аварии сессии, ее последствия всегда одинаковы: после получения идентификатора «зависшего пользователя» его поток принудительно останавливается, все использованные ресурсы освобождаются, сессия принудительно завершается, после чего конвейер самостоятельно разгружается уже в штатном режиме. Все эти действия выполняются в потоке пользователя, обнаружившего проблему. По завершении восстановительных операций поток зависшего пользователя запускается снова, и он предпринимает как минимум одну попытку повторить неудачную сессию заново. В случае второй неудачи пользователь начинает свой поток с ожидания внешних событий. Весь этот процесс регулируется флагами, выставляемыми пользователю в Client Table.

    Кортеж значений

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

    Логически, кортеж представляет собой последовательность элементов, идентифицируемых по их порядковому номеру в кортеже. Элемент кортежа содержит некоторое значение, которое характеризуется своей длиной. Длина значения априори известна, и вынесена в заголовок значения. Реализуется кортеж в виде массива относительных указателей. Каждый указатель представляет собой смещение начала значения относительно начала кортежа. И смещение, и размеры измеряются в байтах.

    Кортеж обладает рядом замечательных свойств.

    Прежде всего, значением в кортеже может быть другой кортеж. С этой точки зрения все содержимое объекта можно рассматривать как одно значение. Длина любого значения известна из его заголовка, а значит известно и количество элементов в кортеже.

    Порядок следования элементов в кортеже строг и неизменен. Операция «Вставка» запрещена. Но можно безболезненно добавлять к имеющемуся набору новые элементы.

    В кортеже не инициализированное значение будет иметь нулевое значение смещения, чем и отличается от «пустого» значения с нулевой длиной. Не инициализированным значением можно бесконфликтно оперировать, в том числе рассматривая его как «пустое» значение.

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

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

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

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

    Изменение объекта

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

    Новое значение, присваиваемое объекту, также размещается в Cache объектов, после чего смещение нового значения относительно экземпляра объекта записывается в соответствующий элемент кортежа.

    Сохранение объектов

    Файловое пространство, выделяемое для хранения объектов, не только кластеризовано, но и разбито на банки данных размером два в степени N кластеров. Каждый банк занимает один файл, который именуется последовательным номером банка. Таким образом, при обращении к объекту на диске, его FP последовательно конвертируется сначала в имя файла, а затем в номер кластера в файле.

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

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

    После завершения сессии измененные объекты транзакции в Cache становятся общедоступны в том виде как есть, а именно - с неполным кортежем. Эти объекты должны заместить собой предыдущие версии.

    Слияние версий

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

    Версия , как правило подгруженная с диска, занимает непрерывную область в Cache, в то время как кортеж и новые значения версии [+1] находятся в разных местах, усиливая дефрагментацию памяти. Поэтому сценарий поглощения версии [+1] выглядит привлекательнее сценария вытеснения версии . Если новое значение версии [+1] по размеру не превышает имеющееся, то оно просто копируется в тело версии , и занимаемая им память освобождается. Иначе это новое значение остается за пределами объекта как есть, и для него вычисляется новое смещение, а объекту выставляется флаг, обязывающий процесс обычного вытеснения анализировать объект на наличие фрагментов за его пределами.

    Формализация транзакций

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

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

    Последовательность формализованных транзакций, сохраненных на диске, образует журнал транзакций.

    Журнал транзакций

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

    Помимо этого стоит отметить, что у журнала есть еще одна функция – фискальная, которая не раз доказывала свою полезность в разборках типа " … это программа накосячила".

    Запись на диск

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

    Тип данных определяет целевой файл, в который будут записываться данные. Основных типов данных всего три: формализованные транзакции, банки объектов и DAT.

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

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

    В результате действий потока записи файловое хранилище принимает следующий вид:

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

    Контрольная точка

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

    Если работа сервера не была завершена надлежащим образом, то как минимум DAT в рабочей области и последний файл журнала транзакций проверку не пройдут, и автоматически запустится процесс восстановления из самой последней контрольной точки.

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

    Сборка мусора

    В нашем распоряжении всего два физических ресурса: память и такты процессора. А так как в приоритете производительность, то следствием является повышенный расход памяти. Так, с целью уменьшить объем файловых операций, новые и измененные объекты сохраняются на диске оптом, одним файлом. При этом более ранние версии изменяемых объектов остаются на прежних местах в предыдущих банках и уже никогда не будут использованы. Чтобы вернуть системе дисковую память, внутренне «поредевший» банк необходимо периодически «уплотнять», уменьшая его размер, и не забывая при этом внести изменения в DAT и перезаписать архивную копию банка. Для облегчения анализа заполненности банков, сервис объектов перманентно поддерживает в актуальном состоянии битовую карту кластеров.

    Архитектура сервера

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

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

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

    Внутренняя логика Модели и Курсоров, а также способы ее реализации - тема отдельного рассказа.

    Масштабируемость

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

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

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

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

    За кадром

    Как это часто случается при изложении достаточно объемного материала, было пропущено много относительно мелких и второстепенных деталей. Так например, не были упомянуты: сегментирование и дублирование DAT в памяти; особый порядок управления «большими» объектами; принципы организации взаимных блокировок потоков пользователей при доступе к общим ресурсам; логика и реализация сборки мусора; отображение процесса исполнения в log-журнал; сбор и отображение статистики; и многое другое.

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

    Резюме

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

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

    Теги:

    • базы данных
    • объектная СУБД
    • архитектура системы
    Добавить метки

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

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

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

    Структура :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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