3154

Рис. 4.3. Традиционная структура системы принятия управленческих решений

Первоначально информация хранится в оперативных базах данных OLTP-систем. Кроме того, на предприятиях существует большой объем нерегламентированной информации, которую также необходимо подвергать анализу. Это информация, которая приходит от руководящих и регулирующих органов и не поступает в базу данных предприятия, а также информация, получаемая из Интернета, и любые другие существенные для бизнеса данные. Хранилище данных (ХД, WD – Data Warehouse) позволяет собирать эту информацию и производить её дальнейший анализ.

Когда данные импортируются в Хранилище Данных, они подвергаются некоторой первичной обработке, обеспечивающей эффективность последующего анализа: производится очистка данных, структурирование по времени, агрегирование, фильтрация и ряд других операций. Агрегированная информация организуется в многомерное хранилище данных Data Warehouse. Затем она используется в процедурах многомерного анализа OLAP и для интеллектуального анализа данных

Data Mining (DM, ИАД).

С целью получения максимального эффекта от использования СППР рекомендуется не изолированное применение, а интеграция в общую информационную систему (ИС) предприятия. Это связано со следующими факторами:

210

−работа с СППР как с отдельной системой является крайне неудобной для пользователей, так как не позволяет видеть общую картину сразу, а требует переключения между системами, что уменьшает использование системы и, как следствие, эффект от ее использования;

−СППР должна получать данные в реальном времени, а пользователь должен моментально видеть результаты ее работы, чтобы без больших временных затрат принять правильное решение;

−кроме того, многопользовательская концепция СППР предполагает получение адекватной прогнозной и рекомендательной информации на настоящий момент, что возможно только при полной интеграции СППР и ИС.

Однако применение СППР не в составе ИС также приводит к увеличению эффективности, но удобство использования при этом уменьшается. В этом случае необходимые данные из ИС следует трансформировать в определенный формат для дальнейшей передачи в СППР.

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

4.4. Хранилища данных Data Warehouse

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

211

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

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

4.4.1. Понятие и основные характеристики Хранилищ данных

Уильям Г. Инмон (William H. Inmon), считающийся основателем нового направления развития технологии баз данных, дал классическое определение Хранилища данных. Он охарактеризовал его как специальным образом администрируемую БД, в которой содержатся данные, обладающие описанными ниже свойствами:

−Предметно-ориентированны. ХД должно разрабаты-

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

−Интегрированы и внутренне непротиворечивы. По-

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

212

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

−Данные инвариантны во времени (неизменчивы). В

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

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

−Поддерживающие хронологию (стабильность ин-

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

−Полнота и достоверность хранимых данных (мини-

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

Ральф Кимбалл (Ralph Kimball), один из соавторов концепции Хранилищ данных, описывал хранилище как «место, где люди могут получить доступ к своим данным». Он же сформулировал и основные требования к хранилищам данных:

−поддержка высокой скорости получения данных из хранилища;

−поддержка внутренней непротиворечивости данных;

−возможность получения и сравнения так называемых срезов данных (slice and dice);

213

−наличие удобных утилит просмотра данных в храни-

лище;

−полнота и достоверность хранимых данных;

−поддержка качественного процесса пополнения дан-

ных.

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

Компоненты, входящие в типичное ХД, представлены на рис. 4.4.

Рис. 4.4. Типичная структура Хранилища данных

214

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

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

При этом для их промежуточного хранения используется Оперативный склад данных (ODS - Operational Data Store). В литературе существуют разные определения этого класса данных. В частности под оперативным складом данных можно подразумевать технологический элемент хранения данных в СППР, который служит буфером между транзакционными источниками данных и хранилищем. Как было уже отмечено ранее, данные, прежде чем попасть в хранилище, должны быть преобразованы в единые форматы, очищены, объединены и синхронизированы. Например, данные, необходимые для поддержки принятия решения, могут существовать в транзакционной системе более короткое время (часы, дни), чем период пополнения данных хранилища (дни, недели). Или семантически однородные данные поступают из транзакционных систем в разное время. В этом случае оперативный склад данных служит аккумулятором данных, поступающих от источников, перед их загрузкой в хранилище. В отличие от хранилища данных информация в складе данных может изменяться со временем в соответствии с изменениями, происходящими в источниках данных.

Конструкция оперативного склада аналогична конструкции хранилища данных. Идентичность оперативного склада и хранилища данных состоит в их предметной ориентированности и хранении детальных данных. Отличие от хранилища данных состоит в том, что оперативный склад данных:

215

−имеет изменяемое содержимое;

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

−содержит текущие значения данных.

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

Данные, хранящиеся в транзакционных БД и оперативном складе данных, уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. Они могут быть загружены в специальную БД OLAP или оставлены в ХД.

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

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

1. С точки зрения пользователей:

−метаданные для бизнес-аналитиков;

−метаданные для администраторов;

−метаданные для разработчиков.

2. С точки зрения предметных областей:

−структуры данных хранилища;

−модели бизнес-процессов;

−описания пользователей;

−технологические и пр.

216

3. С точки зрения функциональности системы:

−метаданные о процессах трансформации;

−метаданные по администрированию системы;

−метаданные о приложениях;

−метаданные о представлении данных пользователям. В настоящее время отсутствует единая промышленная

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

* * *

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

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

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

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

217

4.4.2. Методика (методология) построения Хранилищ данных

Существуют различные подходы к стратегии построения корпоративного хранилища данных: построение сверху вниз; снизу вверх; динамическая интеграция данных и др.

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

Рис. 4.5. Спиральная модель разработки

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

−постановка задачи;

−проектирование;

−реализация;

−внедрение.

218

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

Рис. 4.6. Этапы создания Хранилища данных

219