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

Соответствующие изменения реляционной модели обусловили необходимость расширения стандарта языка запросов SQL. Первый вариант такого стандарта получил название SQL3. Работа над стандартом продолжается и в настоящее время.

В качестве примера в максимальной степени объектно-ориентированной СУБД можно указать исследовательскую СУБД Postgres{3].

Отметим считающиеся объектными расширениями элементы СУБД Microsoft Server 2008.

· Пользовательские расширения. Пользователи имеют возможность вмешиваться в изначально предоставляемый СУБД инструментарий, создавая, в частности, новые пользовательские типы данных.

· Хранение больших объемов данных . Наряду с теми данными, которые хранились в БД традиционно, Microsoft SQL Server 2008 позволяет хранить в столбцах таблицы данные больших размеров (поддерживаются соответствующие типы данных).

· Новые, ориентированные на определенные классы объектов, типы данных . В системе определены новые типы данных (geometry, geography), характерные для тех направлений, в которых объектно-ориентированный подход весьма эффективен и часто используется (картография и соответствующие приложения, геометрическое представление объектов самой разной природы).

· Хранимые процедуры. В определенном смысле хранимые процедуры также являются объектным расширением, осуществляя необходимые пользователю воздействия на данные (стандартный для ООП процедурный подход).

2. Распределенные базы данных

База данных – интегрированная совокупность данных, с которой работают много пользователей. Изложение всех предыдущих разделов предполагало единую базу данных, размещаемую на одном компьютере. Напомним основные принципы, положенные в основу теории баз данных:

· централизованное хранение данных;

· централизованное обслуживание данных (ввод, корректировка, чтение, контроль целостности).

Заметим, что базы данных появились в период господства больших ЭВМ. База данных велась на одной ЭВМ, все пользователи работали именно на ЭВМ (возможные режимы работы описаны в лекции 3). Других вариантов использования вычислительной техники в то время просто не существовало. Если проанализировать работу пользователей с данными в компаниях, организациях, предприятиях в «докомпьютерное» время, то нетрудно заметить, что на отдельных участках пользователи работали со «своими» данными (осуществляли сбор определенных данных, их хранение, обработку, передачу обработанных данных на другие участки или уровни управления).

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

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

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

Распределенная база данных – совокупность логически взаимосвязанных разделяемых данных (и описаний их структур), физически распределенных в компьютерной сети.

ВЛАДИМИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Имени Александра Григорьевича и Николая Григорьевича Столетовых

КАФЕДРА БИЗНЕС-ИНФОРМАТИКИ И ЭКОНОМИКИ

РЕФЕРАТ

по дисциплине «Базы данных»

на тему: «Объектно-ориентированные модели данных»

Выполнила:

студентка 3-го курса

группы БИ-114

Фадеева А.А.

Принял:

ст. пр. Виноградов Д.В.

Владимир 2016

Введение. 3

Общая характеристика объектно-ориентированных моделей данных. 4

Объектно-реляционная модель данных. 5

Пространственная модель данных. 8

Список литературы.. 13

Введение

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

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

Общая характеристика объектно-ориентированных моделей данных

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

При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:

· встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;

· расширение существующего языка работы с базами данных объектно-ориентированными функциями;

· создание объектно-ориентированных библиотек функций для работы с БД;

· создание нового языка и новой объектно-ориентированной модели данных.

К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.

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

В 2000 г. рабочая группа ODMG (Object Database Management Group), образованная фирмами-производителями ООСУБД, выпустила очередной стандарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации заключается в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содержится текст стандарта.

Объектно-реляционная модель данных

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

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

Такой подход был популярен в конце 80-х гг. и воплотился в программных продуктах для автоматизации программирования (CASE), для автоматизации проектирования (CAD), в репозитариях (БД, предназначенных для хранения не пользовательских, а системных данных).

2. Внутренние реляционные механизмы СУБД управления данными расширяются объектно-ориентированными возможностями (расширенный реляционный подход).

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

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

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

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

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

· классы объектов в объектно-реляционной БД соответствую таблицы

· объекты будут соответствовать отдельным записям в таблице

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

· первичный ключ в таблице является идентификатором объекта

· каждый объект может собираться из записей нескольких таблиц базового класса и наследников

Базовый класс объектов должен уметь выполнять основные действия с единичным экземпляром объекта: создание, загрузка, сохранение, удаление. Базовый класс должен обеспечивать возможность изменения и удаления сразу множества объектов.

К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).

Сегодня практически все известные фирмы используют объектные технологии. IBM и Oracle доработали свои СУБД (DB2 и ORACLE8, соответственно, добавив объектную надстройку над реляционным ядром системы, т.е. преобразовали их в объектно-реляционные СУБД. Informix приобрела объектно-реляционную СУБД Illustra и встроила ее в свою СУБД, изменив ее название на универсальный сервер.

Объектно-реляционная модель данных

Другие модели данных

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

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

К сожалению, до настоящего времени разработчики не пришли к единому мнению о том, что должна обеспечивать ОРМД. В 1999 г. был принят стандарт SQL-99, а в 2003 г. вышел второй релиз этого стандарта, получивший название SQL-3, который определяет основные характеристики ОРМД. Но до сих пор объектно-реляционные модели, поддерживаемые различными производителями СУБД, существенно отличаются друг от друга. О перспективах этого направления свидетельствует тот факт, что ведущие фирмы–производители СУБД, в числе которых Oracle, Informix, INGRES и др., расширили возможности своих продуктов до объектно-реляционной СУБД (ОРСУБД).

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

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

При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:

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

К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.

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

В 2000 г. рабочая группа ODMG (Object Database Management Group), образованная фирмами-производителями ООСУБД, выпустила очередной стандарт (ODMG 3.0) для ООСУБД, в котором описана объектная модель, язык определения запросов, язык объектных запросов и связующие языки С++, Smalltalk и Java. Стандарты ODMG не являются официальными. Подход ODMG к стандартизации заключается в том, что после принятия очередной версии стандарта организациями-членами ODMG публикуется книга, в которой содержится текст стандарта.

Теперь рассмотрим, как поддержка моделей данных реализована в реальных системах управления базами данных.

Объектно-ориентированная

Постреляционная модель

Достоинства и недостатки реляционной модели данных

Главные достоинства реляционной модели данных – она проста для понимания, наглядна и имеет строгое математическое обоснование.

Недостатки следующие:

· реляционная модель данных не допускает представления объектов со сложной структурой, поскольку в ее рамках возможно моделирование лишь с помощью двумерных таблиц;

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

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

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

То есть, допускаются многозначные поля, значения которых состоят из подзначений. Пример постреляционной модели – таблица, представляющая собой совокупность данных связанных реляционных таблиц КЛИЕНТЫ и ЗАКАЗЫ.

Достоинства постреляционной модели данных:

· возможность представления связанных реляционных таблиц одной постреляционнной таблицей. Это обеспечивает высокую наглядность представления данных и повышение эффективности их обработки;

· отсутствие ограничений на длину полей и их количество в записях таблицы.

Недостаток постреляционнной модели – сложность в обеспечении целостности данных.

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

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

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

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

Для выполнения действий над объектами применяются объектно-ориентированные механизмы – наследование, инкапсуляция, полиморфизм.

Суть наследования состоит в том, что на основе существующего класса можно образовать новый класс объектов, который будет наследоватьсвойствародительского класса.

Доступ к данным осуществляется только лишь в соответствии с правилами поведения объекта, описываемыми методами(инкапсуляция ).

Полиморфизм – способность объектов по-разному реагировать на одно и тоже событие в окружающем мире. Полиморфизм используется для унификации обработки разнородных объектов. Н–р, метод «Печать результата» может быть определен для многих классов объектов, но работать по-разному, в зависимости от класса, к которому он применяется.

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

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

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

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

Такой подход был популярен в конце 80-х гг. и воплотился в программных продуктах для автоматизации программирования (CASE), для автоматизации проектирования (CAD), в репозитариях (БД, предназначенных для хранения не пользовательских, а системных данных).

2. Внутренние реляционные механизмы СУБД управления данными расширяются объектно-ориентированными возможностями (расширенный реляционный подход ).

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

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

12 мая 2010 в 14:04

Реляционные БД vs Объектно-ориентированные БД

• Разработка веб-сайтов

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

Предыстория

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

Влияние ORM

По моему скромному мнению использование ORM надстроек только тормозит развитие ООБД. Постараюсь пояснить это достаточно спорное утверждение. Я не считаю, что ORM это зло, но и абсолютным добром она тоже не является. Технология ORM несомненно сыграла (да и сейчас играет) важную роль в развитии средств разработки, она показала, что программист на самом деле может и не заботиться о логике хранения данных. Однако здесь, как и везде есть свои «НО».

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

Однако об оптимизации никто не думает в момент написания первой (а зачастую и второй, и третьей) версии продукта. Для большинства контор сейчас главным фактором является не качество, а скорость разработки. Оно и понятно: изначально заказчик хочет получить продукт как можно раньше, затратив минимум денег. И только спустя некоторое время, когда база наполнится реальными данными, пройдет пару месяцев, заказчик (да и разработчик тоже) с удивлением обнаруживает, что время выборок увеличилась почти вдвое, при работе 10-20 пользователей одновременно СУБД пытается покончить жизнь самоубийством и т.д. и т.п. Разработчик часто руководствуется восточной мудростью: А там уже либо ишак сдохнет, либо султан, либо сам Ходжа . Но, если никто не сдох, то вот тут-то разработчик и начинает искать узкие места, выдирает из ORM автоматически сгенерированные запросы, переписывает их руками, перестраивает индексы в таблицах БД и тратит на это и подобную оптимизацию еще уйму времени и сил.

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

Реляционные БД vs ООБД

Не смотря на огромную популярность парадигмы ООП в программировании, в технологии разработки баз данных эта парадигма пока не особо популярна. И тому есть как объективные, так и субъективные причины.

• Популярность. Под реляционные базы создано множество замечательных продуктов, которые необходимо поддерживать и развивать. В эти продукты уже вложены большие деньги и заказчики готовы еще вкладывать деньги в их развитие. Напротив, с использованием ООБД разработано сравнительно мало серьезных коммерческих продуктов, существует мало мощных ООСУБД.
• Язык запросов и его стандартизация. Еще в далеком 1986 году был принят первый стандарт SQL-86, который определил всю судьбу реляционных БД. После принятия стандарта все разработчики реляционных СУБД обязаны были следовать ему. Для объектно-ориентированных баз данных пока стандарта языка запросов нет. Сейчас среди разработчиков даже нет единого мнения о том, что этот язык запросов должен делать, не говоря уже о том, как он это должен делать.
• Математический аппарат. Для реляционных БД в свое время Эдгар Кодд заложил фундамент математического аппарата реляционной алгебры. Этот мат. аппарат объясняет, как должны выполняться основные операции над отношениями в базе данных, доказывает их оптимальность (либо из него видно, где надо оптимизировать). С другой стороны для ООБД нет такого аппарата, даже не смотря на то, что работы в этой области ведутся с 80-х годов. Таким образом, в ООБД пока нет строгих терминов, таких как декартово произведение, отношение и т.д.
• Проблема хранения данных и методов. В реляционных БД хранятся только голые данные. Что с ними будет делать приложение, зависит уже от приложения. В ООБД же, напротив должны храниться объекты, а объект это совокупность его свойств (параметры объекта) и методов (интерфейс объекта). Здесь так же нет единого мнения, как ООБД должна осуществлять хранение объектов и как разработчик должен эти объекты разрабатывать и проектировать. Здесь же возникает и проблема хранения иерархии объектов, хранение абстрактных классов и т.п.

Выводы и перспективы

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

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

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