ТЕМА 6 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ БАЗЫ ДАННЫX

      6.1 Основные понятия и определения

      История развития компьютерной техники – это история непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. Если первые машины требовали от пользователя написания программ в машинных кодах, то языки программирования четвертого уровня (4GLs) позволяют конечным пользователям, не являющимся профессиональными программистами, получать доступ к информации без детального описания каждого шага, но только со встроенными предопределенными типами данных – например, таблицами.
      Аналогичная картина наблюдалась и в области создания баз данных: начиная с модели записей и индексов (ISAM и др.), приобретая со временем способность восстановления после сбоев, проверки целостности данных и возможности работы нескольких пользователей одновременно. Самые ранние модели данных (CODASYL) относились к уровню машинной ориентации. Пришедшие им на смену в 1980-х годах реляционные базы данных, приобрели механизм запросов, позволяющий пользователю указать требуемое качество, предоставив СУБД самой оптимальным образом найти результат, используя динамическую индексацию. Процесс эволюции программного обеспечения баз данных наглядно представлен на рисунке 7.1.

      Следующим шагом на пути совершенствования систем управления базами данных стали объектно-ориентированные системы управления базами данных (ООСУБД), которые создавались  с середины 80‑х годов в основном для поддержки приложений систем автоматизированного проектирования (САПР). Сложные структуры данных САПР, оказалось, очень удобно оформлять в виде объектов, а технические чертежи проще хранить в базе данных, чем в файлах. Это позволило обойтись без разделения (декомпозиции) графических структур  на элементы и записи их в файлы, когда работы над чертежом были завершены, и требовалось  выполнение обратной операции для внесения какого-либо изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для «сборки» результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР.
      Между тем рынок САПР был быстро насыщен, и в начале 90‑х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (database administrator – DBA), средствами резервного копирования/восстановления и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно сказать, что переход к коммерческим приложениям идет достаточно успешно. Для перехода к рассмотрению ООСУБД вначале выделим основные достоинства и недостатки реляционных БД.

      6.2 Достоинства и недостатки реляционных баз данных

Достоинства Реляционных баз данных:

• разделение таблиц разными программами;
• развернутый «код возврата» при ошибках;
• высокая скорость обработки запросов (команда SELECT языка SQL);
• результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию;      
• сама концепция объектных баз данных довольно сложна и требует от программистов серьезного и длительного обучения;
• относительно высокая скорость при работе с большими объемами данных.

      Недостатки реляционных БД:

• нельзя добавлять новые типы данных;
• каждая строка в таблице соответствует одной записи;
• имена элементов внутри таблицы должны быть уникальными;
• высокая трудоемкость манипулирования информацией и изменения связей;
• во всем мире значительные средства уже инвестированы в реляционные СУБД

      Поэтому многие пользователи заинтересованы в комбинированном подходе, который позволил бы им воспользоваться достоинствами объектных баз данных, не отказываясь полностью от своих реляционных БД. Такие решения действительно существуют.

      6.3 Сочетание реляционных БД с другими методами представления данных

      1.Объектно-реляционные методыиспользуются, если переход от реляционной базы данных к объектной базе обходится слишком дорого. Суть метода состоит в применении объектной БД в качестве расширения и дополнения реляционной СУБД. Такое компромиссное решение обеспечивает экономический баланс между объектами и реляционными таблицами.
      2.Объектно-реляционный адаптер - этот метод позволяет автоматически выделить программные объекты и сохранить их в реляционных базах данных. Несмотря на некоторое снижение производительности, такой вариант позволяет программистам целиком сконцентрироваться на объектно-ориентированной разработке. Кроме того, все имеющиеся на предприятии приложения по-прежнему могут обращаться к данным, хранящимся в реляционной форме. Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут сами играть роль мощного объектно-реляционного адаптера, позволяя объектно-ориентиро-ванным приложениям обращаться к реляционным БД.
      Объектно-реляционные адаптеры, такие как Adapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего ПО, объединяющего объектно-ориентированные приложения с реляционными СУБД.
      3.Объектно-реляционные шлюзы, позволяют заменить элементы объектно-ориентиро-ванной БД, компонентами реляционной базы данных. Но это приводит к снижению производительности работы системы, так как шлюз должен преобразовать объекты в набор связей, сгенерировать оригинальные идентификаторы (original identifier – OID) объектов и передать это в реляционную БД. Затем шлюз должен каждый раз, когда используется интерфейс реляционной СУБД, преобразовывать OID, найденный в базе, в соответствующий объект, сохраненный в распределённой СУБД.
      Распределённая СУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Объектно-реляционный шлюз может взаимодействовать как с уровнем данных, то есть обращаться к распределенной СУБД при помощи языка программирования SQL, так и с уровнем носителя, путем вызовами процедур низкого уровня. За счет этого производительность системы будет больше, чем в варианте с объектно-реляционным адаптером. Например, система OpenODB фирмы Hewlett-Packard, которая может играть роль шлюза, поддерживается только на высоком уровне.
      4. Гибридные СУБД - могут хранить и традиционные табличные данные, и объекты. Как предполагают аналитики будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД добавляют к своим продуктам объектно-ориентированные средства. В частности, Sybase и Informix в своих разработках ввели поддержку объектов. Например, компания Shores выпустила в 1996 г. Oracle8, оснастив его  объектно-ориентированными средствами СУБД.
      С другой стороны, производители объектных СУБД, такие как компания Object Design, сознают, что объектно-ориентированные базы данных в обозримом будущем не заменят реляционные СУБД. Это вынуждает их создавать шлюзы для поддержки реляционных и иерархических баз данных или различного рода интерфейсы, характерным примером которых является объектно-реляционный интерфейс Ontos Integration Server фирмы Ontos, применяемый в сочетании с ООСУБД Ontos/DB.

      6.4 Объектно-ориентированные базы данных

      Объектно-ориентированные базы данных применяются с конца восьмидесятых годов двадцатого столетия в соответствии с концепцией объектно-ориентированного программирования. Объектная технология расширяет традиционную методику разработки приложений новым моделированием данных и методами программирования. Для повторного использования кода и улучшения сохранности целостности данных в объектном программировании, данные и код для их обработки организованы в объекты. Таким образом, практически полностью снимаются ограничения на типы данных.
      В распределенных СУБД связи управляются пользователем, создающим внешние ключи. Затем для обнаружения связей динамически во время выполнения система просматривает две (или больше) таблицы, сравнивая внешние ключи до достижения соответствия. Этот процесс, называемый объединением (join), является слабой стороной реляционной технологии. Более двух или трех уровней объединений – сигнал, чтобы искать лучшее решение. В объектно-ориентированной СУБД (ООСУБД) пользователь просто объявляет связь, и система автоматически генерирует методы управления, динамически создавая, удаляя и пересекая связи. В процессе работы системы создаются только прямые ссылки, поэтому нет необходимости в просмотре, сравнении и даже поиске индекса, который может сильно сказаться на производительности. Таким образом, применение объектной модели предпочтительнее для баз данных с большим количеством сложных связей: перекрестных ссылок, ссылок, связывающих несколько объектов с несколькими (many-to-many relationships) двунаправленными ссылками, а также, если данные содержат вложенную структуру, динамически изменяемый размер, определяемые пользователем произвольные структуры (мультимедиа, например).  В то же время в ООСУБД каждая определенная пользова­телем структура–это объект, непосредственно управляемый базой данных.
      В отличие от реляционных баз данных, ООСУБД полностью поддерживают объектно-ориентированные языки программирования. Разработчики, применяющие С++ или Smalltalk, имеют дело с одним набором принципов их создания.

      6.5 Описание объекта в объектно-ориентированной базе данных

      При разработке объектно-ориентированной базы данных используют термин объект, под которым понимается аналог в реальном мире, представленный в БД через проекцию своих свойств. При внесении в БД значений свойств конкретного объекта создается экземпляр описания именно этого объекта. Проекции свойств объекта вносятся в БД с некоторой долей их упрощения. Например, чтобы описать в БД понятие человек, достаточно описать его свойства: фамилию, имя, отчество, дату рождении, номер и серию паспорта и страхового свидетельства и др. данные, однако, вовсе необязательно указывать его ДНК и описывать внутреннее строение. Таким образом, производится отбор свойств объекта и их упрощение.  Для описания объекта отбираются не самые «правильные» характеристики объекта, а те, которые достаточны для моделирования нашего представления о нем в БД. Наиболее точным термином, определяющим описание объекта, является тип данных. Тип данных - это описание объекта реального мира в базе данных. То же самое можно сказать и о методе, т.к. нам неважно как человек ходит, сидит, ест, дышит. Важным является то, что он может выполнить работу и за неё получить зарплату, принять на исполнение документ или распечатать карточку сотрудника и т.д. Поэтому у каждого типа есть свойства и методы. Свойства - это описание набора данных, которые можно хранить как экземпляр типа данных. Методы - это описание реакций на возникающие в БД события. Однако понятия тип, свойство и метод не относятся напрямую к данным, а описывают способы существования и поведения данных в БД.
      Экземпляр типа - это строка данных со значениями свойств и частично методы типа. Строка данных в БД уникально характеризует конкретный экземпляр типа, а методы будут одинаковыми для всех объектов, так как они даже физически существуют в единственном числе для всех экземпляров одного типа. Вместо термина «экземпляр типа» в дальнейшем будем использовать термин – «запись», под которой понимается набор значений свойств объекта. Она является строкой данных в какой-нибудь таблице или полученной из нескольких таблиц с применением промежуточной обработки на сервере БД. Запись является уникальной, так как она характеризует конкретный объект.
      Носителем и механизмом жизни объектов является ядро объектно-ориентированной базы данных. Ядро - это природа объектной БД. В реальном мире все, что нас окружает, взаимодействует друг с другом. По сути, природа в реальном мире является одним большим объектом, состоящим из множества небольших объектов, которые, в свою очередь, так же состоят из более мелких элементов. Поэтому приходится все упрощать, разделяя понятия природы на ядра и объекты. Можно создать механизм хранения объектов со строгими правилами, присущими конкретному типу, т.е. воссоздать в БД упрощенную модель природы. Строгие правила - это законы природы, а правила; присущие конкретному типу это индивидуальная модель поведения объекта, которая описывается типом, а выполняется ядром. Ядро имеет возможность что-либо выполнять над данными по описаниям типов. Ядро является тем механизмом, через который все объекты могут взаимодействовать друг с другом. Ядро, в зависимости от происходящих в БД изменений распространяет события, реакция на которые описывается в типе. Ядро, в зависимости от описаний типов выполняет действия, которые соответствуют этим событиям. Таким образом, ядро - это реализация механизмов, на основе представлений о том, как должны создаваться и взаимодействовать через периферию объекты в объектно-ориентированной БД.
      Объектно-ориентированная база данных создается на основе объектно-ориентирован-ного языка программирования, а сам процесс программирования с помощью этого языка напоминает процесс обработки информации в нашем мышлении.
      Разработчик БД не должен прибегать к трансляции объектной модели в реляционную и обратно. Прикладные программы обращаются и функционируют с объектами, сохраненными в базе данных, которая использует стандартную объектно-ориентированную семантику языка и операции. Напротив, реляционная база данных требует, чтобы разработчик транслировал объектную модель к поддерживаемой модели данных и включил подпрограммы, чтобы обеспечить это отображение во время выполнения. Следствием этого являются дополнительные усилия при разработке и уменьшение эффективности функционирования системы.

      6.6 Спорные моменты технологии ООСУБД

      Все ООСУБД по определению поддерживают сохранение и разделение объектов. Но, когда дело доходит до практической разработки приложений на разных ООСУБД, появляется множество отличий в реализации поддержки трех характеристик: 1) целостность; 2) масштабируемость; 3) отказоустойчивость.
      ООСУБД не требуют многих из тех внутренних функций и механизмов, которые столь привычны и необходимы в реляционных БД. Например, при небольшом числе пользователей, длинных транзакциях и незначительной загрузке сервера объектные СУБД не нуждаются в поддержке сложных механизмов резервного копирования/восстановления (исторически сложилось так, что первые ООСУБД проектировались для поддержки небольших рабочих групп – порядка десяти человек – и не были приспособлены для обслуживания сотен пользователей). Тем не менее, технология БД определенно созрела для крупных проектов.
      Для иллюстрации первой категории рассмотрим механизм кэширования объектов. Большинство объектных СУБД помещают код приложения непосредственно в то же адресное пространство, где работает сама СУБД. Благодаря этому достигается повышение производительности в 10‑100 раз по сравнению с раздельными адресными пространствами. Но при такой модели объект с ошибкой может повредить другие объекты и разрушить базу данных.
      Существуют два подхода к организации реакции СУБД для предотвращения потери данных. Большинство систем передают приложению указатели на объекты, и рано или поздно такие указатели обязательно становятся неверными, так они искажаются после перехода объекта от одного пользователя к другому (например, после перемещения на другой сервер). Если программист, разрабатывающий приложение, пунктуален, то ошибки не возникает. Если же приложение попытается применить указатель в неподходящий для этого момент, то в лучшем случае произойдет крах системы, в худшем – будет утеряна информация в середине другого объекта и нарушится целостность базы данных.
      Метод косвенной адресации лучше, чем метод с использованием прямых указателей,  так как при этом методе СУБД добавляет дополнительный указатель и при необходимости, если объект перемещается, система может автоматически разрешить ситуацию (перезагрузить, если это необходимо, объект) без возникновения конфликтной ситуации.

      Существует еще одна причина для применения косвенной адресации, благодаря которой можно отслеживать частоту вызовов объектов для организации эффективного механизма свопинга - это необходимо для реализации масштабируемости (второго качества БД). Классическая схема клиент-сервер, где основная нагрузка приходится на клиента (такая архитектура называется еще «толстый клиент - тонкий сервер»), лучше справляется с этой задачей, чем мэйнфреймовая структура, однако ее все равно нельзя масштабировать до уровня предприятия. Благодаря многозвенной архитектуре клиент-сервер (N-Tier architecture) происходит равномерное распределение вычислительной нагрузки между сервером и конечным пользователем. Нагрузка распределяется по трем и более звеньям, обеспечивающим дополнительную вычислительную мощность. К чему же ведет такая практика? Архитектура клиент-сервер, еще совсем недавно считавшаяся сложной средой, постепенно превратилась в исключительно сложную среду, благодаря ускоренному переходу к использованию систем клиент-сервер нескольких звеньев. За такое перераспределение приходится расплачиваться дополнительными сложностями, большими затратами времени и множеством проблем, связанных с интеграцией.
      Третье необходимое качество базы данных – это отказоустойчивость. Именно это свойство отличает программный продукт от «прилады». Существуют несколько способов обеспечения отказоустойчивости: а) резервное копирование и восстановление; б) распреде-ление компонентов; в) независимость компонентов; г) копирование.
      При разработке БД программист определяет потенциально опасные участки кода и вставляет в программу некоторые действия, соответствующие началу транзакции – сохранение информации, необходимой для восстановления после сбоя, и окончанию транзакции – восстановление или отправка сообщения администратору. В современных СУБД этот механизм обеспечивает восстановление в случае возникновения практически любой ошибки системы, приложения или компьютера, хотя, конечно, нельзя говорить об идеальной защите от сбоев.
      В мэйнфреймовой архитектуре единственным источником сбоев была центральная ЭВМ. При переходе к распределенной многозвенной организации ошибки могут вызывать не только компьютеры, включенные в сеть, но и коммуникационные каналы. В многозвенной архитектуре при сбое одного из звеньев без специальных мер, результаты работы других окажутся бесполезными. Поэтому при разработке распределенных систем обеспечивается принципиально более высокий уровень обеспечения отказоустойчивости. Обязательными свойствами для современных распределенных СУБД являются: 1) прозрачный доступ ко всем объектам независимо от их местоположения; 2) наличие «трехфазного монитора транзакций» (third-party transaction monitor), благодаря которому транзакция выполняется не в два, а в три этапа, с предварительным формированием запроса о готовности к транзакции.
      СУБД должна иметь независимые компоненты, чтобы при выходе из строя одного из них система, приостановила работу всех пользователей и прервала все транзакции. При сетевом сбое компьютерная сеть разделяется на части, чтобы сохранить возможность работы внутри каждой отдельной части, и дублировании критически важной информации внутри каждого сегмента. Современные системы позволяют администратору базы данных динамически определять сегменты сети, варьируя, таким образом, уровень надежности всей системы в целом.
      При копировании (replication) данных производится добавление к каждому основному серверу резервного сервера. После каждой операции основной сервер передает измененные данные резервному серверу, который автоматически включается в случае выхода из строя основного. При такой организации системы можно выделить два недостатка. Во-первых, это приводит к значительным накладным расходам при дублировании данных, что не только сказывается на производительности, но и само по себе является потенциальным источником сбоев. Во-вторых, в случае сбоя, повлекшего за собой разрыв соединения между двумя серверами, каждый из них должен будет работать в своем сегменте сети в качестве основного сервера, причем изменения, сделанные на серверах за время работы в таком режиме, будет невозможно синхронизовать даже после восстановления работоспособности сети.
      Однако, наиболее совершенным является подход, когда создается необходимое, подбираемое в соответствии с требуемым уровнем надежности, число копий в сегменте. Таким образом, увеличивается доступность копий и даже повышается скорость чтения. Проблема невозможности обновления данных несколькими серверами одновременно в случае их взаимной недоступности решается за счет разрешения проведения модификаций только в одном из сегментов, например имеющем наибольшее число пользователей. При хорошо настроенной схеме кэширования затраты на накладные расходы при дублировании модифицированных данных близки к нулю.

      6.7 Стандарты объектных баз данных

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

• объектной модели;
• языка описания объектов;
• языка организации запросов (Object Query Language – OQL);
• «связующего» языка (C++, Smalltalk);
• администрирования;
• обмена (импорт/экспорт);
• интерфейсов инструментария и др.

      В настоящее время наиболее используемые и устоявшиеся стандарты, является консорциум поставщиков ООСУБД ODMG, которого поддерживают практически все действующие лица отрасли. В сотрудничестве с OMG, ANSI, ISO и другими организациями был создан стандарт ODMG-93. Этот стандарт включает в себя средства для построения законченного приложения, которое будет работать (после перекомпиляции) в любой совместимой с этой спецификацией ООСУБД. В стандарт ODMG-93 входят следующие разделы:

• Язык определения объектов (Object Definition Language – ODL);
• Язык объектных запросов (Object Query Language – OQL);
• Связывание с C++;
• Связывание со Smalltalk.