Преимущества и недостатки объектно-ориентированных баз данных

Размещено на http://www.allbest.ru/

Статья по теме:

Преимущества и недостатки объектно-ориентированных баз данных

Тяпкин Сергей Владимирович, соискатель МАТИ - Российского Государственного Технологического Университета им. К.Э. Циолковского

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

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

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

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

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

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

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

Ниже приведен список преимуществ и недостатков при использовании связки СУООБД или СУРБД с объектно-ориентированным программированием.

Преимущества:

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

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

3. Для доступа к данным из СУООБД не обязателен отдельный язык запросов, поскольку доступ происходит непосредственно к объектам. Тем не менее, возможность использовать запросы существует.

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

Недостатки:

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

2. СУООБД обычно привязана к отдельному языку с помощью отдельного АПИ и данные доступны только через этот АПИ. СУРБД в этом плане имеет большие возможности, благодаря общему языку запросов.

3. В СУРБД, реляционная природа данных позволяет конструировать ad-hoc запросы, где можно объединять различные таблицы. В СУООБД невозможно дублировать семантику соединения двух таблиц соединением двух классов, поэтому в данном случае СУООБД уступает СУРБД в гибкости. Запросы, которые могут исполняться над данными в СУООБД, в большей мере зависят от дизайна системы.

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

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

Литература

база данные программирование управление

1. Mohammad A. Ketabchi, Valdis Berzins. Mathematical Model of Composite Objects and Its Application for Organizing Engineering Databases // IEEE Trans. on Software Eng.- 14, N 1.- 1988.- 71-84

2. Anant Jhingran, Michael Stonebraker. Alternatives in Complex Object Representation: A Performance Persrective // 6th Int. Conf. Data Eng., LosAngeles, Calif., USA, Febr. 5-9, 1990.- 94-102

3. E. F. Codd. A Relational Model of Data for Large Shared Data Banks // Commun. ACM.- 26, N 1.- 1970.- 377-387

4. Francois Bancilhon. Query Languages for Object-Oriented Database Systems: Analysis and Proposal // Datanbanksyst. Buro, Tech. and Wiss.: GI/SI - Fashtag., Zurich, Marz. 1-3, 1989.- 1-18

5. Serge Abiteboul, Richard Hull. IFO: A Formal Semantic Database Model // ACM Trans. Database Syst.- 12, N 4.- 1987.- 525-565

6. D. Maier. Why isn't there an Object-Oriented Data Model? // Technical Report, Oregon Graduate Center, May 1989.

Размещено на Allbest.ru