Обеспечение прозрачности

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

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

§ Прозрачность распределенности.

§ Прозрачность транзакций.

§ Прозрачность выполнения.

§ Прозрачность использования.

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

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

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

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

Пользователь применяет те же самые SQL-операторы, которые потребовалось бы ввести для получения необходимых результатов в централизованной системе.

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

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

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

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

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

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

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

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

- появление проблем с производительностью (поскольку центральный сайт превращается в узкое место всей системы);

- снижение доступности — если центральный сайт по какой-либо причине станет недоступным, все остальные сайты системы не смогут создавать ни­каких новых объектов базы данных.

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

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

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

Распределенная транзакция осуще­ствляет доступ к данным, сохраняемым более чем в одном местоположении. Каждая из транзакций разделяется на несколькосубтранзакций — по одной для каждого сайта, к данным которого осуществляется доступ. На удаленных сайтах субтранзак­ции представляютсяагентами.

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

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

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

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

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

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

- возможность потери сообщения;

- возможность отказа линии связи;

- аварийный останов одного из сайтов;

- расчленение сетевых соединений.

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

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

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

Обработчик распределенных запросов должен знать:

- к какому фрагменту следует обратиться;

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

- какое из местоположений должно использоваться.

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

- время доступа, включающее физический доступ к данным на диске;

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

- время, необходимое для передачи данных по сетевым соединениям.

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

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

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

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

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