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

Разделение функций между клиентами и серверами

В типичном случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL.

В некоторых случаях хотелось бы включить в состав клиентской части системы некоторые функции для работы с «локальным кэшем» базы данных, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно сделать только путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов.

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

2.6. Распределенные БД

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

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

· База данных коллективного пользования - это БД с распределенной обработкой данных и распределенной БД.

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

Говоря о распределенных БД, имеют в виду, что вычислительная сеть поддерживает технологию «клиент - сервер». В этом случае БД хранятся на рабочих станциях, СУБД - на сервере, на рабочих станциях находятся приложения.

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

Выделяют два вида распределенных БД: однородные и неоднородные.

· Однородная распределенная БД - база данных, в которой каждая из локальных баз управляется одной и той же СУБД.

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

2.6.2. Однородные распределенные системы

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

· легкость использования системы;

· возможности автономного функционирования при нарушениях связности сети или при административных потребностях;

· высокая степень эффективности.

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

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

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

Высокая степень эффективности системы является одним из наиболее ключевых требований к распределенным системам управления базами данных. Для достижения этой цели используются два основных приема.

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

Вторым средством повышения эффективности системы является возможность перемещения удаленных отношений в локальную базу данных.

Распределенная система должна:

- осуществлять рассылку копий указанного отношения для хранения в именованных сегментах указанных узлов сети;

- автоматически поддерживать согласованность копий;

- иметь возможность создания мгновенного снимка состояния баз данных в соответствии с заданным запросом на выборку, а также возможность обновления этого снимка;

- поддерживать согласованное состояния мгновенного снимка, разделенных отношений и раскопированных отношений;

- иметь контроль связности сети. При нарушении связности сети работа с распределенной базой данных обычно продолжается только в одной из образовавшихся подсетей. При этом для выбора подсети используются алгоритмы голосования; решение принимается на основе учета количества связных узлов сети.

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

Системное имя отношения должно включать четыре компонента: идентификатор пользователя-создателя отношения; идентификатор узла сети, в котором выполнялась операция создания отношения; локальное имя отношения, присвоенное ему при создании; идентификатор узла, в котором отношение располагалось непосредственно после своего создания.

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

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

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

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

Рассмотрим общую схему распределенной компиляции.

Будем называть главным узлом тот узел сети, в котором инициирован процесс компиляции предложения SQL, и дополнительными узлами - те узлы, которые вовлекаются в этот процесс в ходе его выполнения. На самом грубом уровне процесс компиляции можно разбить на следующие фазы:

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

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

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

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

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

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

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

После этого каждый участник, успешно выполнивший подготовительные действия, посылает координатору сообщение «готов к завершению». Если координатор получает такие сообщения ото всех участников, то он начинает вторую фазу завершения, рассылая всем участникам сообщение «завершить транзакцию», и это считается завершением распределенной транзакции. Если не все участники успешно выполнили первую фазу, то координатор рассылает всем участникам сообщение «откатить транзакцию», и тогда эффект воздействия распределенной транзакции на состояние баз данных отсутствует.

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

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

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

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

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

2.5. Преимущества и недостатки СУБД

2.5.1. Преимущества СУБД

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

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

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

В современных СУБД предусмотрена возможность параллельного доступа к базе данных (обработка нескольких одновременных запросов к одному и тому же элементу) с контролем возникновения конфликтов запросов и потери целостности данных.

Развитые службы резервного копирования и восстановления данных при возникновении различных сбоев предусматривают снижение вероятности потерь информации.

2.5.2. Недостатки СУБД

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

Дата добавления: 2013-12-12