ISSN 1991-3087
Рейтинг@Mail.ru Rambler's Top100
Яндекс.Метрика

НА ГЛАВНУЮ

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

 

Тяпкин Сергей Владимирович,

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

 

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

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

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

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

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

Основное преимущество СУООБД в том, что доступ к объектам базы данных организован достаточно прозрачно и взаимодействие с объектом базы данных не отличается от взаимодействия с объектом в памяти. В этом состоит основное преимущество перед СУРБД – нет необходимости использовать язык запросов или 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., Los Angeles, 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.

 

Поступила в редакцию 5 апреля 2007 г.

2006-2019 © Журнал научных публикаций аспирантов и докторантов.
Все материалы, размещенные на данном сайте, охраняются авторским правом. При использовании материалов сайта активная ссылка на первоисточник обязательна.