Обеспечение доступности объектов в ООБД производится на основе присвоения уникальных имен (ключей) объектам, поскольку OID объектов скрыты для пользователей. Прямое присвоение имени каждому объекту в отдельности не производится, так как БД может состоять из сотен и тысяч объектов, и наличие большого числа сложных имен может только привести к усложнению доступа. Но так как обычно объектно-ориентированная система построена на основе иерархии контейнеров, где одни объекты по крайней мере концептуально содержатся в других (обычно содержатся не сами объекты, а их глобальные уникальные идентификаторы), то имена назначают только базовым объектам либо даже коллекциям объектов. Тогда по ссылкам (OID) можно легко добраться до необходимого объекта. Такой механизм доступа сильно отличается от применяемого в реляционных системах, где все объекты предполагаются постоянными и доступными через значения их потенциальных ключей.
Перманентность объектов, то есть возможность длительного хранения объектов во внешней памяти, может быть реализована тремя различными способами: созданием контрольных точек, сериализацией и явной подкачкой страниц.
В первом способе на диск копируется все адресное пространство программы (или его некоторая часть). В тех случаях, когда копируется все адресное пространство, программу можно вновь запустить с некоторой контрольной точки. Этот подход имеет два серьезных недостатка. Во-первых, контрольная точка может быть использована только той программой, которая ее создала. Во-вторых, на диск копируется множество совершенно ненужной информации.
Во втором способе на диск копируется отдельная иерархия контейнеров объектов. Вначале производится обход связного графа объектов, доступных из выбранного объекта, затем вся эта структура пишется на диск. Но такой подход не позволяет восстанавливать связные структуры данных, которые совместно используют одну и туже подчиненную структуру, при их раздельной записи, так как подчиненная структура после восстановления уже не будет совместной. К тому же сериализация производится сразу большими блоками, что приводит к неэффективному расходу памяти компьютера при сохранении небольших изменений.
Третий способ связан с явным обменом областей оперативной памяти и внешнего устройства. Этот процесс напрямую связан с преобразованием указателей объектов, существующих в оперативной памяти, и указателей на те же объекты в адресном пространстве внешней памяти. Существуют две реализации этого подхода: в первой объект считается перманентным (т.е. сохраняемым) тогда, когда он достижим для перманентного корневого объекта, а во второй он будет перманентным только в том случае, если он явно объявлен перманентным в прикладной программе. В обоих случаях перманентными будут только те объекты, в которых еще на этапе программирования заложена эта возможность. Недостатками такого подхода являются необходимость сборки «мусора» после выполнения программы, так как объект будет перманентным до тех пор, пока не будет явно удален приложением, и необходимость постоянной обработки двух систем указателей. Последний метод можно считать наиболее перспективным, если напрямую включить схемы обеспечения перманентности в базовый язык программирования.
Стандарт ODMG
Совместное использование внешними программами объектов, хранящихся в ООБД, может быть осуществлено только при наличии единого стандарта создания, хранения и использования объектов. Фактически даже отсутствие языка запросов типа SQL, являющимся стандартным языком баз данных, могло бы оказаться серьезной проблемой при использовании ООБД. Растущий интерес к ООБД предопределил появление такого стандарта. Группа ODMG (Object Database Management Group), включающая ряд ведущих производителей программного обеспечения, разработала стандарт объектно-ориентированной модели данных, который используется в ООБД.
Этот стандарт состоит из следующих частей:
· Объектной модели;
· Языка определения объектов (object definition language – ODL);
· Объектного языка запросов (object query language – OQL);
· Расширения объектно-ориентированных языков программирования (C++, Java, Smalltalk, …).
Объектная модель и язык определения объектов стандартизирует ключевые слова, типы данных, их конструкторы и т.д., наряду с механизмами идентификации, связывания, именования, обеспечения доступности и перманентности объектов. К примеру, этот стандарт рекомендует применение только инверсных связей на основе OID и вводит такие ключевые слова как attribute, key, relationship, extent и т.д. Объектный язык запросов представляет собой расширение существующих ООЯП. Синтаксис его похож на SQL и дополнен объектно-ориентированными концепциями наследования, инкапсуляции и полиморфизма. Например, представим определение двух классов, лежащих в основе структуры данных ООБД некоторого университета:
class Person (extent persons, key ssn) {
attribute struct Pname { string fname, string mname, string (name } name;
attribute string ssn;
attribute date birthdate;
attribute enum Gender{M, F) sex;
attribute struct Address { short no, string street, short aptno, string city, string state,
short zip} address;
short age(); };
class Student extends Person(extent students) {
attribute string class;
attribute Department minors_in;
relationship Department majors_in inverse Department::has_majors;
relationship set <Grade> completed_sections inverse Grade::student;
void change_major(in string dname) raises (dname_not_valid);
float gpa();
void register(in short secno) raises (section_not_valid);
void assign_grade(in short secno; in GradeValue grade)
raises (section_not_valid, grade_not_valid); };
и саму структуру (смотри 3)
Рис. 2.14. Структура данных ООБД университета
Примером ООБД можно считать СУБД OpenODB (Hewlett Packard), O2 (Ardent Software) и Object Store (Object Design).
