На главную Контакты Карта сайта Версия для печати
ПОИСК
О компании Партнеры Продукты Услуги Клиенты Пресс-центр Форум

Современные подходы и методы построения аналитических информационных систем

Автор: Ольга Заратуйченко
Издание: Семинар НТЦ АРБ

Тезисы выступления на семинаре НТЦ АРБ
"Практические вопросы информационно-аналитической
работы в коммерческом банке", март 1998

Современные подходы к построению информационных систем;
Систематизация основных понятий многомерного представления данных, классификация и сравнение методов построения аналитических систем;
Разработка практических рекомендаций по проектированию и использованию Аналитических Систем в деятельности предприятий корпоративного типа.

Транзакционные и Аналитические системы

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

  • задачи Операционной обработки данных;
  • задачи Аналитической обработки данных.

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

Будем называть

  • Транзакционными Системами (ТС) - системы или составляющие части информационных систем, ориентированные на операционную, или транзакционную обработку данных. Именно к этому классу относятся Автоматизированные Банковские Системы, которые осуществляют учет и хранение большей части информации по работе банка;

  • Аналитическими Системами (АС) - системы или составляющие части информационных систем, ориентированные на анализ данных. Их часто называют системами поддержки принятия решений и их основная цель - помочь управляющему персоналу организации принять правильное и своевременное решение. (В зарубежной литературе им соответствует термин DSS - Decision Support System).

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

Признаки Транзакционная Система Аналитическая Система
Цель системы

Учет, хранение и оперативная обработка непрерывно поступающих данных.

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

Номенклатура данных

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

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

Вид данных

Детализированные данные

Обобщенные данные

Частота обновления

Данные непрерывно обновляются, но небольшими порциями

Система работает с достаточно редко обновляющимися исходными данными

Характер использования системы

Автоматизация набора основных банковских услуг. Под банковской услугой можно понимать комплекс банковских операций, которые необходимо проводить для выполнения задач в той или иной сфере деятельности банка. Для примера, можно рассмотреть модуль обслуживания Частных вкладов. В набор операций, соответствующих ему, входит ввод данных о новых клиентах, открытие вклада, поступление на счет сумм, выплата процентов и т.д. Это единая услуга, которую банк предоставляет вкладчикам. Набор услуг для каждого банка индивидуален, но самые необходимые и часто используемые, как правило, представлены в каждой АБС.

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

Представление результатов работы

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

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

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

Хранилища данных

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

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

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

В основе понятия Хранилищ Данных лежат две основополагающие идеи:

  • Интеграция ранее разъединенных детализированных данных в едином хранилище, их согласование и предварительная обработка. Источниками данных могут являться рабочие Транзакционные Системы, электронные архивы, а также разнообразные внешние источники (печатные издания, рабочие материалы, статистические отчеты и т.д.);

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

Основные требования к данным, находящимся в Хранилище Данных:

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

  • Интегрированность - все данные взаимно согласованы и хранятся в едином Хранилище;

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

  • Поддержка хронологии - данные хронологически структурированы и отражают историю за достаточный для выполнения задач анализа и прогноза период времени.

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

  • Пополнение Хранилища данных (поступление на склад);

  • Поддержка целостности и непротиворечивости данных (инвентаризация, проверка условий хранения, списание и т.д.);

  • Организация доступа к данным (выдача со склада).

Сбор данных

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

Поддержка логической целостности данных

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

Доступ к данным

Чаще всего доступ к данным определяется возможностями Аналитической Системы, которая базируется на Хранилище данных (или имеет возможность обращаться к нему) и предоставляет пользователю инструментальные средства для извлечения и обработки данных, а также для проведения различных форм анализа. Чаще всего именно Аналитическая Система осуществляет исследование данных (Data Mining), то есть поиск необходимой информации в море хранящихся фактов, а также выявление взаимозависимостей между данными .

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

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

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

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

Витрины (киоски) данных

Некоторым сужением понятия Хранилищ Данных является понятие Витрин данных. (Возможно использование названий Секций или Киосков данных).

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

Аргументы "За" и "Против" использования Витрин Данных,
в отличии от использования Хранилищ Данных.

  Аргументы "За"

Стоимость

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

Сроки

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

Размеры

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

Безопасность

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

  Аргументы "Против"

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

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

Расширение

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

Ограниченность

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

Основные принципы многомерной организации данных

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

Работа с многомерными структурами данных получила название OLAP (on-line analytical processing). Определением этого понятия служат 12 основных требований к средствам реализации OLAP, которые были сформулированы Э.Коддом:

  • Многомерное представление данных на концептуальном уровне (средства должны поддерживать многомерный взгляд на данные);

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

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

  • Согласованная производительность (производительность практически не должна зависеть от количества измерений в запросе);

  • Поддержка архитектуры клиент-сервер (средства должны работать в архитектуре клиент-сервер);

  • Равноправность всех измерений (ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными));

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

  • Поддержка многопользовательского режима работы (средства должны обеспечивать возможность работать с данными более чем одному пользователю);

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

  • Простота манипулирования данными (средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс);

  • Развитые средства представления данных (средства должны поддерживать различные способы визуализации данных);

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

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

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

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

  • показатель (measure) - это поле, значения которого однозначно определяются фиксированным набором измерений.

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

При конструировании и разработке аналитического модуля в составе банковской системы БИСКВИТ, был использован оригинальный подход, который базируется на вышеизложенных теоретических положениях.

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

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

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

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

  • в Многомерной Базе Данных и

  • в Реляционной Базе Данных.

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

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

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

При создании OLAP-приложения на основе Реляционной Базы данных, информация хранится в обычных Реляционных таблицах, которые должны быть специфическим образом организованы. В простейшем случае, это так называемая "радиальная" схема, или схема типа "звезда" (star schema), где имеется одна большая главная таблица и много частных, связанных с ней. Главная аккумулирует данные о наиболее часто запрашиваемом объекте, и/или служит отправной точкой для запросов к таблицам со специальной частной информацией (справочным или содержательным). Радиальная схема оптимизирована под наиболее часто встречающиеся запросы и обычно оказывается реляционно ненормализованной . Усложнением этой схемы можно считать структуру типа "снежных хлопьев" (snowflake) с несколькими основными таблицами.

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

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

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

Особенности логической организации ROLAP-систем,
предназначенных для анализа деятельности корпоративного предприятия
(на примере реализации аналитической системы в составе интегрированной банковской системы БИСКВИТ)

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

Временные периоды. Иерархические отношения этого типа объектов носят вложенный характер. Для реализации нашей системы это ряд Год? Квартал? Месяц? Пятидневка? День. Данные, лежащие на более высоком уровне, должны соответствовать детализированным данным по более низким уровням иерархии.

Подразделения или объекты анализа. Их иерархическая структура определяется сложной структурой организацией предприятий корпоративного типа. В Аналитической Банковской Системе основным анализируемым объектом, несомненно, является банк с филиальной сетью: Банк в целом? Группа филиалов? Филиал, а второстепенными могут быть другие банки или предприятия. Возможна и более глубокая детализация объектов анализа.

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

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

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

Основные операции манипулирования данными

Рассмотрим основные операции манипулирования данными, доступные Аналитической Банковской Системе:

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

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

если операция детализации относится к классу данных, как к объекту воздействия, то осуществляется просмотр информации, находящейся в системе анализа по иерархии любого измерения, допустимого для данного класса данных;

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

Агрегации данных. Эта операция может производиться над любым классом данных и по любому измерению. Причем для любого консолидации анализируемых данных используется одна и та же процедура, но для каждого показателя указываются операторы агрегации по каждому измерению, которые должны выполняться при своде данных. Наиболее часто используемыми операторами агрегации являются: Сумма (Sum), Минимум (Min), Максимум (Max), Среднее арифметическое (Avrg), Последнее и Первое значение (Last и First).

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

В заключение хотелось бы сформулировать основные результаты, полученные в работе:

Была построена модель многомерного представления данных в виде "Вложенных гиперкубов";

На основе предложенной модели в рамках Интегрированной Банковской системы "БИСКВИТ" был разработан модуль "Финансовая отчетность и анализ";

В настоящее время модуль "Финансовая отчетность и анализ" внедрен и успешно работает во всех коммерческих банках, в которых стоит ИБС "БИСКВИТ".