Реферат: Объектно-ориентированные СУБД
· независимость компонентов;
· копирование.
Руководствуясь первым принципом, программист определяет потенциально опасные участки кода и вставляет в программу некоторые действия, соответствующие началу транзакции – сохранение информации, необходимой для восстановления после сбоя, и окончанию транзакции – восстановление или, в случае невозможности, принятие каких-то других мер, например, отправка сообщения администратору. В современных СУБД этот механизм обеспечивает восстановление в случае возникновения практически любой ошибки системы, приложения или компьютера, хотя, конечно, нельзя говорить об идеальной защите от сбоев.
В мэйнфреймовой архитектуре единственным источником сбоев была центральная ЭВМ. При переходе к распределенной многозвенной организации ошибки могут вызывать не только компьютеры, включенные в сеть, но и коммуникационные каналы. В многозвенной архитектуре при сбое одного из звеньев без специальных мер результаты работы других окажутся бесполезными. Поэтому при разработке распределенных систем обеспечивается принципиально более высокий уровень обеспечения отказоустойчивости. Назовем обязательные для современных распределенных СУБД свойства:
· прозрачный доступ ко всем объектам независимо от их местоположения, благодаря чему пользователю доступны все сервисы СУБД и может производиться перераспределение компонентов без нежелательных последствий.
· так называемый “трехфазный монитор транзакций” (third-partytransactionmonitor), благодаря которому транзакция выполняется не в два, а в три этапа – сначала посылается запрос о готовности к транзакции.
Что произойдет, если один из компонентов выйдет из строя? Система, созданная в соответствии только с вышеизложенными доводами, приостановит работу всех пользователей и прервет все транзакции. Поэтому важно такое свойство СУБД, как независимость компонентов.
При сетевом сбое сеть разделяется на части, компоненты каждой из которых не могут сообщаться с компонентами другой части. Для того, чтобы сохранить возможность работы внутри каждой такой части, необходимо дублирование критически важной информации внутри каждого сегмента. Современные системы позволяют администратору базы данных динамически определять сегменты сети, варьируя таким образом уровень надежности всей системы в целом.
И, наконец, о копировании (replication) данных. Простейшим способом является добавление к каждому (основному) серверу резервного. После каждой операции основной сервер передает измененные данные резервному, который автоматически включается в случае выхода из строя основного. Естественно, такая схема не лишена недостатков. Во-первых, это приводит к значительным накладным расходам при дублировании данных, что не только сказывается на производительности, но и само по себе является потенциальным источником сбоев. Во-вторых, в случае сбоя, повлекшего за собой разрыв соединения между двумя серверами, каждый из них должен будет работать в своем сегменте сети в качестве основного сервера, причем изменения, сделанные на серверах за время работы в таком режиме, будет невозможно синхронизовать даже после восстановления работоспособности сети.
Более совершенным является подход, когда создается необходимое (подбираемое в соответствии с требуемым уровнем надежности) число копий в сегменте. Таким образом увеличивается доступность копий и даже (при распределении нагрузки между серверами) повышается скорость чтения. Проблема невозможности обновления данных несколькими серверами одновременно в случае их взаимной недоступности решается за счет разрешения проведения модификаций только в одном из сегментов, например имеющем наибольшее число пользователей. При хорошо настроенной схеме кэширования затраты на накладные расходы при дублировании модифицированных данных близки к нулю.
5.3 Стандарты объектных баз данных.
Для обеспечения переносимости приложений (приложение может работать на разных СУБД) и совместимости с СУБД (может взаимодействовать с разными СУБД), естественно, необходима выработка стандартов. Сразу заметим, что установление стандартов лишает производителя в некоторой степени свободы в принятии решений и увеличивает стоимость продукта за счет лицензионных отчислений и больше не будем обсуждать целесообразность (прямо скажем, очевидную) стандартизации.
В области объектных СУБД в настоящее время выработаны стандарты для:
· объектной модели;
· языка описания объектов;
· языка организации запросов (Object Query Language – OQL );
· “связующего” языка (C++ и, конечно же, Smalltalk);
· администрирования;
· обмена (импорт/экспорт);
· интерфейсов инструментария и др.
Хотя у Microsoft и свое мнение на этот счет, организацией, выработавшей наиболее используемые на сегодня и устоявшиеся стандарты, является консорциум поставщиков ООСУБД ODMG (ООСУБД), которого поддерживают практически все действующие лица отрасли. В сотрудничестве с OMG , ANSI, ISOи другими организациями был создан стандарт ODMG-93. Этот стандарт включает в себя средства для построения законченного приложения, которое будет работать (после перекомпиляции) в любой совместимой с этой спецификацией ООСУБД. В книгу ODMG-93 входят следующие разделы:
· Языкопределенияобъектов (Object Definition Language – ODL);
· Язык объектных запросов (Object Query Language – OQL);
|
Рисунок 4 Схема использования ODL для построения приложения. |
· Связывание с C++;
· Связывание со Smalltalk.
ODL. В качестве языка определения объектов (ODL) ODMG был выбран существующий язык IDL (InterfaceDefinitionLanguage – язык описания интерфейсов), который был дополнен такими необходимыми для объектных БД свойствами, как определение коллекций, двунаправленных связей типа “многие-ко-многим”, ключей и др. В сочетании со средствами языка IDL определения атрибутов и операций, это позволяет определять практически любые объекты. Все дополнения реализованы в виде доопределения методов, что обеспечивает совместимость со стандартами OMG, например стандартом CORBA.
Рисунок 4 показывает работоспособную схему для построения приложения на стандартных языках программирования, в процессе которой автоматически генерируются метаданные , заголовочные файлы и методы. Приведем также пример на языке ODL из “белой книги” компании Objectivity, который иллюстрирует связи типа “один-ко-многим”, объявленные между преподавателем и студентами:
interface professor : employee {
attribute string <32> name;
unique attribute lang unsigned ssn;
relationship dept works_in inverse faculty; relationship set <section> teaches inverse taught_by; . . . operations . . .
{
interfacesection : class {
. . . taught_by: professor . . . ;
. . .
}