Распределенная обработка данных. Найханова Л.В. - 73 стр.

     DEFINE SNAPSHOT  ()
        AS 
        REFRESHED EVERY 
      При выполнении предложения фактически производится выполнение указанного в
нем запроса на выборку, а результирующее отношение сохраняется под указанным в
предложении именем в локальной базе данных в том узле, в котором выполняется
предложение. После этого мгновенный снимок периодически обновляется в соответствии
с запомненным запросом.
      Можно обновить мгновенный снимок, не дожидаясь истечения временного
интервала, указанного в определении, путем выполнения предложения REFRESH
SNAPSHOT .
      Разумное использование мгновенных снимков более реально, чем использование
разделенных отношений и копированных отношений, поскольку их можно в некотором
смысле рассматривать как материализованные представления базы данных. Имя
мгновенного снимка можно было бы использовать прямо в запросе на выборку там, где
можно использовать имена базовых отношений или представлений. Большие проблемы
связаны с обновлением отношений через их мгновенные снимки, поскольку в момент
обновления содержимое мгновенного снимка может расходиться с текущим содержимым
базового отношения.
      По отношению к мгновенным снимкам проблем поддержания согласованного
состояния мгновенного снимка и базовых отношений не существует, поскольку
автоматическое согласование не требуется. Что же касается разделенных отношений и
раскопированных отношений, то для них эта проблема общая и достаточно трудная. Во-
первых, согласование разделов и копий вызывает существенные накладные расходы при
выполнении операций модификации хранимых отношений. Для этого требуется
выработка и соблюдение специальных протоколов модификации.
      Во-вторых, введение копированных отношений обычно производится не столько для
увеличения эффективности системы, сколько для увеличения доступности данных при
нарушении связности сети. В системах, в которых применяется этот подход, при
нарушении связности сети работа с распределенной базой данных обычно продолжается
только в одной из образовавшихся подсетей. При этом для выбора подсети используются
алгоритмы голосования; решение принимается на основе учета количества связных узлов
сети. Применяются и другие подходы, но все они очень дорогостоящие, а самое главное,
они плохо согласуются с базовым подходом System R* по поводу выбора способа
выполнения запроса на стадии его компиляции. Поэтому, как нам кажется, в System R*
никогда не будут реализованы средства, позволяющие тем или иным способом
поддерживать копии отношений в нескольких узлах сети.
      Далее мы рассмотрим аспекты проекта System R*, которые нашли отражение в ее
реализации и являются на наш взгляд наиболее интересными: средства именования
объектов и организацию распределенного каталога баз данных; подход к распределенным
компиляции и выполнению запросов; особенности использования представлений;
средства оптимизации запросов; особенности управления транзакциями; средства
синхронизации и распределенный алгоритм обнаружения синхронизационных тупиков.
Именование объектов и организация распределенного каталога
     Напомним прежде всего, что полное имя отношения (базового или представления) в
базе данных System R имеет вид имя-пользователя.имя-отношения, где имя-пользователя
идентифицирует пользователя - создателя отношения, а имя-отношения - это то имя,
которое было указано в предложениях CREATE TABLE или CREATE VIEW. В запросах
можно указывать либо это полное имя отношения, либо его локальное имя. Во втором
случае при компиляции используются стандартные правила дополнения локального



                                                                                  73