Оглавление 
 
 

   Введение

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

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

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

   1. Общие понятия объектно-ориентированного подхода и их преломление в ООБД

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

   В наиболее общей и классической постановке объектно-ориентированный подход базируется на концепциях:

• объекта и идентификатора объекта;
• атрибутов и методов;
• классов;
• иерархии и наследования классов.

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

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

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

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

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

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

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

   2. Потенциал объектно-ориентированных баз данных

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

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

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

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

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

   Еще один источник технологического скачка - мощные средства конструирования типов данных, подразумеваемые объектно-ориентированным подходом. Эти средства устраняют недостатки, существующие в РБД.

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

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

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

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

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

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

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