Аннотация

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

1. Введение

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

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

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

В этой статье мы вводим понятие пространства данных как новую абстракцию управления данными в таких сценариях. В качестве ключевой программы работ в области управления данными мы предлагаем проектирование и разработку платформ поддержки пространств данных (DataSpace Support Platforms, DSSP). Коротко говоря, DSSP обеспечивает набор взаимосвязанных услуг и гарантирует разработчикам возможность концентрироваться на специфических проблемах их приложений, а не на повторяющихся задачах, возникающих при потребности согласованной и эффективной работы со взаимосвязанными, но раздельно управляемыми данными. Свое обсуждение пространств данных и DSSP мы начнем с определения их места в контексте существующих систем.

1.1 Архитектуры управления данными

На рис. 1 показана классификация существующих решений управления данными по двум измерениям. Измерение "Administrative Proximity" ("административная близость") показывает, насколько близки различные источники данных с точки зрения административного управления. "Near" ("близко") означает, что источники находятся под единым или, по крайней мере, координированным управлением, а "Far" (далеко) показывает более слабую координацию и даже, может быть, полное отсутствие координации. Чем ближе административное управление группы источников данных, тем сильнее гарантии (например, согласованность, стабильность), которые могут быть предоставлены системой управления данными.

Измерение "Semantic Integration" ("семантическая интеграция") является мерой того, насколько близко могут быть сопоставлены схемы различных источников данных. Другими словами, насколько хорошо соответствуют типы, имена, единицы измерения, смысл и т.д. данных в источниках. На дальнем конце ("low") информация о схемах вообще отсутствует. В промежутке между "high" и "low" размещаются различные решения и подходы интеграции данных, основанные на полуструктурированных данных и контролируемых словарях. Это измерение показывает уровень, на котором могут быть обеспечены семантически развитые средства запрашивания данных и манипулирования данными над группой источников данных, причем более высокий уровень интеграции обеспечивает более развитые функциональные возможности.

Как показывает рисунок, традиционные СУБД представляют только одну точку (хотя и очень важную) в пространстве решений управления данными. СУБД требуют, чтобы все данные находились под единым административным управлением и соответствовали единой схеме. В ответ на удовлетворение этих ограничений СУБД могут обеспечить развитые средства манипулирования данными и обработки запросов с понятной и строгой семантикой, а также строгие транзакционные гарантии обновлений, параллельного доступа и долговременного хранения (так называемые свойства "ACID"). Важной точкой на рис. 1 являются "системы интеграции данных". На самом деле, системы интеграции данных и обмена данными традиционно предназначаются для поддержки многих других осмысленных служб в системах пространств данных. Особенность состоит в том, что в системах интеграции данных требуется семантическая интеграция до того, как могут быть обеспечены какие-либо прочие услуги. Поэтому, хотя и отсутствует единая схема, которой соответствуют все данные, система должна знать точные взаимосвязи между элементами, используемыми в каждой схеме. В результате для создания системы интеграции данных требуется существенная предварительная работа.

Пространства данных не являются подходом к интеграции данных; скорее, это подход сосуществования данных. Цель поддержки пространства данных состоит в обеспечении базового набора функций надо всеми источниками данных, а не в их интеграции. Например, DSSP может обеспечить надо всеми своими источниками данных поиск по ключевым словам, аналогично тому, что обеспечивают существующие поисковые системы в десктопах. При потребности в более сложных операциях, таких как запросы в реляционном стиле, анализ данных (data mining) или мониторинг каких-либо источников, можно приложить дополнительные усилия к более тесной интеграции этих источников в инкрементной манере "оплаты текущих счетов" ("pay-as-you-go").

Аналогичная гибкость имеется и в измерении административной близости рис. 1. Если желательно наличие административной автономии, то DSSP не сможет гарантировать согласованность, устойчивость результатов операций обновления и т.д. Для удовлетворения потребности в более строгих гарантиях нужны дополнительные усилия для достижения соглашений между владельцами источников данных и открытия некоторых интерфейсов (например, для протоколов фиксации транзакций).

Подводя итог, отличительными свойствами систем пространств данных является следующее:

• DSSP должны работать с данными и приложениями в разнообразных форматах, доступных от многих систем через различные интерфейсы. От DSSP требуется поддержка всех данных пространства данных, без каких-либо исключений (как это бывает при использовании СУБД).
• Хотя DSSP обеспечивает средства интегрированного поиска, запрашивания, обновления и администрирования пространств данных, те же самые данные часто могут быть доступны для чтения и обновления через собственный интерфейс системы, непосредственно управляющей данными. Поэтому, в отличие от СУБД, DSSP не имеет полного контроля над своими данными.
• Могут обеспечиваться разные уровни услуг по обработке запросов к DSSP, и в некоторых случаях они могут возвращать наилучшие из возможных приблизительные ответы. Например, если некоторые источники данных становятся недоступными, DSSP может обеспечить наилучший из возможных результат на основе данных, доступных во время выполнения запроса.
• DSSP должны поддерживать средства для обеспечения более тесной интеграции данных пространства, если это становится необходимо.

1.2 План работ в области пространств данных

По всем меркам, исследовательское сообщество управления данными остается активным, энергичным и растущим. Однако возникает ощущение, что в настоящее время у сообщества отсутствует основная идея - эквивалент "реляционной СУБД" для нового мира разнородных децентрализованных данных. * Кроме того, у многих исследователей возникает все более сильное ощущение, что термин "исследование баз данных" является ограничительным для широты тематики, затрагиваемой сообществом. Хотя, возможно, наша область просто стала слишком большой, чтобы можно было согласовать единую, сжатую концепцию, целью этой статьи является выработка предложения, которое могло бы помочь при дальнейших обсуждениях соответствующих проблем.

В сообществе баз данных давно происходит процесс самооценки, в ходе которого известные исследователи периодически встречаются для анализа состояния дел в данной области и определения обещающих исследовательских направлений в будущем (последними из опубликованных результатов таких собраний являются Asilomar Report [BBC+98] и Lowell Self-Assessment [AAB+05] *). Эта статья основывается на многих целях и проблемах, определенных в этих отчетах. На самом деле, в большей части исследований в сообществе управления данными уже прямо поддерживаются требования пространств данных и DSSP, включая такие направления, как сопоставление схем, интеграция данных и управление моделями, единообразный поиск над несколькими типами данных; комбинирование структурированных, полуструктурированных и неструктурированных данных, приближенная обработка запросов; запросы к неточным данным и их происхождению; управление и обработка потоковых и сенсорных данных. Таким образом, можно считать, что пространства данных - это все лишь "зонтик" над этими разнообразными исследовательскими работами. Однако, как мы обсудим позже, мы также полагаем, что единое представление на основе пространств данных и DSSP может и само привести к новому набору исследовательских проблем.

Оставшаяся часть статьи организована следующим образом. В разд. 2 потребность в системах пространств данных обосновывается с помощью двух примеров. В разд. 3 описываются логические компоненты пространства данных и первая попытка представления архитектуры DSSP. В разд. 4 очерчивается несколько исследовательских проблем, критичных для построения DSSP, и в разд. 5 обсуждается несколько перспектив плана работ. В разд. 6 содержится заключение.

2. Примеры

Мы начнем с описания двух сценариев пространств данных.

Управление персональной информацией: Цель управления персональной информацией (Personal Information Management, PIM) состоит в обеспечении простого доступа и манипулирования всей информацией на персональном компьютере с возможными расширениями к мобильным устройствам, персональной информации в Web и даже всей информации, накопленной в течение жизни человека.

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

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

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

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

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

Этот сценарий иллюстрирует несколько требований пространства данных: (1) каталог пространства данных; (2) поддержку анализа происхождения данных и (3) создание коллекций и индексов сверх тех, которые поставляются любым участвующим в пространстве источником данных.

3. Пространства данных

Опишем теперь логические компоненты пространства данных и сервисы, ожидаемые нами от DSSP.

3.1 Логические компоненты пространств данных

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

Участниками пространства данных являются индивидуальные источники данных: они могут быть реляционными базами данных, репозиториями XML, текстовыми базами данных, Web-сервисами и пакетами программного обеспечения. Они могут храниться или быть потоками данных (локально управляемыми системами потоков данных), или даже сенсорными установками.

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

Пространство данных должно уметь моделировать любой вид связи между двумя (или несколькими) участниками. В более традиционном варианте мы должны уметь моделировать ситуации, когда один участник является представлением или репликой другого участника, или отображать одна на другую схемы двух участников. Однако нам хотелось бы моделировать намного более широкий набор связей, например, что источник A был вручную произведен из источников B и C, или что источники E и F создавались независимо, но отражают одну и ту же физическую систему (например, ДНК мыши). Связи могут быть даже менее конкретными, например, два набора данных образованы из одного источника данных в одно и то же время.

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

3.2 Сервисы пространства данных

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

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

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

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

Другие ключевые сервисы DSSP включают мониторинг, обнаружение событий и поддержку сложных потоков работ. Например, мы можем захотеть произвести вычисление при поступлении новой части данных и распространить результаты этого вычисления в набор приемных источников данных. Аналогично, в DSSP должны поддерживаться различные формы анализа данных.

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

3.3 Системы пространств данных

Теперь мы очертим один из возможных наборов компонентов и архитектуру системы пространств данных. Как изображено на рис. 2, DSSP обеспечивает несколько взаимосвязанных служб над пространством данных, некоторые из которых являются обобщением компонентов, поддерживаемых в традиционной СУБД. Важно помнить, что, в отличие от СУБД, в DSSP не предполагается наличие полного контроля над данными в пространстве данных. Вместо этого, DSSP позволяет управлять данными системам-участникам, но обеспечивает новый набор служб поверх всех этих систем, соблюдая их потребности в автономности. Кроме того, у нас может иметься несколько DSSP, обслуживающих одно и то же пространство данных - в некотором смысле, у DSSP может иметься свое собственное представление о конкретном пространстве данных.

Каталог и просмотр: Каталог содержит информацию обо всех участниках пространства данных и о связях между ними. У каталога должна иметься возможность поддерживать разнообразные источники и сохранять информацию об их структуре и возможностях на разных уровнях. В частности, для каждого участника каталог должен включать схему источника, статистические данные, скорость изменения, точность, возможности ответов на запросы, информацию о владельце и данные о политике доступа и поддержке конфиденциальности. Связи могут сохраняться в виде преобразований запросов, графов зависимости, а иногда даже в виде текстовых описаний.

При наличии возможности каталог должен содержать базовый реестр элементов данных в каждом участнике: идентификатор, тип, дата создания и т.д. Тогда в нем можно поддерживать базовую возможность просмотра объединенного реестра всех участников. Хотя интерфейс просмотра не является очень масштабируемым, его можно, по крайней мере, использовать для ответов на вопросы пользователей о наличии или отсутствии элемента данных или определения того, какие участники хранят документы данного типа. Возможности этого интерфейса могут быть расширены с помощью запуска над участниками простых скриптов. Например, вычисление и сохранение для всех элементов данных значения свертки по алгоритму хэширования MD5 может помочь обнаружить дубликаты, хранимые разными участниками.

Поверх каталога DSSP должны поддерживать среду управления моделями, позволяющую создавать новые связи и манипулировать существующими связями (например, объединять или инвертировать отображения, сливать схемы и создавать единые представления нескольких источников).

Поиск и запрашивание: Этот компонент должен обеспечивать следующие возможности:

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

(2) Стуктурированные запросы: Запросы в стиле баз данных должны поддерживаться на основе общих интерфейсов (т.е. схем-посредников), обеспечивающих доступ к нескольким источникам, или же они могут адресоваться к конкретному источнику данных (с использованием его собственной схемы) с намерением получения ответов и от других источников (как в системах управления одноранговыми данными — Peer-Data Management System). Запросы могут формулироваться на разнообразных языках (и на основе разных моделей данных), и они должны, по возможности, наилучшим образом переформулироваться на другие модели данных и схемы, обеспечивая точные и приближенные семантические отображения.

(3) Запросы к метаданным: В системе должен поддерживаться широкий спектр запросов к метаданным. Должны обеспечиваться возможности (a) получения данных об источнике ответа или о том, как этот ответ был выведен или вычислен; (b) обеспечения временных меток на элементах данных, которые участвовали в вычислении ответа; (c) указания того, какие другие элементы данных в пространстве данных могут зависеть от заданного элемента данных, и поддержки гипотетических запросов (т.е. Что бы изменилось, если бы я удалил элемент данных X?); (d) запрашивания источников и уровня недостоверности ответа.

DSSP должны также поддерживать запросы на установление местоположения данных, ответами на которые являются источники данных, а не конкретные элементы данных. Например, система должна быть в состоянии отвечать на запросы Где я могу найти данные про IBM? или В каких источниках имеется атрибут "salary"?. Аналогично, при наличии XML-документа должна иметься возможность запросить XML-документы с похожей структурой и соответствующие XML-преобразования. Наконец, при наличии фрагмента схемы или описания Web-сервиса должно быть возможно найти в пространстве данных похожие фрагменты.

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

Локальное хранение и индексирование: В DSSP будет иметься компонент хранения и индексирования для достижения следующих целей: (1) для создания запрашиваемых ассоциаций между объектами данных от разных участников; (2) для совершенствования доступа к источникам с ограниченными собственными средствами доступа; (3) для обеспечения возможности выполнения некоторых запросов без доступа к реальному источнику данных и (4) для поддержки высокого уровня доступности и восстановления.

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

Нам может захотеться кэшировать некоторые фрагменты пространства данных (вертикальные или горизонтальные), чтобы (1) строить на них дополнительные индексы для поддержки более эффективного доступа; (2) повысить уровень доступности данных, хранимых в ненадежных участниках и (3) уменьшить нагрузку запросами участников, которые не могут обрабатывать непредусмотренные внешние запросы.

Компонент раскрытия: Назначение этого компонента состоит в обнаружении участников в пространстве данных, создании связей между ними и оказании помощи администраторам при совершенствовании и усилении этих связей.

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

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

Компонент расширения источников: У некоторых участников могут отсутствовать существенные функции управления данными. Например, участник может являться всего лишь ведомственным репозиторием документов, единственной службой в котором может являться еженедельное резервное копирование. У DSSP должны иметься средства наполнения такого участника дополнительными возможностями, такими как схема, каталог, поиск по ключевым словами и мониторинг обновлений. Заметим, что может оказаться необходимо обеспечивать эти расширения "по месту", поскольку могут иметься существующие приложения или потоки данных, рассчитанные на имеющиеся форматы или справочные структуры.

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

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

4. Исследовательские проблемы

В этом разделе определяются некоторые новые проблемы, возникающие при построении DSSP.

4.1 Модели данных и запросы в DSSP

Моделирование данных и базовые возможности запросов: В отличие от СУБД, в ядре DSSP требуется поддержка нескольких моделей данных, чтобы естественным образом поддерживалось как можно больше типов участников.

Модели данных, поддерживаемые DSSP, будут образовывать иерархию в соответствии с их выразительной мощностью. Каждый участник пространства данных поддерживает некоторую модель данных и некоторый язык запросов, соответствующий этой модели. Например, на самом верхнем уровне иерархии (наиболее общем) находятся коллекции именованных ресурсов, возможно, с базовыми свойствами - размер, дата создания и тип (например, изображение JPEG, база данных MySQL). "Запрос" к такой модели данных соответствует тому, что обычно поддерживается в файловых системах по отношению к их директориям: сопоставление имен, поиск в диапазоне дат, сортировка по размеру файла и т.д. На следующем уровне DSSP должны поддерживать модель данных мультимножества слов, из чего следует, что бы должны будем иметь возможность формулировки запросов по ключевым словам для любого участника пространства данных и, следовательно, получим некоторую возможность видения содержимого участников пространства данных.

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

В иерархии будут присутствовать и другие модели данных: реляционная модель, XML со схемой, RDF, OWL (Web Ontology Language). При наличии некоторой среды ключевая проблема состоит в нахождении методов интерпретации запросов на различных языках на участниках, поддерживающих некоторые модели. Более точно, проблема состоит в переформулировании запроса, представленного на сложном языке, для источника, который поддерживает более слабую модель данных, и наоборот, переформулировании запроса, представленного на простом языке, для источника, который поддерживает более выразительные модель данных и язык запросов (например, запрос по ключевым словам к реляционной базе данных).

Более широкое представление запрашивания: Для адекватного удовлетворения потребностей сценариев приложений и пользователей пространства данных, в DSSP требуется поддержка более широкого подхода к запросам. Благодаря WWW и наступающей революции в области доступа людей к информации, люди воспринимают поиск как одну из основных активностей. Пользователи компьютеров осознают, что существенная часть их поддерживаемых компьютером активностей может быть разделена на две части: поиск релевантной информации и работа с обнаруженной информацией. Может существовать много разновидностей поиска, некоторые из которых напоминают запросы к базам данных (нахождение билетов для совершения путешествия, оперативная проверка банковского баланса), а другие находятся ближе к поиску по ключевым словам (нахождение нужных документов на предприятии или поиск рецептов для изготовления вафель).

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

4.2 Раскрытие пространства данных

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

4.3 Повторное использование человеческого труда

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

4.4 Хранение и индексирование пространств данных

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

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

4.5 Гарантии корректности

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

4.6 Теоретические основы

Имеется несколько вопросов относительно теоретических обоснований пространств данных. Ясно, что требуется формальное понимание различных моделей данных, связей и ответов на запросы в пространстве данных. Если копать глубже, то в традиционной теории баз данных одним из основных вопросов является выразительная мощность языка запросов. В контексте пространств данных аналогичный вопрос будет относиться к выразительной мощности языка запросов над множеством участников с использованием определенных свойств связей, специфицированных между ними. То есть вопрос состоит в том, какие запросы могут быть выражены над пространством данных? Аналогично, как мы можем распознать семантически эквивалентные, но синтаксически различные способы ответов на запросы?

5. Перспективы

В завершение нашего обсуждения, коротко обсудим несколько важных перспектив пространств данных.

5.1 Связь с другими областями

Разработка DSSP основывается на традиционных сильных сторонах нашей области, и будет вовлекать существенные расширения методов управления данными, но важно также применять методы из нескольких других областей. Здесь мы упомянем некоторые из них. Поскольку мы пытаемся придать смысл неоднородным коллекциями в пространстве данных, два преимущества можно извлечь из последних работ в области представления знаний (и Semantic Web): простые, но полезные формализмы для представления онтологий и понятие URI (Uniform Resource Identifiers) как механизма ссылок на глобальные константы, относительно которых имеется некоторое соглашение между несколькими поставщиками данных. Аналогично, как говорилось ранее, некоторые операции над пространствами данных по своему существу приводят к некоторой неопределенности данных, их происхождения, корректности и полноты. В сообществе искусственного интеллекта разработано несколько формализмов для моделирования неопределенности, но они обладают слишком большой выразительностью. Проблема состоит в нахождении моделей, которые были бы полезными, но простыми, понятными и масштабируемыми.

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

5.2 Обучение пространствам данных

Лакмусовой бумажкой для понятия пространства данных является то, можно ли разработать соответствующий курс. Естественно, что, по мере выполнения исследований, основания пространств данных будут существенно развиваться, но мы полагаем, что уже сейчас имеется достаточный для курса материал. Кроме обзора основных моделей данных и языков запросов, следовало бы рассмотреть следующие темы: проблемы неоднородности и различных источников; архитектуры интеграции данных и обмена данными; запросы как механизм трансляции данных; алгоритмы полуавтоматического сопоставления схем; разные понятия качества обслуживания; поддержка запросов в стиле "лучшее, что возможно" и интеграция запросов к структурированным и неструктурированным данным. Важным компонентом такого курса было бы использование и анализ удачных примеров пространств данных (например, Sloan Digital Sky Survey *).

5.3 Промышленные перспективы

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

Например, начинает набирать силу корпоративная интеграция информации (Enterprise Information Integration). Компании, специализирующиеся в этой области, производят системы для обработки запросов к нескольким источникам данных внутри организации. Имеется несколько примеров продуктов, которые создают индексы над несколькими источниками данных для достижения целей, которые мы упоминали выше (например, Master Data Management, компонент продукта NetWeaver компании SAP). Имеются проекты, направленные на раскрытие источников данных предприятия, и только немногие компании изучают различные аспекты управления корпоративными метаданными. Интересно, что средства поиска персональных компьютеров также распространяются на корпоративный уровень, поступая совсем из другого сектора индустрии.

6. Заключение

Наиболее острые проблемы управления информацией в организациях сегодня произрастают из наличия в организациях многих разнотипных, но часто взаимосвязанных источников данных. В этой статье мы предложили идею пространств данных и разработки платформ поддержки пространств данных (DataSpace Support Platforms, DSSP) как средства решения этих проблем. Назначением DSSP является освобождение разработчиков от потребности постоянной повторной реализации основных функций управления данными при работе со сложными, разнородными, взаимосвязанными источниками данных, во многом подобно тому, как традиционные СУБД обеспечили аналогичные возможности для работы со структурированными реляционными базами данных. Однако, в отличие от СУБД, в DSSP не предполагается наличие полного контроля над данными в пространстве данных. Вместо этого, DSSP позволяет управлять данными системам-участникам, но обеспечивает новый набор служб надо всеми системами, удовлетворяя их требования автономности.

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

Благодарности

Авторы были вдохновлены (независимо друг от друга) обсуждениями, проведенными во время конференций CIDR 2005 и SIGMOD 2005. Эти дискуссии привели, в конце концов, к данному документу. В разработке исходного понятия пространства данных ключевую роль сыграла Дженифер Видом (Jennifer Widom). При обсуждении ранних вариантов материала полезные советы (некоторые из которых мы приняли) были даны Серджем Абитбулем (Serge Abiteboul), Филом Бернштейном (Phil Bernstein), Майком Кэри (Mike Carey), Дэвидом Девитом (David DeWitt), Лаурой Хаас (Laura Haas), Зэком Ивесом (Zack Ives), Дональдом Коссманом (Donald Kossmann), Майком Стоунбрейкером (Mike Stonebraker), Дэном Сьюси (Dan Suciu), Джеффом Ульманом (Jeff Ullman), Герхардом Вейкумом (Gerhard Weikum) и Стэном Здоником (Stan Zdonik). Мы также хотели бы поблагодарить многих коллег, которые читали ранние (более длинные) версии этого документа.

Литература

[AAB+05]

Serge Abiteboul, Rakesh Agrawal, Phil Bernstein, Mike Carey, Stefano Ceri, Bruce Croft, David DeWitt, Mike Franklin, Hector Garcia Molina, Dieter Gawlick, Jim Gray, Laura Haas, Alon Halevy, Joe Hellerstein, Yannis Ioannidis, Martin Kersten, Michael Pazzani, Mike Lesk, David Maier, Jeff Naughton, Hans Schek, Timos Sellis, Avi Silberschatz, Mike Stonebraker, Rick Snodgrass, Jeff Ullman, Gerhard Weikum, Jennifer Widom, and Stan Zdonik. The Lowell Database Research Self-Assessment. Commun. ACM, 48(5):111-118, 2005.

[BBC+98]

Phil Bernstein, Michael Brodie, Stefano Ceri, David DeWitt, Mike Franklin, Hector Garcia-Molina, Jim Gray, Jerry Held, Joe Hellerstein, H V Jagadish, Michael Lesk, Dave Maier, Jeff Naughton, Hamid Pirahesh, Mike Stonebraker, and Jeff Ullman. The Asilomar Report on Database Research. ACM SIGMOD Record, 27(4):74-80, 1998.