Информационные хранилища как основа построения архивов фактографической информации для принятия управленческих решений

Информационные хранилища (Data Warehousing) – это новый этап представления данных в рамках современных бизнес-процессов. Концепция DW предложена в 1990 году Б. Инмоном и стала одной из доминирующих в разработке информационных технологий обработки данных 90-х годов. По Инмону DW – есть предметно-ориентированный, интегрированный, неизменный, поддерживающий хронологию набор данных, предназначенный для поддержки принятия решений. В этом определении соединены две различные функции: сбор, организация, подготовка данных для анализа в виде постоянно наращиваемой БД; собственно анализ, как элемент принятия решений.

В Российской печати термин DW переводится двояко - хранилище данных и информационное хранилище. Термин «Information Warehouse» был введен корпорацией IBM еще в начале 80-х годов и, по мнению специалистов, отражает нечто большее, чем DW по Инмону.

Назначение информационных хранилищ заключается в следующем:

· интеграция данных в масштабе бизнес-процессов;

· функционально-стоимостной анализ эффективности бизнес-процессов;

· сложные аналитические запросы в разрезах: виды услуг, клиенты, регионы, технологии;

· анализ данных в динамике и в сравнении с показателями отрасли.

Основные принципы организации хранилищ данных.

1. Предметная ориентация. В оперативной базе данных обычно поддерживается несколько предметных областей, каждая из которых может послужить источником данных для ХД. Например, для магазина, торгующего видео- и музыкальной продукцией, интерес представляют следующие предметные области: клиенты, видеокассеты, CD-диски и аудиокассеты, сотрудники, поставщики. Явно прослеживается аналогия между предметными областями ХД и классами объектов в объектно-ориентированных базах данных. Это говорит о возможности применения методов проектирования, применяемых в объектно-ориентированных СУБД.

2. Средства интеграции. Приведение разных представлений одних и тех же сущностей к некоторому общему типу.

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

4. Хронология данных. Благодаря средствам интеграции реализуется определенный хронологический временной аспект, присущий содержимому ХД.

В настоящее время также значителен рост интереса в области многомерных аналитических хранилищ данных, часто объединяемых под единым названием оперативной аналитической обработки (On-Line Analytical Processing – OLAP). Учитывая, что подобные хранилища предназначены для хранения многолетней информации, одной из специфических задач, выполняемых в процессе эксплуатации в аналитических хранилищах, является анализ разреженности куба и оптимизации технологии его хранения. Кроме того, производится расчет промежуточных агрегатов, которые позволяют значительно оперативнее предоставлять данные по запросу.

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

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

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

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

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

Основные этапы реализации технологии DW можно представить следующим образом. Разработчик DW сначала определяет логические концепции бизнес-предметов и их элементов. Модель строится на базе исследования источников оперативных данных на предмет их местонахождения и формата, степени детализации, методов доступа к ним и других физических свойств, помогающих описывать способы отображения данных в DW. Кроме того, есть возможность создания любой произвольной информации, которая не хранится в явном виде в хранилище оперативных данных. Логическая модель должна быть переведена на язык модели физических данных, которая определяет реальную архитектуру хранения данных в DW. В такой модели должно учитываться, каким образом будут использованы данные. В физической модели данных учитывается как могут быть определены индивидуальные хранилища данных (Data Marts) – киоск или витрина данных, а также частота загрузки данных.

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

Архитектура информационного хранилища представлена на рисунке 5.

Рисунок 5 - Архитектура информационного хранилища.

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

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

Существует две противоположные точки зрения на хранение данных в системах поддержки принятия решений. Прежде всего, это подход МОLАР (Multidimensional-многомерный ОLАР), при котором все данные хранятся либо вычисляются по формулам в многомерной базе данных. Один из первых производителей таких систем - компания Агbог Software. Компания 0гасlе предлагает систему 0гас1е Ехргеss, интегрированную с универсальным 0гасlе Server. Известны и другие производители МОLАР-систем, например SAS Institute.

Другой подход - ROLAP (реляционный ОLАР), когда данные хранятся в реляционной базе данных, а для пользователя создается многомерное представление на логическом уровне в виде слоя метаданных, т.е. для систем RОLАР гиперкуб - это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. Слой метаданных отображает реляционные термины (таблицы, связи, ключи) в многомерные (измерения, иерархии, показатели) и, таким образом, скрывает от конечного пользователя сложную структуру реляционной БД. Одной из лучших реализаций технологии RОLАР "в чистом виде", предлагаемой корпорацией 0гасlе, является Discoverer или MetaCube фирмы Informix.

На практике существуют клиентские ОLАР-серверы, предназначенные для работы с небольшими объемами данных и ориентированные на индивидуального пользователя. Подобные системы были названы настольными, или DОLАР- серверами (Desktop ОLАР). В этом направлении работают фирмы Business Objects, Andyne (CubeCreator, PaBLO), Cognos, Brio Technology.

У каждого подхода есть свои достоинства и недостатки. Так, например, многомерная модель весьма чувствительна к объемам хранимых данных, данные сначала помещаются в специальную многомерную базу МDВ, а затем эффективно обрабатываются ОLАР-сервером. Для МDВ характерна высокая производительность, мощная аналитика и поддержка сложных запросов, которые неудобно реализовывать в SQL.

С другой стороны, при использовании подхода RОLАР нет необходимости дублировать данные; в реляционных БД могут храниться терабайты данных, более развиты методы репликации, восстановления после сбоев и т.д.

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

- четкое представление цели анализа;

- сбор релевантных данных;

- выбор методов анализа;

- выбор программного средства;

- выполнение анализа;

- принятие решения об использовании результатов

- контроль полноты и согласованности данных

Интеллектуальный. анализ, в отличие от ОLАР, используется для генерации гипотез, а не для их проверки. Так, занимаясь поиском путей повышения вероятности возврата кредитов, аналитик может прибегнуть к помощи средств интеллектуального анализа данных для получения прогноза о степени риска кредитования хозяйствующих субъектов с низким уровнем доходов и большой задолженностью. Но, кроме того, он может выявить и другую закономерность, например, о влиянии на степень риска отношения задолженности к доходам или другой характеристики.

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

Компания Information Discovery разработала системы System и OLAP Affinity System, предназначенные специально для интеллектуального анализа многомерных агрегированных данных.

Ро1уАnalyst компании «Мегапьютер» - отечественная разработка в области DМ, основанная на оригинальных методах анализа данных, позволяющая выявлять нелинейные зависимости одной переменной от множества факторов, а также проводить классификацию многомерных данных. Для оценки статистической значимости выводов используются, в основном, непараметрические методы. Ро1уАnalist позволяет выявлять и изучать влияние аномалий – «выбросов», допускают содержательную интерпретацию моделей, предоставляют средства визуализации. Система PolyAnalyst выполнена в архитектуре клиент-сервер.

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

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

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