Предвестники новых манифестов управления данными Сергей Кузнецов




НазваниеПредвестники новых манифестов управления данными Сергей Кузнецов
Дата конвертации22.02.2013
Размер445 b.
ТипОтчет


Предвестники новых манифестов управления данными

  • Сергей Кузнецов


Введение (1)

  • 4-6 мая 2003 г., Лоуэлл, шт. Массачусетс (США)

  • До этого собрания в Лагуна-Бич (1989 г.) и Асиломаре (1996 г.)

  • Отчет опубликован в 2003 г. Джимом Греем на сайте компании Microsoft

  • В середине 2005 г. появилась официальная публикация



Введение (2)

  • Отчеты собраний строятся на основе мнения большинства участников

  • Носят очень компромиссный характер, определяя общие проблемы и задачи, но не концентрируясь на конкретных технологических решениях

  • Затем более узкие группы авторов предлагают подходы к решению этих проблем и задач, основанные на более конкретных идеях и методах



Введение (3)

  • Показательным является отчет Лагуна-Бич

  • На абстрактном уровне говорилось о необходимости внедрения в СУБД встроенных средств расширения возможностей систем для удовлетворения потребностей новых приложений



Введение (4)

  • Среди авторов Дэвид Девитт и Дэвид Майер, с одной стороны, и Филипп Бернштейн, Джим Грей, Брюс Линдсей, Лоуренс Роув и Майкл Стоунбрейкер, с другой стороны

  • В том же 1989 г. группа исследователей, в которую входили Девитт и Майер, опубликовала «Манифест систем объектно-ориентированных баз данных»



Введение (5)

  • Годом позже другой группой, в которой активно участвовали Берштейн, Грей, Роув и Стоунбрейкер, был выпущен «Манифест систем баз данных третьего поколения»

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



Введение (6)

  • Эти два манифеста оказали существенное воздействие на современный облик технологии баз данных

  • До конца 2005 г. не были заметны какие-либо попытки конкретизации подходов к решению проблем, перечисленных в Лоэллском отчете

  • Однако в декабрьском номере журнала ACM SIGMOD Record за 2005 г. появились две статьи, обладающими, на мой взгляд, некоторыми свойствами манифестов



Введение (7)

  • M. Stonebraker, U. Cetintemel, and S. Zdonik: The 8 Requirements of Real-Time Stream Processing

  • M. Franklin, A. Halevy and D. Maier: From Databases to Dataspaces: A New Abstraction for Information Management

  • Обе статьи явно или неявно опирается на идеи Лоэлловского отчета

  • В каждой из них предлагается некоторая стратегическая линия развития технологии управления данными



Лоуэллский отчет (1)

  • Нецелесообразно выдвижение очередной «сверхзадачи» (Grand Challenge) в области управления данными

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

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

  • Структуризация и классификация предложений Лоуэллского отчета



Лоуэллский отчет (2) Различные аспекты интеграции данных

  • Интеграция текста, данных, кода и потоков

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



Лоуэллский отчет (3) Различные аспекты интеграции данных

  • Слияние информации

  • «…подход хранилищ (DataWarehouse) и витрин (data mart) данных на основе извлечения операционных данных, их трансформации к единой схеме и загрузки данных в хранилище (процедура ETL – extraction, transformation, loading) пригоден для использования на предприятии с несколькими десятками операционных баз данных, находящихся под единым контролем. В Internet парадигма ETL не приемлема.»



Лоуэллский отчет (4) Различные аспекты интеграции данных

  • Сенсорные данные и сенсорные сети

  • «… при запросе данных у сенсорной сети часто более выгодным является полное распределение вычислений по отдельным узлам… При вычислении запроса необходимо уметь изменять план запроса при изменении сети по причине выхода из строя сенсора или его отключения от сети.»

  • Одна из пионерских работ TinyDB в этом направлении была начата в университете Беркли и продолжается теперь в лаборатории Intel в Беркли



Лоуэллский отчет (5) Различные аспекты интеграции данных

  • Мультимедийные запросы

  • «…объем мультимедийных данных (изображения, аудио, видео и т.д.) значительно возрастает. Проблемой сообщества баз данных является создание простых способов анализа, обобщения, поиска и обозрения электронных подборок мультимедийной информации, относящейся к некоторому человеку.»

  • Это частный аспект интеграции данных: требуется, прежде всего, унифицированное представление метаданных на этими данными.



Лоуэллский отчет (6) Новые черты обработки запросов

  • Использование неточных данных

  • «…СУБД должны обеспечивать встроенную поддержку неточных данных. … должна иметься возможность задания неточных запросов, и процессор запросов должен относиться к этому как к дополнительному источнику неполноты и неточности.»

  • В последние годы достаточно интенсивно исследуется частный случай этой проблемы, так называемые top-K-запросы



Лоуэллский отчет (7) Новые черты обработки запросов

  • Персонализация

  • «… ответы на запросы должны зависеть от профиля пользователя. Ответ на запрос эксперта должен отличаться от ответа на запрос новичка. Релевантность ответа тоже должна зависеть от пользователя и от контекста. …требуется среда для накопления и использования соответствующих метаданных.»

  • Этот пункт близок к предыдущему. В ответ на запрос «новичка» - не обязательно абсолютно точные данные, а те, которые в наибольшей степени соответствуют его профилю



Лоуэллский отчет (8) Новые черты обработки запросов

  • Конфиденциальность

  • «Решения о правомерности доступа должны основываться не только на том, кто запрашивает данные, но и на том, что он собирается с ними делать.»

  • Развивается тема персонализации доступа к данным

  • Решение о правомерности доступа и о виде ответа на запрос должно решаться в зависимости не только от профиля пользователя, но и от его текущей роли в сценарии использования запрашиваемых данных



Лоуэллский отчет (9) Новые черты обработки запросов

  • Системы, заслуживающие доверия

  • «Очень важно обеспечивать корректность результатов запросов и вычислений над большими объемами данных, в особенности во встроенных приложениях. Для подтверждения корректности может оказаться полезной технология логического вывода, например, методы доказательства теорем или верификации моделей.»

  • Близость с проблемой качества интегрированных данных, достаточном для целей оперативного анализа



Лоуэллский отчет (10) Совершенствование технологии

  • Самоадаптация

  • «Для многих новых приложений требуется необслуживаемое функционирование СУБД. СУБД должна сама распознавать внутренние неисправности и неисправности коммуникационных компонентов, находить поврежденные данные, обнаруживать сбои приложений и что-то делать по этому поводу.»

  • Попытками решения отдельных аспектов этой проблемы заняты все ведущие компании, производящие СУБД



Лоуэллский отчет (11) Совершенствование технологии

  • Оптимизация запросов

  • «Нужно продолжать работать в областях оптимизации средств интеграции информации, языков запросов полуструктурированных данных, таких как XQuery, процессоров потоков, сенсорных сетей и т.д.»

  • «Требуются исследования «межзапросной» оптимизации над большим числом традиционных, чисто реляционных запросов.»

  • «Межзапросная» оптимизация, по сути, очень близка к «самоадаптации» системы



Лоуэллский отчет (12) Совершенствование технологии

  • Data Mining

  • «Проблемой data mining в области баз данных является разработка алгоритмов и структур данных для просеивания базы данных в поисках «жемчужин». Такая обработка должна вестись в фоновом режиме с потреблением остаточных системных ресурсов. Другой важной проблемой является интеграция data mining с подсистемой поддержки запросов, оптимизацией и другими средствами базы данных, такими как триггеры.»

  • Методы data mining активно используются в подходе Сураджита Чаудхари к «межзапросной» оптимизации запросов



Лоуэллский отчет (13) Совершенствование технологии

  • Новые пользовательские интерфейсы

  • «Отличные системы визуализации информации – QBE и VisiCalc – были предложены еще в 80-е гг. прошлого века»

  • «Тридцать лет исследований в области языков запросов сводятся к тому, что «мы двигаемся от SQL к XQuery»

  • «…наиболее интересные возможности связаны с исследованиями, ассоциируемыми с термином «semantic Web».»

  • Мое скептическое отношение к направлению использования естественных языков для запросов к базам данным



Лоуэллский отчет (14) Столетнее хранение

  • «…человечество нуждается в средствах хранения, поддерживающих неограниченный во времени доступ к данным в полезной форме. Эти средства должны … автоматизировать процесс миграции данных из одного формата в другой и/или поддерживать аппаратно-программные механизмы, требующиеся для доступа к данным. Вместе с хранимыми документами должны присутствовать описывающие их метаданные.»

  • По моему мнению, решение этой проблемы выходит за пределы возможностей области управления данными



Управление потоковыми данными (1) Введение

  • Майкл Стоунбрейкер с конца 1990-х гг. является профессором MIT

  • В начале 2000-х гг. совместно с группами из Brandeis University и Brown University (Стенли Здоник и Угур Гетинтемел основал проект Aurora

  • В MIT выполнялся отдельный проект Medusa

  • На основе результатов проектов Aurora и Medusa выполняется новый совместный проект Borealis

  • В 2003 г. он основал компанию StreamBase Systems для коммерциализации технологии, разработанной в проектах Aurora и Medusa



Управление потоковыми данными (2) Введение

  • Хотя в исследовательском сообществе известно несколько реализованных проектов в области управления потоковыми данными, Стоунбрейкер и Здоник являются наиболее активными и последовательными представителями этой части сообщества баз данных

  • Поэтому я имею основания считать их публикацию «предманифестом» систем обработки потоковых данных

  • На манифест систем баз данных третьего поколения также оказала сильнейшее влияние система Postgres Майкла Стоунбрейкера



Управление потоковыми данными (3) Восемь требований Стоунбрейкера и Здоника (i)

  • В системе потоковой обработки реального времени сообщения должны обрабатываться “в потоке”, без потребности их сохранения до выполнения какой-либо операции или группы операций

  • Система должна быть в состоянии выполнять обработку сообщений, не прибегая к дорогостоящим операциям с внешней памятью

  • Существует дополнительная проблема задержек в пассивных системах, которые до начала обработки ждут, пока приложение скажет им, что нужно делать



Управление потоковыми данными (4) Восемь требований Стоунбрейкера и Здоника (ii)

  • Должен поддерживаться высокоуровневый язык “StreamSQL” со встроенными ориентированными на потоки примитивами и операциями

  • StreamSQL должен расширять семантику SQL путем добавления к нему мощных оконных конструкций и потоковых операций

  • Требуются новые, ориентированные на потоки операции, не представленные в стандартном SQL

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



Управление потоковыми данными (5) Восемь требований Стоунбрейкера и Здоника (iii)

  • Должны иметься встроенные механизмы, обеспечивающие устойчивость к “дефектам” потоков, включая отсутствие и нарушение порядка данных, что обычно присутствует в реальных потоках данных

  • Инфраструктура должна обеспечить управление данными, которые запаздывают, отсутствуют или поступают не в ожидаемом порядке

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



Управление потоковыми данными (6) Восемь требований Стоунбрейкера и Здоника (iv)

  • Процессор обработки потоков должен гарантировать предсказуемые и повторяемые результаты

  • Во всем обрабатывающем конвейере системы должна поддерживаться упорядоченная по времени, детерминированная обработка

  • Предсказуемые результаты также важны и с точки зрения отказоустойчивости и восстановления

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



Управление потоковыми данными (7) Восемь требований Стоунбрейкера и Здоника (v)

  • Должна иметься возможность эффективного хранения, доступа и модификации информации о состоянии, а также ее комбинирования с реальными потоковыми данными

  • Для бесшовной интеграции в системе должен использоваться единообразный язык для работы с обеими разновидностями данных

  • Состояние должно сохраняться в адресном пространстве той же операционной системы, в среде которой работает приложение, с использованием встроенной системы баз данных



Управление потоковыми данными (8) Восемь требований Стоунбрейкера и Здоника (vi)

  • Приложения должны быть работоспособными и доступными, а данные всегда целостными независимо от наличия сбоев

  • Cистема потоковой обработки должна основываться на решении с высоким уровнем доступности

  • Перезапуск операционной системы и восстановление приложения по журналу порождают слишком большие накладные расходы и поэтому неприемлемы для обработки в реальном времени



Управление потоковыми данными (9) Восемь требований Стоунбрейкера и Здоника (vii)

  • Система потоковой обработки должна распределять свою обработку по нескольким процессорам и машинам для достижения инкрементной масштабируемости

  • В идеале это распределение должно быть автоматическим и прозрачным

  • Должна иметься возможность расщепить приложение для выполнения на нескольких машинах, а также многопотоковое функционирование

  • Должна обеспечиваться балансировка нагрузки результирующего приложения между машинами



Управление потоковыми данными (10) Восемь требований Стоунбрейкера и Здоника (viii)

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

  • Важной проблемой является минимизация числа «пересечений границ» путем интеграции всех важнейших функций (например, обработки и сохранения) в одном системном процессе

  • При разработке всех компонентов должны учитываться требования производительности



Управление потоковыми данными (11) Связь восьми требований с Лоуэллским отчетом

  • Требование устойчивости к “дефектам” потоков находится в явном родстве пунктом Лоуэллского отчета об использовании неточных данных

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



Управление потоковыми данными (12) Связь восьми требований с Лоуэллским отчетом

  • Требование бесшовной интеграции потоковых и хранимых данных соответствует положению об интеграции текста, данных, кода и потоков

  • Соответствие является предельно точным: в модели системы потоковой обработки Стоунбрейкера и Здоника и потоки, и хранимые данные являются сущностями «первого класса»; ни одна из них не реализуется на основе другой



Управление потоковыми данными (13) Связь восьми требований с Лоуэллским отчетом

  • Наконец, требование высоко оптимизированного процессора является уточнением пункта об оптимизации запросов

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



Пространства данных (1) Введение

  • Дэвид Майер - профессор Portland State University (до этого много лет работал в Oregon Health and Science University)

  • The Theory of Relational Databases

  • Stanley B. Zdonik, David Maier. Readings in Object-Oriented Database Systems

  • Майкл Франклин – профессор университета Беркли с 2004 г.

  • Алон Хэлеви с 1998 г. работает в University of Washington, профессор этого университета



Пространства данных (2) Введение

  • Два ведущихся проекта, ориентированных на поддержку пространств индивидуальных данных

  • Проект SEMEX – SEMantic Explorer выполняется в University of Washington под руководством Хэлеви

  • Проект iMeMex выполняется с 1 апреля 2006 г. под руководством Йенса-Петера Диттриха в ETH Zurich

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



Пространства данных (3) Свойства и архитектура систем пространств данных

  • Измерение “административной близости” показывает, насколько близки различные источники данных с точки зрения административного управления

  • Измерение “семантической интеграции” является мерой того, насколько близко могут быть сопоставлены схемы различных источников данных



Пространства данных (4) Свойства и архитектура систем пространств данных

  • Традиционные СУБД представляют только одну точку в пространстве решений управления данными

  • Все данные находятся под единым административным управлением и соответствуют единой схеме

  • СУБД могут обеспечить развитые средства манипулирования данными и обработки запросов с понятной и строгой семантикой, а также строгие транзакционные гарантии обновлений, параллельного доступа и долговременного хранения



Пространства данных (5) Свойства и архитектура систем пространств данных

  • Важной точкой пространства решений являются “системы интеграции данных”

  • Особенность состоит в том, что в системах интеграции данных требуется семантическая интеграция до того, как могут быть обеспечены какие-либо прочие услуги

  • Система должна знать точные взаимосвязи между элементами, используемыми в каждой схеме

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



Пространства данных (6) Свойства и архитектура систем пространств данных

  • Цель поддержки пространства данных состоит в обеспечении базового набора функций надо всеми источниками данных, а не в их интеграции

  • Например, DSSP (DataSpace Support Platform) может обеспечить надо всеми своими источниками данных поиск по ключевым словам

  • При потребности в более сложных операциях, таких как запросы в реляционном стиле, анализ данных (data mining) или мониторинг каких-либо источников, можно приложить дополнительные усилия к более тесной интеграции этих источников в инкрементной манере



Пространства данных (7) Свойства и архитектура систем пространств данных

  • Аналогичная гибкость имеется и в измерении административной близости

  • Если желательно наличие административной автономии, то DSSP не сможет гарантировать согласованность, устойчивость результатов операций обновления и т.д.

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



Пространства данных (8) Свойства и архитектура систем пространств данных

  • Отличительные свойства систем пространств данных

  • DSSP должны работать с данными и приложениями в разнообразных форматах, доступных от многих систем через различные интерфейсы

  • От DSSP требуется поддержка всех данных пространства данных, без каких-либо исключений



Пространства данных (9) Свойства и архитектура систем пространств данных

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

  • Поэтому, в отличие от СУБД, DSSP не имеет полного контроля над своими данными



Пространства данных (10) Свойства и архитектура систем пространств данных

  • Могут обеспечиваться разные уровни услуг по обработке запросов к DSSP, и в некоторых случаях они могут возвращать наилучшие из возможных приблизительные ответы

  • Например, если некоторые источники данных становятся недоступными, DSSP может обеспечить наилучший из возможных результат на основе данных, доступных во время выполнения запроса



Пространства данных (11) Свойства и архитектура систем пространств данных

  • DSSP должны поддерживать средства для обеспечения более тесной интеграции данных пространства, если это становится необходимо



Пространства данных (12) Свойства и архитектура систем пространств данных

  • Каталог и просмотр

  • Каталог содержит информацию обо всех участниках пространства данных и о связях между ними

  • Для каждого участника каталог должен включать схему источника, статистические данные, скорость изменения, точность, возможности ответов на запросы, информацию о владельце и данные о политике доступа

  • Связи могут сохраняться в виде преобразований запросов, графов зависимости, и даже текстовых описаний



Пространства данных (13) Свойства и архитектура систем пространств данных

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

  • Тогда в нем можно поддерживать базовую возможность просмотра объединенного реестра всех участников

  • Интерфейс просмотра можно использовать для ответов на вопросы пользователей о наличии или отсутствии элемента данных или определения того, какие участники хранят документы данного типа



Пространства данных (14) Свойства и архитектура систем пространств данных

  • Поиск и запрашивание

  • У пользователей должна иметься возможность запроса любого элемента данных, независимо от его формата и модели данных

  • В начале работы с пространством данным DSSP должна поддерживать для каждого участника запросы по ключевым словам

  • По мере получения большей информации об участнике, DSSP должна постепенно начать поддерживать более сложные запросы

  • Должно поддерживаться плавное переключение между запросами по ключевым словам, просмотром и структурированными запросами



Пространства данных (15) Свойства и архитектура систем пространств данных

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

  • Запросы могут формулироваться на разнообразных языках (и на основе разных моделей данных), и они должны наилучшим образом переформулироваться на другие модели данных и схемы, обеспечивая точные и приближенные семантические отображения



Пространства данных (16) Свойства и архитектура систем пространств данных

  • В системе должен поддерживаться широкий спектр запросов к метаданным

  • Должны обеспечиваться возможности получения данных об источнике ответа или о том, как этот ответ был выведен или вычислен; обеспечения временных меток на элементах данных, которые участвовали в вычислении ответа; указания того, какие другие элементы данных в пространстве данных могут зависеть от заданного элемента данных; запрашивания источников и уровня недостоверности ответа

  • DSSP должны также поддерживать запросы на установление местоположения данных, ответами на которые являются источники данных



Пространства данных (17) Свойства и архитектура систем пространств данных

  • Службы поиска и запрашивания данных должны также поддерживаться в инкрементной форме, применимой в реальном времени к потоковым или изменяемым источникам данных

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

  • Служба инкрементного мониторинга может обеспечить функции обнаружения сложных событий и генерации сигналов



Пространства данных (18) Свойства и архитектура систем пространств данных

  • Локальное хранение и индексирование

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



Пространства данных (19) Свойства и архитектура систем пространств данных

  • Средства индексирования должны обладать высоким уровнем адаптивности к неоднородным средам

  • В качестве входных данных должно приниматься любое значение, встречающееся в пространстве данных, и должны выдаваться координаты всех объектов данных, в которых имеется такое значение, и роли каждого его вхождения

  • Индекс определяет информацию для всех участников, когда значения входят в несколько источников данных, и должен справляться с разнообразием ссылок на объекты реального мира



Пространства данных (20) Свойства и архитектура систем пространств данных

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



Пространства данных (21) Свойства и архитектура систем пространств данных

  • Компонент раскрытия

  • Обнаружении участников в пространстве данных, создании связей между ними и оказании помощи администраторам при совершенствовании и усилении этих связей

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

  • Компонент должен выполнять начальную классификацию участников на основе их типов и содержимого



Пространства данных (22) Свойства и архитектура систем пространств данных

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

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

  • Компонент раскрытия должен осуществлять мониторинг содержимого пространства данных, чтобы можно было со временем предложить новые связи



Пространства данных (23) Свойства и архитектура систем пространств данных

  • Компонент расширения источников

  • У некоторых участников могут отсутствовать существенные функции управления данными

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

  • Может оказаться необходимо обеспечивать эти расширения “по месту”, поскольку могут иметься существующие приложения или потоки данных, рассчитанные на имеющиеся форматы или справочные структуры



Пространства данных (24) Свойства и архитектура систем пространств данных

  • Хотя DSSP с полным набором служб должны содержать все эти компоненты, многие из них могли бы использоваться независимо для достижения некоторого компромисса между расходами и получаемыми преимуществами

  • Важно, что DSSP допускает инкрементное инвестирование, а не представляет собой только монолитное решение



Пространства данных (24) Новые исследовательские проблемы

  • Моделирование данных и базовые возможности запросов

  • Более широкое представление запрашивания

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

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

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

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

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



Пространства данных (25) Пространства данных и Лоуэллский отчет

  • Пункт об интеграция текста, данных, кода и потоков развивается и обогащается на основе идеи иерархии моделей данных

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

  • Но цель преследуется та же, и кажется заманчивой перенести идею иерархии моделей на локальную СУБД



Пространства данных (26) Пространства данных и Лоуэллский отчет

  • Пункт о слиянии информации получает оригинальную и предельно ясную трактовку

  • С использованием компонентов DSSP и зависящего от конкретной ситуации объема человеческого труда можно обеспечить интеграцию любого числа источников данных любой природы с требуемым уровнем качества

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

  • Весь вопрос в том, сколько это будет стоить



Пространства данных (27) Пространства данных и Лоуэллский отчет

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

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



Пространства данных (28) Пространства данных и Лоуэллский отчет

  • Пункт о самоадаптации трансформируется в «повторное использование человеческого труда»

  • И снова это кажется очень здравой идеей, поскольку первичным источником знаний, которыми должна руководствоваться программная система, является человек



Пространства данных (29) Пространства данных и Лоуэллский отчет

  • Наконец, целый ряд идей можно соотнести с пунктом о пользовательских интерфейсах

  • Здесь и комбинирование средств контекстного поиска и структурированных запросов, и итерационное совершенствование формы запроса под руководством системы, и т.д.



Заключение (1)

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

  • Эти задачи кажутся авторам публикаций настолько привычными и естественными, что обычно они даже и не пытаются объяснить читателям их происхождение и актуальность

  • В Асиломарском отчете такого рода исследовательские работы относились к категории «delta-X»

  • «Исследования "delta-X" отличаются тем, что сосредотачиваются на сиюминутной цели, "улучшении" некоторой уже широко известной идеи»



Заключение (2)

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

  • Одним из результатов собрания в Лагуна-Бич [1] стало появление Манифеста систем объектно-ориентированных баз данных и Манифеста систем баз данных третьего поколения

  • Эти документы во многом определили развитие технологии баз данных в конце прошлого столетия



Заключение (3)

  • Рассмотренные публикации, последовавшие за официальным опубликованием Лоэллского отчета, кажутся мне продолжением этой традиции в новом столетии

  • Отличаясь по духу и форме от классических манифестов, эти работы обеспечивают основу нового этапа развития технологии управления данными.



Похожие:

Предвестники новых манифестов управления данными Сергей Кузнецов iconПредположим, что Вы хотите управлять данными о Предположим, что Вы хотите управлять данными о
Рабочую программу какого типа можно использовать для управления этой информацией?
Предвестники новых манифестов управления данными Сергей Кузнецов iconЕвразийская патентная система взгляд поверенного Кузнецов Ю. Д., партнер
Преследовали в том числе цель компенсировать пробелы оснащения новых патентных ведомств
Предвестники новых манифестов управления данными Сергей Кузнецов iconПредвестники возникновения средневековых городов в X-XI веках Предвестники возникновения средневековых городов в X-XI веках
Возникновение и рост городов закономерное следствие отделения ремесла от земледелия
Предвестники новых манифестов управления данными Сергей Кузнецов iconДоступ к информации и участие населения в процессе принятия решений по вопросам окружающей среды
С начала 1990-ых состояние окружающей среды и экологического управления в Чили улучшилось. Однако, существующие экологические вызовы,...
Предвестники новых манифестов управления данными Сергей Кузнецов iconОбъектно-реляционные базы данных: прошедший этап или недооцененные возможности? Сергей Кузнецов
Личная точка зрения: Манифест систем баз данных следующего поколения, sql, реализации ibm и Oracle
Предвестники новых манифестов управления данными Сергей Кузнецов iconСбор, обработка, анализ и запрос отчетной информации, требуемой в рамках кпмо, с муниципального органа управления образования в установленных форматах
Портал имеет возможность обмена данными с административными системами управления, внедряемыми проектом поставки стандартного базового...
Предвестники новых манифестов управления данными Сергей Кузнецов iconЛекция 4 Работа с файлами
Файловая система это часть операционной системы, назначение которой состоит в том, чтобы организовать эффективную работу с данными,...
Предвестники новых манифестов управления данными Сергей Кузнецов iconЛекция 4 Работа с файлами
Файловая система это часть операционной системы, назначение которой состоит в том, чтобы организовать эффективную работу с данными,...
Предвестники новых манифестов управления данными Сергей Кузнецов iconИнформационное обеспечение системы управления государственной службой и кадрами в новых условиях функционирования

Предвестники новых манифестов управления данными Сергей Кузнецов icon1. Введение Лесным кодексом РФ новых инструментов государственного управления лесами, регламентирующих доступ к освоению лесов
Введение Лесным кодексом РФ новых инструментов государственного управления лесами, регламентирующих доступ к освоению лесов
Разместите кнопку на своём сайте:
hnu.docdat.com


База данных защищена авторским правом ©hnu.docdat.com 2012
обратиться к администрации
hnu.docdat.com
Главная страница