Дата публикации оригинала: 2008-05-22
Автор: Олег Усольцев
Материал опубликован в блоге Олега Усольцева

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

  1. Определение сущностей и размерностей данных. Исходя из требований, необходимо определить сущности, которые будут подвергаться анализу (с точки зрения системы бизнес-анализа) или которые являются объектами транзакций (с точки зрения транзакционных систем). Эти сущности являются ни чем иным, как будущими таблицами фактов. Каждая сущность характеризуется определенным набором атрибутов, которые необходимо анализировать и которые формируют структуру соответствующей таблицы фактов, а также позволяют выделить размерности данных. Чтобы пояснить наглядно, приведу пример. В рамках инвестиционного банкинга, одной из аналитических и транзакционных сущностей является трейд. Эта сущность является кандидатом на таблицу фактов. У этой сущности можно выделить следующие атрибуты: продукт, клиент, регион, номер журнала торгов (blotter), брокер, бизнес-сегмент, ценная бумага, тип подтверждения, дата торга, дата подтверждения, дата мэтчинга, дата расчета, дата платежа, комиссионные, накопленный процент и т.д. Из них, например, продукт, клиент, регион, бизнес-сегмент и тип подтверждения, являются размерностями. Далее эти атрибуты выделяются как сущности-размерности и выполняется их детализация: теперь уже для них определяются атрибуты, в разрезе которых будут анализироваться трейды;
  2. Определение фактических данных (фактов). Теперь, когда мы имеем набор сущностей и определили сущности-размерности, из оставшегося набора атрибутов мы формируем набор фактов, которые необходимо будет анализировать. Сразу скажу, что практика “берем и грузим все!” - порочна и свидетельствует лишь об отсутствии четких требований к хранилищу данных. В хранилище данных должны попадать только те данные, которые необходимы для формирования аналитических отчетов, согласно бизнес-требованиям. Безусловно, в дальнейшем набор анализируемых данных может расширяться, в связи с появлением новых требований и постепенным уточнением требований к системе бизнес-анализа. Но грузить все данные, которые только можно найти - все равно не стоит. Хранилище данных должно развиваться постепенно, итеративно, в соответствии с новыми требованиями и улучшениями существующего функционала. И так, сформированный набор атрибутов аналитической сущности будет определять структуру таблицы фактов. Например, для трейда это могут быть: цена, количество, код в системе-источнике (вырожденная размерность), дата обработки трейда и т.д. Среди расчетных могут быть: время до подтверждение (с момента ввода торга в трейдинговую систему и до отправления подтверждения), время до расчета, время до платежа и т.п. Такие расчетные атрибуты будут формировать метрики торга;
  3. Определение справочных таблиц и таблиц сопоставления. После определения таблиц размерностей и их атрибутов, необходимо определить множество возможных значений. Если информация о трейдах поступает из нескольких систем (например, торги акциями - из одной, ЦБ с фиксированным доходом - из другой, деривативами - из третей и т.д.), то скорее всего необходимо будет выполнить анализ исходных данных на предмет определения золотого стандарта данных. Под этим термином необходимо понимать набор данных, который является золотым стандартом для всех систем и позволяет сформировать правильную аналитическую картину. Таким золотым стандартом могут быть: размерность времени (корпоративный календарь), клиенты, продукты, регионы, бизнес-сегменты и т.д. Как можно заметить, данные золотого стандарта - это данные размерностей. Таким образом, после определения размерностей и зависимостей между аналитическими сущностями (фактами) и сущностями размерности, необходимо выполнить анализ на предмет формирования золотого стандарта данных. Это в свою очередь потребует определения таблиц соответствия для сопоставления значений атрибутов из входных данных значениям атрибутов золотого стандарта (например, сопоставление имени клиента из набора входных данных с соответствующим ему “золотым” именем клиента в хранилище данных). Преследуемая цель - качество аналитических отчетов. Если в каждой системе-источнике, например, регион или продукт будет иметь различные коды, аналитические отчеты не будут представлять правильную картину текущих дел;
  4. Определение бизнес-правил. В результате определения фактов мы получаем набор данных, который также может включать расчетные атрибуты - метрики, как например, время от поступления заказа и до его исполнения. Чаще всего в хранилище данных, помимо таблиц фактов, будут создаваться суммирующие таблицы, например, значения показателей эффективности за день или за месяц. На примере все тех же трейдов, это могут быть показатели Z/Yen. Пользователю эти показатели могут быть представлены в виде scorecard (числовые значения) или dashboards (графики). Соответственно, для расчета первоначальных метрик (для каждой транзакции из таблицы фактов) и суммирующих значений необходимо определить бизнес-правила, т.е. правила расчета и суммирования метрик. Помимо этого, могут быть определены правила по преобразованию данных в процессе их загрузки в таблицы фактов (объединение полей в одно, изменение формата данных и т.п.);
  5. Определение суммирующих таблиц. Как я уже отмечал в пункте 4, чаще всего в хранилище данных будут созданы суммирующие таблицы. В этом случае необходимо определить, какие данные должны быть агрегированы, а также логика и правила их агрегации. В свою очередь, чтобы успешно справиться с этой задачей, необходимо знать требования к аналитическим отчетам, которые будут использовать эти данные. Первоначально, можно определить две-три суммирующих таблицы для стандартных отчетов, а по мере появления новых требований и анализа запросов к хранилищу данных создавать новые суммирующие таблицы.


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: