Понятно, что ограничением ненормализованных реляционных баз данных является обязательность иерархической организации хранимой информации. Конечно, это совсем другой уровень построения информации, чем тот, который поддерживался в дореляционных иерархических системах. Между элементами данных отсутствуют явно проводимые физические ссылки. Упрощена процедура реструктуризации данных (в частности, в ненормализованной реляционной модели предполагается наличие пары операций nest/unnest, позволяющих сделать существующую таблицу элементом, хранимым в столбце другой таблицы, или "вытянуть" на верхний уровень некоторую вложенную таблицу). Тем не менее, общая структура остается иерархической. Во многих случаях этого достаточно (в частности, для решения проблемы, упоминавшегося выше примера Эстер Дайсон).

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

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

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

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

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

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

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

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

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

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

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

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

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