Распределенные бд: разновидности распределенных систем, распределенная субд System r, интегрированные или федеративные системы и мультибазы данных.

Основная задача распределенных СУБД (РСУБД) состоит в обеспечении средства интеграции локальных БД, располагающихся в узлах вычислительной сети, чтобы пользователь имел доступ ко всем частям БД, как к единой БД. РСУБД обеспечивают 1) простоту использования системы; 2) возможности автономного функционирования при нарушениях связности сети или при административных потребностях; 3) высокую степень эффективности.

Разновидности распределенных систем.

Бывают однородные и неоднородные распределенные БД (РБД). В однородном случае каждая локальная БД управляется одной и той же СУБД. В неоднородной системе локальные БД могут относиться к разным моделям данных. Сетевая интеграция неоднородных БД - это актуальная, но очень сложная проблема. Многие решения известны на теоретическом уровне. Есть практическое решение - интеграция неоднородных SQL-ориентированных систем (из-за стандартизации языка SQL). Пример однородной РСУБД – System R* (далее SR*).

Распределенная СУБД System R*.

1. Простота использования: пользователи остаются в среде SQL. Возможность использования SQL основывается на обеспечении SR* прозрачности местоположения данных: сама система обнаруживает место, указанное в запросе объектов данных; одна и та же прикладная программа может быть выполнена в разных узлах, при этом в каждом узле при компиляции запроса строится свой оптимальный план.

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

3. Эффективность достигается 2-мя путями: 1) Как и в System R, в System R* выполнению запроса предшествует его компиляция. В ходе этого процесса производится поиск употребляемых в запросе имен объектов БД в распределенном каталоге и замена имен на внутренние идентификаторы; проверка прав доступа пользователя, от имени которого производится компиляция, и выбор наиболее оптимального глобального плана выполнения запроса, который затем подвергается декомпозиции и по частям рассылается в соответствующие узлы сети, где производится выбор оптимальных локальных планов выполнения компонентов запроса и происходит генерация модулей доступа в машинных кодах. В результате много действий производится на стадии компиляции до реального выполнения запроса. Обработанная посредством прекомпилятора SR* прикладная программа, включающая предложения SQL, может в далее выполняться много раз без дополнительных накладных расходов. 2) Возможность перемещения удаленных отношений в локальную БД. Диалект SQL, используемый в SR*, включает предложение MIGRATE TABLE, позволяющее выполнить перемещение. Оно обеспечивает более эффективную реализацию транзакций.

Средства, предложенные на начальной стадии проекта:

1. Средства горизонтального и вертикального разделения отношений РБД. Средства горизонтального разделения выполняют разбиение отношения на ряд подотношений, содержащих кортежи, удовлетворяющие условию и каждое подотношение рассылается в указ. узел для хранения в указ. сегменте. Средства вертикального разбиения образуют набор подотношений с помощью проекции зад. отношения на атрибуты из зад. списка. Затем аналогично рассылаются.

2. Средства дублирования отношений в нескольких узлах с поддержкой согласованности копий, которое производит рассылку копий указанного отношения для хранения в именованных сегментах указанных узлов сети. Система должна автоматически поддерживать согласованность копий.

3. Средства поддержания мгновенных снимков состояния БД в соответствии с заданным запросом. Их можно рассматривать как материализованные представления базы данных. Имя мгновенного снимка можно было бы использовать прямо в запросе на выборку там, где можно использовать имена базовых отношений или представлений. Большие проблемы связаны с обновлением отношений через их мгновенные снимки, поскольку в момент обновления содержимое мгновенного снимка может расходиться с текущим содержимым базового отношения.

Аспекты проекта SR*, которые реализованы:

1. Именование объектов и организация распределенного каталога.

В БД System R полное имя отношения: имя пользователя и имя отношения. В запросах можно указывать только имя отношения. В БД SR* системное имя отношения включает: идентификатор пользователя-создателя отношения; идентификатор узла сети, в котором выполнялась операция создания отношения; локальное имя отношения, присвоенное ему при создании; идентификатор узла, в котором отношение располагалось непосредственно после своего создания.

В запросах можно использовать как системное имя, так и локальное. 2 интерпретации локальных имен: часть системного имени и синоним системного имени, созданный оператором SQL и сохраненный в лок.каталоге.

Концепция распределенного каталога SR* основана на наличии у каждого объекта РБД уникального системного имени. Принято следующее соглашение: информация о размещении любого объекта БД сохраняется в локальном каталоге того узла, в котором объект располагался непосредственно после создания. Для получения полной информации об отношении необходимо сначала воспользоваться локальным каталогом узла, в котором происходит компиляция, затем обратиться к удаленному каталогу родового узла данного отношения и в заключение воспользоваться каталогом текущего узла.

2. Распределенная компиляция запросов.

Главный узел - узел сети, в котором инициирован процесс компиляции предложения SQL, и дополнительные узлы - те узлы, которые вовлекаются в этот процесс в ходе его выполнения.

Этапы компиляции:

1) В главном узле производится грамматический разбор предложения SQL с построением внутреннего представления запроса в виде дерева.

2) В главном узле генерируется глобальный план выполнения запроса, в котором учитывается лишь порядок взаимодействий узлов при реальном выполнении запроса.

3) Если в глобальном плане выполнения запроса участвуют дополнительные узлы, производится его декомпозиция на части, каждую из которых можно выполнить в одном узле. Соответствующие части запроса (во внутреннем представлении) рассылаются в дополнительные узлы.

4) Эта стадия включает 2 последние фазы процесса компиляции запроса в System R: оптимизацию и генерацию машинных кодов. Производится проверка прав пользователя; происходит обработка представлений базы; осуществляется локальная оптимизация обрабатываемой части запроса; генерация кода.

3. Управление транзакциями и синхронизация.

Выполнение транзакции в SR* является распределенным. Выполнение одной транзакции, инициированной в некотором узле сети, влечет инициирование транзакций в дополнительных узлах. Основной проблемой является проблема согласованного завершения распределенной транзакции, чтобы результаты ее выполнения во всех затронутых ею узлах были либо отображены в состояние локальных БД, либо полностью отсутствовали. Для её решения используется протокол: есть ряд независимых транзакций-участников распределенной транзакции, выполняющихся под управлением транзакции-координатора. Решение об окончании распределенной транзакции принимается координатором. 1) координатор передает каждому из участников сообщение "подготовиться к завершению". Получив такое сообщение, каждый участник переходит в состояние готовности как к немедленному завершению транзакции, так и к ее откату. После этого каждый участник, успешно выполнивший подготовительные действия, посылает координатору сообщение "готов к завершению". 2) Если координатор получает такие сообщения ото всех участников, то он рассылает всем участникам сообщение "завершить транзакцию", и это считается завершением распределенной транзакции. Если не все участники успешно выполнили первую фазу, то координатор рассылает всем участникам сообщение "откатить транзакцию".

Основной проблемой является проблема возможных распределенных тупиков, которые могут возникнуть между несколькими распределенными транзакциями, выполняющимися параллельно. (Тупики между транзакциями - участниками одной распределенной транзакции невозможны, т.к. все участники получают один общий идентификатор транзакции и не конфликтуют по синхронизации). Для обнаружения распределенных синхронизационных тупиков в SR* применяется распределенный алгоритм, не нарушающий требования автономности узлов сети, минимизирующий число передаваемых по сети сообщений и выполняющий необходимую процессорную обработку.

Интегрированные или федеративные системы и мультибазы данных.

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

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

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

27. Объектно-ориентированные СУБД: связь объектно-ориентированных СУБД с общими понятиями объект­но-ориентированного подхода, объектно-ориентированные модели данных, языки программирования объектно-ориентированных баз данных, языки запросов объектно-ориентированных баз данных, примеры объектно-ориентированных СУБД.

Связь объектно-ориентированных СУБД с общими понятиями объектно-ориентированного подхода.

Основные концепции объектно-ориент.подхода: 1) понятие объекта и идентификатора объектов; 2) атрибуты и методы объектов; 3) понятие класса; 4) наследование, инкапсуляция и полиморфизм.

ООБД расширяют набор этих концепций, добавляя 3 аспекта: 1) потребность в средствах спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.); 2) потребность в механизме определения разного рода семантических связей между объектами разных классов; 3) в контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа и класса объектов.

Объектно-ориентированные модели данных.

У объектно-ориент.модели данных нет строгого математического аппарата.

Рассмотрим модель данных реально применяемую в ООСУБД О2.

В O2 поддерживаются объекты и значения. Объект - это пара (идентификатор, значение), причем объекты инкапсулированы, т.е. их значения доступны только через методы. Значения могут быть атомарными или структурными. Структурные значения строятся из значений или объектов, представленных своими идентификаторами, с помощью конструкторов множеств, кортежей и списков. Элементы структурных значений доступны с помощью предопределенных операций (примитивов).

Разделяется понятие типа и класса. Каждому классу сопоставляется тип, описывающий структуру экземпляров класса. Типы определяются рекурсивно на основе атомарных типов и ранее определенных типов и классов с применением конструкторов.

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

Метод - программный код, привязанный к конкретному классу и применимый к объектам этого класса. Определение метода в O2 производится в два этапа. 1) объявляется сигнатура метода, т.е. его имя, класс, типы или классы аргументов и тип или класс результата. Методы могут быть публичными или приватными; 2) определяется реализация класса на одном из языков программирования O2.

В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.

Языки программирования ООБД.

ООСУБД – объединение системы программирования и СУБД.

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

Языки программирования ООБД и БД различаются только терминологически; существенным отличием является поддержание в языках первого класса подхода к наследованию классов. Языки второго класса более развиты как в отношении системы типов, так и в отношении управляющих конструкций.

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

Полностью разработанного языка прогр-ия для ООБД нет. Используются уже существующие объектно-ориент.языки. Язык Smalltalk80 оказал влияние на разработку первых ООСУБД.

Близость объектно-ориент.языков и функционального подхода позволила использовать функциональные языки (Лисп – основа проекта Orion).

Также были разработаны различные модификации языка Си, например, СО2. Язык СО2 не является полностью самостоятельным.

Этот язык входит в многоязыковую среду O2 и предназначен для программирования методов ранее определенных классов. Определение классов, сигнатур методов и имен, постоянно хранимых значений и объектов производится с использованием отдельного языка определения схемы БД.

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

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

Основой манипулирования объектами, хранимыми в БД, является средство итерации. Итератор применим к значениям-множествам или спискам. Итератор языка CO2 обеспечивает явную навигацию в классах объектов.

Языки запросов объектно-ориентированных баз данных.

Существует 3 подхода к организации языков запросов ООБД: 1) языки, являющиеся объектно-ориентированными расширениями языков запросов реляционных систем. Наиболее распространены языки с синтаксисом, близким к известному языку SQL; 2) построение полного логического объектно-ориентированного исчисления. По поводу построения такого исчисления имеются теоретические работы, но законченный и практически реализованный язык запросов нам неизвестен; 3) применение дедуктивного подхода.

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

Примеры декларативных языков запросов:

1. В языке запросов ООСУБД ORION полностью поддерживается принцип инкапсуляции объектов. Запросы могут основываться только на одном классе. Синтаксис языка ориентирован на SQL. Очень развит набор допустимых предикатов селекции. В частности, для атрибута, доменом которого является суперкласс, можно указать имя интересующего пользователя подкласса.

2. Язык запросов системы Iris находится под влиянием реляционной парадигмы. Даже название этого языка OSQL отражает его связь с реляционным языком SQL. По сути дела, OSQL - это реляционный язык, рассчитанный на работу с ненормализованными отношениями. Естественно, при таком подходе в OSQL нарушается инкапсуляция объектов.

3. Декларативный язык запросов системы O2 RELOOP. В общих словах, это язык запросов с SQL-ориентированным синтаксисом, основанный на специально разработанной для модели O2 алгебре объектов и значений. Запрос задается на значении-множестве или списке. Долговременному классу в O2 соответствует одноименное значение-множество, то тем самым можно определить запрос на любом хранимом классе. Результатом запроса может являться объект, значение-множество или значение-список. При этом элементами значений-множеств могут являться объекты, либо значения-кортежи с элементами-объектами разных классов. В совокупности эти особенности языка позволяют формулировать запросы над несколькими классами, а также употреблять вложенные подзапросы.

Основная цель оптимизации запроса в системе ООБД - создание оптимального плана выполнения запроса с использованием примитивов доступа к внешней памяти ООБД.

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

Примеры объектно-ориентированных СУБД.

1. Проект ORION (с 1985 по 1989 г. фирмой MCC). ORION-1 - однопользовательская система; ORION-1SX, предназначенная для использования в качестве сервера в локальной сети рабочих станций; ORION-2 - полностью распределенная ООСУБД. Реализация всех систем производилась с использованием языка Common Lisp на рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС Genera 7.0 и SUN-3 в среде ОС UNIX.

В ORION-1 все компоненты располагаются на одной рабочей станции; в ORION-1SX - разнесены между разными рабочими станциями (в частности, управление объектами производится на рабочей станции-клиенте). Применение в ORION-1SX для взаимодействия клиент-сервер механизма удаленного вызова процедур позволило использовать в этой системе практически без переделки многие модули ORION-1.

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

2. Проект О2 (компания Altair, образованной специально для целей проектирования и реализации ООСУБД. Проект начался с 1986 г., и он был рассчитан на пять лет. После успешного завершения проекта для сопровождения системы и ее дальнейшего развития была организована новая коммерческая компания O2).

Прототип системы функционировал в режиме клиент/сервер в локальной сети рабочих станций SUN c соответствующим разделением функций между сервером и клиентами.

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

Функции системы управления объектами:

- создание и уничтожение объектов, выборку объектов по именам, поддержку предопределенных методов, поддержку объектов со внутренней структурой-множеством, списком и кортежем;

- управление передачей сообщений между объектами;

- управление транзакциями;

- управление коммуникационной средой (на базе транспортных протоколов TCP/IP в локальной сети Ethernet);

- отслеживание долговременно хранимых объектов;

- управление буферами ОЗУ;

- управление кластеризацией объектов во внешней памяти;

- управление индексами.

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

Компонент управления схемой БД реализован над подсистемой управления объектами: в системе поддерживаются несколько невидимых для программистов классов и в том числе классы "Class" и "Method", экземплярами которых являются, соответственно, объекты, определяющие классы, и объекты, определяющие методы. Удаление класса, который не является листом иерархии классов или используется в другом классе или сигнатуре какого-либо метода, запрещено.

Вывод: «+» ООСУБД – возможность отображать информацию о сложных взаимосвязях объектов. «-» ООСУБД – высокая понятийная сложность, неудобства обработки данных, низкая скорость выполнения запросов.