Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Методы и средства интеграции независимых баз данных в распределенных телекоммуникационных сетях. Монография

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 12 / 162 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > Следующая >>>

различных ИД, преобразование данных к виду, необходимому для загрузки в хранилище данных, и собственно загрузку данных [6]. Среди задач, общих для области интеграции данных и области ETL, стоит выделить задачу создания и поддержания отображений между схемами различных ИД [7], задачи, общие для области интеграции данных и области распределенных СУБД оптимизация запросов в распределенной среде и задача представления данных [8]. Специфичными для области интеграции данных являются задачи получения ответов на запросы в случаях недоступности ИД, агрегирование данных множества ИД с учетом их неполноты.

Задача сопоставления двух схем заключается в исследовании двух схем и данных, соответствующих этим схемам, с целью создания отображения между этими ними. Задача поддержания корректности отображений между схемой ИД (которую также называют локальной схемой) и целевой схемой (которую также называют глобальной схемой) заключается в обнаружении изменений схемы и способов представления данных в ИД, которые делают некорректным имеющиеся отображения между схемой ИД и целевой схемой. Эта задача является особенно важной в области интеграции данных, так как ИД обычно управляются независимо от системы интеграции данных (СИД) и их схемы могут изменяться с течением времени [9]. Задача оптимизации запросов хорошо исследована в процессе создания распределенных СУБД, однако специфика области интеграции данных предъявляет новые требования к оптимизации запросов. Здесь может рассматриваться оптимизация запросов к различным типам ИД (например, оптимизация запросов к Web-сервисам [10] или HTML-формам), оптимизация в случае устаревшей или отсутствующей статистики, оптимизация в случае использования неполных ИД или недоступности отдельных ИД.

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

В настоящей главе рассматриваются задачи, методы и средства интеграции данных, уточняется научная задача и частные задачи исследования . Основное внимание уделяется методам оптимизации запросов и получения ответов на запросы в условиях недоступности части ИД.

1.1. Различные подходы к интеграции данных: GAV,

LAV, GLAV

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

При рассмотрении отображения между двумя схемами обычно говорят о схеме ИД и целевой схеме, в терминах которой формулируются запросы. Выделяют три основных подхода к составлению отображений: GAV (Global As View) [11], LAV (Local As View) [12] и GLAV [13]. Подходы GLAV и LAV предоставляют более гибкие, чем при использовании подхода GAV, средства для

описания отображений между схемами ИД и целевой схемой. Однако алгоритмы обработки запросов при использовании подходов LAV и GLAV значительно сложнее аналогичных алгоритмов СИД, использующей GAV-подход к составлению отображений между схемами.

При использовании подхода GAV целевая схема выражается через схемы ИД посредством нерекурсивных программ Datalog'а (логического языка запросов (ЯЗ) к БД [14]), состоящих из правил вида

где r — отношение целевой схемы, — отношения схем ИД, [13]. При этом запросы выражаются в терминах целевой схемы, и выполнение запросов сводится к вычислению представлений.

При использовании подхода LAV схема ИД выражаются через отношения целевой схемы посредством не рекурсивных программ Datalog'а, состоящих из правил вида

где — отношения целевой схемы, s - отношение схемы ИД,

[12]. При этом запросы выражаются в терминах целевой схемы. В данном случае обработка запросов усложняется и может быть выполнена согласно алгоритму, приведенному в [12]. Данный алгоритм состоит из нескольких шагов. Его основой является последовательное преобразование правил, соответствующих запросу пользователя и выполнение отображения между целевой схемой и схемой ИД. Указанные действия выполняются с целью избавления от переменных, присутствующих в , но

отсутствующих в . В результате работы алгоритма получается план, представляющий собой Datalog-программу, в которой в качестве явных предикатов используются предикаты ИД.

При использовании подхода GLAV правила, описывающие

отношения между схемой ИД и целевой схемой имеют вид [13]:

, где и —

конъюнкция отношений ИД или предикат Datalog'а, выраженный через отношения ИД, - отношения целевой схемы. Алгоритм построения ответа на запрос при использовании подхода GLAV к описанию отображений между целевой схемой и схемой ИД включает два этапа. На первом этапе по описаниям ИД и запросу пользователя строятся правила, подобные обратным правилам, используемым при использовании подхода LAV. На втором этапе из обратных правил строятся программы Datalog'а, в которых отсутствуют функциональные символы, и в качестве явных предикатов используются предикаты, используемые в ИД. Подробно алгоритмы, используемые на этих этапах, описаны в [13]. Заметим, что алгоритмы генерации программ имеют полиномиальную сложность, а алгоритм формирования ответа на запросы - экспоненциальную по отношению к количеству правил в запросе. В связи с дополнительными накладными расходами на обработку пользовательских запросов, а также в связи со сложностью реализации, подходы LAV и GLAV в практически доступных средствах интеграции данных практически не используются.

1.2. Модели данных и языки запросов, используемые в

области интеграции данных

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

информации. Популярными моделями данных, используемых СИД, являются реляционная МД, иногда расширяемая системой правил (в стиле Datalog'а), XML модель данных, RDF[15] и OWL[16] модели. При использовании реляционной МД в качестве ЯЗ обычно используется SQL или Datalog, с XML обычно используется XQuery [17], при использовании RDF или OWL — RQL или SPARQL [18]. Некоторые СИД используют объектные МД и собственные ЯЗ. Следует отметить, что большинство МД и ЯЗ может быть сведено к реляционной МД и расширенным версиям Datalog'а.

Практически все средства интеграции данных, встроенные в современные СУБД, например, программный продукт Oracle Heterogeneous Services [19], встроенный в СУБД Oracle, используют реляционную МД и SQL в качестве ЯЗ. Реляционная МД применяется также в распределенной СУБД Mariposa [20]. При использовании реляционной МД упрощается перевод запросов к глобальной схеме в запросы к локальным схемам, когда в качестве ИД используются СУБД, которые в подавляющем большинстве построены на основе реляционной МД. В качестве недостатков применения реляционной МД в чистом виде в качестве основной МД СИД стоит отметить отсутствие встроенных средств для работы с неполными или противоречивыми данными. Модификации реляционной МД, дополненные подобными средствами, описываются в работе [21].

Некоторые СИД (например, TSIMMIS [11]) используют объектные МД (в случае TSIMMIS - OEM [22]) или объектнореляционные (система Information Manifold [23]). При этом для составления запросов в работе [11] предлагается использовать специализированный язык LOREL. В работе [23] в качестве ЯЗ предлагается специализированный логический язык Carin [24].

Модель OEM представляет собой легковесную объектноориентированную модель. В этой модели каждый объект состоит из 4 компонент: идентификатора объекта (который гарантированно сохраняется у объекта только в пределах одного запроса), метки (его класс), типа (тип множество (соответствует составным типам данных в языках программирования) или элементарный тип данных (например, строка)) и значения (атомарное значение или множество объектов). Для формального представления модели OEM может использоваться исчисление предикатов. Метки представляются предикатами, которые связывают идентификаторы различных объектов. Например, для схемы базы данных библиотеки, представленной на рис. 1.1, метке book будет соответствовать предикат book(x,y), соединяющий идентификаторы объектов с меткой book и идентификаторы объектов множества, которое является значением объекта book. Если b1 идентификатор объекта book, а и a

и t

- идентификаторы

объектов author и title, представленных на рис.1.1, то (book(b1,a1) и book(b

) и будут истинны.

1,t1

Синтаксис языка LOREL основывается на синтаксисе языка SQL. Например, для выборки заголовков книг, автором которых является Ахо или в которых описываются компиляторы, может использоваться запрос select library.book.title where library.book.author="Aho" or library.book.subject="compilers".

Данный язык использует частичное сопоставление объектов, то есть не требуется, чтоб объект содержал все атрибуты, к которым происходит обращение в WHERE-части запроса. Например, для рассмотренного запроса будут выбраны названия книг, автором которых является Ахо, даже если для этих книг не определен атрибут subject.

Рис.1.1 OEM схема базы данных библиотеки

Язык Carin [24] основан на дескрипционной логике и правилах Хорна. Запрос на данном языке является конъюнктивным запросом над отношениями глобальной схемы и представляется одним правилом Datalog-подобного языка. В рассматриваемой СИД Information Manifolder объектнореляционной МД могут быть определены реляционные отношения, иерархия классов, множество атрибутов классов. Значением атрибута отношения может быть либо атомарное значение (строка или целое), либо уникальный идентификатор объекта. Два класса могут быть объявлены не пересекающимися, то есть объект не может одновременно принадлежать этим двум классам. С каждым классом ассоциируется унарное отношение, с каждым атрибутом — бинарное, что позволяет работать и с классами, и с отношениями единообразно.

При решении задачи интеграции данных множества сайтов в сети Интернет могут с успехом использоваться слабо структурированные МД, например XML. Данная МД в сочетании с ЯЗ XQuery используется, например, в СИД Piazza [25].

В последнее время для интеграции данных в глобальных сетях все более популярным становится использование различных

средств описания онтологий в качестве МД [26]. Одним из ранних примеров использования подобных МД в СИД является система SIMS [27]. Данные в системе SIMS представляются в виде семантической сети, при этом глобальная схема представляет собой описание классов данных (понятий) и отношений между данными классами. Для формулировки запросов к системе используется логический язык Loom [28]. В настоящее время в подобных системах (например, [29]) используется RDF и словарь RDFS [30] или OWL для описания глобальной схемы и SPARQL или RQL для составления запросов к ней. Отметим, что использование RDF и OWL в качестве МД (вместо реляционной МД или XML) существенно повышает ее выразительность, предоставляя средства, достаточные для описания ER-модели [31], однако подобных результатов можно добиться и за счет использования Datalog-подобных правил и реляционной МД. Отдельно стоит отметить, что представление глобальной схемы в модели данных RDF, то есть в виде троек (объект, связь, объект), и использование реляционных СУБД в качестве ИД приводит к тому, что для получения ответа на запрос пользователя, производящий выборку по нескольким свойствам объекта, приходится производить соединение множества бинарных отношений связь(объект,объект), что при отсутствии дополнительной оптимизации запросов приводит к генерации неэффективного SQL-кода, выполняющего множество излишних самосоединений таблиц ИД [32].

1.3. Методы обработки и оптимизации запросов в СИД

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

Далее описываются некоторые методы оптимизации запросов в распределенных СУБД. Затем подробно описываются методы обработки и оптимизации запросов в СИД.

1.3.1. Методы оптимизации запросов в реляционных

СУБД

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

Выбор оптимального плана выполнения, как правило, не возможен в связи с большим пространством поиска (большим количеством различных планов исполнения) [33]. В задачу оптимизатора запросов входит генерация рассматриваемых планов выполнения, оценка стоимости выполнения каждого из рассматриваемых планов (оценка, как правило, состоит из взвешенных затрат ресурсов CPU, RAM, подсистемы ввода-вывода) и выбор плана с наименьшей стоимостью. Методы оптимизации запросов в СУБД (распределенных или нет), как правило, существенно отличаются от методов оптимизации запросов в СИД. Дело в том, что в СУБД в качестве элементарных операций используются низкоуровневые операции обработки данных: полное сканирование таблицы, использование индексов для доступа к данным, различные механизмы выполнения соединения двух таблиц и т.д. Но СИД не имеет возможности задавать поведение

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

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

Стандартные наборы преобразований, используемых для генерации планов выполнения запроса, включают выбор алгоритма соединения таблиц при использовании операций JOIN, изменения порядка соединения таблиц, раскрытие представлений, преобразование подзапросов (используемых в операторах IN и EXISTS) в соединения с внешним запросом. Наиболее интересно с точки зрения применения в распределенных системах выглядят оптимизации, основанные на передачи информации из одной части запроса в другую. Может использоваться как простое распространение условий через операции соединения, так и передача частичных результатов между различными подзапросами.

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

<<< < Предыдущая 12 / 162 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]