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

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

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

– возможность разбить систему на совокупность независимых сущностей (объек­тов) и провести их строгую независимую спецификацию;

– простота эволюции системы за счет использования таких элементов объектно­го подхода как наследование и полиморфизм;

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

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

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

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

Не нашли, что искали? Воспользуйтесь поиском: