Определение и типовые архитектуры хранилищ данных

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

Репозиторий— место для хранения данных, моделей, интерфейсов и программных реализаций.

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

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

Рис. 7. Модель хранилища данных

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

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

Виртуальное хранилище данных — это система, предоставляющая интерфейсы и методы доступа к регистрирующей системе, которые эмулируют работу с данными в этой системе, как с хранилищем данных. Виртуальное хранилище данных можно организовать, создав ряд «представлений» (view) в базе данных либо применив специальные средства доступа. Главными достоинствами такого подхода являются: простота и малая стоимость реализации, единая платформа с источником информации, отсутствие сетевых соединений между источником информации и хранилищем данных. Однако недостатков гораздо больше. Создавая виртуальное хранилище данных, пользователь создает не хранилище как таковое, а иллюзию. Структура хранения и само хранение не претерпевают изменений, и остаются проблемы: производительности, трансформации данных, интеграции данных с другими источниками, отсутствие истории, чистоты данных, зависимость от доступности и структуры основной базы данных.

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

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

4.4.3. Проектирование структуры реляционного хранилища данных
   Хранилища строятся на основе многомерной модели данных, подразумевающей выделение отдельных измерений (время, география, клиент, счет) и фактов (объем продаж, доход, количество товара) с их анализом по выбранным измерениям. Многомерная модель данных физически может быть реализована как в многомерных, так и в реляционных СУБД. В последнем случае она выполняется по схеме «звезда» или «снежинка». Данные схемы предполагают выделение таблиц фактов и таблиц измерений. Каждая таблица фактов содержит детальные данные и внешние ключи на таблицы измерений.

Опыт построения КХД на крупных многофилиальных предприятиях показывает, что решающее значение для успешного хода данного процесса имеют организационные меры:

• постоянная заинтересованность и поддержка со стороны спонсора проекта, при этом все спорные вопросы должны решаться административным методом в минимально короткие сроки;

• централизация сбора данных, причем данные должны собираться по возможности неконсолидированные;

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

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

этого этапа зависит от типа концептуальной архитектуры).

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

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

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

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

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

лучить и почему этого нельзя добиться с использованием той или иной технологии – еще одна причина появления противоречий между бизнес-подразделениями и ИТ -структурами. Централизация сбора данных позволит

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

  К архитектурным принципам относятся принципы построения данных, принципы работы механизма запросов, принципы построения рабочих хранилищ, принципы построения метаданных, принципы масшта-

бируемости, принципы управления хранилищем.

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

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

проектирования модели и собственно хранилища; обработки запросов и представления информации.

Собственно архитектура хранилища данных делится на три части: архитектуру доступа, архитектуру данных и технологическую архитектуру. Архитектура доступа представляет собой описание способов, с помо-

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

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

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

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

СППР и хранилищ данных.

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

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

бируемости, времени ответа и пропускной способности.

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

ганизационной ИТ -архитектуры и принятых в организации стандартах в области ИТ . Хранилище данных должно адаптироваться ивзаимодействовать со всеми остальными корпоративными системами.

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

Объем начального проекта определяется только исходя из решения наиболее важных бизнес-задач и консолидации данных в наиболее востребованных отчетах.

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

КХД в следующих трех вариантах:

• реконструкции существующей модели данных;

• разработки модели КХД с использованием какого- либо промышленного шаблона рассматриваемой предметной области;

• разработки модели КХД с нуля под заказ.

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

сократить путем включения в первый этап только наиболее важных отчетов.

Мировая практика показывает, что работы, связанные с разработкой модели данных, являются наиболее сложными и трудоемкими, а поэтому для сокращения срока работ по построению этой модели и снижения риска

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

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

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

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

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

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

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

но совершенно необходимый для формирования непротиворечивой информационной среды предприятия;

• поэтапному построению КХД (сначала под одну задачу, затем под вторую и т.д.), так как невозможно одномоментно консолидировать все данные, имеющиеся в организации;

• интеграции и дедубликации существующей информации, то есть в КХД не должно быть несогласованных измерений и фактов;

• централизации процесса сбора данных;

• хранению по возможности единственной версии «правды» и сбору только атомарных данных (в случае, если хранятся агрегированные данные – запрету drill-down);

• очистке и аудиту данных перед и их загрузкой в КХД;

 • построению модели данных с непосредственным участием бизнес-пользователей и с использованием того или иного промышленного шаблона;

• предоставлению данных пользователю в удобных форматах (из-за форматов, которые не устраивают конечного пользователя можно вообще его лишиться);

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