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

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

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

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

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

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

Основная идея независимости от расположения, или так называемой прозрачности

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

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

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

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

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

FRAGMENT ЕМР AS N ЕМР AT SITE

New York

WHERE DEPT# OR DEPT#

L EMP AT SITE London WHERE DEPT#

Dl D3 D2

Восприятие пользователя

Нью-Йорк

N EMP

L EMP

Лондон

Puc. 20.2. Пример фрагментации

Замечание. Здесь подразумевается, что кортежи служащих отображаются в физической памяти каким-то непосредственным способом; что номера служащих и номера отделов представлены символьными строками, а размер заработной платы - числами; что Dl и D3 - отделы, расположенные в Нью-Йорке, а D2 - отдел, расположенный в Лондоне. Таким образом, кортежи служащих из Нью-Йорка хранятся на узле в Нью-Йорке, а кортежи служащих из Лондона- на узле в Лондоне. Отметим, что внутрисистемные имена фрагментов - N EMP и L EMP.

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

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

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

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

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

Замечание. Необходимо сказать еще несколько слов относительно вертикальной фрагментации. Как утверждалось выше, несомненно, что такая фрагментация должна выполняться без потерь. Поэтому разбиение переменной-отношения ЕМР на фрагменты-проекции, например, вида {EMPI,DEPTI} и {SALARY} было бы недопустимым. Однако в некоторых системах хранимые переменные-отношения рассматриваются как имеющие скрытый, предоставляемый системой атрибут идентификатор кортежа , или сокращенно - атрибут TID (tuple ID). Для каждого хранимого кортежа атрибут TID, грубо говоря, является адресом. Очевидно, что он является потенциальным ключом для соответствующей переменной-отношения. Например, если бы переменная-отношение ЕМР содержала такой атрибут, то она могла бы быть фрагмен-тирована на проекции {TID,EMPI,DEPTI} и {TID,SALARY}, поскольку такая фрагментация уже, конечно, выполняется без потерь. Также обратите внимание, что если, например, атрибут TID является скрытым, то это никак не нарушает информационный принцип, поскольку независимость от фрагментации означает, что пользователь не должен знать чего-либо о фрагментации.

Заметим, между прочим, что простота выполнения фрагментации и восстановления - это две основные причины, по которым распределенные базы данных должны быть именно реляционными. Реляционная модель предоставляет все те операции, которые необходимы для решения этих задач [20.15].

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

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