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

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

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

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

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

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

FRAGMENT EMP AS

М_ЕМР AT SITE 'New York' WHERE DEPT# = DEPT# ('Dl')

OR DEPT# = DEPT# ('D3') ,

L_EMP AT SITE 'London^’ WHERE DEPT# = DEPT# ('D2') ;

Примечание. Здесь подразумевается, что кортежи с данными о служащих переменной отношения емр отображаются в физической памяти каким-то непосредственным спосо­бом, причем D1 и D3 — отделы, расположенные в Нью-Йорке, a D2 — отдел, располо­женный в Лондоне. Таким образом, кортежи с данными о служащих из Нью-Йорка хра­нятся на узле в Нью-Йорке, а кортежи с данными о служащих из Лондона — на узле в Лондоне. Отметим, что внутрисистемные имена фрагментов— n_emp и L_EMP.

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

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

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

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

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

Рис. 21.2. Пример фрагментации

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

Необходимо сказать еще несколько слов относительно вертикальной фрагментации. Как утверждалось выше, несомненно, что такая фрагментация должна выполняться без потерь. Поэтому разбиение переменной отношения ЕМР, показанной на рис. 21.2, на фрагменты-проекции, например, вида {emp#,dept#} и {SALARY} было бы недопусти­мым. Однако в некоторых системах хранимые переменные отношения рассматриваются

как имеющие скрытый, предоставляемый системой атрибут идентификатор кортежа, или сокращенно— атрибут TID (Tuple ID). Для каждого хранимого кортежа атрибут ГШ, грубо говоря, является адресом. Очевидно, что он является одним из потенциальных ключей для соответствующей переменной отношения. Поэтому, например, если бы пе­ременная отношения ЕМР содержала такой атрибут, то она могла бы быть фрагментиро-вана на проекции {TID,EMP#,DSPT#} и {TID,SALARY), поскольку такая фрагмента­ция уже, безусловно, выполняется без потерь. Также обратите внимание на то, что если, например, атрибут TID является скрытым, то это никак не нарушает информационный принцип, поскольку незаоисимость от фрагментации (которая вскоре будет рассматри­ваться в данной главе) означает, что пользователь не должен знать о существовании фрагментации.

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

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

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

ЕMР WHERE SALARY > 4OK AND DEPT# = DEPT# ('Dl')

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

Рассмотрим этот пример более подробно. Переменная отношения ЕМР с точки зрения пользователя может рассматриваться (упрощенно) как некоторое представление, сфор­мированное на основе базовых фрагментовы_ЕМР и L_EMP, следующим образом.

VAR ЕМР "VIEW" /* Псевдокод */

Ы_ЕМР UHION L_EMP ;

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

( N_EMP UNION L_EMP ) WHERE SALARY > 40K

AND DEPT# = DEPT# ('D1')

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

( N_EMP WHERE SALARY > 40K AND DEPT# = DEPTH# ('Dl'} )

UNION { L_EMP WHERE SALARY > 4OK AND DEPT# = DEPT# ('Dl'} )

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

ЕМР WHERE SALARY > 4OK AND DEFT# =

DEPT# ('Dl') AND DEPT# = DEPT# ('D2')

Это выражение в результате вычисления даст пустое отношение, поскольку соответ­ствующее условие в конструкции WHERE никогда не может стать истинным (TRUE), Таким образом, весь первоначальный запрос может быть приведен к следующему виду,

N_EMP WHERE SALARY > 40K AND DEPT# = DEPT# {'Dl')

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

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

ЕМР WHERE SALARY > 40K

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