Архитектурные решения и моделирование данных для хранилищ и витрин данных

Архитектурные решения и моделирование данных для хранилищ и витрин данных 

Константин Лисянский, архитектор хранилищ данных линии программных  продуктов DiasoftMIS 
 

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

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

Основные отличия  систем поддержки принятия решений  от традиционных оперативных систем 

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

На данный момент существует масса публикаций, в которых  эти отличия рассматриваются  весьма подробно [4, 6, 8]. Такой анализ выходит за рамки данной статьи, по этому мы ограничимся отличиями, влияющими на приемы моделирования  тех и других систем.  

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

Варианты архитектуры  СППР 

На сегодняшний  день известно несколько способов построения СППР. Большинство из них основано на технологиях хранилищ и витрин данных. Остановимся на некоторых  из них.  

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

Функциональная  СППР.

Независимые витрины  данных.

Двухуровневое хранилище данных.

Трехуровневое хранилище данных.

Функциональная  СППР 

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

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

Преимущества:

Быстрое внедрение  за счет отсутствия этапа пере грузки данных в специализированную систему 

Минимальные затраты  за счет использования одной платформы. Недостатки:

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

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

Большая нагрузка на оперативную систему. Сложные  запросы могут привести к остановке  ра боты оперативной системы, что  весьма нежелательно.

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

Модель данных хранилища данных 

Данные поддерживают оперативные процессы, базовые запросы и принятие простейших решений. 

Данные поддерживают исторические запросы, анализ тенденций  и принятие стратегических решений.  

Модель ориентирована  на приложение. 

Модель ориентирована  на предметную область. 

Может содержать  разрозненные данные и домены из-за унаследованных баз данных и приложений.  

Единое согласованное  на уровне предприятия определение  данных и общие домены данных.  

Полная нормализация для контроля целостности данных. 

Контролируемая  денормализация для эффективного извлечения данных. 

Текущие значения данных. 

Данные с полной или частичной историей изменений. 

Минимальное количество производных данных. 

Базовые и суммарные  данные. 

Содержит все  оперативные данные, требующиеся  в данный момент. 

Содержит данные, имеющие ценность во времени. 

Содержит данные, произведенные, в основном, в пределах предприятия. 

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

СППР с использованием независимых витрин данных 

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

Преимущества:

Витрины данных можно внедрять очень быстро

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

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

Недостатки:

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

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

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

СППР на основе двухуровнего хранилища данных 

Двухуровневое хранилище данных (рис.3) строится централизовано для предоставления информации в  рам ках компании. Для поддержки  такой архитектуры необхо дима выделенная команда профессионалов в области хра нилищ данных.  

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

Преимущества:

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

Минимальные затраты  на хранение данных

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

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

Недостатки:

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

Возможны проблемы с производительностью системы 

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

СППР на основе трехуровневого хранилища данных 

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

Преимущества:

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

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

Гарантированная производительность  

Недостатки:

Существует избыточность данных, ведущая к росту требований на хранение данных

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

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

Подробное описание преимуществ и недостатков каждого  варианта архитектуры можно найти  в литературе [2, 3].

Моделирование хранилищ данных 

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

Особенности моделирования  времени в хранилищах данных 

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

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

Модель снимков  данных 

Снимок данных — это представление данных в  опре деленный момент времени. Данная модель характерна для оперативных  систем (OLTP). Обновления данных носят  деструктивный характер, то есть предыдущие значения атрибутов замещаются новыми (рис. 5). Модель имеет достаточно ограниченный круг применения в хранилищах данных, поскольку не обеспечивает хранения истории изменений.

Событийная модель 

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

 

Статусная модель 

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

Существует три  способа моделирования изменяющих ся во времени статусов:

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

начало и конец  — для хранения промежутков времени  используется два поля — дата начала и дата окончания периода действия статуса;