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

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

1. Абстракция: Каждая реальная "вещь", которая хранится в БД, является членом какого-либо класса. Класс определяется как совокупность свойств (properties), методов (methods), общедоступных (public) и частных (private) структур данных, а также программы, применимых к объектам (экземплярам) данного класса. Классы представляют собой ни что иное, как абстрактные типы данных. Методы - это процедуры, которые вызывается для того, чтобы произвести какие-либо действия с объектом (например, напечатать себя или скопировать себя). Свойства - это значения данных, связанные с каждым объектом класса, характеризующие его тем или иным образом (например, цвет, возраст). Свойства присутствуют не во всех реализациях, по сути дела, они являются краткой записью методов без аргументов (таких как "сообщите свой цвет", "сообщите свой возраст").

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

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

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

5. Сообщения: Взаимодействие c объектами осуществляется путем посылки сообщений с возможностью получения ответов. Это отличается от традиционного для других моделей вызова процедур. Для того, чтобы применить метод к объекту, надо послать ему сообщение типа "примени к себе данный метод" (например, "напечатай себя"). Парадигма пересылки сообщений не всегда используется в объектно-ориентированных базах данных, однако типична для "истинно" ОО-реализаций.

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

Определим здесь два класса верхнего уровня: "Отдел" (табл.5.1) и "Служащий" (табл.5.2). Определим также класс Руководитель (табл.5.3), который является подклассом класса Служащий. Унаследованные свойства и методы показаны курсивом.

Таблица 5.1

Таблица 5.2

Таблица 5.3

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

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

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

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

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

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

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

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