Интеграция данных

редактировать

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

Содержание

  • 1 История
  • 2 Пример
  • 3 Теория
    • 3.1 Определения
    • 3.2 Обработка запросов
  • 4 В науках о жизни
  • 5 См. Также
  • 6 Ссылки
  • 7 Внешние ссылки

История

Рисунок 1: Простая схема хранилища данных. Процесс Извлечь, преобразовать, загрузить (ETL) извлекает информацию из исходных баз данных, преобразует ее и затем загружает в хранилище данных. Рисунок 2: Простая схема решения для интеграции данных. Разработчик системы создает опосредованную схему, по которой пользователи могут выполнять запросы. виртуальная база данных взаимодействует с исходными базами данных с помощью кода оболочки, если требуется.

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

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

По состоянию на 2009 год тенденция в интеграции данных благоприятствовала ослаблению связи между данными и предоставлению единого интерфейса запросов для доступа к данным в реальном времени через опосредованную схему (см. Рисунок 2), что позволяет информация должна быть получена непосредственно из исходных баз данных. Это согласуется с популярным в то время подходом SOA. Этот подход основан на сопоставлениях между опосредованной схемой и схемой исходных источников, а также на преобразовании запроса в разложенные запросы для соответствия схеме исходных баз данных. Такие сопоставления могут быть указаны двумя способами: как сопоставление сущностей в опосредованной схеме с сущностями в исходных источниках (подход "" (GAV)) или как сопоставление сущностей из исходных источников с опосредованной схемой ( "" (LAV) подход). Последний подход требует более сложных выводов для разрешения запроса по опосредованной схеме, но упрощает добавление новых источников данных в (стабильную) опосредованную схему.

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

По состоянию на 2011 год было определено, что текущие методы моделирования данных обеспечивают изоляцию данных в каждая архитектура данных в виде островков разрозненных данных и информационных хранилищ. Эта изоляция данных является непреднамеренным артефактом методологии моделирования данных, который приводит к разработке разрозненных моделей данных. Разрозненные модели данных, когда они созданы как базы данных, образуют несопоставимые базы данных. Были разработаны усовершенствованные методологии моделей данных для устранения артефактов изоляции данных и содействия разработке интегрированных моделей данных. Один усовершенствованный метод моделирования данных изменяет модели данных, дополняя их структурными метаданными в форме стандартизованных объектов данных. В результате преобразования нескольких моделей данных набор преобразованных моделей данных теперь будет иметь одно или несколько отношений общности, которые связывают структурные метаданные, которые теперь являются общими для этих моделей данных. Отношения общности - это одноранговые отношения сущностей, которые связывают стандартизованные сущности данных нескольких моделей данных. Несколько моделей данных, которые содержат один и тот же стандартный объект данных, могут участвовать в одном и том же отношении общности. Когда интегрированные модели данных создаются как базы данных и правильно заполняются из общего набора основных данных, эти базы данных интегрируются.

С 2011 года подходы концентратора данных вызывают больший интерес, чем полностью структурированные (обычно реляционные) хранилища данных предприятия. С 2013 года подходы озера данных выросли до уровня концентраторов данных. (См. Популярность всех трех поисковых запросов в Google Trends.) Эти подходы объединяют неструктурированные или различные данные в одном месте, но не обязательно требуют (часто сложной) главной реляционной схемы для структурирования и определения всех данных в хабе.

Пример

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

Решение по интеграции данных может решить эту проблему, рассматривая эти внешние ресурсы как материализованные представления по виртуальной опосредованной схеме, что приводит к «интеграции виртуальных данных». Это означает, что разработчики приложений создают виртуальную схему - опосредованную схему - для наилучшего моделирования типов ответов, которые хотят получить их пользователи. Затем они разрабатывают «оболочки» или адаптеры для каждого источника данных, такого как база данных о преступлениях и веб-сайт погоды. Эти адаптеры просто преобразуют результаты локальных запросов (возвращаемые соответствующими веб-сайтами или базами данных) в легко обрабатываемую форму для решения по интеграции данных (см. Рисунок 2). Когда пользователь приложения запрашивает опосредованную схему, решение по интеграции данных преобразует этот запрос в соответствующие запросы по соответствующим источникам данных. Наконец, виртуальная база данных объединяет результаты этих запросов в ответ на запрос пользователя.

Это решение предлагает удобство добавления новых источников путем простого создания для них адаптера или блейда прикладного программного обеспечения. Это контрастирует с системами ETL или решениями с единой базой данных, которые требуют ручной интеграции всего нового набора данных в систему. Виртуальные решения ETL используют виртуальную опосредованную схему для реализации гармонизации данных; посредством чего данные копируются из назначенного «главного» источника в определенные целевые объекты, поле за полем. Расширенная виртуализация данных также основана на концепции объектно-ориентированного моделирования для создания виртуальной опосредованной схемы или виртуального репозитория метаданных с использованием архитектуры концентратора и луча.

Каждый источник данных несопоставим и не предназначен для поддержки надежных соединений между источниками данных. Следовательно, виртуализация данных, а также объединение данных зависят от случайной общности данных для поддержки объединения данных и информации из разрозненных наборов данных. Из-за отсутствия общности значений данных в источниках данных возвращаемый набор может быть неточным, неполным и невозможным для проверки.

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

Теория

Теория интеграции данных формирует подмножество теории баз данных и формализует основные концепции проблемы в логике первого порядка. Применение теорий указывает на возможность и сложность интеграции данных. Хотя его определения могут показаться абстрактными, они обладают достаточной общностью, чтобы приспособить все виды систем интеграции, включая те, которые включают вложенные реляционные базы данных / базы данных XML, и те, которые рассматривают базы данных как программы. Соединения с конкретными системами баз данных, такими как Oracle или DB2, обеспечиваются технологиями уровня реализации, такими как JDBC, и не изучаются на теоретическом уровне.

Определения

Системы интеграции данных формально определяются как набор ⟨G, S, M⟩ {\ displaystyle \ left \ langle G, S, M \ right \ rangle}\ left \ langle G, S, M \ right \ rangle где G {\ displaystyle G}G- глобальная (или опосредованная) схема, S {\ displaystyle S}S - это разнородный набор исходных схем, а M {\ displaystyle M}M- это отображение, которое отображает запросы между исходной и глобальной схемами. И G {\ displaystyle G}G, и S {\ displaystyle S}S выражены на языках поверх алфавитов состоит из символов для каждого из их соответствующих отношений. mapping M {\ displaystyle M}Mсостоит из утверждений между запросами по G {\ displaystyle G}Gи запросами по S {\ Displaystyle S}S . Когда пользователи задают запросы в системе интеграции данных, они задают запросы в G {\ displaystyle G}G, а затем отображение устанавливает связи между элементами в глобальной схеме и исходными схемами.

База данных по схеме определяется как набор наборов, по одному для каждого отношения (в реляционной базе данных). База данных, соответствующая исходной схеме S {\ displaystyle S}S , будет включать набор наборов кортежей для каждого из разнородных источников данных и называется исходной базой данных. Обратите внимание, что эта база данных с одним источником фактически может представлять собой набор отключенных баз данных. База данных, соответствующая виртуальной опосредованной схеме G {\ displaystyle G}G, называется глобальной базой данных. Глобальная база данных должна удовлетворять отображению M {\ displaystyle M}Mпо отношению к исходной базе данных. Законность этого сопоставления зависит от характера соответствия между G {\ displaystyle G}Gи S {\ displaystyle S}S . Существует два популярных способа моделирования этого соответствия: глобальный как представление или GAV и локальный как представление или LAV.

Рисунок 3: Иллюстрация пространства кортежей отображений GAV и LAV. В GAV система ограничена набором кортежей, отображаемых посредниками, в то время как набор кортежей, выражаемых через источники, может быть намного больше и богаче. В LAV система ограничена набором кортежей в источниках, тогда как набор кортежей, выражаемых через глобальную схему, может быть намного больше. Следовательно, LAV-системы часто должны иметь дело с неполными ответами.

GAV-системы моделируют глобальную базу данных как набор представлений по S {\ displaystyle S}S . В этом случае M {\ displaystyle M}Mсвязывает каждый элемент G {\ displaystyle G}Gс запросом по S {\ displaystyle S}S . Обработка запроса становится простой операцией из-за четко определенных связей между G {\ displaystyle G}Gи S {\ displaystyle S}S . Бремя сложности ложится на реализацию кода посредника, инструктирующего систему интеграции данных, как именно извлекать элементы из исходных баз данных. Если к системе присоединяются какие-либо новые источники, могут потребоваться значительные усилия для обновления посредника, поэтому подход GAV представляется предпочтительным, когда кажется, что источники вряд ли изменятся.

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

С другой стороны, в LAV исходная база данных моделируется как набор представлений над G {\ displaystyle G}G. В этом случае M {\ displaystyle M}Mсвязывает каждый элемент S {\ displaystyle S}S с запросом по G {\ displaystyle G}G. Здесь точные связи между G {\ displaystyle G}Gи S {\ displaystyle S}S больше не определены. Как показано в следующем разделе, бремя определения способа извлечения элементов из источников возлагается на обработчик запросов. Преимущество моделирования LAV заключается в том, что новые источники могут быть добавлены с гораздо меньшими затратами, чем в системе GAV, поэтому подход LAV следует отдавать предпочтение в случаях, когда опосредованная схема менее стабильна или может измениться.

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

Обработка запросов

Теория обработки запросов в системах интеграции данных обычно выражается с помощью конъюнктивных запросов и Datalog, чисто декларативного язык логического программирования. Можно условно представить конъюнктивный запрос как логическую функцию, применяемую к отношениям в базе данных, например «f (A, B) {\ displaystyle f (A, B)}f(A,B)где A < B {\displaystyle AA<B". Если кортеж или набор кортежей подставляется в правило и удовлетворяет ему (делает его истинным), то мы рассматриваем этот кортеж как часть набора ответов в запросе. В то время как формальные языки, такие как Datalog, выражают эти запросы кратко и без двусмысленности, общие запросы SQL также считаются конъюнктивными запросами.

С точки зрения интеграции данных «сдерживание запросов» представляет собой важное свойство конъюнктивных запросов. Запрос A {\ displaystyle A}Aсодержит другой запрос B {\ displaystyle B}B (обозначенный A ⊃ B {\ displaystyle A \ supset B }A \ supset B ), если результаты применения B {\ displaystyle B}B являются подмножеством результатов применения A {\ displaystyle A}Aдля любой базы данных. Эти два запроса считаются эквивалентными, если результирующие наборы равны для любой базы данных. Это важно, потому что как в системах GAV, так и в LAV, пользователь ставит конъюнктивные запросы по виртуальной схеме, представленной набором представлений или «материализованных» конъюнктивных запросов. Интеграция стремится переписать запросы, представленные представлениями, чтобы их результаты были эквивалентны или максимально содержались в запросе нашего пользователя. Это соответствует проблеме ответа на запросы с использованием views ().

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

В системах LAV запросы подвергаются более радикальному процессу переписывания, поскольку не существует посредника, который бы согласовывал запрос пользователя с простой стратегией расширения. Система интеграции должна выполнить поиск в пространстве возможных запросов, чтобы найти лучший вариант перезаписи. Результирующая перезапись может не быть эквивалентным запросом, но максимально содержать, а результирующие кортежи могут быть неполными. По состоянию на 2011 год алгоритм GQR является ведущим алгоритмом перезаписи запросов для систем интеграции данных LAV.

В целом сложность перезаписи запроса NP-полная. Если пространство для перезаписи относительно невелико, это не представляет проблемы - даже для систем интеграции с сотнями источников.

В науках о жизни

Крупномасштабные вопросы в науке, такие как глобальное потепление, распространение инвазивных видов и истощение ресурсов, все чаще требуется сбор разрозненных наборов данных для метаанализа. Этот тип интеграции данных особенно сложен для экологических данных и данных по окружающей среде, потому что стандарты метаданных не согласованы, и в этих областях создается много разных типов данных. Инициативы Национального научного фонда, такие как Datanet, призваны упростить интеграцию данных для ученых путем предоставления киберинфраструктуры и установления стандартов. Пять финансируемых инициатив Datanet : DataONE, возглавляемые Уильямом Миченером из Университета Нью-Мексико ; Служба защиты данных, возглавляемая Сайедом Чоудхури из Университета Джона Хопкинса ; SEAD: «Устойчивая окружающая среда с помощью практических данных», руководитель Маргарет Хедстром из Мичиганского университета ; Консорциум Федерации DataNet, возглавляемый Рейганом Муром из Университета Северной Каролины ; и Terra Populus во главе с Стивеном Рагглзом из Университета Миннесоты. Research Data Alliance недавно исследовал создание глобальных структур интеграции данных. В рамках проекта OpenPHACTS, финансируемого через Европейский союз Innovative Medicines Initiative, была создана платформа для открытия лекарств путем связывания наборов данных от таких поставщиков, как Европейский институт биоинформатики, Королевское химическое общество, UniProt, WikiPathways и DrugBank.

См. Также

Ссылки

Внешние ссылки

Найдите интеграцию данных в Wiktionary, бесплатном словаре.
Последняя правка сделана 2021-05-17 14:10:21
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте