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

ЕМР WHERE SALARY > 40К AND DEPTi = Dl

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

Рассмотрим этот пример более детально. Переменная-отношение ЕМР, как ее воспринимает пользователь, может рассматриваться (упрошенно) как некоторое представление, построенное на основе базовых фрагментов N EMP и L EMP.

VAR ЕМР VIEW

N EMP UNION L EMP ;

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

(N EMP UNION L EMP) WHERE SALARY > 40K AND DEPT# = Dl

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

( N EMP WHERE SALARY > 40К AND DEPT# = Dl ) UNION

( L EMP WHERE SALARY > 40K AND DEPT# = Dl )

Из определения фрагмента L EMP в каталоге оптимизатору будет известно, что второй из этих двух операндов объединения в результате вычисления даст пустое отношение (условие DEPTt = Dl AND DEPTt = D2 никогда не может быть истинным). Таким образом, все выражение может быть приведено к следующему виду.

N EMP WHERE SALARY > 40К AND DEPTt = Dl

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

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

ЕМР WHERE SALARY > 4OK

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

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

Система поддерживает репликацию данных, если данная хранимая переменная-отношение- или в обшем случае данный фрагмент данной хранимой переменной-отношения - может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах. Рассмотрим конкретный пример (рис. 20.3). Обратите внимание, что внутри системы дубликаты имеют имена NL EMP и LN EMP.

REPLICATE N EMP AS

LN EMP AT SITE London ;

REPLICATE L EMP AS

NL EMP AT SITE New York ;

New York J

London

N EMP

L EMP

NL EMP (дубликат L EMP)

LN EMP (дубликат N EMP)

Puc. 20.3. Пример репликации данных

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

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

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

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

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

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

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

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

Во-первых, рассмотрим запрос Получить сведения о лондонских поставщиках красных деталей . Предположим, что пользователь работает на узле в Нью-Йорке, а данные размещены на узле в Лондоне. Предположим также, что имеется п поставщиков, которые удовлетворяют данному запросу. Если система реляционная, то вьшолнение данного запроса будет, по существу, включать пересылку двух сообщений: одно - с запросом из Нью-Йорка в Лондон, а другое - с возвращаемым результатом, т.е. набором из л кортежей, пересылаемых из Лондона в Нью-Йорк. Если, с другой стороны, система не реляционная и использует операции с таблицами на уровне отдельных записей, выполнение запроса будет, по существу, включать пересылку 2п сообщений - л сообщений из Нью-Йорка в Лондон, которые запрашивают следующего поставщика, и л сообщений из Лондона в Нью-Йорк, которые возвращают сведения об очередном поставщике. Этот пример показывает, что по производительности распределенная реляционная система может на порядок превосходить не реляционную.

Во-вторых, оптимизация в распределенных системах даже более важна, нежели в централизованных. Суть в том, что для запроса, подобного рассмотренному выше, может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос. Поэтому крайне важно, чтобы была найдена эффективная стратегия. Например, запрос для, скажем, объединения отношения Rx, хранимого на узле X, и отношения Ry, хранимого на узле У, может быть выполнен посредством пересылки отношения Rx на узел У или отношения Ry на узел X, или обоих отношений на какой-либо узел Z и т.п. Неопровержимая иллюстрация важности оптимизации, включающая упомянутый выше запрос ( Получить сведения о лондонских поставщиках красных деталей ), представлена в разделе 20.4. Подводя краткий итог этого примера, можно отметить, что по вопросу обработки данного запроса анализируется шесть различных стратегий с учетом определенного набора вероятных допущений. В результате показано, что время ответа в каждом случае различно и изменяется в широких пределах от минимального (от одной до десяти секунд) до максимального (около шести часов!). Таким образом, оптимизация.