Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства интеграции независимых баз данных в распределенных телекоммуникационных сетях. Монография
.pdf
множества предикатов на несколько различных систем предикатов,
представляющих некоторые достаточно независимые схемы данных.
Под ПИ будем понимать именованную совокупность предикатов. ПИ
выделяют логически связанные предикаты в глобальной схеме.
Подобное средство позволяет различать наборы явных предикатов и
различных предопределенных правил, определяющих неявные
предикаты, подобно понятию схемы, используемому в СУБД MS SQL
Server и Oracle. ПИ позволяют поддерживать несколько систем
предикатов в СИД.
Третье расширение Datalog'а состоит в том, что в DISGO QL, в
описании структуры предикатов определяются не только типы
данных аргументов предикатов, но и имена этих аргументов. Это
позволяет существенно изменить семантику правил, определяющих
неявные предикаты. ПИА могут использоваться в правилах
глобальной схемы или в пользовательских программах. У ПИА, в
отличие от обычного предиката, на все аргументы предиката
происходит ссылка по имени. При обнаружении такого предиката в
хвосте правила (то есть в его правой части), система ищет в ПИ
обнаруженного предиката все предикаты с таким же именем,
имеющие аргументы с указанными именами, и выражает
обнаруженный ПИА через найденные предикаты. При
использовании ПИА в голове (то есть в левой части) правила
пользовательской программы такой предикат добавляется к
пространству поиска ПИА. Аргументы всех явных предикатов,
определенных в глобальной схеме, имеют имена. Однако, как в
программах пользователя, так и в правилах глобальной схемы могут
определяться предикаты, не имеющие имен аргументов. Подобные
предикаты обрабатываются системой по стандартным правилам
обработки Datalog-программ.
61

2.2.2. Подход к построению отображений между
глобальной схемой и локальными схемами
Предикаты с именованными аргументами не только
обеспечивают повышение выразительности языка запросов, но и
оказывают существенное влияние на возможности построения
отображений между глобальной и локальными схемами. Прежде
всего, отметим, что только при использовании подхода GLAV
удается добиться необходимой гибкости в описании отображений.
При использовании подхода GAV алгоритм обработки запроса к
глобальной схеме тривиален, но теряется часть информации,
предоставляемая ИД Пример описания отображения приводится
ниже в п. 2.2.3. При использовании
подхода LAV возможно
представить больше информации, но все равно теряется часть
информации, а также появляется необходимость вводить излишние
атрибуты в отношения глобальной схемы. Выполнение запросов к
глобальной схеме при использовании подхода GLAV усложнено тем,
что в ходе обработки запросов при использовании подходов LAV и
GLAV получаемые ответы могут быть неполными даже при
доступности всех подсоединенных ИД [12]. В связи с этим
описываемые методы используют расширение подхода GAV,
основанное на использовании ПИА, которое позволяет эффективно
обрабатывать любые запросы пользователя, и при этом возвращать
полные ответы в случае доступности всех подсоединенных ИД.
Рассмотрим пример задания отображений при использовании
ПИА. При использовании данного средства при объединении данных
ИД A и ИД B (см.п. 2.2.3), в глобальной схеме определяются два ПИА
(имена аргументов в языке DISGO QL указываются в фигурных
скобках после указания имени предикатов). Данные предикаты
определяются в некотором ПИ, например,
http://www.sfedu.ru/~alp/subjects1#, имеющем псевдоним subject1, и
имеют вид:
subject1:SubjectGlobal{name,lector,hours,course,type,spec}(?n,?l,?h,?c,?t,?s) и
62

subject1:SubjectGlobal{name,lector,hours,type}(?n,?l,?h,?t)
Отображение данных предикатов на схему ИД А выглядит так:
subject1:SubjectGlobal{name,lector,hours,course,type,spec}(?n,?l,?h,?c,«lecture»,?s
):- Lecture(?n,?l,?h,?c,?s);
А на схему ИД B — следующим образом:
subject1:SubjectGlobal{name,lector,hours,type}(?n,?l,?h,?t):Subject(?n,?lid,?h,?t),Tutors(?lid, ?l, ?sd);
При этом для обращения к данным предикатам из DISGO QL
возможно использовать следующую конструкцию (например, для
извлечения названий всех лекций, читаемых лектором Петровым):
subject1:SubjectGlobal{name,lector,type}
(?lecture,«Петров»,«lecture»)
При обработке данного запроса СИД сопоставит ПИ, имя и
список имен аргументов предиката в запросе и характеристики
предикатов глобальной схемы, и использует данные ИД A и ИД B. В
случае, если в запросе пользователя присутствует обращение к
атрибутам предиката, определенным только в некоторых ИД, то
происходит обращение только к этим ИД. Например, при обработке
запроса пользователя «какие предметы и на каком курсе читает
Петров?», система опросит только ИД A (так как ИД B не содержит
информации о курсах, на которых читаются предметы). Один из
возможных вариантов такого запроса имеет вид:
subject1:SubjectGlobal{name,lector,course}
(?subject,«Петров»,?с)
Таким образом, использование ПИА, во-первых, освобождает
пользователя от знания всех деталей глобальной схемы, во-вторых,
позволяет при добавлении новых ИД в систему автоматически
учитывать их данные во встроенных в уже существующие
прикладные программы запросах. Фактически, как и при
использовании GLAV подхода к интеграции данных, не все
атрибуты предикатов глобальной схемы, используемых
пользователем, должны отображаться на атрибуты всех
соответствующих отношений локальных схем (как при
63

использовании подхода GAV), и не все атрибуты локальных схем
должны отображаться на атрибуты глобальной схемы (как при
использовании подхода LAV). В связи с этой особенностью
представляется целесообразным использовать явное указание имен
аргументов используемых системных предикатов даже в случаях,
когда в момент написания запроса системе известен только один
предикат нужной структуры. В этом случае при добавлении ИД,
предоставляющих дополнительные данные о некотором
отношении, существующие запросы к глобальной схеме (и
включающие их прикладные программы) не придется
переписывать, для того чтобы они использовали информацию из
данного отношения, которую до этого предоставляли другие
предикаты.
Рассмотрим следующий пример (Рис. 2.4).
Рис. 2.4. Использование ПИА
Пусть программа выбирает данные о лекциях, читаемых
преподавателями университета, используя ПИА Lection из
пространства имен studdb с аргументами
64
course, group, lector
. Пусть

системе на момент запуска программы известно два типа ИД.
Первый предоставляет информацию о названии предмета, номере
курса и группы и имени лектора, а второй - о номере курса, группы,
идентификаторе читаемого предмета, фамилии лектора.
Тогда в системе возможно описать два ПИА Lection в
пространстве имен studdb с набором аргументов
title,course,group,lector и сcourse,group,lect_id,lector соответственно, а
также описать множество отображений каждого из этих ПИА на
произвольный SQL запрос к известным СИД ИД (или выразить
данные предикаты через другие известные системе предикаты). При
этом программа получит доступ к данным ИД обоих типов.
Предположим, что в дальнейшем появится еще два типа ИД
(например, предоставляющие информацию только о требуемых
параметрах и имеющих дополнительные сведения о количестве
читаемых лекций и названии курсов). Тогда определив два
дополнительных ПИА Lection в пространстве имен studdb с наборами
аргументов title,course,group и title,course,group,hours,lector и
составив необходимые отображения на SQL запросов к ИД, новую
информацию можно сделать доступной для приложения без
изменения самого приложения.
Описанные методы основаны на использовании ПИА при
построении отображений между глобальной схемой и локальными
схемами. Такой подход позволяет использовать дополнительный
промежуточный уровень отображения, при его использовании
создается трехуровневая схема (используемые ПИА => определяемые
ПИА => запросы к отношениям ИД). В запросе прикладной
программы указываются используемые предикаты и аргументы.
СИД ищет предикаты, описанные в глобальной схеме и содержащие
запрашиваемые аргументы. Обращения к найденным предикатам
отображаются на запросы к ИД. При этом каждый предикат может
отображаться на запросы к нескольким ИД. Динамическое
определение используемых приложением предикатов (и,
65

соответственно, ИД) позволяет существующим приложениям
использовать новые ИД (без изменения используемых этими
приложениями запросов), даже если новые ИД предоставляют
избыточную информацию, на работу с которой приложения
изначально не рассчитаны.
Отметим, что прямых аналогов разработанного метода не
существует. Похожая концепция необязательных свойств классов
используется в OWL [16] и МД OEM [22]. Однако использование
указанных моделей предполагает представление информации в виде
троек (объект, связь, объект), что вызывает значительные сложности
при составлении отображений между схемами, описанными в рамках
этих МД, и реляционными схемами, а также при преобразовании
запросов к таким схемам в эффективные запросы к реляционным
СУБД [32] .
2.2.3. Пример описания отображения между схемами
данных источников данных при использовании различных
подходов к описанию отображений
Рассмотрим пример описания отображений между глобальной
схемы локальными схемами при использовании различных подходов
к описанию отображений. Пусть в некотором источнике данных
(назовем его ИД A) определено отношение Lecture (name, lector,
hours, course, spec). Пусть данное отношение описывает лекции,
которые читаются студентам курса course по специальности spec.
Пусть некоторый другой ИД (назовем его ИД B) предоставляет
подобную информацию в виде Subject(title, lector_id, hours, type),
Tutors(lector_id, name, subdepartment), где поле type может
принимать значение «lecture» и «practice».
Допустим, что в СИД необходимо получать данные о лекциях,
информация о которых есть в источниках данных A и B. Тогда при
использовании подхода GAV в чистом виде возможно определить в
66

глобальной схеме следующее отношение: LectureGlobal (name, lector,
hours) и отобразить его на два представления в подсоединенных ИД.
Для ИД A отображение выражается следующим образом:
LectureGlobal (NAME, LECTOR, HOURS):-
Lecture(NAME,LECTOR,HOURS);
А для ИД B отображение выглядит так:
LectureGlobal (NAME, LECTOR, HOURS):Subject(NAME, LID, HOURS, «lecture»),Tutors(LID, LECTOR,
SD);
При использовании подхода LAV существует возможность
определить отношение
SubjectGlobal(name,lector,lid,hours,course,type,spec) в глобальной
схеме. При этом в определении отношения учитывается тип занятия
(лекция это или практика). Значит, в глобальной схеме можно
представить больше информации с использованием одного
отношения. Кроме того, возможно для каждого ИД задать неполное
отображение данного отношения глобальной схемы на отношения
ИД.
Для ИД A отображение выражается следующим образом:
Lecture(NAME,LECTOR,HOURS,COURSE,SPEC) :SubjectGlobal(NAME,LECTOR,LID,HOURS,COURSE,«lecture», SPEC);
Для ИД B определяется следующее отображение:
Subject(NAME, LID, HOURS, TYPE):-
SubjectGlobal(NAME,LECTOR,LID,HOURS,COURSE,TYPE,
SPEC);
При этом отношение Tutor источника данных B нельзя
выразить через отношения глобальной схемы, так как аргумент
SUBDEPARTMENT данного отношения не определен. Таким образом
теряется информация о связи Subject и Tutors (или в глобальной
схеме приходится вводить дополнительный атрибут
SUBDEPARTMENT, который, вероятно, там является излишним), а
67

также приходится вводить в глобальной схеме дополнительный
атрибут LID.
При использовании подхода GLAV в глобальной схеме
определяется отношение
SubjectGlobal(name,lector,hours,course,type,spec). Для ИД A
отображение выглядит так (где "=>" означает логическое следствие):
Lecture(NAME,LECTOR,HOURS,COURSE,SPEC)=>
SubjectGlobal(NAME,LECTOR,HOURS,COURSE,«lecture»,
SPEC)
А для ИД B:
Subject(NAME,LID,HOURS,TYPE),Tutors(LID, LECTOR, SD) =>
SubjectGlobal(NAME,LECTOR,HOURS,COURSE,TYPE,SPEC)
2.3. Методы обработки и оптимизации запросов
Рассмотрим методы обработки запросов, которые
предлагается использовать в СИД, предназначенной
для
объединения информации множества реляционных ИД в
распределенной сети. Вначале рассматривается общий алгоритм
обработки запросов, затем метод непосредственного выполнения
запросов и оптимизированный метод выполнения запросов.
Общий алгоритм выполнения запросов здесь рассматривается
только для того, чтобы пояснить роль описываемых методов при
обработке пользовательского запроса. Методы выполнения
запросов рассмотрены в порядке их усложнения. Использование
метода непосредственной обработки запросов позволяет применить
ряд оптимизаций (в том числе исключение обращений к
«медленным» ИД) без разделения процесса выполнения запроса
на несколько стадий. При использовании оптимизированного
метода выполнения запросов в нем выделяются стадии генерации
плана выполнения запроса и собственно выполнения запроса. Это
позволяет применить ряд дополнительных оптимизаций, включая
68

объединение операций извлечения данных из одного ИД и
применение понятия группы операций во время выполнения
запросов, что позволяет гибко обрабатывать сбои при обращениях
к ИД и использовать контролируемую параллельную обработку
подзапросов.
2.3.1. Общий алгоритм выполнения запросов
Рассмотрим общий алгоритм формирования ответа на запрос
пользователя. Он включает следующие шаги [2]:
1. Анализ запроса.
Запрос представляет собой программу на расширении языка
Datalog (DISGO QL). На этом шаге синтаксический анализатор
анализирует и преобразует текст запроса в синтаксическое дерево
запроса (СДЗ).
2. Преобразование запроса в выражение реляционной алгебры.
Преобразование выполняется в три этапа. Вначале по СДЗ
строится MCIG граф запроса. В графе MCIG вершины
соответствуют используемым в программе предикатам. Вершины
сгруппированы по принадлежности к правилам. Дуги соединяют
вершины и обозначают возможность выразить предикат,
соответствующий первой вершине через предикат,
соответствующий второй вершине. Данный граф является
основным внутренним представлением программы пользователя и
подробно описывается в третьей главе. Затем в этот граф
добавляются новые правила, которые появляются при обработке
ПИА и правил глобальной схемы. И на 3-м этапе на основе графа
MCIG строится выражение РА, соответствующее запросу, и
циклические программы РИ, в которые отображаются рекурсивно
определенные предикаты пользовательского запроса.
3. Обработка выражения РА.
69

На данном шаге происходит выполнение запроса
пользователя. При этом может использоваться либо метода
непосредственного выполнения, либо метод, основанный на
использовании групп операций. Основные оптимизации запроса
выполняются именно на этом этапе. Они включают как
оптимизации, специфичные для используемого метода
выполнения, так и общие оптимизации, например,
распространение условий, используемых в запросе как можно
ближе к месту извлечения информации из ИД (подробно алгоритм
распространения условий описан в третьей главе).
4. Возврат результата выполнения запроса пользователю.
В результате обработки запроса получается таблица привязок
переменных (ТПП) и код ответа. В ТПП указываются значения
переменных, запрашиваемых пользователем, при которых
основная часть запроса истинна.
Во время выполнения запроса на третьем шаге описанного
выше укрупненного алгоритма происходит извлечение информации
из подсоединенных ИД и ее дальнейшая обработка в центральной
СУБД. На этом этапе обработки запрос представляет собой
выражение РА и набор программ РИ, которые нужно выполнить в
центральной СУБД для формирования таблиц БД, соответствующих
рекурсивно определенным предикатам. Различие методов
выполнения запросов определяет различие в механизмах
оптимизации запросов, используемых на этапе выполнения.
2.3.2. Метод непосредственного выполнения запросов
Данный метод позволяет получить неполный уверенный
ответ на запрос пользователя, представленный в виде выражения
РА и программ РИ, распараллеливая операции извлечения
информации из ИД и исключая из рассмотрения медленные и
недоступные ИД.
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
