Введение в системы БД (542480), страница 201
Текст из файла (страница 201)
(Если действительно необходимо хранить одну и ту же часть данных в нескольких различных местах, можно воспользоваться системным механизмом репликаиии; см. следующий подраздел). Восстановление исходной переменной-отношения из ее фрагментов выполняется с помощью соответствующих операций соединения и объединения (соединения — для вертикальных фрагментов, а объединения — для горизонтальных). Кстати, обратите внимание, что благодаря первому правилу в случае объединения операцию исключения дубликатов выполнять не потребуется. Замечание. Необходимо сказать еше несколько слов относительно вертикальной фрагментации. Как утверждалось выше, несомненно, что такая фрагментация должна выполняться без потерь.
Поэтому разбиение переменной-отношения ЕИР на фрагменты-проекции, например, вида (ЕИР!(,0ЕРТ() и (ЯАЬАЕТ) было бы недопустимым. Однако в некоторых системах хранимые переменные-отношения рассматриваются как имеющие скрытый, предоставляемый системой атрибут "идентификатор кортежа", или сокращенно — атрибут Т10 (гор!е 1Р). Для каждого хранимого кортежа атрибут Т!О, грубо говоря, является адресом.
Очевидно, что он является потенциальным ключом для соответствующей переменной-отношения. Например, если бы переменная-отношение ЕИР содержала такой атрибут, то она могла бы быть фрагментнрована на проекции (Т10,ЕИР(,0ЕРТ$) и (Т10,ЯАААЕУ), поскольку такая фрагментация уже, конечно, выполняется без потерь. Также обратите внимание, что если, например, атрибут Т!0 является скрытым, то это никак не нарушает информационный принцип, поскольку независимость от фрагментации означает, что пользователь не должен знать чего-либо о фрагментации. Заметим, между прочим, что простота выполнения фрагментации и восстановления — это две основные причины, по которым распределенные базы данных должны быть именно реляционными.
Реляционная модель предоставляет все те операции, которые необходимы для решения этих задач (20.15). Теперь перейдем к главному вопросу. Система, которая поддерживает фрагментацию данных, должна поддерживать н независимость от фрагментации (иногда говорят "прозрачность фрагментации" ). Другими словами, пользователи должны иметь возможность работать точно так, по крайней мере с логической точки зрения, как если бы данные в действительности были вовсе не фрагментированы. Независимость от фрагментации (как и независимость от расположения) — это весьма желательное свойство, поскольку она позволяет упростить разработку пользовательских программ и выполнение терминальных операций.
В частности, зто гарантирует, что в любой момент данные могут быть заново восстановлены (а фрагменты перераспределены) в ответ на изменение требований к эффективности работы системы, причем ни пользовательские программы, ни терминальные операции при этом не затрагиваются. Таким образом, если обеспечивается независимость от фрагментации, пользователи получают данные в виде некоторого представления, в котором фрагменты логически скомбинированы с помощью соответствующих операций соединения и объединения. К обязанностям сис немного оптимизатора относится определение фрагментод, к которым Глава 20. Распределенные базы данных 775 требуется физический доступ для выполнения любого из поступивших запросов пользователя.
В случае варианта фрагментации, показанного на рис. 20.2, пусть, например, пользователь выдает следуюший запрос. ЕМР МНЕЕЕ ЯАЬАНХ > 40К АЫ0 0ЕРХ4 = '01' Из определений фрагментов (которые хранятся, конечно же, в каталоге) оптимизатору должно быть известно, что весь требуемый результат может быть получен только по данным узла в Нью-йорке, а значит, нет никакой необходимости устанавливать связь с узлом из Лондона.
Рассмотрим этот пример более детально. Переменная-отношение ЕМР, как ее воспринимает пользователь, может рассматриваться (упрошенно) как некоторое представление, построенное на основе базовых фрагментов М ЕМР и Ь ЕМР. ЧАЕ ЕМР Ч1ЕМ М ЕМР НМХОМ Ь ЕМР 1 Тогда оптимизатор преобразует исходный запрос пользователя в следующее выражение. (М ЕМР НМ10М Ь ЕМР) МНЕНЕ ЯА)АЕХ > 40К АМ0 0ЕРХ4 = '01' В процессе дальнейшей оптимизации это выражение будет преобразовано в следуюшее выражение (поскольку операция выборки распределяется по объединению). ( М ЕМР МНЕЕЕ ЯАЬААХ > 40К АМ0 0ЕРХ4 = '01' ) НМХОМ ( Ь ЕМР МНЕЕЕ ЯАЬАЕХ > 40К АМН 0ЕРХ4 = '01' Из определения фрагмента Ь ЕМР в каталоге оптимизатору будет известно, что второй из этих двух операндов объединения в результате вычисления даст пустое отношение (условие 0ЕРХ4 = '01' АМ0 0ЕРТ4 = '02' никогда не может быть истинным), Таким образом, все выражение может быть приведено к следующему виду.
М ЕМР МНЕНЕ ЯАЬАЕХ > 40К АМ0 0ЕРХ4 = '01' Теперь оптимизатору станет ясно, что потребуется доступ лишь к данным узла в Нью-йорке. Улралснение. Рассмотрите, какие действия должен будет выполнить оптимизатор при обработке следуюшего запроса. ЕМР МНЕЙЕ ЯАЬАЕХ > 40К Из предыдущего обсуждения следует, что проблема поддержки операций для фрагментированных переменных-отношений в некоторых вопросах пересекается с проблемой поддержки операций представлений, определенных с помощью операций соединения и объединения (фактически это одна и та же проблема — она лишь проявляется на разных уровнях обшей системной архитектуры).
В частности, проблема обновления фрагментированных переменных-отношений совпадает с проблемой обновления представлений, определенных с помощью операций соединения и объединения (см. главу 9). Отсюда следует, что обновление некоторого кортежа — опять же, если говорить нестрого — может привести к тому, что кортеж будет перенесен из одного фрагмента в другой, если обновленный кортеж больше не удовлетворяет предикату для того фрагмента, которому он принадлежал ранее. 776 Часть р'.
дополнительные аспекты 6. Независимость от репликации Система поддерживает репликацию данных, если данная хранимая переменная- отношение — или в обшем случае данный фрагмент данной хранимой переменной- отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах. Рассмотрим конкретный пример (рис. 20.3). Обратите внимание, что внутри системы дубликаты имеют имена КЕ ЕМР и 1Л ЕМР.
КЕР11САТЕ М ЕМР АЯ АМ ЕМР АТ Я1ТЕ 'Болг)оп' З КЕРЫСАТЕ Ь ЕМР АЯ М1 ЕМР АТ Я1ТЕ 'Маи УогН' Рис. 20.3. Лрииер репзикаиии данных Репликация желательна по крайней мере по двум причинам. Во-первых, она способна обеспечить более высокую производительность, поскольку приложения смогуг обрабатывать локальные копии вместо того, чтобы устанавливать связь с удаленными узлами. Во-вторых, наличие репликации может также обеспечивать более высокую степень доступности, поскольку любой реплицируемый объект остается доступным для обработки (по крайней мере для выборки данных), пока хотя бы одна реплика в системе остается доступной. Главным недостатком репликации, конечно, является то, что если реплицируемый объект обновляется, то и все его копии должны быть обновлены (проблема распространения обновления).
В разделе 20.4 мы еше скажем несколько слов относительно этой проблемы. Отметим, между прочим, что репликация в распределенных системах представляется специфическим приложением идеи контролируемой избыточности, которая обсуждалась в главе!. Очевидно, что репликация, как и фрагментация, теоретически должна быть "прозрачной для пользователя". Другими словами, система, которая поддерживает репликацию данных, также должна поддерживать независимость от репликации (иногда говорят "прозрачносз.ь репликации").
Для подьзователей должна быть создана такая среда, чтобы они, по крайней мере с логической точки зрения, могли считать, что в действительности данные не дублируются. Независимость от репликации (как и независимость от расположения, и независимость от фрагментации) является весьма желательной, поскольку она упрощает создание пользовательских программ и выполнение терминальных операций. В ча- 777 Глава 20. Распределенные базы данньп стностн, независимость от репликации позволяет создавать и уничтожать дубликаты в любой момент в соответствии с изменяющимися требованиями, не затрагивая при этом никакие из пользовательских программ или терминальных операций. Из требования независимости от репликации следует, что к обязанностям системного оптимизатора также относится определение, какой именно из физических дубликатов будет применен для доступа к данным при выполнении каждого введенного пользователем запроса.
Здесь мы опускаем детали этого вопроса. Завершая подраздел, отметим, что многие коммерческие продукты в настоящее время поддерживают такой вил репликацни, который не обеспечивает полной независимости от репликацин, т.е. репликация будет яе полностью "прозрачна для пользователя". Некоторые дополнительные замечания по этому вопросу будут приведены в подразделе о распространении обновления в разделе 20.4. 7. Обработка распределенных запросов Существуют две особенности, касающиеся темы этого раздела, которые необходимо предварительно прокомментировать.
° Во-первых, рассмотрим запрос "Получить сведения о лонлонских поставщиках красных деталей". Предположим, что пользователь работает на узле в Нью-Йорке, а данные размещены на узле в Лондоне. Предположим также, что имеется л поставщиков, которые удовлетворяют данному запросу. Если система реляционная, то выполнение данного запроса будет, по существу, включать пересылку двух сообщений: одно — с запросом из Нью-Йорка в Лондон, а другое — с возвращаемым результатом, т.е. набором из л кортежей, пересылаемых из Лондона в Нью-Йорк. Если, с другой стороны, система не реляционная н использует операции с таблицами на уровне отдельных записей, выполнение запроса будет, по существу, включать пересылку 2л сообщений— л сообщений из Нью-Йорка в Лондон, которые запрашивают "следующего" поставщика, и л сообщений из Лондона в Нью-Йорк, которые возвращают сведения об "очередном" поставщике. Этот пример показывает, что по произволительности распределенная реляционная система может на порядок превосходить не реляционную.