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

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

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

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

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

Например, для выборки сведений обо всех руководителях отделений компании «Аренда жилья» (у них атрибут должность имеет значение «менеджер») при наличии в системе прозрачности фрагментации, можно воспользоваться следующим SQL-оператором:

SELECT фамилия, имя

FROM сотрудники

WHERE должность = ‘менеджер’;

Это тот же самый SQL-оператор, который потребовалось бы ввести для получения указанных результатов в централизованной системе (СУБД).

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

Пусть отношениеСотрудники фрагментировано так:

верт. фр. S₁ П (л. номер, пол, зарплата, ИНН (сотрудники)) ® фрагмент расположен на сайте 5

верт. фр. S₁ П ( л. номер, фамилия, имя, адрес, номер отделения (сотрудники))

гор. фр. s ном. отд. = ‘B3’(S₂) ® фрагмент расположен на сайте 3

гор. фр. s ном. отд. = ‘B5’(S₂) ® фрагмент расположен на сайте 5

гор. фр. s ном. отд. = ‘B7’(S₂) ® фрагмент расположен на сайте 7

Тогда предыдущий запрос следует записать так:

SELECT фамилия, имя

FROM S₂₁

WHERE л. номер IN (SELECT л. номер FROM S₁ WHERE должность = ‘менеджер’) UNION

SELECT фамилия, имя

FROM S₂₂

WHERE л. номер IN (SELECT л. номер FROM S₁ WHERE должность = ‘менеджер’) UNION и т. д.

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

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

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

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

SELECT фамилия, имя

FROM S₂₁ AT SITE 3

WHERE л. номер IN (SELECT л. номер FROM S₁ AT SITE 5 WHERE должность = ‘менеджер’) UNION

SELECT фамилия, имя

FROM S₂₂ AT SITE 5

WHERE л. номер IN (SELECT л. номер FROM S₁ AT SITE 5 WHERE должность = ‘менеджер’) UNION

SELECT фамилия, имя

FROM S₂₃ AT SITE 7

WHERE л. номер IN (SELECT л. номер FROM S₁ AT SITE 5 WHERE должность = ‘менеджер’)

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

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

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

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

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

Альтернативное решение состоит в использовании префиксов (приставок), помещаемых в имена объектов в качестве идентификатора сайта, создавшего этот объект. Например, отношение R1, созданное на сайте S_i, могло бы получить имя SI.R1. Аналогичным образом, необходимо уметь идентифицировать каждый фрагмент и каждую его копию. Поэтому второй копии третьего фрагмента отношения R1, созданного на сайте S_i, можно было бы присвоить имя SI.R1.F3.C2. Однако такой подход приводит к утрате прозрачности распределенности.

Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым методам, состоит в использовании алиасов (псевдонимов), создаваемых для каждого из объектов базы данных. В результате объект SI.R1.F3.C2 пользователям сайта S_i может быть известен под именем local R1. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных возлагается на СУРБД.

 

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

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

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

Пример распределенной транзакции.

Рассмотрим выполнение транзакции Т, выполняющей распечатку имен сотрудников компании «Аренда недвижимости», при использовании схемы фрагментации, определенной в §1.6.1. в виде фрагментов S₁, S₂, S₂₁, S₂₂, S₂₃. Транзакция будет включать три субтранзакции T_S3, T_S5, T_S7, представленные агентами на сайтах 3, 5 и 7 соответственно. Каждая из субтранзакций печатает имена работников отделений компаний. График распределенной транзакции представлен в табл. 1.6.2.1.

Табл. 1.6.2.1

Время	Субтранзакция TS3	Субтранзакция TS3	Субтранзакция TS3
t1	начало транзакции	начало транзакции	начало транзакции
t2	read (фамилия, имя)	read (фамилия, имя)	read (фамилия, имя)
t3	print (фамилия, имя)	print (фамилия, имя)	print (фамилия, имя)
t4	конец транзакции	конец транзакции	конец транзакции

 

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

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

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

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

Прозрачность отказов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

Заключение

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

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

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

 

 

Правила распределенных СУБД

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

Правило0. Основнойпринцип.

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

Правило1. Локальнаяавтономность.

Сайты в распределенной системе должны быть автономными. В данном контексте автономность означает следующее:

¾ локальные данные принадлежат локальным владельцам и сопровождаются локально;

¾ все локальные процессы остаются чисто локальными;

¾ все процессы на заданном сайте контролируются только этим сайтом.

Правило2. Отсутствиеопорынацентральныйсайт.

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

Правило3. Непрерывноефункционирование.

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

¾ добавление или удаление сайта из системы;

¾ динамическое создание или удаление фрагментов из одного или нескольких сайтов.

Правило4. Независимостьотрасположения.

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

Правило5. Независимостьотфрагментации.

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

Правило6. Независимостьотрепликации.

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

Правило7. Обработкараспределенныхзапросов.

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

Правило8. Обработкараспределенныхтранзакций.

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

Правило9. Независимостьоттипаоборудования.

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

Правило10. Независимостьотоперационнойсистемы.

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

Правило11. Независимостьотсетевойархитектуры.

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

Правило12. НезависимостьоттипаСУБД.

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

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

Резюме

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

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

3. Преимущества СУРБД заключается в том, что она позволяет: 1) отразить структуру организации, 2) повышает возможности совместного использования удаленных данных, 3) повышает надежность, доступность и производительность системы, 4) позволяет получить экономию средств, 5) организовать модульное увеличение размеров сети.

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

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

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

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

8. Существует четыре стратегии распределения, определяющие способ размещения данных: 1) централизованное (единственная централизованная база данных), 2) фрагментированное распределение (каждый фрагмент размещается на одном из сайтов), 3) распределение с полной репликацией (полная копия всей базы данных поддерживается на каждом сайте) и 4) распределение с выборочной репликацией (комбинация первых трех способов).

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

Вопросы к теме «Распределенные базы данных и СУБД».

1. Поясните значение терминов РБД и СУРБД и назовите причины создания подобных систем. Основные концепции РБД и СУРБД. § 1.1.1.

2. Сравните и укажите отличия между СУРБД и системами с распределенной обработкой. § 1.1.2.

3. Сравните и укажите отличия между СУРБД и системами с параллельной обработкой. При каких обстоятельствах СУРБД оказывается предпочтительнее параллельной СУБД? § 1.1.3.

4. Назовите преимущества и недостатки, свойственные распределенным системам. § 1.2.1.

5. Функции СУРБД. § 1.3.

6. Рекомендуемая архитектура СУРБД. § 1.4.

7. Компонентная архитектура СУРБД. § 1.4.3.

8. Назначение глобального системного каталога. § 1.4.6.

9. Главные особенности, которые должны учитываться при проектировании РБД. § 1.5.

10. Стратегические цели определения и размещения (распределения) фрагментов. § 1.5.

11. Стратегии размещения данных в системе. § 1.5.1.

12. Назначение и типы фрагментации. § 1.5.2.

13. Поясните, как можно обеспечить корректность фрагментации § 1.5.2.2.

14. Репликации в распределенных системах: определение, виды репликации. § 1.5.3.

15. Реализация механизмов (схем) обновления (владения) данных в распределенных системах. § 1.5.3.3.÷1.5.3.7.

16. Цель обеспечения прозрачности в СУРБД и типы прозрачности. § 1.6.

17. Прозрачность распределенности: назначение и уровни. § 1.6.1.

18. Прозрачность транзакций: назначение и аспекты. § 1.6.2.

19. Прозрачность выполнения: назначение. Дополнительные функции обработчика распределенных запросов. § 1.6.3.

20. Изложите правила, по которым должны создаваться распределенные СУБД (правило Дейта). § 1.7.

 

 

Введение в объектные СУБД

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

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