Объектно-ориентированные и реляционно-объектные СУБД. Общая структура и примеры. Постреляционные СУБД. Парадигма NoSQL.

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

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

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

• имеется возможность определения новых типов данных и операций с ними.

В то же время, ОО-модели присущ и ряд недостатков:

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

• вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц с помощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами - расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектно-реляционных СУБД).

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

 ODMG (Object Data Management Group) - консорциум поставщиков ООБД и других заинтересованных организаций, созданный в 1991 г. Его задачей является разработка стандарта на хранение объектов в базах данных. В настоящее время опубликована вторая версия стандарта, которую так и называют ODMG 2.0. Рассмотрим кратко основные положения этого документа.

Стандарт на хранение объектов ODMG 2.0 разработан на основе трех существующих стандартов: управление базами данных (SQL), объекты (стандарты OMG - Object Management Group) и стандарты на объектно-ориентированные языки программирования (C++, Smalltalk, Java).

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

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

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

- методы объектов (поведение)

- множественное наследование

- идентификаторы объектов (ключи)

- определение таких совокупностей объектов как списки, наборы, массивы и т.д.

- блокировка объектов и изоляция доступа

- операции над базой данных

• Язык описания объектов (ODL - Object Defifnition Language) - средство определения схемы базы данных (по аналогии с DDL в реляционных СУБД). ODL является расширением IDL (Interface Definition Language - язык описания интерфейсов) модели OMG и предоставляет средства для определения объектных типов, их атрибутов, связей и методов. ODL создает слой абстрактных описаний так, что схема базы данных становится независима как от языка программирования, так и от СУБД. ODL рассматривает только описание объектных типов данных, не вдаваясь в детали реализации их методов. Это позволяет переносить схему БД между различными ODMG-совместимыми СУБД и языками программирования, а также транслировать ее в другие DDL.

• Язык объектных запросов (OQL - Object Query Language) - SQL - подобный декларативный язык, который предоставляет эффективные средства для извлечения объектов из базы данных, включая высокоуровневые примитивы для наборов объектов и объектных структур. Синтаксис опретора SELECT, определенный SQL-92, является подмножеством OQL, это гарантирует, что SELECT-утверждения, выполняемые над реляционными таблицами, сохранят работоспособность и с наборами объектов ODMG. OQL-запросы могут вызываться из ОО-языка, точно также из OQL-запросов могут делаться обращения к процедурам, написанным на OO-языке. OQL предоставляет средства обеспечения целостности объектов (вызов объектных методов и использование собственных операторов изменения данных).

• Связывание с ОО-языками. Стандарт связывания с C++, Smalltalk и Java определяет Object Manipulation Language (OML) - язык манипулирования объектами, который расширяет базовые ОО-языки средствами манипулирования и хранения объектов. Также включаются OQL, средства навигации и поддержка транзакций. Каждый ОО-язык имеет свой собственный OML, поэтому разработчик остается в одной языковой среде, ему нет необходимости разделять средства программмирования и доступа к данным.

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

В 1991 г. был образован консорциум ODMG (Object Database Management Group ), основной целью которого стала выработка промышленного стандарта объектно-ориентированных баз данных. Последняя версия стандарта имеет индекс 3.0. К концу 90-х существовало около десяти компаний, производящих коммерческие продукты, позиционируемые на рынке как ООСУБД. Наиболее известными системами данного класса стали Objectivity, Versant производства одноименных компаний, а также СУБД Jasmine, выпущенная компанией CA. Несмотря на преимущества, позволяющие более эффективно решать определенный ряд задач, объектно-ориентированные системы так и не смогли завоевать значимую долю рынка СУБД, оставшись «нишевым» продуктом.

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

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

NoSQL – это концепция, предназначенная для осуществления доступа к группированным данным, не использующая реляционную модель данных. Фундаментальные различия кроются в способе осуществлении доступа и актуализации данных, а также их размещении. Например, когда вы должны были бы хранить данные о каком-то счете, то вам требовалась специальная таблица, работа с которой предусматривала знание особого серверного языка для того, чтобы преобразовать эти данные в реальные объекты. Используя NoSQL, вам нужно хранить только данные о счёте.