2. Предпосылки появления объектно-ориентированных субд

В середине 70-х годов XX века начали рождаться новые идеи, которые привели впоследствии к формированию объектного подхода в технологиях баз данных.

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

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

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

Дело в том, что одним из основных положений реляционной модели данных является требование нормализации отношений: поля кортежей могут содержать лишь атомарные значения, то есть, по существу, требование примитивности структур данных, лежащих в основе реляционной модели. Для традиционных приложений реляционных СУБД (РСУБД) - банковских систем, систем резервирования (билетов, посадочных мест и т.д.) - это вовсе не ограничение, а даже преимущество, позволяющее проектировать экономные по памяти БД с предельно простой и понятной структурой. Запросы с соединениями в таких системах сравнительно редки, для динамической поддержки целостности используются соответствующие средства SQL. Заметим, что плоские нормализованные отношения универсальны и теоретически достаточны для представления данных любой предметной области.

Однако такой подход является весьма неестественным при управлении наборами данных или данными, которые необходимо описать с большей степенью детализации. Допустим, в столбце Адрес таблицы СЛУЖАЩИЙ может быть указан полный домашний адрес, причем различные приложения могут обрабатывать различные компоненты адресов. Однако РСУБД будет трактовать данные столбца Адрес как единое целое (строку символов), не замечая компонентные элементы данных; поэтому либо каждому приложению придется распаковывать содержимое поля, либо, что более соответствует духу реляционной модели, для каждой компоненты адреса будет выделен отдельный столбец.

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

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

3. Проблема, название которой можно перевести как импеданс (или расхождение) моделей. Она выражается в том, что модель данных, используемая в приложении, отличается от модели данных базы данных. Это различие, в свою очередь, приводит к двум проблемам в приложениях, в результате которых и возникает расхождение:

• Программист, разрабатывающий приложение, должен оперировать двумя различными языками программирования, с различным синтаксисом, семантикой и типами систем, а именно, прикладным языком программирования (например, Си++) и языком манипулирования базами данных (то есть, SQL). Логика приложения реализуется средствами прикладного языка, в то время как SQL используется для создания и манипулирования данными в базе.

• При извлечении данных из реляционной базы, они должны быть переведены из представления, в котором они там хранились, в представление, соответствующее представлению данных в памяти, характерному для данного приложения. Аналогично, все обновления данных должны быть переданы базе данных при помощи другого предложения SQL, то есть требуется еще одно преобразование из представления, используемого в приложении, в представление базы данных. Весь обмен данными между базой данных и приложением приводит к ненужной дополнительной обработке, которой можно было бы избежать, будь модели данных приложения и базы данных одинаковыми.