Информационные компоненты интеллектуальных систем (часть 3)

Сводка данных может управлять массивными наборами гранулированных данных в меньшем, более нормализованном физическом пространстве, например 3НФ и схеме «звезда». Основывается на математических принципах, которые поддерживают нормализованные модели данных. Внутренняя часть модели сводки данных – близкие структуры, которые соответствуют традиционным определение схемы «звезда» и 3НФ, содержащие измерения, связи “многие ко многим” и стандартные табличные структуры. Отличия заключаются в представлении связей, структуризации поля и гранулированном, связанном с тем, хранении данных.

Есть такие подвиды хранилища данных: витрина данных, оперативное хранилище данных.

Определение 4. Витрина данных (ВД) – срез хранилища данных, массив тематической, узконаправленной информации, ориентированный, например, на пользователей одной рабочей группы или департамента.

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

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

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

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

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

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

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

А вы знаете историю той среды, в которой вы проводите каждый день кучу времени? Я про Интернет конечно! Знакома ли вам история поисковых систем? Очень познавательно ее узнать для общего развития и выявления тенденций и перспектив.

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

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

Определение 6. Пространство данных DS – это множество данных, представленных в разных моделях (баз данных DB, хранилищ данных DW, статических Web-страниц Wb, неструктурированных данных Nd, графических и мультимедиа Gr), локальных хранилищ и индексов ODW, а также средств интеграции Int, поиска Se и обработки информации Wo, объединенных средой управления моделями EM.

DS = <DB, DW, ODW, Wb, Nd, Gr, Int, Se, Wo, EM>.

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

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

Проблемы, которые привели к необходимости введения такой абстракции данных, как пространство данных:

1. Интеграция текста, данных, кода и потоков (частично решена благодаря введению Коддом 12-ти правил построений хранилищ данных и их последующей модификации).

2. Возможность багатоконтрольности данных (в концепции хранилищ данных) обеспечивалась с помощью процедур извлечения, преобразования и загрузки данных (extract, transform and load-ETL), а в случае Интернет с тысячами источников информации, представленной в различных форматах, ETL не пригодна для использования).

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

4. Поддержка неточных и несвоевременных (поступающих с опозданием или в неожиданном порядке) данных и реализация неточных запросов. В последние годы достаточно интенсивно исследуется частный случай этой проблемы, так называемые top-K-запросы и неточные запросы. Опять же, разработаны модели и технологии работают только с определенными моделями данных (в частности реляционной – Fquery, Fuzzy Grouping и Fuzzy Lookup). Относительно несвоевременных данных вообще отсутствуют методы, которые бы давали возможность не только фиксировать факт опоздания данных, но и на основе этих отсутствующих данных принимать решение (ведутся работы в области машин для обработки событий, однако сегодня задекларированы только проблемы, которые приводят к задаче манипулирования потоками . Работы, проведенные в середине 90-х годов в области активных баз данных (Active DBMS, ADBMS), остались неиспользованными из-за большого время отклика запросов и неучет временного отсутствия данных).

5. Релевантность ответа должна зависеть от пользователя и от контекста. Нужно среду для накопления и использования соответствующих метаданных. Есть разработки по определению типа пользователя на основе записей в журнале доступа к ресурсам.

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

7. Использование естественных языков запросов к базам данных (так называемые системы с естественноязыковой интерфейсом) – предусматривают формирование запросов к системе в виде вопросительных предложений на естественном языке.

8. Поддержка систем обработки потоковых данных (например, система Postgres Майкла Стоунбрейкера, высокоуровневый язык “STREAMSQL” со встроенными ориентированными на потоки примитивами и операциями).

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

%d такие блоггеры, как: