Преимущества
и недостатки объектно-ориентированных баз данных.
Тяпкин Сергей Владимирович,
соискатель МАТИ
- Российского Государственного Технологического Университета им.
К.Э.Циолковского.
В
настоящее время наиболее популярный подход к организации информационных систем
- это клиент-серверные приложения, в основе которых
лежит взаимодействие с базой данных. В большинстве своем в качестве хранилища
данных используются реляционные базы данных, а приложения, обеспечивающие
интерфейс к базе данных реализованы на основе объектно-ориентированного
программирования. При этом обнаруживается несоответствие, связанное с тем, что
модели данных, использующиеся в программировании, отличаются от моделей данных
СУБД, которое влечет за собой необходимость поддерживать соотношения и
взаимосоответствия между картежами базы данных и объектами в программировании.
Необходимость таких согласований, или импеданс, был принят в качестве платы за
производительность, предоставляемую реляционной организацией данных. Но можно
ли найти другой вариант построения системы, при котором такой платы удастся
избежать?
Объектно-ориентированные
базы данных явились результатом совмещения принципов объектно-ориентированного
программирования и принципов управления базами данных. В одной системе объединены
понятия инкапсуляции, полиморфизма, наследования из объектно-ориентированного
программирования и атомарности, целостности, изоляции из баз данных. В
результате мы имеем возможность управлять большими
объемами информации при помощи объектно-ориентированного подхода.
Объектно-ориентированная
база данных (ООБД) способна хранить объекты в том же виде, в котором они будут
доступны для языка программирования. Это обеспечивается за счет того, что
объекты в ООБД принадлежат классу, имеющему в своем составе набор атрибутов,
выражаемых простыми типами данных или другими классами. К классам применяются
правила наследования, несущие в себе все полагающиеся преимущества:
полиморфизм, переопределение наследованных методов и возможность динамической
привязки.
Каждый
объект класса имеет идентификатор объекта, который используется для
однозначного определения данного объекта в системе. Идентификатор назначается
системой и не зависит от состояния объекта.
В
объектной модели хранение ссылок на другие объекты выглядит достаточно удобным,
но здесь могут возникать другие проблемы, связанные с
ссылочной целостностью. Например, когда объект удаляется, другие объекты могут
иметь ссылку на его идентификатор. Потому система управления
объектно-ориентированными базами данных (СУООБД) должна представлять собой не
только систему, ориентированную на среду разработки ПО, но и систему управления
данными. СУООБД присущи многие черты, характерные для реляционных СУБД, такие
как транзакции, индексы, выявление и разрешение дедлоков, механизмы
восстановления данных.
Основное
преимущество СУООБД в том, что доступ к объектам базы данных организован
достаточно прозрачно и взаимодействие с объектом базы данных не отличается от
взаимодействия с объектом в памяти. В этом состоит основное преимущество перед
СУРБД – нет необходимости использовать язык запросов или 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
2.
Anant Jhingran,
Michael Stonebraker. Alternatives in Complex Object
Representation: A Performance Persrective // 6th Int.
Conf. Data
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,
Поступила в редакцию 5 апреля