Системы поддержки принятия решений для банков

В.К. Бизунок, О.Ю. Горчинская, Г.М. Ладыженский

1. Введение

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

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

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

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

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

Для работы по пилотному проекту была создана проектная группа, в нее были включены сотрудники отдела управления активами и пассивами и управления информационных технологий (со строны ММБ) и консультанты Technology Solution Group (отдела технического консалтинга Oracle Russia). В работе проектной группы принимали участие и авторы статьи. Работа была начата в январе 1998 года, сразу после Рождественских праздников. В общей сложности для реализации пилотного проекта потребовалось около полутора месяцев работы нескольких консультантов Oracle. После успешного окончания технической части проекта была проведена серия семинаров -- для управления информационных технологий и для аналитических подразделений, затем проект был представлен вниманию Правления ММБ, которое положительно оценило выполненную работу.

Теоретической основой проекта послужили классические работы У.Инмона, посвященные хранилищам данных [1]. При работе над проектом мы также использовали как богатый практический опыт, накопленный в корпорации Oracle благодаря реализации сложных систем СППР, так и готовую методологическую платформу таких проектов – Oracle Data Warehousing Method [2].

2. Постановка задачи и цель пилотного проекта

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

Для анализа открытых позиций банка применяются два основных показателя – spot-позиция и forward-позиция, каждый из которых может быть подсчитан для каждого центра прибыли банка, на любую дату, для любой валюты и выражен как в исходной валюте, так и в ее долларовом эквиваленте. Эти показатели должны вычисляться на основе данных, полученных из действующих в банке оперативных систем обработки транзакций (OLTP-систем). Прежде всего данные целесообразно извлекать из систем MIDAS DBA, работающей на платформе AS/400 с использованием СУБД DB2/400, и FXMM, опирающейся на MS SQL Server. С точки зрения конечных пользователей-аналитиков, интерес представляет как анализ собственно структуры и динамики изменения открытой позиции банка для различных валют и временных интервалов, так и сравнение однотипных показателей, полученных из разных источников.

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

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

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

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

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

3. Характеристика решения

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

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

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

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

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

Рис.1. Архитектура СППР

Особо отметим, что основные технологические узлы схемы, то есть:

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

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

В нашем случае для создания Хранилища данных было решено использовать уже установленный в банке четырехпроцессорный сервер IBM RS/6000 под управлением ОС AIX. Задача пилотного проекта не требовала особых вычислительных мощностей и можно было бы ограничиться сервером меньшей производительности, однако мы хотели построить технологическую схему СППР так, чтобы в дальнейшем она без каких-либо изменений в платформах заработала бы на реальных объемах данных. При этом мы исходили из общемировой практики, которая свидетельствует о том, что подавляющее большинство систем хранилищ данных строится на UNIX-платформах. В то же время для сервера очистки, преобразования и согласования данных, равно как и для сервера многомерных баз данных мы решили использовать также имевшийся в наличии Intel-сервер под управлением Windows NT. Неоднородная компьютерная среда не создала нам никаких проблем, так как продукты Oracle прекрасно работают на различных платформах, а детали сетевого взаимодействия скрыты Oracle SQL*Net и не заметны прикладному программисту. Разработанные аналитические приложения запускались на персональных компьютерах под управлением Windows’95.

Работа по реализации рассмотренной выше технологической схемы состояла из трех основных этапов:

• Проектирование и реализация схемы хранилища данных;
• Разработка процедур согласования, очистки и загрузки данных в хранилище из операционных систем;
• Организация многомерной витрины данных.

3.1. Проектирование хранилища данных

Центральным компонентом системы является хранилище данных – база данных, предназначенная для хранения в согласованном виде исторической информации, загружаемой из различных операционных систем и внешних источников. Для хранилища был выделен отдельный компьютер RS/6000, на котором была установлен Oracle8 Enterprise Edition.

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

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

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

Центральным компонентом Oracle Designer является репозиторий – специальная база данных, в которой хранится вся метаинформация о структуре и объектах хранилища. Различные “клиентские” средства, входящие в состав инструментальной среды, обеспечивают доступ к репозитарию и ориентированы на выполнение различных задач, возникающих в процессе проектирования.

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

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

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

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

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

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

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

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

3.2. Очистка, согласование и преобразование данных

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

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

В нашем случае данные об открытой позиции банка извлекаются из двух оперативных систем: MIDAS DBA и FXMM. Но ни в одной из оперативных систем не хранятся непосредственно значения нужных для хранилища показателей. Их можно получать из БД путем специальных преобразований, вычислений и агрегирования. Кроме того, при извлечении информации из разных источников, однотипные по смыслу данные имеют различный формат, вид представления, идентификацию. В этом случае требуются дополнительные действия по согласованию и очистке данных. У нас это относилось к такой информации, как временные периоды, справочники валют, списки центров прибыли. Необходимо было, например, учитывать нестандартный формат дат в MIDAS DBA (вместо календарной даты хранится номер дня с момента установки системы), различную степень детализации данных и др.

Процессы извлечения, согласования, преобразования данных и загрузки их в хранилище выполняются в инструментальной среде Data Mart Builder (один из компонентов продукта Oracle Data Marts Suite). Разработка соответствующих процедур производится по следующей схеме.

1. Прежде всего, необходимо в репозитарий Data Mart Builder поместить метаинформацию о структурах и объектах источников, т.е. о таблицах, представлениях, из которых необходимо будет извлекать данные. Для этого Data Mart Builder обеспечивает связь с рядом наиболее популярных СУБД, включая Oracle, Microsoft SQL Server, Sybase и др. Для остальных баз данных можно установить связь с помощью соответствующих ODBC-драйверов. При необходимости можно также использовать шлюзы -- специальное ПО класса middleware, позволяющее работать с различными БД так, как будто они являются базами данных Oracle.

2. После создания в репозитории Data Mart Builder описаний всех источников формируется “общий понятийный аппарат“ (метапредставление), который будет использоваться при построении планов. Его смысл заключается в том чтобы обеспечить возможность работы с данными, не ссылаясь на конкретные столбцы конкретных таблиц источников, а на более абстрактном уровне.

Общий логический взгляд на данные состоит из одного или нескольких метапредставлений. Каждое метапредставление представляет собой набор категорий (понятие, аналогичное сущности в ER-моделях), определяемых атрибутами. Например, понятие или категория “Валюта“ может определяться атрибутами “Код“, “Наименование“ и “Точность“.

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

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

Для построения планов загрузки Data Mart Builder предоставляет удобные графические средства с использованием техники “drag and drop”. Для этого в специальном окне выводится иерархически упорядоченный список всех стандартных трансформеров, из которого выбирается нужный трансформер и включается в текущий план.

3.2. Создание многомерной витрины данных

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

Рис.2. Пример многомерного куба

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

Разумеется, данные не представляются конечному пользователю в виде гиперкубов. Аналитику привычнее иметь дело с двумерным таблицами и графиками. Он анализирует определенные срезы или проекции кубов (рис 3).

Рис. 3. Логическое представление данных пользователю

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

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

Прежде всего была спроектирована и реализована многомерная база данных для хранения основных показателей об открытой позиции. Основные показатели, spot и forward, с точки зрения многомерных объектов представляют собой пятимерные “кубы”, зависящие от размерностей время, валюта, центр прибыли, единица измерения, источник информации. Программы загрузки данных из хранилища в многомерную базу данных были сгенерированы автоматически средствами администрирования Express Administrator. С помощью этих программ производится как первичная загрузка, так и последующее пополнение витрины по мере необходимости.

Для хранения и обработки многомерной информации нами использовался Oracle Express Server - система управления многомерными базами данных, обеспечивающая хранение и обработку больших объемов агрегированной информации. В состав Oracle Express Server входит функционально полный язык программирования с встроенными операторами манипулирования многомерными данными и широким спектром математических, финансовых, статистических и других функций, необходимых при работе с историческими данными, прогнозировании и проведении what-if анализа. Oracle Express Server легко интегрируется в общую архитектуру информационной сети организации, предоставляя удобные средства связи с существующими реляционными базами данных и другими источниками через локальную или удаленную сеть. Oracle Express Server работает на всех популярных вычислительных платформах от персональных компьютеров до UNIX-серверов и мэйнфреймов.

Анализ многомерной информации производился средствами Oracle Express Analyzer. Этот продукт представляет собой объектно-ориентированное средство для динамического формирования запросов, отчетов, диаграмм и графиков, реализующих различные представления многомерных данных. Oracle Express Analyzer ориентирован на широкий круг пользователей. Он может быть использован в качестве инструментария непосредственно конечного пользователя (аналитики, руководители). С его помощью можно также разрабатывать и регламентированные приложения, представляющие собой “многостраничные книги”, страницами которых являются интерактивные таблицы, диаграммы, поясняющие тексты.

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

1. Структурный анализ Spot и Forward

2. Динамика изменения общей открытой позиции

3. Сравнение открытых позиций разных подсистем (по структуре и в динамике)

1. Анализ распределения открытой позиции по центрам прибыли)

4. Заключение

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

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

Литература

1. W.H. Inmon, J.D. Welch, Katherine L.Glassey. Managing the Data Warehouse. Wiley Computing Publishing, 1997
2. Oracle Method. Custom Development. Data Warehouse Method Handbook, Release 1.0.0, 1996 Oracle Corporation.
3. Сахаров А.А. Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server). СУБД, N3/1996.

Сведения об авторах

Валентина Кирилловна Бизунок
Международный Московский Банк, начальник управления информационных технологий, кандидат экономических наук

Ольга Юрьевна Горчинская
Oracle Corporation, консультант по OLAP/Data Warehouse, кандидат технических наук

Глеб Михайлович Ладыженский
Oracle Corporation, консультант по комплексным решениям

Данная статья опубликована в журнале "Банки и технологии", 5-6/1998 и размещена здесь с любезного разрешения редакции этого журнала.