2.5. Объектно-ориентированная модель данных

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

Стандартизованная объектно-ориентированной модель описана в рекомен­дациях стандарта ODMG-93 (Object Database Management Group — группа уп­равления объектно-ориентированными базами данных). Реализовать в полном объеме рекомендации ODMG-93 пока не удается. Для иллюстрации ключевых идей рассмотрим несколько упрощенную модель объектно-ориентированной БД.

Структура объектно-ориентированной БД (ООБД) графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым — string) или типом, конструируемым пользователем (определяется как class).

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

Пример логической структуры ООБД библиотечного дела приведен на рис. 2.8.

Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА могут иметь одного или разных родителей. Объекты типа КНИГА, имеющие одного и того же родителя, должны различаться по крайней мере инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.

Рис. 2.8. Логическая структура БД библиотечного дела

Логическая структура ООБД внешне похожа на структуру ИБД. Основное отличие между ними состоит в методах манипулирования данными.

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

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

Рассмотрим кратко понятия инкапсуляции, наследования и полиморфизма применительно к объектно-ориентированной модели БД.

Инкапсуляция ограничивает область видимости имени свойства пре­делами того объекта, в котором оно определено. Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБО­НЕНТ и КАТАЛОГ. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа КНИГА, являющимся по­томками объекта типа КАТАЛОГ, можно приписать свойства объекта-роди­теля: isbn, удк, название и автор. Если необходимо расширить действие ме­ханизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типаabs. Так, определение абстрактных свойств билет и номер в объекте БИБЛИОТЕКА приводит к наследованию этих свойств всеми дочерними объектами АБОНЕНТ, КНИГА и ВЫДАЧА. Не случайно поэтому значения свойствабилет классов АБОНЕНТ и ВЫДАЧА, показанных на рисунке, будут одинаковыми — 00015.

Полиморфизм в объектно-ориентированных языках программированияозначает способность одного и того же программного кода работать с разно­типными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковымиименами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Применительно к нашей объектно-ориентированной БД полиморфизм означает, что объекты класса КНИГА, имеющие разных родителей из класса КАТАЛОГ, могут иметь разный набор свойств. Следовательно, программы работы с объектами класса КНИГА могут содержать полиморфный код.

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

Рис. 2.9. Фрагмент БД с объектом-целью

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

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

В 90-е годы существовали экспериментальные прототипы ООСУБД. В настоящее время насчитывается более 300 таких СУБД. Некоторые системы получили относительно широкое распространение, например следующие СУБД: Cache (InterSystems), РОЕТ (РОЕТ Software), Jasmine (Computer Associates), Versant(VersantTechnologies),O2 (ArdentSoftware),ODB-Jupiter(научно-производственный центр «Интелтек Плюс»), а такжеIris,OrionиPostgres.

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

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