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

Объединение данных из разных источников и предоставление единого представления

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

История

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

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

Проблемы с объединением разнородных источников данных часто называют информационными хранилищами , под одним интерфейсом запроса, которые существуют уже некоторое время. В начале 1980-х годов специалисты по информатике начали проектировать системы для взаимодействия разнородных баз данных. ^[5] Первая система интеграции данных, основанная на структурированных метаданных, была разработана в Университете Миннесоты в 1991 году для Integrated Public Use Microdata Series (IPUMS) . IPUMS использовала подход к хранению данных , который извлекает, преобразует и загружает данные из разнородных источников в уникальную схему представления , поэтому данные из разных источников становятся совместимыми. ^[6] Сделав тысячи баз данных населения совместимыми, IPUMS продемонстрировала осуществимость крупномасштабной интеграции данных. Подход к хранению данных предлагает тесно связанную архитектуру, поскольку данные уже физически согласованы в одном запрашиваемом репозитории, поэтому обычно требуется мало времени для разрешения запросов. ^[7]

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

По состоянию на 2009 год ^{[обновлять]}тенденция в интеграции данных благоприятствовала слабому связыванию данных ^[8] и предоставлению унифицированного интерфейса запросов для доступа к данным в реальном времени через опосредованную схему (см. Рисунок 2), что позволяет извлекать информацию напрямую из исходных баз данных. Это согласуется с популярным в ту эпоху подходом SOA . Этот подход основан на сопоставлениях между опосредованной схемой и схемой исходных источников и переводе запроса в разложенные запросы для соответствия схеме исходных баз данных. Такие сопоставления могут быть указаны двумя способами: как сопоставление из сущностей в опосредованной схеме в сущности в исходных источниках (подход «Global-as-View» ^[9] (GAV)), или как сопоставление из сущностей в исходных источниках в опосредованную схему (подход «Local-as-View» ^[10] (LAV)). Последний подход требует более сложных выводов для разрешения запроса по опосредованной схеме, но упрощает добавление новых источников данных в (стабильную) опосредованную схему.

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

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

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

Интеграция данных играет большую роль в бизнесе в отношении сбора данных , используемых для изучения рынка. Преобразование необработанных данных, полученных от потребителей, в связные данные — это то, что компании пытаются сделать, когда рассматривают, какие шаги им следует предпринять дальше. ^[14] Организации все чаще используют интеллектуальный анализ данных для сбора информации и закономерностей из своих баз данных, и этот процесс помогает им разрабатывать новые бизнес-стратегии для повышения эффективности бизнеса и более эффективного проведения экономического анализа. Компиляция большого объема данных, которые они собирают, для хранения в своей системе — это форма интеграции данных, адаптированная для бизнес-аналитики, чтобы повысить их шансы на успех. ^[15]

Пример

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

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

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

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

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

Теория

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

Определения

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

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

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

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

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

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

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

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

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

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

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

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

В общем случае сложность переписывания запросов является NP-полной . ^[21] Если пространство переписывания относительно невелико, это не представляет проблемы — даже для систем интеграции с сотнями источников.

Медицина и науки о жизни

Масштабные вопросы в науке, такие как реальные мировые свидетельства , глобальное потепление , распространение инвазивных видов и истощение ресурсов , все чаще требуют сбора разрозненных наборов данных для метаанализа . Этот тип интеграции данных особенно сложен для экологических и природоохранных данных, поскольку стандарты метаданных не согласованы, и в этих областях производится много разных типов данных. Инициативы Национального научного фонда, такие как Datanet, призваны облегчить интеграцию данных для ученых, предоставляя киберинфраструктуру и устанавливая стандарты. Пять финансируемых инициатив Datanet : DataONE ^[23] под руководством Уильяма Миченера из Университета Нью-Мексико ; The Data Conservancy ^[24] под руководством Саида Чоудхури из Университета Джонса Хопкинса ; SEAD: Sustainable Environment through Actionable Data ^[25] под руководством Маргарет Хедстром из Мичиганского университета ; DataNet Federation Consortium ^[26] под руководством Рейгана Мура из Университета Северной Каролины ; и Terra Populus , ^[27] под руководством Стивена Рагглза из Университета Миннесоты . Research Data Alliance , ^[28] совсем недавно исследовал создание глобальных фреймворков интеграции данных. Проект OpenPHACTS , финансируемый через Инициативу Европейского союза по инновационным лекарствам , построил платформу для открытия лекарств, связав наборы данных от таких поставщиков, как Европейский институт биоинформатики , Королевское химическое общество , UniProt , WikiPathways и DrugBank .

Смотрите также

• Управление бизнес-семантикой
• Сбор данных об изменениях
• Основная интеграция данных
• Интеграция данных клиентов
• Киберинфраструктура
• Смешивание данных
• Обработка данных
• Слияние данных
• Картографирование данных
• Обработка данных
• Модель базы данных
• Пространства данных
• Интеграция периферийных данных
• Интеграция корпоративных приложений
• Структура архитектуры предприятия
• Интеграция корпоративной информации (EII)
• Интеграция предприятия
• Geodi: Интеграция геонаучных данных
• Интеграция информации
• Информационный бункер
• Центр компетенции по интеграции
• Интеграционный консорциум
• ISO 15926: Интеграция данных жизненного цикла для технологических установок, включая объекты добычи нефти и газа
• JXTA
• Управление основными данными
• Объектно-реляционное отображение
• Открытый текст
• Семантическая интеграция
• Соответствие схемы
• Подход с тремя схемами
• УДЕФ
• Интеграция веб-данных
• Веб-сервис

Ссылки

1. Маурицио Ленцерини (2002). «Интеграция данных: теоретическая перспектива» (PDF) . PODS 2002. стр. 233–246.
2. Фредерик Лейн (2006). "IDC: Мир создал 161 миллиард гигабайт данных в 2006 году". Архивировано из оригинала 2015-07-15.
3. mikben. "Data Coherency - Win32 apps". docs.microsoft.com . Архивировано из оригинала 2020-06-12 . Получено 2020-11-23 .
4. Chung, P.; Chung, SH (2013-05). «Об интеграции данных и интеллектуальном анализе данных для разработки бизнес-аналитики». IEEE Long Island Systems, Applications and Technology Conference (LISAT) 2013 : 1–6. doi : 10.1109/LISAT.2013.6578235.
5. Джон Майлз Смит и др. (1982). «Multibase: интеграция гетерогенных распределенных систем баз данных». Труды AFIPS '81 от 4 по 7 мая 1981 г., Национальная компьютерная конференция . С. 487–499.
6. Стивен Рагглз , Дж. Дэвид Хакер и Мэтью Собек (1995). «Порядок из хаоса: интегрированная серия микроданных для общественного пользования». Исторические методы . Т. 28. С. 33–39.{{cite news}}: CS1 maint: несколько имен: список авторов ( ссылка )
7. Дженнифер Видом (1995). «Исследовательские проблемы в области хранилищ данных». Труды Четвертой международной конференции по управлению информацией и знаниями CIKM '95 . С. 25–30.
8. Паутассо, Чезаре; Уайлд, Эрик (2009-04-20). «Почему веб слабосвязан?». Труды 18-й международной конференции по всемирной паутине . WWW '09. Мадрид, Испания: Ассоциация вычислительной техники. С. 911–920. doi :10.1145/1526709.1526832. ISBN 978-1-60558-487-4. S2CID  207172208.
9. "Что такое GAV (Global as View)?". GeeksforGeeks . 2020-04-18. Архивировано из оригинала 2020-11-30 . Получено 2020-11-23 .
10. "Local-as-View", Википедия (на немецком языке), 2020-07-24 , получено 2020-11-23
11. Шубхра С. Рэй и др. (2009). «Объединение информации из нескольких источников с помощью функциональной аннотации на основе взвешивания: предсказание функции гена у дрожжей» (PDF) . Труды IEEE по биомедицинской инженерии . 56 (2): 229–236. CiteSeerX 10.1.1.150.7928 . doi :10.1109/TBME.2008.2005955. PMID  19272921. S2CID  10848834. Архивировано (PDF) из оригинала 2010-05-08 . Получено 2012-05-17 . 
12. Майкл Миреку Квакье (2011). «Практический подход к слиянию многомерных моделей данных». hdl :10393/20457.
13. "Тенденции поиска Hub Lake and Warehouse". Архивировано из оригинала 2017-02-17 . Получено 2016-01-12 .
14. "Data mining in business analytics". Western Governors University . 15 мая 2020 г. Архивировано из оригинала 23 декабря 2020 г. Получено 22 ноября 2020 г.
15. Surani, Ibrahim (2020-03-30). "Интеграция данных для бизнес-аналитики: лучшие практики". DATAVERSITY . Архивировано из оригинала 2020-11-30 . Получено 2020-11-23 .
16. Alagić, Suad; Bernstein, Philip A. (2002). Языки программирования баз данных . Конспект лекций по информатике. Том 2397. С. 228–246. doi :10.1007/3-540-46093-4_14. ISBN 978-3-540-44080-2.
17. "Вложенные сопоставления: Перезагрузка сопоставления схем" (PDF) . Архивировано (PDF) из оригинала 2015-10-28 . Получено 2015-09-10 .
18. "Инициатива общей структуры для алгебраической спецификации и разработки программного обеспечения" (PDF) . Архивировано (PDF) из оригинала 2016-03-04 . Получено 2015-09-10 .
19. Кристоф Кох (2001). "Интеграция данных против множественных развивающихся автономных схем" (PDF) . Архивировано из оригинала (PDF) 2007-09-26.
20. Джеффри Д. Ульман (1997). «Интеграция информации с использованием логических представлений». ICDT 1997. С. 19–40.
21. Alon Y. Halevy (2001). «Ответы на запросы с использованием представлений: опрос» (PDF) . The VLDB Journal . стр. 270–294.
22. Джордж Константинидис и др. (2011). «Масштабируемое переписывание запросов: подход на основе графов» (PDF) . в Трудах Международной конференции ACM SIGMOD по управлению данными, SIGMOD'11, 12–16 июня 2011 г., Афины, Греция .
23. Уильям Миченер и др. «DataONE: Observation Network for Earth». www.dataone.org. Архивировано из оригинала 22.01.2013 . Получено 19.01.2013 .
24. Саид Чоудхури и др. "Data Conservancy". dataconservancy.org. Архивировано из оригинала 2013-01-13 . Получено 2013-01-19 .
25. Маргарет Хедстром и др. «SEAD Sustainable Environment — Actionable Data». sead-data.net. Архивировано из оригинала 20-09-2012 . Получено 19-01-2013 .
26. Рейган Мур и др. "DataNet Federation Consortium". datafed.org. Архивировано из оригинала 2013-04-15 . Получено 2013-01-19 .
27. Стивен Рагглз и др. «Terra Populus: Integrated Data on Population and the Environment». terrapop.org. Архивировано из оригинала 2013-05-18 . Получено 2013-01-19 .
28. Билл Николс. "Research Data Alliance". rd-alliance.org. Архивировано из оригинала 2014-11-18 . Получено 2014-10-01 .

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