    Глава 21 

    Распределенные базы данных и системы клиент/сервер 

    21.1. Введение 

    Тема распределенных баз данных была затронута в конце главы 2, где 
отмечалось:! "...полная поддержка для распределенных баз данных означает, что 
отдельное приложение может прозрачно обрабатывать данные, распределенные на 
множестве раз-1 личных баз данных, управление которыми осуществляют разные 
СУБД, работающие на многочисленных машинах с различными операционными 
системами, соединенных j вместе коммуникационными сетями. Здесь понятие 
прозрачно означает, что прило- ] жение выполняет обработку данных с логической 
точки зрения, как будто управление | данными   полностью   осуществляется   
одной   СУБД,   работающей   на  отдельной 1 машине". В данной главе эти идеи 
исследуются более детально. Вы узнаете, что ] представляют собой 
распределенные базы данных, чем они важны и какие нерешенные технические 
задачи еще существуют в этой области. 
    В главе 2 также кратко обсуждались системы клиент/сервер, которые 
расценивались как простой случай распределенных систем вообще. Подробнее 
системы клиент/сервер рассматриваются в отдельном разделе этой главы. 
    Общая схема главы приведена в следующем разделе. 

    21.2. Предварительные замечания 

    Начнем с предварительного определения: 
    •   Системы дистрибутивных баз данных состоят из набора узлов, связанных 
вместе коммуникационной сетью, в которой: 
    1) каждый узел обладает своими собственными системами баз данных; 
    2) узлы работают согласованно, поэтому пользователь может получить доступ 
к данным на любом узле сети, как будто все данные находятся на его собственном узле. 
    Из этого следует, что так называемая "распределенная база данных" на самом 
деле является типом виртуального объекта, части которого физически сохраняются 
в ряду отдаленных "реальных" баз данных на удаленных узлах (фактически, это 
логическая единица всех этих реальных баз данных). На рис. 21.1 приведен 
пример распределенной системы баз данных. 
    Обратите внимание на то, что каждый узел обладает своими собственными 
базами данных, собственными локальными пользователями, собственной СУБД и 
программным обеспечением для управления транзакциями (включая собственное 
программное обеспечение для блокирования, регистрации, восстановления и т.д.), 
а также своим собственным локальным диспетчером передачи данных. В частности, 
пользователь может на собственном локальном узле выполнять операции с данными 
так, как будто этот узел вовсе не является частью распределенной системы (по 
крайней мере, к распределенной СУБД предъявляется такое требование). Таким 
образом, распределенная СУБД может рассматриваться как некий способ совместной 
работы отдельных локальных СУБД, расположенных на отдельных локальных узлах. 

    564 Часть V. Дополнительные аспекты 

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

    Нью-Йорк	Лондон 
    Лос-Анджелес 
    Сан-Франциско 

    Рис, 21.1. Типичная распределенная система баз данных 

    Чаще всего предполагается, что узлы распределены физически, а также 
географически, как показано на рис. 21.1, хотя в действительности достаточно, 
чтобы они были распределены логически. Однако два "узла" могут даже 
сосуществовать на одном компьютере (особенно во время установки и тестирования 
системы). В последние годы смысл понятия распределенная система несколько 
изменился. Несмотря на то что в первоначальных исследованиях в области 
распределенных баз данных описывались географически распределенные системы, во 
многих первых коммерческих системах вместо этого использовалось локальное 
распределение с несколькими узлами, размещенными в одном и том же здании и 
соединенными с помощью локальной сети. Однако с точки зрения распределенной 
базы данных между ними нет существенных различий, поскольку в обоих случаях 
необходимо решать одни и те же технические проблемы. Поэтому представленную на 
рис, 21.1 схему можно рассматривать как макет типичной распределенной системы. 

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

    Глава 21, Распределенные базы данных и системы клиент/сервер 565 


    Преимущества 

    Почему распределенные базы данных столь необходимы? В основном потому, что 
крупные предприятия обычно имеют распределенную структуру, по крайней мере, 
они разделены логически (на отделения, отделы, рабочие группы и т.д.) и даже 
физически (на заводы, фабрики, лаборатории и т.д.). Из этого следует, что 
данные в них также разделены, поскольку на каждом организационном уровне 
ведется работа с j данными, которые относятся к этому уровню. Таким образом, в 
распределенной системе можно отобразить структуру предприятия с помощью 
соответствующей ей] структуры базы данных, т.е. данные локального значения 
могут храниться локально, что в наибольшей мере отвечает логической структуре 
системы, тогда как доступ к ] удаленным данным может осуществляться по мере необходимости. 
    Рассмотрим в качестве примера рис. 21.1, на котором изображена упрощенная 
банковская система, обслуживающая Лос-Анджелес и Сан-Франциско. Согласно этой 
схе- j ме в Лос-Анджелесе хранятся сведения о банковских счетах клиентов из 
Лос-Анджелеса, а в Сан-Франциско — сведения о банковских счетах клиентов из 
Сан-Франциско. Преимущества такой системы очевидны: в распределенной системе 
комбинируются эффективность обработки (данные хранятся вблизи от того места, 
где они более всего необходимы) и повышенная доступность (с помощью средств 
связи можно из Сан-Франциско обеспечить доступ к счету в Лос-Анджелесе и наоборот). 
    Возможность отображения структуры предприятия в структуре базы данных (как 
это только что объяснялось), вероятно, наиболее существенное преимущество 
распределенных систем. Хотя такие системы имеют множество других 
дополнительных преимуществ, которые рассматриваются в соответствующих разделах 
этой главы. Однако следует отметить, что этим системам присущи также и 
некоторые недостатки, в частности сложность распределенных систем, по крайней 
мере с технической точки зрения. В идеальном случае такая сложность будет 
препятствием для разработчика, а не для пользователя. Однако если не 
предпринять особых мер, то с практической точки зрения некоторые аспекты такой 
сложности могут быть актуальны и для пользователей. 

    Примеры распределенных систем 

    В качестве примера можно кратко упомянуть некоторые хорошо известные 
распределенные системы. Среди многочисленных прототипов и 
научно-исследовательских систем следует упомянуть систему SDD-1, созданную в 
конце 70-х — начале 80-х годов в научно-исследовательском отделении фирмы 
Computer Corporation of America [21.26]; систему R* (читается "R star"), 
которая является распределенной версией системы System R и создана в начале 
80-х годов фирмой IBM [21.30]; а также систему Distributed INGRES, которая 
является распределенной версией системы INGRES [21.28] и создана также в 
начале 80-х годов в Калифорнийском университете в Беркли. 
    Что касается коммерческих продуктов, то в настоящее время в большинстве 
реляционных систем предусмотрены разные виды поддержки использования 
распределенных баз данных с разной степенью функциональности. Среди таких 
систем наиболее известны система INGRES/STAR отделения Ingres Division фирмы 
The ASK Gn Inc., система ORACLE? фирмы Oracle Corporation, а также модуль 
распределена^ работы системы DB2 фирмы IBM. 

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

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

    566 Часть V. Дополнительные аспекты

существует несколько причин, по которым успешно функционирующая распределенная 
система, должна быть реляционной, а реляционная технология является 
предпосылкой создания эффективной методики распределенной работы [21.14]. 
Причины такого положения дел разъясняются далее в этой главе. Фундаментальный принцип 
    Теперь, после краткого введения, можно привести формулировку 
фундаментального принципа распределенной базы данных [21.13], 
    • Для пользователя распределенная система должна выглядеть точно так же, 
как НЕраспределенная система. 
    Иначе говоря, работу пользователей в распределенной системе следует 
организовать таким же образом, как если бы она не была распределенной. Все 
связанные с распределенными системами проблемы являются (или должны быть) 
внутренними и должны возникать только на внутреннем уровне или уровне 
разработки, а не на внешнем уровне или на уровне пользователей. 

    Замечание. В данном случае термин "пользователи" относится к пользователям 
(потребителям или разработчикам приложений), которые выполняют операции 
управления данными. Все эти операции должны оставаться логически неизменными, 
в отличие от операций определения данных, которые, наоборот, могут быть 
расширены в распределенной системе. Например, пользователь на узле Л" может 
указать, что хранимое отношение можно разделить на "фрагменты" для физического 
хранения на узлах У и Z (более подробно фрагментация обсуждается ниже). 

    Изложенный фундаментальный принцип приводит к набору перечисленных ниже 
вспомогательных правил и целей, которые подробнее рассматриваются далее в этой 
главе. (Термин "правило" вместе с разъяснением смысла этого понятия было 
впервые предложено в [21.13], а понятие "фундаментальный принцип" было названо 
в этой статье "правилом нуль" (Rule Zero). Однако далее вместо термина 
"правила" будет использоваться более подходящий и менее догматичный термин "цель".) 
    1. Локальная автономия. 
    2. Независимость от центрального узла. 
    3. Непрерывное функционирование. 
    4. Независимость от расположения. 
    5. Независимость от фрагментации. 
    6. Независимость от репликации. 
    7. Обработка распределенных запросов. 
    8. Управление распределенными транзакциями. 
    9. Независимость от аппаратного обеспечения, 
    10. Независимость от операционной системы. И. Независимость от сети. 12. 
Независимость от СУБД. 
    Эти двенадцать целей не являются независимыми одна от другой, к тому же не 
все они равнозначны (различные пользователи могут придавать разное значение 
разным целям в разном окружении), ими также не исчерпывается список всех 
возможных целей. Однако они весьма полезны для понимания основ распределенной 
технологии и для общей характеристики функциональности некоторой 
распределенной системы. Именно в таком плане они будут обсуждаться далее в 
этой главе. Сначала будет представлен краткий обзор каждой из этих целей, а 
более подробно некоторые из них рассматриваются в следующих разделах. Далее 
приводится обсуждение системы клиент/сервер, а затем рассматривается

    Глава 21. Распределенные базы данных и системы клиент/сервер	567 

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

    21.3. Двенадцать целей Локальная автономия 

    В распределенной системе узлы следует делать автономными. Локальная 
автономия означает, что операции на данном узле управляются этим узлом, т.е. 
функционирование любого узла X не зависит от успешного выполнения некоторых 
операций на каком-то другом узле Y (в противном случае может возникнуть крайне 
нежелательная ситуация, а именно: выход из строя узла Y может привести к 
невозможности исполнения операций на узле X, даже если с узлом X ничего не 
случилось). Из принципа локальной автономии также следует, что владение и 
управление данными осуществляется локально вместе с локальным ведением учета. 
Действительно, даже если доступ к данным осуществляется с других удаленных 
узлов, все они относятся к некоторой локальной базе данных. Такие вопросы, как 
безопасность, целостность и структура хранения локальных данных, остаются под 
контролем и юрисдикцией этого локального узла. 
    В действительности цель локальной автономии достигается не полностью, 
поскольку есть множество ситуаций, в которых узел X должен предоставить 
некоторую часть управления другому узлу Y. Поэтому цель достижения локальной 
автономии требует более точной формулировки, а именно: узлы следует делать 
автономными в максимально возможной степени. Более подробные сведения по этой 
теме можно найти в [21.13]. 

    Независимость от центрального узла 

    Под локальной автономией подразумевается, что все узлы должны 
рассматриваться как равные. Следовательно, не должно существовать никакой 
зависимости и от центрального "основного" узла с некоторым централизованным 
обслуживанием, например централизованной обработкой запросов, централизованным 
управлением транзакциями или централизованным присвоением имен. Таким образом, 
вторая цель является логическим следствием первой (если достигнута первая 
цель, то вторая — тем более). Однако, если локальная автономия не достигается 
в полной мере, даже достижение независимости от центрального узла само по себе 
очень важно и может рассматриваться как отдельная цель. 
    Зависимость от центрального узла нежелательна по крайней мере по двум 
причинам. Во-первых, центральный узел может быть "узким" местом всей системы, 
а во-вторых, более важно то, что система в таком случае становится уязвимой, 
т.е. при повреждении центрального узла может выйти из строя вся система. 

    568	Часть V. Дополнительные аспекты 


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

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

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

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

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

    В системе поддерживается фрагментация данных, если некое хранимое 
отношение в целях физического хранения можно разделить на части, или 
"фрагменты". Фрагментация желательна для повышения производительности системы, 
поскольку данные лучше хранить в том месте, где они наиболее часто 
используются. При такой организации многие операции будут чисто локальными, а 
объем пересылаемых в сети данных снизится. Например, рассмотрим отношение 
сотрудников ЕМР, показанное на рис. 21.2. В системе, в которой поддерживается 
фрагментация, определены два фрагмента, показанных в нижней части рис. 21.2. 

    Глава 21. Распределенные базы данных и системы клиент/сервер	569 


    FRAGMENT EMP INTO 
    N_EMP AT SITE 'New York' WHERE DEPT# = 'Dl' OR DEPT# = 'D3', L_EMP AT SITE 
'London' WHERE DEPT# = 'D2' ; 

    Замечание. Предполагается, что кортежи сотрудников некоторым заданным 
образом непосредственно отображаются на структуру физического хранения, D1 и 
D3 являются отделами в Нью-Йорке (New York), a D2 — в Лондоне (London). Иначе 
говоря, в Нью-Йорке будут храниться кортежи сотрудников из Нью-Йорка, а в 
Лондоне — кортежи сотрудников из Лондона. Обратите внимание на внутренние 
системные имена фрагментов: N_EMP и L_EMP. 


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

    EMP   EMP#   DEPT#  SALARY 
    E1           D1            40K E2          D1            42K E3           
D2            ЗОК Е4          D2            35К Е5           D3            48К 
    I 
    New York		L_EMP			London 
    N_EMP 
    ЕМР#	DEPT#   SALARY	EMP#		DEPT#	SALARY 
    Е1 Е2 Е5	D1            40K D1            42K D3            48K	E3 E4		D2 
D2	30K 45K 
    
    
    Рис. 21.2. Пример фрагментации 

    Существует два основных типа фрагментации — горизонтальная и вертикальная, 
которые связаны с реляционными операциями выборки и проекции соответственно. 
(На рис. 21.2 показана горизонтальная фрагментация.) Иначе говоря, фрагментом 
может быть любое произвольное подчиненное отношение, которое можно вывести из 
исходного отношения с помощью операций выборки и проекции. При этом следует 
учесть приведенные ниже допущения. 
    •   Предполагается без утраты общности, что все фрагменты данного 
отношения независимы, т.е. ни один из фрагментов не может быть выведен из 
других фрагментов либо иметь выборку или проекцию, которая может быть выведена 
из других фрагментов. (Если есть необходимость сохранить одну и ту же 
информацию в нескольких разных местах, для этого следует использовать механизм 
репликации системы. Подробнее это обсуждается ниже.) 
    •   Проекции не должны допускать потерю информации (см. главы 10, 11). 
    Реконструкцию исходного отношения на основе его фрагментов можно 
осуществить с помощью операций соединения (для вертикальных фрагментов) и 
объединения (для горизонтальных фрагментов). Обратите внимание, что в случае 
объединения не потребуется выполнять операцию исключения дубликатов 
(объясните, почему). 

    Замечание. В отношении вертикальной фрагментации необходимо привести 
дополнительные разъяснения. Как уже упоминалось выше, при такой фрагментации 
не должна допускаться потеря информации, потому что фрагментация отношения ЕМР 
на проекции (ЕМР#, DEPT#) и (SALARY) не будет достоверной. Однако в некоторых 
системах хранимые отношения имеют скрытый атрибут TID ("tuple ID" — 
идентификатор кортежа), т.е. физический или логический адрес этого кортежа. 
Атрибут TID 

    570 Часть V. Дополнительные аспекты 

является потенциальным ключом для данного кортежа, поэтому если бы 
отношение ЕМР содержало такой атрибут, то оно могло бы быть корректно 
фрагментировано на проекции (TID, ЕМР#, DEPT#) и (TID, SALARY), поскольку 
такая фрагментация происходит без потери информации. 
    Обратите внимание, что именно легкость выполнения фрагментации и 
реконструкции — одна из многих причин, по которым для распределенных систем 
используется реляционная модель. Дело в том, что в ней предусмотрены именно те 
операции, которые необходимы для выполнения таких задач [21.14]. 
    Наконец, переходя к главному, нужно сказать, что в системе, поддерживающей 
фрагментацию данных, следует также предусмотреть поддержку независимости от 
фрагментации (или прозрачность фрагментации). Иными словами, с логической 
точки зрения пользователям следует обеспечить такой режим работы, при котором 
данные кажутся вовсе нефрагментированными. Независимость от фрагментации (как 
и независимость от расположения) весьма желательна, поскольку упрощает 
пользовательские программы и терминальную деятельность. В частности, она 
позволяет в любой момент осуществить дефрагментацию данных (и фрагменты могут 
быть перераспределены в любой момент времени) в ответ на изменение требований 
к производительности, причем без необходимости отключения любых 
пользовательских программ и терминальной деятельности. 
    Независимость от фрагментации предполагает, что данные будут представлены 
для пользователей в виде логически комбинированных фрагментов на основе 
соответствующих объединений и соединений. При этом системный оптимизатор 
отвечает за определение фрагментов, к которым необходимо обеспечить физический 
доступ для выполнения любого заданного пользователем запроса. В качестве 
примера допустим, что для фрагментации, показанной на рис. 21.2, пользователь 
задает следующий запрос: 

    ЕМР WHERE SALARY > 4 OK AND DEPT# =   'Dl' 

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

    ЕМР = N_EMP UNION L_EMP 

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

    ( N_EMP UNION LJMP  )   WHERE SALARY > 4OK AND DEPTtt =   'Dl' 
    А это выражение, в свою очередь, можно преобразовать к виду 
    ( N_EMP WHERE SALARY > 40К AND DEPT# =   'Dl'   ) 
    ONION ( L_EMP WHERE SALARY > 40K AND DEPTi =   'Dl'   ) 

    Из хранящегося в каталоге определения фрагмента L_EMP оптимизатору 
известно о том, что второе из этих двух выражений даст в результате пустое 
отношение (условие целостности DEPT# = 'Dl' AND DEPT# = 'D21 не может быть 
оценено как истинное). Таким образом, все выражение в целом можно свести к 
следующему упрощенному виду: 

    HJMP WHERE SALARY > 40K AND DEPT# = ' Dl' 

    Теперь оптимизатору известно, что доступ требуется осуществить только к 
узлу в Нью-Йорке. Упражнение. Рассмотрите действия, выполняемые оптимизатором 
при работе с приведенным ниже запросом. 

    ЕКР WHERE SALARY > 40K 

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

    Глава 21, Распределенные базы данных и системы клиент/сервер	571 

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

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

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

    REPLICATE N_EMP 
    LN_EMP AT SITE 'London' ; 
    REPLICATE L_EMP 
    NL_EMP AT SITE 'New York1 ; 
    Обратите внимание на внутренние системные имена реплик NL_EMP и LN_EMP. 
    New York						1 L_EMP			London ======= 
    N_EMP 
    ЕМР#	DEPT#	SALARY			ЕМР#	DEPT#	SALARY 
    Е1 Е2 Е5	D1 D1 D3	40K 42K 48K			ЕЗ Е4	D2 D2	ЗОК 35К 
    ЕМР# = Е=3~ = Е4	DEPT#	SALARY			ЕМР# = Ё~1= = Е2 Е5	DEPT#	SALARY 
    D2 D2	ЗОК 35K				D1 D1 D3	40К 42К 48К 
    NL_EMP (реплика L_EMP) 
    
    
    Рис. 21.3. Пример репликации 

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

    572 Часть V. Дополнительные аспекты 

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

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

    Здесь рассматриваются два важных и обширных вопроса. 
    •  Рассмотрим запрос "Получить сведения о находящихся в Лондоне 
поставщиках красных деталей", причем допустим, что пользователь находится в 
Нью-Йорке, а данные хранятся на узле в Лондоне. Предположим также, что такому 
запросу удовлетворяют п поставщиков. Если система является реляционной, то в 
запросе будут содержаться два сообщения — одно с запросом из Нью-Йорка для 
Лондона, а другое с возвращаемым результатом, т.е. набором из п кортежей, 
которые пересылаются из Лондона в Нью-Йорк. С другой стороны, если система не 
является реляционной, а работает в режиме последовательной обработки данных, 
то в запрос будет включено 2п сообщений — я из Нью-Йорка в Лондон с запросом 
сведений о "следующем" поставщике, а также п из Лондона в Нью-Йорк для 
возвращения сведений о "следующем" поставщике. Этот пример иллюстрирует, что 
реляционная система по производительности может на несколько порядков 
превосходить нереляционную (по крайней мере на уровне множеств). 
    •  Вопрос оптимизации более важен для распределенной, нежели для 
централизованной системы. Основная причина заключается в том, что для 
выполнения охватывающего несколько узлов запроса существует довольно много 
способов перемещения данных по сети. В таком случае чрезвычайно важно найти 
наиболее эффективную стратегию. Например, запрос на объединение отношения Rx, 
хранимого на узле X, и отношения Ry, хранимого на узле У, мог бы быть выполнен 
с помощью перемещения отношения Rx на узел Y, перемещения отношения Ry на узел 
X или перемещения этих двух отношений на третий узел Z (и т.д.). Эта ситуация 
подробно рассматривается ниже, а здесь следует отметить, что на основе 
некоторых правдоподобных предположений можно составить шесть различных 
стратегий обработки такого запроса. При этом время отклика может варьироваться 
от минимального значения, равного одной десятой секунды, до максимального, 
равного приблизительно шести часам] Таким образом, оптимизация может оказаться 
весьма существенной, и э тот факт, в свою очередь, может рассматриваться как 
еще одна причина, по которой распределенные системы всегда являются 
реляционными. Особенность заключается в том, что запросы могут быть 
оптимизированы на уровне множеств, но не на уровне записей. 

    Глава 21, Распределенные базы данных и системы клиент/сервер	573 


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

    Существует два основных аспекта управления обработкой транзакций, а 
именно: управление восстановлением и управление параллелизмом, каждому из 
которых в распределенных системах должно уделяться повышенное внимание. 
Однако, прежде чем перейти к подробному описанию, следует ввести новое понятие 
"агент". В распределенной системе выполнение одной транзакции может быть 
связано с исполнением кода на нескольких узлах, в частности она может 
выполнять операции обновления на нескольких узлах. В таком случае говорят, что 
каждая транзакция состоит из нескольких агентов, т.е. процессов, выполняемых 
на данном узле по указанию заданной транзакции. Системе необходимо указать, 
что некоторые два агента представляют собой части одной и той же транзакции, 
например для того, чтобы избежать возникновения тупиковой ситуации для двух 
агентов, которые содержит одна и та же транзакция. 
    Теперь следует сказать несколько слов об управлении восстановлением. Для 
подтверждения того, что в распределенном окружении данная транзакция является 
атомарной (типа все-или-ничего), система должна убедиться, что агенты 
заданного набора должны быть все вместе либо завершены, либо отменены. Эта 
цель может быть достигнута только за счет реализации протокола двухфазной 
фиксации, который уже обсуждался (хотя и не в контексте распределенного 
окружения) в главе 13. Несколько более подробных замечаний на эту тему 
представлено ниже. 
    Что касается управления параллелизмом, то в распределенных системах, так 
же как и в нераспределенных, это управление обычно основано на блокировке. (В 
нескольких более современных системах уже используются средства 
многовариантного управления [14.1], однако в большинстве систем для этого все 
же продолжает использоваться метод блокировки.) Более подробно эта тема 
рассматривается ниже в данной главе. 

    Независимость от аппаратного обеспечения 

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

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

    Эта цель является следствием предыдущей, и ее описание будет также 
немногословным. Очевидно, важно запустить одну и ту же СУБД не только на 
разном аппаратном обеспечении, но и на разных операционных системах, причем 
даже в тех случаях, когда разные операционные системы используются на 
однотипном аппаратном обеспечении. Например, для того чтобы версии СУБД для 
операционной системы MVS, а также для систем UNIX и PC/DOS могли совместно 
работать в одной и той же распределенной системе. 

    Независимость от сети 

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

    574	Часть V. Дополнительные аспекты 


    Независимость от СУБД 

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

    21.4, Проблемы распределенных систем 

    Ниже более подробно описываются некоторые уже упомянутые проблемы. 
Основная проблема информационных сетей, по крайней мере глобальных, 
заключается в том, что они достаточно .медленны. В типичной глобальной сети 
интенсивность обмена данными равна приблизительно 5 или 10 тыс. байт в 
секунду, а для обычного жесткого диска интенсивность обмена данными— около 5 
или 10 .млн байт в секунду [13.11]. (С другой стороны, в локальных 
вычислительных сетях уже может поддерживаться скорость обмена данными, 
сравнимая с интенсивностью обмена на жестких дисках.) Вследствие этого 
основным требованием к распределенным системам является минимизация 
использования сети, т.е. сокращение до минимума количества и объема 
пересылаемых в сети сообщений. Стремление к достижению этой цели приводит, в 
свою очередь, к необходимости решения перечисленных ниже проблем (хотя 
перечень всех проблем не исчерпывается этим списком). 
    •	Обработка запросов. 
    •	Управление каталогом. 
    •	Распространение обновления. 
    •	Управление восстановлением. 
    •	Управление параллелизмом. 

    Обработка запросов 

    При минимизации использования сети предполагается, что сама по себе 
оптимизация запроса, как и его исполнение, должна быть распределенной. Иначе 
говоря, общий процесс оптимизации обычно состоит из этапа глобальной 
оптимизации, который сопровождается несколькими этапами локальной 
оптимизацией. Например, допустим, что запрос Q задан на узле X и включает 
объединение отношения Ry, содержащего сто кортежей на узле Y, и отношения Rz, 
содержащего миллион кортежей на узле Z. Оптимизатор на узле X выберет 
глобальную стратегию для выполнения запроса Q; при этом, очевидно, лучше 
переместить отношение Ry на узел Z, а не отношение /Ьна узел К (и конечно же, 
не следует перемещать оба отношения Ry и Rz на узел X), Тогда сразу после 
перемещения отношения Ry на узел Z стратегия выполнения объединения на узле Z 
будет выбрана локальным оптимизатором на узле Z. 

    Глава 21, Распределенные базы данных и системы клиент/сервер	575 

    Приведенная ниже подробная иллюстрация этих идей основана на примере из 
[21.12], который, в свою очередь, заимствован из статьи Роти (Rothnie) и 
Гудмана (Goodman) [21.25]. 
    Рассмотрим базу данных поставщиков и деталей (упрощенный вариант): 
    S {	S#,	CITY }	10	000 хранимых кортежей на узле А 
    Р {	Р#,	COLOR }	100	000 хранимых кортежей на узле В 
    SP {	S#,	Р# }	1 000	000 хранимых кортежей на узле А 
    Предполагается, что каждый хранимый кортеж имеет размер 25 байт (200 бит). 
Запрос "Получить сведения о находящихся в Лондоне (London) поставщиках красных 
(Red) деталей: 
    S.S# WHERE EXISTS SP EXISTS P ( S.CITY = 'London1 AND 
    S.S# = SP.S# AND SP.P# = P.P# AND P.COLOR = 'Red' ) 
    Оценочные границы промежуточных результатов: 
    Число красных деталей	=10 Число поставок, выполняемых поставщиками из 
Лондона = 100 000 
    Предполагаемые параметры обмена данными в сети: 
    Интенсивность обмена данными = 50 000 бит/с Задержка доступа	= О,1 с 
    Теперь можно вкратце рассмотреть шесть возможных стратегий обработки этого 
запроса с вычислением для каждой /-стратегии общего времени передачи данных 
7[/'] по следующей формуле: 
    T[i] = общая задержка доступа + (общий объем данных / интенсивность обмена 
данными) = ( число сообщений / 10 ) + ( число бит / 50 000) 
    1.  Переместить отношение Р на узел А и выполнить запрос на узле А. 
    Г[1] = 0,1 + (100 000 * 200 ) / 50 000 = = приблизительно 400 с (6,67 мин) 
    2.  Переместить отношения S и SP на узел В и выполнить запрос на узле В. 
    Т[2] = 0,2 + ( ( 10 000 + 1 000 000 ) * 200 ) / 50 000 = = приблизительно 
4 040 с (1,12 ч) 
    3.  Соединить отношения S и SP на узле А, выбрать из полученного 
результата кортежи для поставщиков из Лондона, а затем для каждого кортежа на 
узле В проверить, не является ли соответствующая деталь красной. Каждая из 
этих проверок будет содержать два сообщения: запрос и ответ. Время передачи 
данных для таких сообщений будет значительно меньше по сравнению с задержкой доступа. 
    Т[3]   = приблизительно 20 000 с   (5,56 ч) 
    4.  Выбрать из отношения Р на узле В кортежи, соответствующие красным 
деталям, а затем для каждого кортежа на узле А проверить, не поставляется ли 
соответствующая деталь поставщиком из Лондона. Каждая из этих проверок будет 
содержать два сообщения: запрос и ответ. Время передачи данных для этих 
сообщений опять будет значительно меньше по сравнению с задержкой доступа. 
    Т[4] = приблизительно 2 с 
    5.  Соединить отношения S и SP на узле А, выбрать из полученного 
результата кортежи для поставщиков из Лондона, результат разбить на проекции 
по атрибутам S# и Р#, а затем переместить на узел В. Завершить выполнение 
запроса на узле В. 
    Т[5] = 0,1 + ( 100 000 * 200 ) / 50 000 = приблизительно 400 с (6,67 мин) 
    6.  Выбрать из отношения Р на узле В кортежи, соответствующие красным 
деталям, а затем переместить результат на узел А. Завершить выполнение запроса 
на узле А. 
    Т[6]   = 0,1 +   (  10  * 200  )   / 50 000 = приблизительно 0,1 с 

    576 Часть V. Дополнительные аспекты 

    На рис. 21.4 эти результаты представлены в одной таблице. 

    Стратегия	Метод	Время передачи данных 
    =^====: 1	Переместить отношение Р на узел А	6, 67 мин 
    2	Переместить отношения S и SP на узел В	1,12 ч 
    3	Для каждой поставки из Лондона проверить, не является	5,56 ч 
    ли деталь красной 
    4	Для каждой красной детали проверить, не поставляется	2 с 
    ли она из Лондона 
    5	Переместить сведения о поставках из Лондона на узел В	6, 67 мин 
    6	Переместить сведения о красных деталях на узел А	0,1с (наилучший ре
    зультат) 

    Рис. 21.4. Стратегии распределенного выполнения запроса (итоги) 

    Внимательно ознакомившись с этими результатами, можно отметить следующие 
важные особенности: 
    •  Каждая из шести стратегий представляет собой один из возможных подходов 
к решению этой проблемы, несмотря на очень значительные вариации во времени 
передачи данных. 
    •  Интенсивность обмена данными и задержка доступа являются важными 
факторами, влияющими на выбор той или иной стратегии. 
    • Для плохих стратегий продолжительность операций вычисления и 
ввода-вывода данных пренебрежимо мала по сравнению со временем передачи 
данных. (Это в большей или меньшей мере может относиться и к более совершенным 
стратегиям [21.27].) 
    В дополнение к сказанному выше следует отметить, что некоторые стратегии 
позволяют выполнять параллельную обработку на двух узлах. Таким образом, время 
отклика в такой системе может оказаться меньше времени отклика в 
централизованной системе. Обратите внимание, что в данном обсуждении 
игнорировался вопрос о том, какой узел получает окончательные результаты. 

    Управление каталогом 

    Каталог распределенной системы содержит не только обычные данные, 
касающиеся базовых отношений, представлений, индексов, пользователей и т.д., 
но также и всю информацию, необходимую для обеспечения независимости 
размещения, фрагментации и репликации. В таком случае возникает вопрос: где и 
как следует хранить системный каталог? Ниже перечислены некоторые варианты 
хранения системного каталога. 
    !. Централизованный каталог. Весь каталог хранится в одном месте, т.е. на 
центральном узле. 
    2. Полностью редуцированный каталог. Весь каталог полностью хранится на 
каждом узле. 
    3. Секционированный каталог. На каждом узле содержится его собственный 
каталог для объектов, хранимых на этом узле. Общий каталог является 
объединением всех разъединенных локальных каталогов. 
    4.  Комбинация первого и третьего вариантов. На каждом узле хранится 
собственный локальный каталог (как в п. 3), кроме того, на одном центральном 
узле хранится унифицированная копия всех этих локальных каталогов (как в п. 1). 
    Для каждого подхода характерны определенные недостатки и проблемы. В 
первом подходе, очевидно, не достигается "независимость от центрального узла". 
Во втором утрачивается автономность функционирования, поскольку при обновлении 
каждого каталога это обновление придется распространить на каждый узел. В 
третьем выполнение 

    Глава 21. Распределенные базы данных и системы клиент/сервер 577 

нелокальных операций становится весьма дорогостоящим (для поиска 
удаленного объекта потребуется в среднем осуществить доступ к половине 
имеющихся узлов). Четвертый подход более эффективен, чем третий (для поиска 
удаленного объекта потребуется осуществить доступ только к одному удаленному 
каталогу), но в нем снова не достигается "независимость от центрального узла". 
На самом деле в традиционных системах не используется ни один из описанных 
выше подходов! В качестве примера здесь рассматривается подход, использованный 
в системе R* [21.30]. 
    Для того чтобы описать структуру каталога системы R*, необходимо прежде 
всего рассмотреть принятый в ней порядок именования объектов. Именование 
объектов является существенным аспектом распределенных систем, поскольку, если 
два разных узла А и В содержат хранимое отношение под одинаковым именем R, это 
приводит к необходимости выработки некоторого метода обеспечения уникальности 
имен в рамках всей системы. Однако при указании пользователю уточненного имени 
(например, A.R и B.R) нарушается требование независимости расположения. В 
таком случае необходимо отображение известных пользователям имен на 
соответствующие системные имена. 
    В системе R* используется следующий подход к этой проблеме. В ней вводятся 
понятия печатного имени, т.е. имени объекта, на которое обычно ссылаются 
пользователи (например, в выражениях SQL), а также системного имени, которое 
является глобальным уникальным внутренним идентификатором этого объекта. 
Системное имя содержит четыре компонента. 
    •  Идентификатор создателя объекта. 
    •  Идентификатор узла создателя, т.е. узла, на котором была выполнена 
операция создания объекта. 
    • Локальное имя, т.е. неуточненное имя объекта. 
    •  Идентификатор узла хранения, т.е. узла, на котором этот объект хранился 
в исходном состоянии. 
    Так, системное имя 

    MARYLIN @ NEWYORK . STATS @ LONDON 

    идентифицирует объект (например, хранимое отношение) с локальным именем 
STATS, созданный пользователем Marilyn на узле в Нью-Йорке и изначально 
хранившийся на узле в Лондоне. Такое имя гарантировано от каких-либо изменений 
даже при перемещении этого объекта на другой узел (подробнее это объясняется ниже). 
    Как уже отмечалось, пользователи обычно применяют к объектам их печатные 
имена, которые состоят из простого неуточненного имени: например, либо 
"локального компонента" системного имени (STATS в рассматриваемом примере), 
либо синонима системного имени, определенного с помощью специальной инструкции 
CREATE SYNONYM языка SQL, используемого в системе R*. Ниже приводится пример 
такой инструкции. 

    CREATE SYNONYM MSTATS TOR MARILYN @ NEWYORK . STATS @ LONDON ; 

    Теперь можно использовать одно из следующих выражений: 

    SELECT ... FROM STATS ... ; SELECT . .. FRCM MSTATS ...; 

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

    578	Часть V. Дополнительные аспекты 

    Во втором случае (при использовании синонимов) системное имя определяется 
с помощью опроса соответствующей таблицы синонимов. Эти таблицы 
рассматриваются как первый компонент каталога, а каждый узел содержит набор 
таблиц для всех пользователей, известных на данном узле, с отображением 
синонимов этого пользователя на системные имена. 
    В дополнение к таблицам синонимов на каждом узле поддерживаются следующие объекты: 
    1. Элемент каталога для каждого объекта, созданного на этом узле. 
    2.  Элемент каталога для каждого объекта, хранимого в данный момент на 
этом узле. 
    Допустим, пользователь создает запрос для поиска синонима MSTATS. Сначала 
система ищет соответствующее ему системное имя в соответствующей таблице 
синонимов (чисто локальная подстановка). После этого становится известным 
место создания объекта; в рассматриваемом примере это Лондон. Затем система 
опрашивает каталог Лондона, что в общем случае приводит к подстановке с 
удаленным доступом (первый удаленный доступ). Каталог Лондона будет содержать 
элемент для данного объекта согласно упомянутому выше пункту 1. Если искомый 
объект находится все еще в Лондоне, то он будет немедленно найден. Однако, 
если он перемещен, например в Лос-Анджелес, в таком случае это будет указано в 
элементе каталога Лондона. Благодаря такой организации система теперь может 
опросить каталог Лос-Анджелеса (второй удаленный доступ), который согласно 
пункту 2 будет содержать элемент для искомого объекта. Таким образом, этот 
объект будет найден, по крайней мере, с помощью двух попыток удаленного доступа. 
    Более того, при очередной миграции объекта, например в Сан-Франциско, в 
системе будут выполнены следующие действия: 
    • Вставлен элемент каталога Сан-Франциско. 
    • Удален элемент каталога Лос-Анджелеса. 
    • Элемент каталога Лондона, указывающий на Лос-Анджелес, будет заменен 
элементом каталога, указывающим на Сан-Франциско. 
    Общий эффект от их выполнения заключается в том, что объект снова может 
быть найден с помощью всего лишь двух попыток удаленного доступа. К тому же 
такая система является действительно распределенной, так как в ней нет 
каталога на центральном узле, а также не существует никакой другой возможности 
для глобального краха системы. 
    Следует отметить, что в модуле распределенной работы в системе DB2 
используется схема именования объектов, похожая на описанную выше, но не 
идентичная ей. 

    Распространение обновления 

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

    Глава 21. Распределенные базы данных и системы клиент/сервер	579 

    Общая схема устранения этой проблемы (и не единственно возможная в этом 
случае), называемая схемой первичной копии, описана ниже. 
    •  Одна копия каждого реплицируемого объекта называется первичной копией, 
а все остальные — вторичными. 
    •  Первичные копии различных объектов находятся на различных узлах (таким 
образом, эта схема является распределенной). 
    •  Операции обновления считаются завершенными, если обновлены все 
первичные копии. В таком случае в некоторый момент времени узел, содержащий 
такую копию, несет ответственность за распространение операции обновления на 
вторичные копии. (Однако поскольку свойства транзакции АСИД (атомарность, 
согласованность, изоляция, долговечность— см. главу 13) должны выполняться, то 
подразумевается, что "некоторый момент" времени предшествует завершению 
исполнения транзакции. Подробные замечания на эту тему приведены ниже.) 
    Конечно, данная схема приводит к некоторым дополнительным проблемам, 
изложение которых выходит за рамки этой книги. Обратите внимание, однако, что 
эти проблемы приводят к нарушению требования локальной автономии, поскольку 
даже если локальная копия остается доступной, выполнение транзакции может 
потерпеть неудачу из-за недоступности удаленной (первичной) копии некоторого объекта. 

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

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

    Управление восстановлением 

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

    580 Часть V. Дополнительные аспекты 

любой среде, в которой одна транзакция может взаимодействовать с 
несколькими автономными администраторами ресурсов. Однако она особенно важна в 
распределенной системе, поскольку администраторы ресурсов, т.е. локальные 
СУБД, действуют на разных узлах и, следовательно, автономны. 
    Здесь необходимо отметить несколько важных особенностей. 
    1.  Стремление к "независимости от центрального узла" означает, что 
функция координатора (см. главу 13) не должна присваиваться ни одному из узлов 
сети, вместо этого она должна выполняться для разных транзакций различными 
узлами. Обычно она выполняется узлом, на котором данная транзакция была 
запущена. Таким образом, каждый узел должен для одних транзакций выполнять 
роль узла-координатора, а для других — узла-участника. 
    2.  При двухфазной фиксации требуется, чтобы координатор обменивался 
данными с каждым узлом-участником, что, в свою очередь, означает большее 
количество сообщений и больше накладных расходов. 
    3.  Если узел Y действует как участник процесса двухфазной фиксации, 
координируемого узлом X, то узел Y должен выполнять любые действия, 
предписываемые узлом X (например, завершение или отмену выполнения 
транзакции). При этом неизбежна утрата локальной автономности. 
    4.  В идеальной ситуации, конечно, хотелось бы, чтобы процесс двухфазной 
фиксации продолжался несмотря на неисправность сети или отдельных узлов либо 
был устойчив по отношению к любым возможным видам неисправности. К сожалению, 
легко заметить, что эта проблема неразрешима в принципе, т.е. не существует 
никакого конечного протокола, который мог бы гарантировать, что все агенты 
одновременно завершат выполнение успешной транзакции либо отменят выполнение 
неуспешной транзакции несмотря на неисправности произвольного характера. Можно 
предположить и обратную ситуацию, т.е. что такой протокол все-таки существует. 
Пусть минимальное количество сообщений, необходимых для осуществления этого 
протокола, равняется N. Предположим теперь, что последнее из этих /V сообщений 
утеряно по какой-то причине. Тогда либо это сообщение не является необходимым, 
что противоречит исходному предположению о минимально необходимом количестве 
сообщений N, либо такой протокол не будет работать. Любой из этих случаев 
ведет к противоречию, из чего можно заключить, что такого протокола не существует. 
    5. Описанный в этой книге протокол двухфазной фиксации (глава 13) может 
рассматриваться как основной протокол. Однако существует множество модификаций 
этого основного протокола, которые можно и следовало бы применить на практике. 
Например, в [21.22] описан вариант под названием протокол предполагаемой 
фиксации, в котором при успешном выполнении транзакции число сообщений 
уменьшается за счет введения дополнительных сообщений для случая неуспешного 
выполнения транзакции. В [21.14] содержится краткое введение в эту тему. 

    Управление параллелизмом 

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

    Глава 21. Распределенные базы данных и системы клиент/сервер	581 

объектов, хранимых на этом узле (как это было бы при соблюдении локальной 
автономии), то для простейшего способа управления параллелизмом потребовалось 
бы по крайней мере 5п сообщений: 
    п запросов на блокировку, 
    п разрешений на блокировку, 
    п сообщений об обновлении, 
    п подтверждений, 
    п запросов на снятие блокировки. 
    Конечно, можно легко усовершенствовать этот способ, используя 
подтверждения, вложенные в блок данных обратного направления. Таким образом 
могут комбинироваться запрос на блокировку и сообщения об обновлении, а также 
разрешение на блокировку и подтверждения. Но даже в таком случае общее время 
обновления может быть на несколько порядков выше, чем в централизованной системе. 
    Обычный подход к этой проблеме заключается в принятии стратегии первичной 
копии, которая в краткой форме была представлена выше. Для данного объекта R 
узел, содержащий первичную копию объекта /?, будет управлять всеми операциями 
блокировки, включающими R (помните, что первичные копии разных объектов в 
общем случае могу/быть расположены на различных узлах). При такой стратегии 
множество всех копий объекта в целях блокировки может рассматриваться как 
единый объект, а общее число сообщений будет снижено от 5п до 2п+3 (один 
запрос на блокировку, одно разрешение на блокировку, п обновлений, п 
подтверждений и один запрос на снятие блокировки). Однако обратите внимание, 
что при таком решении опять утрачивается автономность, т.е. транзакция может 
оказаться неуспешной, если первичная копия недоступна (даже при использовании 
транзакции только для чтения), а локальная копия доступна. (Заметьте, что для 
блокировки первичной копии необходимы не только операции обновления, но также 
и операции извле чения [21.14]. Таким обра зом, неприятный побочный эффект при 
использовании стратегии первичной копии заключается в снижении 
производительности и доступности данных как для операций извлечения, так и для 
операций обновления.) 
    Другой проблемой блокировки в распределенной системе является то, что она 
может привести к глобальному тупику, который охватывает два или более узлов. 
На рис. 21.5 представлен пример возникновения такого тупика. Узел X 

    Ожидание окончания 
    выполнения транзакции 
    Т1 на узле Y 
    Блокировка Lx 
    "т	1  • ———————————	Т2 
    Ожидание снятия 
    блокировки на узле X транзакцией Т1 
    ания акции г			Ож выло 
    Т	1 - ——————————— >	Т2 
    Ожидание снятия 
    блокировки на узле Y  Блокировка транзакцией Т2    Ly 
    Ожидание окончания 
    выполнения транзакции 
    Т2 на узле X 
    Узел Y 

    Рис. 21.5. Пример глобального тупика 


    582     Часть V. Дополнительные аспекты 

    1. Агент транзакции 72 на узле X ожидает, когда агент транзакции 77 снимет 
блокировку на узле X. 
    1.   Агент транзакции 77 на узле X ожидает, когда закончится выполнение 
транзакции 77 на узле Y. 
    3.  Агент транзакции 77 на узле К ожидает, когда агент транзакции Т2 
снимет блокировку на узле Y. 
    4.  Агент транзакции 77 на узле Y ожидает, когда закончится выполнение 
транзакции 77 на узле X, Тупиковая ситуация! 
    Проблема тупика такого типа состоит в том, что ни один из узлов не может 
обнаружить тупик, используя только информацию, которая сосредоточена на этом 
узле. Иначе говоря, в локальных диаграммах ожидания нет никаких циклов, но они 
появятся при объединении локальных диаграмм в глобальную диаграмму ожидания. 
Отсюда следует, что обнаружение глобальных тупиков связано с увеличением 
накладных расходов, поскольку для этого требуется дополнительно совместить 
отдельные локальные диаграммы. 
    Весьма элегантная (распределенная) схема обнаружения глобального тупика 
приводится в публикациях, посвященных системе R*, например в [21.30]. 

    21.5. Шлюзы 

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

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

    Предположим теперь, что существует два узла — X и У, на которых запущены 
соответственно системы INGRES и ORACLE. Допустим также, что некоторый 
пользователь U на узле X желает взглянуть на распределенную базу данных, 
которая содержит данные из базы данных INGRES на узле X и из базы данных 
ORACLE на узле Y. По определению U является пользователем системы INGRES, а 
потому работа с распределенной базы данных должна походить на работу базы 
данных INGRES. Таким образом, режим работы пользователя должен поддерживаться 
системой INGRES, а не системой ORACLE. В чем заключается такая поддержка? 
    В принципе, она организована довольно просто. Система INGRES должна иметь 
надстроечную программу, которая называется шлюзом и взаимодействует с системой 
ORACLE так, чтобы создавалось впечатление, что "работа системы ORACLE выглядит 
так же, как и работа системы INGRES". Такая распределенная система показана на 
рис. 21.6. 
    Тогда шлюз должен выполнять все перечисленные ниже функции, причем 
некоторые из них с точки зрения технического воплощения представляют собой 
весьма сложную задачу. (Более подробно эти проблемы обсуждаются ниже при 
описании стандартов удаленного доступа.) 
    • Воплощение протоколов обмена информацией между системами INGRES и 
ORACLE. Такие протоколы, помимо прочего, должны содержать сведения о 
совместимости формата сообщений, с помощью которых утверждения SQL 

    Глава 21. Распределенные базы данных и системы клиент/сервер	583 

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

    s        ^\		INGRES (SQL)	INGRES/ STAR		Шлюз	ORACLE (SQL) 
    ? ——		k 
    Пользователь системы INGRES			ci= База данных JNGRESj	Распределенная база 
данных INGRES			Ваза данных ^ORACLE, 

    Рис. 21.6. Гипотетический шлюз, обеспечиваемый системой INGRES для обмена 
данными с системой ORACLE 

    Отображение между типами данных систем INGRES и ORACLE. Эта проблема 
включает множество подчиненных проблем, которые связаны с различием 
процессоров (например, у разных процессоров может по-разному определяться 
длина переменной типа "word"), различием кодировок символов (при сравнении 
строк в запросах упорядочения могут быть получены неожиданные результаты), 
различием формата чисел с плавающей запятой (широко известная проблема), 
различием в способе управления датой и временем (никакие известные автору СУБД 
не поддерживают это управление одинаковым образом) и т.д. Более подробно этот 
вопрос обсуждается в [21.14]. 
    Отображение диалекта языка SQL, принятого в системе INGRES, на диалект 
SQL, принятый в ORACLE. Следует отметить, что как в системе INGRES, так и в 
системе ORACLE поддерживаются отдельные инструменты языка SQL, которые не 
поддерживаются в другой системе. К тому же в них содержатся некоторые 
конструкции, синтаксически одинаковые, но семантически различные. 
    Отображение информации, посылаемой обратно от системы ORACLE (код возврата 
и т.д.), в формате INGRES. 
    Отображение каталога ORACLE в формате INGRES таким образом, чтобы узел 
INGRES и его пользователи могли понимать содержимое базы данных ORACLE. 
    Работа в качестве участника (в варианте INGRES) протокола двухфазной 
фиксации (при условии, что транзакции INGRES разрешено выполнение обновлений в 
базе данных ORACLE). Сможет ли данный шлюз выполнить эту функцию, зависит от 
модулей, предоставляемых администратором транзакций на узле системы ORACLE. 
Стоит отметить, что во время написания этой книги в коммерческих вариантах 
администраторов транзакций (за некоторым исключением) не обеспечивалась 
необходимая для этого поддержка. Иными словами не предусматривалась 
способность прикладной программы сообщить администратору транзакций о 
"подготовке к прекращению выполнения" (как альтернатива сообщению о 
безусловном прекращении выполнения, т.е. завершении или отмене выполнения). 
    Данные на узле системы ORACLE, которые необходимо блокировать по запросу 
узла системы INGRES, должны блокироваться тогда, когда система INGRES

    584 Часть V. Дополнительные аспекты 

нуждается в этом. Снова следует отметить, что шлюз сможет выполнить эту 
функцию в зависимости от того, будет ли архитектура блокировки системы ORACLE 
совпадать с системой INGRES или нет. 
    До сих пор независимость от СУБД обсуждалась только в контексте 
реляционных систем, а что будет, если в реляционную нераспределенную систему 
включить нереляционный узел. Например, можно ли организовать доступ к узлу 
системы IMS с узлов систем INGRES или ORACLE? Возможность реализации такого 
доступа была бы весьма полезной с практической точки зрения, поскольку 
позволила бы использовать огромное количество данных, хранящихся в системе IMS 
и других системах "дореляционного периода". Однако как это можно сделать? 
    Если этот вопрос сформулировать конкретнее, а именно: "можно ли это 
выполнить на все 100%", т.е. "можно ли обеспечить доступ ко всем нереляционным 
данным с помощью реляционного интерфейса и могут ли все реляционные операции 
быть выполнены с этими данными", то по причинам, подробно разъясняемым в 
[21.15], ответ будет определенно отрицательным. Но если этот же вопрос 
сформулировать иначе, а именно: "можно ли в такой системе обеспечить некоторый 
уровень полезной функциональности", то ответ будет положительным. Все 
необходимые и более подробные сведения читатель может найти в [21.13-21.15]. 
    В заключение следует отметить, что при организации удовлетворительной 
работы шлюзов часто возникают существенные проблемы, особенно если система 
вывода данных не является реляционной. Однако потенциальные выгоды весьма 
велики, даже если методы их воплощения не очень совершенны. Поэтому на рынке 
программного обеспечения уже появилось много программных продуктов с 
поддержкой шлюзов, к тому же в ближайшие годы можно ожидать дальнейшего 
увеличения их количества. Однако следует предупредить читателя, что несмотря 
на заверения производителей о совершенности предлагаемых ими изделий, как 
правило, дело обстоит совсем наоборот. Caveat emptor (покупатель действует на 
свой страх и риск). 

    21.6. Системы типа клиент/сервер 

    Как отмечалось выше, системы клиент/сервер могут рассматриваться как 
особый случай распределенных систем. Точнее, система клиент/сервер является 
распределенной системой, в которой одни узлы являются клиентами, а другие — 
серверами, все данные хранятся на серверах, все приложения исполняются 
клиентами, а "места их соединения не скрыты от пользователя" (т.е. не 
достигается цель независимости от расположения). Схематически такая система 
показана на рис. 21.7 (а также на рис. 2.5 в главе 2). 
    К моменту написания этой книги наиболее значительный коммерческий интерес 
проявлялся к системам клиент/сервер, а не к распределенным системам общего 
назначения. Тем не менее, автор считает, что наиболее перспективны именно 
распределенные системы, которым и посвящена большая часть материала, 
излагаемого в этой главе. Однако наряду с этим было бы полезно также сказать 
несколько слов и о системах клиент/сервер. 
    Если вспомнить, что в главе 2 термин "клиент/сервер" был отнесен 
преимущественно к архитектуре или логике распределения ответственности, то в 
таком случае клиент — это приложение, т.е. внешний интерфейс, а сервер — СУБД, 
т.е. внутренний интерфейс для непосредственной работы с базами данных. Таким 
образом, система может быть четко разделена на две части с использованием двух 
разных типов компьютеров. Эта последняя возможность настолько притягательна, 
что (по многим причинам, изложенным в главе 2) термин "клиент/сервер" стал 
применяться почти исключительно в случаях, когда клиент и сервер действительно 
находятся на разных компьютерах. И хотя такое определение весьма небрежно, как 
уже было отмечено в главе 2, оно все же является общепринятым и будет 
использоваться при последующем изложении материала. 

    Глава 21. Распределенные базы данных и системы клиент/сервер	585 

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

    Компьютер клиента 
    Удаленный доступ 
    Компьютер сервера 
    Второй способ, по сути, является формулировкой истинной распределенной 
системы ("со скрытыми соединениями"), смысл которой не соответствует широко 
распространенному смыслу термина "клиент/ сервер". Поэтому в дальнейшем этот 
способ рассматриваться не будет. 

    Рис. 21.7. Система клиент/сервер 


    Стандарты систем клиент/сервер 

    Для систем клиент/сервер разработано несколько различных стандартов. 
Во-первых, некоторые черты технологии клиент/сервер нашли воплощение в более 
современной версии стандарта языка SQL (а именно в стандарте SQL/92), включая 
операции CONNECT и DISCONNECT для установления и разрыва соединения типа 
клиент/сервер. Фактически, приложение SQL должно выполнять операцию 
установления соединения CONNECT до запуска запросов к базе данных (хотя 
операция соединения может быть задана также и неявным образом). Как только 
соединение установлено, приложение, т.е. клиент, может обычным образом 
задавать запросы на языке SQL, a все необходимые операции будут выполнены сервером. 
    Согласно этому стандарту SQL-клиент, уже связанный с некоторым сервером, 
также может быть связан с некоторым другим сервером. После установления второй 
такой связи первая становится пассивной. Последующие запросы обрабатываются 
вторым сервером до тех пор, пока клиент не переключится к предыдущему серверу 
(с помощью другой операции установления связи SET CONNECTION) или не 
присоединится к следующему серверу, в результате чего второе соединение будет 
также признано пассивным. Иначе говоря, согласно этому стандарту SQL-клиент 
может иметь только одно активное соединение и любое число пассивных 
соединений. Причем все запросы от клиента к базе данных направляются и 
обрабатываются сервером активного соединения. 

    586 Часть V. Дополнительные аспекты 


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

    Наконец, каждое соединение, установленное данным клиентом (независимо от 
того, пассивно оно или активно), должно в случае необходимости разрываться 
соответствующей операцией DISCONNECT (в самых простых ситуациях операция 
DISCONNECT, как и операция CONNECT, может быть задана неявным образом). 
    Наряду с описанным выше стандартом SQL, существует также стандарт ISO для 
удаленного доступа к данным (Remote Data Access — RDA) [21.1-21.2]. Этот 
стандарт во время написания настоящей книги существовал только в очень общей и 
приблизительной форме. Тем не менее, он весьма важен, поскольку нечто похожее 
на него уже воплощено членами консорциума разработчиков программного 
обеспечения для открытых систем и возможностей взаимодействия SQL Access Group (SAG). 

    Замечание, Здесь не стоит подробно останавливаться на различиях, 
существующих между версиями ISO и SAG стандарта RDA, а потому в дальнейшем обе 
эти версии будут упоминаться под общим названием стандарта RDA. 

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

    Замечание, К моменту написания этой книги стандарт RDA поддерживал только 
сетевое окружение OSI (Open Systems Interconnection — соединение открытых 
систем), но сейчас также ведется работа по его расширению на окружения TCP/IP 
и других типов. 

    Третий, и последний, описываемый здесь стандарт разработан фирмой IBM и 
называется стандартом архитектуры распределенной реляционной базы данных 
(Distributed Relational Database Architecture— DRDA) [21.3]; он является 
фактическим, но не юридическим стандартом. Стандарты RDA и DRDA имеют сходное 
предназначение, однако в некоторых аспектах стандарт DRDA отличается от 
стандарта RDA, в частности в нем отражено его происхождение от фирмы IBM. 
Например, стандартом DRDA допускается возможность использования клиентом не 
только стандартной версии SQL, но и некоторых диалектов этого языка. Одним из 
следствий такого подхода может быть повышение производительности, поскольку 
клиент может использовать некоторые специфические особенности сервера. С 
другой стороны, это может уменьшить переносимость программного обеспечения и 
именно потому, что клиенту становятся известны некоторые специфичные для 
данного сервера особенности его устройства (т.е. клиенту нужно обладать 
сведениями о типе сервера, с кот орым он обменивается данными). Наряду с этим 
в стандарте DRDA не предполагается никакой частной структуры каталога, 
хранящегося на сервере. Форматы и протоколы стандарта DRDA весьма существенно 
отличаются от форматов и протоколов стандарта RDA (в этом случае важное 
значение имеет то, что стандарт DRDA основан на собственной архитектуре и 
стандартах IBM, тогда как стандарт RDA основан на международных стандартах, 
которые не зависят от какого-либо отдельного производителя! 

    Глава 21. Распределенные базы данных и системы клиент/сервер	587 

    Более подробные сведения о стандартах RDA и DRDA выходят за рамки этой 
книги, однако все необходимые сведения для проведения сравнительного анализа 
этих стандартов можно найти в [21.19, 21.23]. 

    Программирование приложений клиент/сервер 

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

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

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

    588	Часть V. Дополнительные аспекты 

    21.7. Поддержка технологий клиент/сервер в стандарте языка SQL 
    В настоящее время в стандарте языка SQL не предусмотрена поддержка 
истинных распределенных СУБД, Однако для управления данными никакой поддержки 
не требуется, поскольку в распределенной СУБД способности управления данными 
должны оставаться неизменными. Тем не менее, были бы необходимы такие операции 
определения данных, как фрагментация FRAGMENT, репликация REPLICATE и т.д. 
[21.14], но они в настоящее время не поддерживаются. 
    С другой стороны, в стандарте языка SQL предусмотрены некоторые 
особенности систем клиент/сервер, например, как упоминалось выше, в нем 
обеспечиваются инструменты присоединения и отсоединения от сервера. Более 
подробное изложение этого вопроса (в дополнение к сведениям, изложенным в этой 
главе) можно найти в описании стандарта языка SQL [8.1] или вводном учебном 
пособии на эту тему [8.5]. 

    21.8. Резюме 

    В этой главе приведено краткое описание распределенных СУБД. В качестве 
основы этого описания были представлены двенадцать целей распределенной базы 
данных [21.13], хотя при этом отмечалось, что их достижение не всегда 
оправдано. Также кратко рассматривались некоторые технические проблемы в 
области обработки запросов, управления каталогом, распространения обновления, 
управления восстановлением и управления параллелизмом. В частности, 
обсуждались условия, необходимые для удовлетворения требования независимости 
от СУБД (при описании шлюзов). Затем речь шла об обработке процессов в системе 
клиент/сервер, которая может рассматриваться как особый случай обшей 
распределенной системы, получившей в настоящее время широкое распространение 
на рынке программного обеспечения. В частности, были подытожены аспекты 
стандарта языка SQL, которые имеют отношение к системе клиент/сервер. Однако 
пользователям следует избегать составления кода на уровне записей (т.е. 
операций с курсорами в терминологии SQ L). В этой главе была также кратко 
описана концепция хранимых процедур и удаленных процедурных вызовов. 
    Следует отметить, что в этой главе совсем не обсуждалась проблема 
физического проектирования базы данных для распределенных систем. Фактически, 
даже при игнорировании возможности фрагментации и/или репликации, существует 
широко известная проблема размещения отношений на узлах [21.25]. Поддержка 
фрагментации и репликации только усложняет эту проблему. 
    Достойно упоминания также появление на рынке компьютерных систем на основе 
массового параллелизма. Такие системы обычно состоят из большого количества 
процессоров, соединенных вместе с помощью высокоскоростной шины. Каждый 
процессор имеет собственную оперативную память, жесткие диски и собственную 
копию СУБД, а вся база данных полностью размещена на жестких дисках. Иначе 
говоря, такая система состоит из распределенной системы управления базами 
данных, размещенной в "одной коробке"! К такой системе применимы все 
рассуждения, изложенные в данной главе в отношении стратегий обработки 
запросов, протокола двухфазной фиксации, глобального тупика и т.д. 
    В качестве заключительного замечания следует отметить, что взятые вместе 
"двенадцать целей" распределенной базы данных (или некоторое их подмножество, 
включающее по крайней мере пункты 4, 5, 6 и 8) эквивалентны приведенному ниже 
правилу Кодда о "независимости от распределения" для реляционных СУБД [21.10]. 
    •  "Реляционная СУБД обладает независимостью от распределения... если СУБД 
имеет подъязык данных, который позволяет пользовательским программам и 
терминальной деятельности оставаться логически неповрежденными: 

    Глава 21. Распределенные базы данных и системы клиент/сервер	589 

    1) при попытке введения некоторого распределения данных (если СУБД 
оперирует только нераспределенными данными); 
    2) при перераспределении данных (если СУБД оперирует распределенными данными)". 
    Наконец, можно заметить, что, как уже упоминалось в этой главе, цели 4-6 и 
9-12, т.е. все цели, в названии которых есть слово "независимость", могут 
рассматриваться как расширения знакомого понятия независимости данных, 
применяющегося для распределенного окружения. 

    Упражнения 

    21.1. Дайте определение понятиям независимости от расположения, от 
фрагментации и от репликации. 
    21.2. Почему почти все распределенные СУБД являются реляционными? 
    21.3. Какими преимуществами и недостатками обладают распределенные системы? 
    21.4. Объясните следующие термины: стратегия обновления на основе 
первичной копии, стратегия блокировки на основе первичной копии, глобальный 
тупик, протокол двухфазной фиксации, глобальная оптимизация. 
    21.5. Опишите схему именования объектов в системе R*. 
    21.6. Как было указано в этой главе, успешное воплощение шлюзов зависит 
(помимо других причин) от согласования интерфейса между двумя рассматриваемыми 
СУБД. Рассмотрите две знакомые вам СУБД (желательно реляционного типа, более 
того, основанные на языке SQL) и идентифицируйте как можно большее количество 
различий между их интерфейсами пользователя. Рассмотрите как синтаксические, 
так и семантические различия. 
    21.7. Исследуйте доступную вам систему клиент/сервер. Поддерживаются ли в 
ней явным образом операции установления соединения CONNECT и разрыва 
соединения DISCONNECT? Поддерживаются ли в ней утверждения типа SET CONNECTION 
или операции соединения другого типа? Поддерживаются ли в ней многосерверные 
транзакции? Какие форматы и протоколы используются для общения типа 
клиент/сервер? Какие сетевые окружения в ней поддерживаются? Какое аппаратное 
обеспечение поддерживается для узлов-клиентов и узлов-серверов? Какое 
программное обеспечение (операционная система, СУБД) поддерживается для 
узлов-клиентов и узлов-серверов? 
    21.8. Исследуйте любую доступную реляционную СУБД. Поддерживаются ли в ней 
хранимые процедуры? Если да, то как они создаются и вызываются? На каких 
языках они описаны? Поддерживается ли в них полностью стандарт языка SQL? 
Поддерживается ли в них обычное условное ветвление (типа IF-THEN-ELSE) и 
циклы? Каким образом результаты возвращаются клиенту? Может ли одна хранимая 
процедура вызвать другую, хранящуюся на этом или другом узле? Выполняется ли 
хранимая процедура как часть вызванной транзакции? 

    Список литературы 

    21.1. Документ ISO DIS 9579-1. Information Processing Systems, Open 
Systems Interconnection, Remote Data Access Part 1: Generic Model, Service, 
and Protocol. — 1990. 
    21.2. Документ ISO DIS 9579-2. Information Processing Systems, Open 
Systems Interconnection, Remote Data Access Part 2: SQL Specialization. — 1990. 

    590	Часть V. Дополнительные аспекты 

    21.3. IBM Form № SC26-4651. Distributed Relational Database Architecture Reference. 
    В стандарте DRDA, разработанном в фирме IBM, заданы четыре уровня 
функциональности распределенной базы данных. 
    1.	Удаленный запрос. 
    2.	Удаленная часть работы. 
    3.	Распределенная часть работы. 
    4.	Распределенный запрос. 
    Поскольку по некоторым признакам эти термины фактически стали промышленным 
стандартом, здесь следует объяснить их немного подробнее. Замечание. Термины 
"запрос" и "часть работы" предложены специалистами фирмы IBM для понятий 
"утверждение SQL" и "транзакция" соответственно. 
    1. Удаленный запрос означает, что приложение на одном узле X может послать 
для исполнения отдельное утверждение на языке SQL некоторому удаленному узлу 
Y. Исходное приложение на узле X может впоследствии послать другой запрос узлу 
Y (или, возможно, третьему узлу Z), независимо от того, был ли первый запрос 
успешным или безуспешным. 
    2.   Удаленная часть работы означает, что приложение на узле X может 
посылать для исполнения все запросы к базе данных в составе некоторой заданной 
"части работы" (т.е. транзакции) на некоторый удаленный узел Y. Таким образом, 
обработка транзакции для этой базы данных выполняется целиком на удаленном 
узле Y. Однако решение о том, будет ли данная транзакция выполнена или 
отменена, принимается на локальном узле X. Замечание. Удаленная часть работы, 
по сути, является некоторым процессом в системе клиент/сервер с единственным сервером. 
    3.  Распределенная часть работы означает, что приложение на узле Сможет 
посылать для исполнения некоторые или все запросы к базе данных в составе 
некоторой заданной "части работы" (т.е. транзакции) к одному или нескольким 
удаленным узлам Y, Z... Таким образом, обработка транзакции для этой базы 
данных в общем случае выполняется на нескольких узлах. Причем каждый 
индивидуальный запрос может выполняться полностью на отдельном узле, а 
смешанные запросы — на нескольких различных узлах. Однако локальный узел X все 
еще остается координатором, т.е. решение о том, будет ли данная транзакция 
выполнена или отменена, принимается на этом узле. 
    4.   Распределенный запрос — это единственный из четырех уровней, наиболее 
близкий к понятию поддержки истинной распределенной базы данных. Понятие 
"распределенный запрос" означает то же самое, что и "распределенная часть 
работы" плюс разрешение выполнения индивидуальных запросов (SQL-утверждений) к 
базе данных с охватом нескольких узлов. Например, согласно запросу, 
поступившему от узла X, может потребоваться выполнить объединение или 
соединение таблицы на узле У и таблицы на узле Z. Обратите внимание, что 
только на этом уровне о системе можно сказать, что она обладает истинной 
независимостью от расположения. Во всех трех предыдущих случаях пользователь 
должен иметь сведения о физическом расположении данных. 
    21.4. Bell   D.,   Grimson   J.   Distributed   Database   Systems.—   
Reading,   Mass.: Addison-Wesley, 1992. 

    Глава 21, Распределенные базы данных и системы клиент/сервер 591 

    Это одно из последних учебных пособий, посвященных теме данной главы (два 
других упоминаются в [21,9, 21.24]). Особенностью этой книги является 
подробное изложение учебного материала на основе примера создания сети 
здравоохранения. К тому же, по сравнению с двумя следующими ссылками, эта 
книга является более практической. 
    21.5. Bernstein P.A., Rothnie J.B., Shipman D.W. (eds.) Tutorial: 
Distributed Data Base Management // IEEE Computer Society. — Long Beach, 
Calif., 1978. 
    Сборник статей из различных источников, сгруппированных в следующие разделы. 
    1.	Обзор методов управления реляционной базой данных. 
    2.	Обзор методов управления распределенной базой данных. 
    3.	Методы обработки распределенных запросов. 
    4.	Методы управления распределенным параллелизмом. 
    5.	Методы обеспечения надежности распределенной базы данных. 
    21.6. Bernstein P.A. et al. Query Processing in a System for Distributed 
Databases (SDD-1)// ACM TODS. — 1981. — 6, № 4. 
    См. комментарий к [21.26]. 
    21.7. Bernstein P.A., Shipman D.W, Rothnie J.B. Concurrency Control in a 
System for Distributed Databases (SDD-1) // Ibid. — 1980. — 5, № 1. 
    См. комментарий к [21.26]. 
    21.8. Breitbart Y., Garcia-Molina H.,  Silberschatz A.  Overview of 
Multidatabase Transaction Management // The VLDB Journal. — 1992. — 1, № 2. 
    Термин система с многими базами данных (multidatabase system) иногда 
используется для обозначения распределенной системы (обычно неоднородной) с 
полной автономией. В такой системе чисто локальные транзакции полностью 
управляются локальными СУБД, а глобальные транзакции — совсем по-другому. В 
статье представлен обзор результатов и исследований, полученных в этой ("очень 
важной") области. 
    21.9. Ceri S., Pelagatti G. Distributed Databases: Principles and 
Systems.— New York, N.Y.: McGraw-Hill, 1984. 
    21.10. Codd E.F. Is Your DBMS Really Relational? // Computerworld. — 1985. 
— 14th. 
    21.11. Daniels D. et al. An Introduction to Distributed Query Compilation 
in R* // Distributed Data Bases (ed. H.-J. Schneider): Proc. 2nd International 
Symposium on Distributed Data Bases. — New York, N.Y.: North-Holland, 1982. 
    См. комментарий к [21.30]. 
    21.12. Date C.J. Distributed Databases // C.J. Date An Introduction to 
Database Systems: Volume II. Chapter 7. — Reading, Mass.: Addison-Wesley, 1983. 
    Некоторые части данной главы основаны на этой более ранней публикации. 
    21.13. Date C.J. What Is a Distributed Database System? // C.J. Date. 
Relational Database Writings 1985-1989. — Reading, Mass.: Addison-Wesley, 1990. 
    В статье введены "двенадцать требований" к распределенным системам 
(приведенный в этой главе материал построен строго в соответствии с этой 
статьей). Как уже упоминалось, требование локальной автономности не может быть 
достигнуто на все 100%. Поэтому определенные ситуации требуют принятия в этом 
отношении компромиссных решений, кратко перечисленных ниже. 
    • К отдельным фрагментам фрагментированного отношения не может быть 
обеспечен непосредственный доступ даже с узла, на котором они хранятся. 

    592	Часть V. Дополнительные аспекты 

    • К отдельным копиям реплицированного отношения (или фрагмента) не может 
быть обеспечен непосредственный доступ даже с узла, на котором они хранятся. 
    • Пусть Р является первичной копией некоторого реплицированного отношения 
(или фрагмента) R и пусть Р хранится на узле X. Тогда каждый узел, который 
обращается к R, зависит от узла X, даже если на этом узле хранится другая 
копия R. 
    • К отношению, которое фигурирует в ограничении целостности для многих 
узлов, нельзя осуществлять доступ с целью обновления в локальном контексте 
узла, на котором оно хранится. Это возможно только в контексте распределенной 
базы данных, для которой это ограничение задано. 
    • Узел, который действует как участник процесса двухфазной фиксации, 
должен строго придерживаться указаний соответствующего узла-координатора. 
    21.14. Date CJ. Distributed Database: A Closer Look // C.J. Date and Hugh 
Darwen. Relational Database Writings 1989-1991. — Reading, Mass.: 
Addison-Wesley, 1992. 
    Продолжение публикации [21.13], в котором более подробно (хотя изложение 
ведется в стиле учебного пособия) обсуждаются многие из перечисленных в этой 
главе двенадцати целей. 
    21.15. Date C.J. Why Is It So Difficult to Provide a Relational Interface 
to IMS? // C.J. Date. Relational Database: Selected Writings, — Reading, 
Mass.: Addison-Wesley, 1986. 
    21.16. Epstein R., Stonebraker M., Wong E. Distributed Query Processing in 
a Relational Data Base System // Proc. 1978 ACM SIGMOD Intern. Conf. on 
Management of Data. -—Austin, Texas, 1978. 
    См. комментарий к [21.28], 
    21.17. Grant J., Litwin W., Roussopoulos N,, Sellis T. Query Languages for 
Relational Multidatabases // The VLDB Journal. — 1993. — 2, № 2. 
    В статье предлагаются расширения реляционной алгебры и реляционного 
исчисления в отношении систем с многими базами данных [21.8]. В ней 
обсуждаются вопросы оптимизации, а также показано, что каждое выражение 
реляционной алгебры для нескольких отношений имеет эквивалент в реляционном 
исчислении для нескольких отношений ("обратная теорема представляет собой 
интересную научную задачу"). 
    21.18. Gray J.N. A Discussion of Distributed Systems // Proc. Corigresso 
AICA 79. — Bari, Italy, 1979. (Эта статья также опубликована в виде отчета: 
IBM Research Report RJ2699. — 1979.) 
    Краткий, но очень удачный обзор и одновременно учебное пособие. 
    21.19. Hackathorn R.D. Interoperability: DRDA or RDA? // InfoDB. — 1991. — 
6, № 2. 
    21.20. Hammer M., Shipman D. Reliability Mechanism for SDD-1: A System for 
Distributed Databases // ACM TODS. — 1980. — 5, № 4. 
    См. комментарий к [21.26]. 
    21.21. Lindsay B.C. et al. Notes on Distributed Databases // IBM Research 
Report RJ2571, — 1979. 
    Эта работа разбита на пять глав, 
    1.  Реплицированные данные. 
    2.  Права доступа и представления, 
    3.  Введение в управление распределенными транзакциями. 

    Глава 21, Распределенные базы данных и системы клиент/сервер	593 

    4.  Инструменты восстановления. 
    5.  Инициирование, миграция и прекращение выполнения транзакции. 
    В главе 1 обсуждается проблема распространения обновления. Глава 2, за 
исключением нескольких замечаний в самом конце, почти полностью посвящена 
вопросам предоставления прав доступа в нераспределенной системе (в стиле 
системы System R). В главе 3 очень кратко рассматриваются вопросы 
инициирования, миграции и прекращения выполнения транзакций, управления 
параллелизмом и восстановлением. Глава 4 посвящена теме восстановления в 
нераспределенной (опять) системе. Наконец, в главе 5 более подробно 
обсуждается управление распределенными транзакциями, в частности дается 
подробное описание протокола двухфазной фиксации. 
    21.22. Mohan С., Lindsay B.G. Efficient Commit Protocols for the Tree of 
Processes Model of Distributed Transactions // Proc. 2nd ACM SIGACT-SIGOPS 
Symposium on Principles of Distributed Computing. — 1983. 
    См. комментарий к [21.30]. 
    21.23. Newman S., Gray J. Which Way to Remote SQL? // Database Programming 
& Design. — 1991.—4, № 12. 
    21.24. Oszu M.T., Valduriez P. Principles of Distributed Database 
Systems.— Englewood Cliffs, N.J.: Prentice-Hall, 1991. 
    21.25. Rothnie J.B., Goodman N. A Survey of Research and Development in 
Distributed Database Management // Proc. 3rd Intern. Conf. on Very Large Data 
Bases. — Tokyo, Japan, 1977. (Эта статья также опубликована в [21.5].) 
    Очень полезный обзор следующих тем: 
    1.  Синхронизация транзакций обновления. 
    2.  Обработка распределенного запроса. 
    3.  Управление при неисправностях компонентов. 
    4.  Управление каталогом. 
    5.  Проектирование базы данных. 
    Последняя тема относится к проблеме физического проектирования, которая в 
настоящей главе называется проблемой размещения. 
    21.26. Rothnie J.B. et al. Introduction to a System for Distributed 
Databases (SDD-1) // ACM TODS. — 1980. — 5, № 1. 
    Работы [21.6, 21.7, 21.20, 21.26, 21.31] связаны с ранним вариантом 
распределенной системы SDD-1, которая работала на нескольких компьютерах 
PDP-lOs фирмы DEC, связанных с помощью сети APRANET. В такой системе 
обеспечивалась полная независимость от размещения, фрагментации и репликации. 
Ниже приводится несколько замечаний по поводу некоторых особенностей этой системы. 
    Обработка запросов. Оптимизатор запросов в системе SDD-1 (см. [21.6, 
21.31]) в значительной мере использует оператор полусоединения. (Термин 
"полусоединение" был впервые использован в статье Палермо (Palermo) [18.15].) 
Полусоединение двух отношений А и В означает результат соединения А и В, 
спроецированный по атрибутам отношения А. Иначе говоря, в результате 
выполнения операции полусоединения будет получено подмножество кортежей 
отношения А, которые согласно условию соединения соответствуют по крайней мере 
одному кортежу отношения В. Например, полусоединение отношения поставщиков S и 
отношения поставок SP (по номерам поставщиков) является множеством кортежей 
отношения S, 

    594	Часть V. Дополнительные аспекты 

соответствующих поставщикам, которые поставляют по крайней мере одну деталь, т.е. 
является набором кортежей отношения S для поставщиков SI, S2, S3 и S4 (для 
обычных значений из рассматриваемого в этой книге примера). Обратите внимание, 
что выражения "А полусоединение В" и "В полусоединение А" в общем случае не эквивалентны. 
    Преимущество использования полусоединений при обработке распределенных 
запросов заключается в том, что они могут привести к сокращению количества 
данных, пересылаемых по сети. Например, предположим, что отношение поставщиков 
S хранится на узле А, отношение поставок SP — на узле В, а запрос 
формулируется следующим образом: "Вычислите соединение отношений S и SP по 
атрибуту S#". Вместо пересылки всего отношения S на узел В, можно выполнить 
перечисленные ниже действия. 
    • Вычислить проекцию (TEMPI) отношения SP по атрибуту S# на узле В. 
    • Переслать проекцию TEMPI на узел А. 
    • Вычислить полусоединение (ТЕМР2) проекции TEMPI и отношения S по 
атрибуту S# на узле А. 
    • Переслать полусоединение ТЕМР2 на узел В. 
    • Вычислить полусоединение ТЕМР2 и отношения SP по атрибуту S# на узле В. 
В результате будет получен ответ на сформулированный выше запрос. 
    Эта процедура, очевидно, приведет к значительному сокращению пересылки 
данных по сети тогда и только тогда, когда размер (TEMPI) 4 размер (ТЕМР2) < 
размер (S) , где термин размер означает кардинальное число отношения, 
умноженное на длину отдельного кортежа (в битах). Таким образом, оптимизатору 
необходимо уметь оценивать размер промежуточных результатов типа TEMPI и ТЕМР2. 
    Распространение обновления. Алгоритмом распространения обновления в 
системе SDD-1 является "немедленное распространение" (понятие первичной копии 
в ней не вводится). 
    Управление параллелизмом. Управление параллелизмом основано не на 
блокировке, а на методе синхронизации. Целью этого метода является попытка 
избежать дополнительных накладных расходов на посылку сообщений о блокировке, 
однако расплатой за это будет не очень большая степень параллелизма! Изложение 
дополнительных подробностей выходит за рамки этой книги. Более подробную 
информацию можно получить в [21.7, 21.12]. 
    Управление восстановлением. Восстановление основано на протоколе 
четырехфазной фиксации, цель которого заключается в том, чтобы в случае краха 
координирующего узла обеспечить большую гибкость всего процесса, чем при 
использовании протокола двухфазной фиксации. При такой организации управления 
весь процесс в целом значительно усложняется, однако изложение дополнительных 
подробностей выходит за рамки этой книги. 
    Каталог. Каталог управляется так же, как и обычные пользовательские 
данные, т.е. он может быть произвольно фрагментирован, а сами фрагменты могут 
реплицироваться и распространяться произвольным образом, как и любые другие 
данные. Преимущества такого подхода очевидны, а недостатки, к сожалению, 
состоят в том, что, поскольку система не обладает никакими сведениями о 
расположении произвольной части каталога, ей для хранения таких сведений 
необходимо поддерживать каталог более высокого уровня, который полностью 
реплицируется, т.е. на каждом узле хранится его копия. 

    Глава 21. Распределенные базы данных и системы клиент/сервер	595 

    21.27. Selinger P.O., Adiba M.E. Access Path Selection in Distributed Data 
Base Management Systems // S,M. Deen and P. Hammersley. Proc. Intern. Conf. on 
Data Bases. — Aberdeen, Scotland; London, England: Heyden and Sons Ltd., 1980. 
    См. комментарий к [21.30]. 
    21.28. Stonebraker M.R., Neuhold E.J. A Distributed Data Base Version of 
INGRES // Proc. 2nd Berkeley Conf. on Distributed Data Management and Computer 
Networks. — Lawrence Berkeley Laboratory, 1977. 
    Работы [21.16, 21.28, 21.29] связаны с прототипом распределенной системы 
INGRES. Распределенная система Distributed INGRES состоит из нескольких копий 
программного обеспечения University INGRES, установленного и запущенного на 
нескольких компьютерах PDP-lOs фирмы DEC. В них поддерживается независимость 
от расположения (как в системах SDD-1 и R*), независимость от фрагментации, 
репликация данных для фрагментов и независимость от такой репликации. В 
отличие от систем SDD-1 и R*, в системе Distributed INGRES не предполагается, 
что передача данных в сети должна быть обязательно медленной, наоборот, эта 
система спроектирована как для "медленных" сетей дальней связи, так и для 
сравнительно быстрых локальных сетей. Причем оптимизатор запросов может 
обнаружить разницу между двумя этими случаями. Алгоритм оптимизации запросов 
является расширением стратегии декомпозиции системы INGRES. Более подробно он 
описывается в [21.16]. 
    В системе Distributed INGRES обеспечиваются два алгоритма распространения 
обновления: "эффективный" алгоритм, согласно которому обновляется первичная 
копия, а затем управление возвращается данной транзакции (причем 
распространение обновлений выполняется параллельно с помощью набора 
подчиненных процессов), а также "надежный" алгоритм, согласно которому все 
копии обновляются одновременно (см. [21.29]). В обоих случаях управление 
параллелизмом основано на блокировке, а управление восстановлением — на 
протоколе двухфазной фиксации (с некоторыми усовершенствованиями, более 
подробно описанными в [21.29, 21.14]). 
    Что касается каталога, в системе Distributed INGRES используется полная 
реплика для некоторых порций каталога, в основном тех, которые содержат 
логическое описание видимых для пользователя отношений, а также описание того, 
как эти отношения фрагментированы. Кроме того, с полной репликой комбинируются 
элементы локальных каталогов других порций, например описывающих локальные 
физические структуры хранения, локальную статистику базы данных (используемую 
оптимизатором), а также ограничения целостности и правила безопасности. 
    21.29. Stonebraker M.R. Concurrency Control and Consistency of Multiple 
Copies in Distributed INGRES // IEEE Trans. on Software Engineering SE-5. — 
1979. — № 3. 
    См. комментарий к [21.28]. 
    21.30. Williams R. et al. R*: An Overview of the Architecture // P. 
Scheuermann. Improving Database Usability and Responsiveness. — New York, 
N.Y.: Academic Press, 1982. (Эта работа также опубликована в виде отчета: IBM 
Research Report RJ3325. — 1981.) 
    В работах [21.11, 21.22, 21.27, 21.30] описана система R*, которая 
является распределенной версией системы System R. В системе R* обеспечивается 
независимость от расположения, но не поддерживается фрагментация и репликация, 
а потому не обеспечивается независимость от фрагментации и репликации. По той 
же причине для этой системы не возникает вопрос о распро

    596	Часть V. Дополнительные аспекты 

    охранении обновления. Управление параллелизмом основано на блокировке 
(обратите внимание, что существует только одна копия любого блокируемого 
объекта, при этом вопрос о первичной копии также не возникает). Управление 
восстановлением основано на протоколе двухфазной фиксации, но с некоторыми 
усовершенствованиями, которые в результате могут привести к снижению числа 
необходимых сообщений (см. [21.22, 21.14]). 
    21.31. Wong Е. Retrieving Dispersed Data from SDD-1: A System for 
Distributed Databases. (Опубликовано в [21.5].) См. комментарий к [21.26]. 
    21.32. Yu C.T., Chang С.С. Distributed Query Processing // ACM Сотр. Surv. 
— 1984.—16, №4. 
    Здесь представлен материал по методам оптимизации запросов в 
распределенных системах, а также приводится обширная библиография. 

    Глава 21. Распределенные базы данных и системы клиент/сервер	597 

