СУБД Oracle, можно с успехом использовать вомногих областях, например в качестве
связующего ПО, объединяющего объектно-ориентированные приложения с реляционными
СУБД.
Объектно-реляционные шлюзы. При использовании такого метода пользователь
взаимодействует с БДпри помощи языка ООСУБД, а шлюз заменяет все
объектно-ориентированные элементы этого языка на их реляционные компоненты. За
это опять приходитьсярасплачиваться производительностью. Например, шлюз должен
преобразовать объекты в набор связей, сгенерировать оригинальные идентификаторы
(original identifier – OID) объектов и передать этов реляционную БД. Затем шлюз
должен каждый раз, когда используется интерфейс реляционной СУБД,
преобразовывать OID, найденный в базе, в соответствующий объект, сохраненный
вРСУБД.
Производительность в рассмотренных двух подходах зависит от способа доступа к
реляционной базе данных. Каждая РСУБД состоит из двухуровней: уровня управления
данными (data manager layer) и уровня управления носителем (storage manager
layer). Первый из нихобрабатывает операторы на языке SQL, а второй отображает
данные в базу. Шлюз или адаптер могут взаимодействовать какс уровнем данных (то
есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя
(вызовамипроцедур низкого уровня). Производительность в первом случае намного
ниже (например, система OpenODBфирмы Hewlett-Packard, которая может выполнять
роль шлюза, поддерживает только на высоком уровне).
Гибридные СУБД. Еще одним решением может стать создание гибридных
объектно-реляционных СУБД,которые могут хранить и традиционные табличные данные,
и объекты. Многие аналитики считают, что будущее за такими гибридными БД.
Ведущие поставщикиреляционных СУБД начинают (или планируют) добавлять к своим
продуктам объектно-ориентированные средства. В частности, Sybase и Informix
собираются в следующих версияхСУБД ввести поддержку объектов. Подобные
разработки намерены вести и независимые фирмы. Например, компания Shores
готовится оснастить объектно-ориентированными средствамиСУБД Oracle8, выпуск
которой намечен на конец 1996 г.
С другой стороны, производители объектных СУБД, такие как компания Object
Design,сознают, что объектно-ориентированные базы данных в обозримом будущем не
заменят реляционные СУБД. Это вынуждает их создавать шлюзы для
поддержкиреляционных и иерархических баз данных иди различного рода интерфейсы,
характерным примером которых является объектно-реляционный интерфейс Ontos
Integration Server фирмы Ontos, применяемый всочетании с ее ООБД Ontos/DB.
5. Объектно-ориентированные базы данных.
5.1Why ODBMS?
“Белыми книгами” с названием, вынесенным в заголовок, с избытком снабдит любая
компания, занимающаяся объектными базами данных. Кое-чтоо преимуществах и
недостатках объектно-ориентированных СУБД уже упоминалось выше, подведем в таком
случае итог.
Объектно-ориентированные базы данных применяются с конца 1980-х для обеспечения
управления базами данных приложениями, построенными всоответствии с концепцией
объектно-ориентированного программирования. Объектная технология расширяет
традиционную методику разработки приложений новыммоделированием данных и
методами программирования. Для повторного использования кода и улучшения
сохранности целостности данных в объектном программированииданные и код для их
обработки организованы в объекты. Таким образом, практически полностью снимаются
ограничения на типы данных.
Если данные состоят из коротких, простых полей фиксированной длины (имя, адрес,
баланс банковского счета), то лучшим решением будетприменение реляционной базы
данных. Если, однако, данные содержат вложенную структуру, динамически
изменяемый размер, определяемые пользователемпроизвольные структуры
(мультимедиа, например), представление их в табличной форме будет, как минимум,
непростым. В то же время в ООСУБД каждая определеннаяпользователем структура –
это объект, непосредственно управляемый базой данных.
В РСУБД связи управляются пользователем, создающим внешние ключи. Затем для
обнаружения связей динамически во время выполнения системапросматривает две (или
больше) таблицы, сравнивая внешние ключи до достижения соответствия. Этот
процесс, называемый объединением (join), является слабой сторонойреляционной
технологии. Более двух или трех уровней объединений – сигнал, чтобы искать
лучшее решение. В ООСУБД пользователь просто объявляет связь, и
СУБДавтоматически генерирует методы управления, динамически создавая, удаляя и
пересекая связи. Ссылки при этом прямые, нет необходимости в просмотре
исравнении или даже поиске индекса, который может сильно сказаться на
производительности. Таким образом, применение объектной модели
предпочтительнеедля баз данных с большим количеством сложных связей:
перекрестных ссылок, ссылок, связывающих несколько объектов с несколькими
(many-to-many relationships)двунаправленными ссылками.
В отличие от реляционных, ООСУБД полностью поддерживают объектно-ориентированные
языки программирования. Разработчики, применяющие С++или Smalltalk, имеют дело с
одним набором правил (позволяющих использовать такие преимуществаобъектной
технологии, как наследование, инкапсуляция и полиморфизм). Разработчик не должен
прибегать к трансляцииобъектной модели в реляционную и обратно. Прикладные
программы обращаются и функционируют с объектами, сохраненными в базе данных,
которая используетстандартную объектно-ориентированную семантику языка и
операции. Напротив, реляционная база данных требует, чтобы разработчик
транслировал объектнуюмодель к поддерживаемой модели данных и включил
подпрограммы, чтобы обеспечить это отображение во время выполнения. Следствием
являются дополнительные усилияпри разработке и уменьшение эффективности.
И, наконец, ООСУБД подходят (опять же без трансляций между объектной и
реляционной моделями) для организации распределенных вычислений.Традиционные
базы данных (в том числе и реляционные и некоторые объектные) построены вокруг
центрального сервера, выполняющего все операции над базой. Посуществу, эта
модель мало отличается от мэйнфреймовой организации 60‑х годов с центральной ЭВМ
– мэйнфреймом (mainframe), выполняющей все вычисления, и пассивных
терминалов.Такая архитектура имеет ряд недостатков, главным из которых является
вопрос масштабируемости. В настоящее время рабочие станции (клиенты)
имеютвычислительную мощность порядка 30 ‑ 50 % мощности сервера базы данных, то
есть большая часть вычислительных ресурсов распределена среди клиентов.Поэтому
все больше приложений, и в первую очередь базы данных и средства принятия
решений, работают в распределенных средах, в которых объекты(объектные
программные компоненты) распределены по многим рабочим станциям и серверам и где
любой пользователь может получить доступ к любому объекту.Благодаря стандартам
межкомпонентного взаимодействия (об этом позже) все эти фрагменты кода
комбинируются друг с другом независимо от аппаратного,программного обеспечения,
операционных систем, сетей, компиляторов, языков программирования, различных
средств организации запросов и формирования отчетови динамически изменяются при
манипулировании объектами без потери работоспособности.
5.2 Спорныемоменты технологии.
Все ООСУБД по определению поддерживают сохранение и разделение объектов. Но,
когда дело доходит до практической разработкиприложений на разных ООСУБД,
проявляется множество отличий в реализации поддержки трех характеристик:
Целостность;
Масштабируемость;
Отказоустойчивость.
Отметим, что ООБД не требуют многих из тех внутренних функций и механизмов,
которые столь привычны и необходимы в реляционных БД.Например, при небольшом
числе пользователей, длинных транзакциях и незначительной загрузке сервера
объектные СУБД не нуждаются в поддержке сложных механизмоврезервного
копирования/восстановления (исторически сложилось так, что первые ООБД
проектировались для поддержки небольших рабочих групп – порядка десятичеловек –
и не были приспособлены для обслуживания сотен пользователей). Тем не менее
технология БД определенно созрела для крупных проектов.
Дляиллюстрации первой категории рассмотрим механизм кэширования объектов.
Большинство объектных СУБД помещают код приложения непосредственно в то
жеадресное пространство, где работает сама СУБД. Благодаря этому достигается
повышение производительности часто в 10‑100раз по сравнению с раздельными
адресными пространствами. Но при такой модели объект с ошибкой может повредить
объекты и разрушить базу данных.
Существуют два подхода к организации реакции СУБД для предотвращения потери
данных.Большинство систем передают приложению указатели на объекты, и рано или
поздно такие указатели обязательно становятся неверными. Так, они всегда
неправильныпосле перехода объекта к другому пользователю (например, после
перемещения на другой сервер). Если программист, разрабатывающий приложение,
пунктуален, тоошибки не возникает. Если же приложение попытается применить
указатель в неподходящий для этого момент, то в лучшем случае произойдет крах
системы, вхудшем – будет утеряна информация в середине другого объекта и
нарушится целостность базы данных.
Есть метод, лучший, чем использование прямых указателей (Рисунок 3). СУБД
добавляетдополнительный указатель и при необходимости, если объект перемещается,
система может автоматически разрешить ситуацию (перезагрузить, если это
необходимо,объект) без возникновения конфликтной ситуации.