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

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

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

Рисунок 4 иллюстрирует принципы интеграции информации на основе управления федеративными данными.

Рис. 4.  Принципы интеграции через управление федеративными данными

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

Частью процесса описания архитектуры является сбор информации, которая определяет объекты в виде "как есть", определение целевого состояния, а также плана перехода из текущего состояния в целевое. Это верно и для Архитектуры информации, и для моделей информации. Как правило, текущее состояние архитектуры информации описывается с использованием логических и физических моделей данных, многие из которых могут отсутствовать в репозитории метаданных предприятия. Эти модели обычно являются платформенно-зависимыми. Целевое состояние, как правило, описывается в форме платформенно-независимых семантических или виртуальных моделей. Для перехода от текущего состояния в желаемое будущее потребуется установление отображения (mapping) и трансформации между платформенно-зависимыми моделями и виртуальными моделями. Со временем, когда понадобится создание новой прикладной системы, может потребоваться отображение виртуальной модели на новую, специфическую для выбранной платформы реализации модель.

Инструменты

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

Хранилища данных

Согласно [4], Корпоративное хранилище данных – это специальным образом организованный массив данных предприятия (организации), обрабатываемый и хранящийся в едином аппаратно-программном комплексе, который обеспечивает быстрый доступ к оперативной и исторической информации, многомерный анализ данных (KPI по различным измерениям), получение прогнозов и статистики в разрезах согласованной нормативно-справочной информации (НСИ).

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

Структура хранилища данных

Рис. 5. Компоненты корпоративного хранилища данных предприятия

1) У клиента всегда имеются операционные системы – источники данных для корпоративного хранилища данных. Это, например, бухгалтерские, биллинговые, банковские и т.п. системы.

2) Используя ETL-приложение (программное обеспечение, позволяющее извлекать, трансформировать и загружать данные), данные из систем-источников попадают в базу данных хранилища данных. В качестве ETL-средства могут использоваться: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Существуют и продукты от других вендоров, но они почти не представлены на российском рынке.

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

4) Модель данных представляет собой описание всех сущностей, объектов базы данных корпоративного хранилища данных и включает в себя: концептуальную модель данных, логическую модель данных и физическую модель базы данных. На уровне концептуальной модели определяются сущности и взаимосвязи между ними. На уровне логической модели сущности делятся на бизнес-области, им дается подробное и полное описание, прописываются взаимосвязи. При разработке физической модели базы данных определяется вся структура базы данных - от таблиц и полей в них, до партиций и индексов. Модели данных сегодня на рынок поставляют IBM, SAP и Oracle, но покупка модели данных не означает автоматическое построение верного корпоративного хранилища. Модель данных - это не коробочный продукт. Ее нужно модифицировать под нужды конкретного клиента.

5) Далее, уже используя данные из корпоративного хранилища данных, производится настройка областей анализа, отчетности и витрин данных. В последствии пользователи вполне самостоятельно могут строить необходимую отчетность и проводить многомерный анализ. В качестве инструментов анализа в основном используются Business Objects, Oracle Discoverer, IBM AlphaBlocks и другие продукты.

Процессы работы с данными в ХД

Источниками данных могут быть:

• Традиционные системы регистрации операций

• Отдельные документы

• Наборы данных

Операции с данными:

• Извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.

• Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.

• Загрузка – помещение данных в хранилище, производится атомарно, путем добавления новых фактов или корректировкой существующих.

• Анализ – OLAP, Data Mining, сводные отчёты.

• Представление результатов анализа.

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

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

Логическая структура данных хранилища данных отличается от структуры данных источников данных.

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

Кроме извлечения данных из БД, принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.

С точки зрения пользователя в процессе извлечения знаний из БД должны решаться след. преобразования: данные → информация → знания → полученные решения.

Enterprise content management

Enterprise content management (ECM) — управление информационными ресурсами предприятия или управление корпоративной информацией [7].

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

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

• Управление документами — экспорт/импорт, контроль версий, безопасность и службы библиотек для деловых документов.

• Управление образами документов (Document Imaging) — захват, преобразование и управление бумажными документами.

• Управление записями (или, в соответствии с последним переводом стандарта IEEE 15489 — ГОСТ Р ИСО 15489-1-2007, «управление документами») — долгосрочное архивирование, автоматизация политик хранения и соответствия нормам регулирующих органов, обеспечение соответствия законодательным и отраслевым нормам.

• Управление потоками работ (Workflow) — поддержка бизнес-процессов, передача контента по маршрутам, назначение рабочих задач и состояний, создание журналов аудита.

• Управление веб-контентом (WCM) — автоматизация роли веб-мастера, управление динамическим контентом и взаимодействием пользователей.

• Управление мультимедиаконтентом (DAM) — управление графическими, видео и аудиофайлами, различными маркетинговыми материалами, например, флеш-баннерами, рекламными роликами.

• Управление знаниями (Knowledge Management) — поддержка систем для накопления и доставки релевантной для бизнеса информации.

• Документо-ориентированное взаимодействие (Collaboration) — совместное использование документов пользователями и поддержка проектных команд.

В российской практике понятие ECM часто подменяется на «системы электронного документооборота» (СЭД).

Список литературы

1. Информационная архитектура [Электронный ресурс] // Википедия : [Сайт]. [2012]. URL: http://en.wikipedia.org/wiki/Information_architecture

2. Архитектура информации [Электронный ресурс] // вики-портал образовательных ресурсов: [Сайт]. [2011]. URL: http://wiki.vspu.ru/workroom/pi51/%D1%87%D0%B0%D1%81%D1%82%D1%8C%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D0%B8_11

3. Архитектура предприятия. Лекция 5. [Электронный ресурс] // Интуит – интернет-университет : [Сайт]. [2012]. URL: http://www.intuit.ru/studies/courses/995/152/lecture/2229?page=8#sect8

4. Что такое корпоративное хранилище данных (Data Warehouse) и кому его продавать. [Электронный ресурс] // Корпоративные хранилища данных. Интеграция систем. Проектная документация: [Сайт]. [2010]. http://www.prj-exp.ru/dwh/what_is_dwh.php

5. Хранилище данных [Электронный ресурс] // Википедия : [Сайт]. [2012]. URL: http://ru.wikipedia.org/wiki/%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B5_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

6. OLAP [Электронный ресурс] // Википедия : [Сайт]. [2012]. URL: http://ru.wikipedia.org/wiki/OLAP

7. ECM [Электронный ресурс] // Википедия : [Сайт]. [2012]. URL: http://ru.wikipedia.org/wiki/Enterprise_content_management