CC BY
34
Н.Э. Иванова
ТЕХНОЛОГИЯ АНАЛИТИЧЕСКОЙ ОБРАБОТКТ ДАННЫХ В БАНКОВСКИХ СИСТЕМАХ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
Одной из тенденций развития рынка программных систем для банков является переход от простых систем обработки данных (СОД) к системам поддержки принятия решений (СППР) с использованием объектно-ориентированного (ООП) подхода к проектированию и программированию.
Разработка СППР продиктована требованиями банковского бизнеса, для успешного развития которого актуально моделирование реальных и возможных ситуаций развития банковских процессов, проведение их многоаспектного анализа в целях своевременной оценки рисков и поиска вариантов их предупреждения и/или снижения, прогнозирования результатов деятельности, обеспечения надежной и устойчивой работы банка.
Традиционные банковские автоматизированные системы класса СОД являются трансакционными OLTP-системами (Online Transaction Processing), обеспечивающими обработ-
ку и представление менеджменту банка внутренней учетной и отчетной информации, отражающей результаты деятельности и финансовое состояние банка в форме документов утвержденной структуры либо в виде оперативных сводок по запросам пользователей.
Банковские ОЬТР-системы являются учетными системами и, как правило, представляют собой набор функциональных модулей (расчетное обслуживание, операции с наличной валютой, корреспондентские счета, кредиты, депозиты юридических и физических лиц, фондовые операции и депозитарный учет и др.), работающих с единой логической базой данных и объединенных вокруг единого ядра.
Для получения необходимой информации пользователями формируются прямые к запросы к базе данных. Технология выборки данных пользователями из основных таблиц базы данных ОЬТР-системы представлена на рис.1.
Рис. 1. Схема технологического процесса обработки данных в банковской ОЬТР-системе
С уверенностью можно констатировать, что БРЬ- запросы, извлекающие информацию из нормализованных таблиц СОД, вряд ли будут эффективными для большого количества информации из-за большого количества соединений.
Следует отметить, что в ОЬТР-системах модель данных обычно проектируется для оптимизации ввода и хранения данных, а не для доступа к ним, поэтому прямые запросы к учетной системе отчасти идут в ущерб скорости выполнения трансакций. В крупном банке, где к базе данных одновременно может обращаться очень много пользователей, работа программной системы может вообще остановиться. Кроме того, снижается производительность и самих запросов, поскольку они используют те же системные ресурсы, что и сама учетная система.
Наконец, наряду с регламентированной отчетной информацией, руководству банка необходима визуальная информация за различные периоды времени для принятия различного рода решений (отчеты, графики, экранные формы и т.д.), а в ОЬТР-системах время хранения данных часто ограничено последним кварталом или годом, поэтому исследование тенденций временных рядов
и решение прогнозных задач может быть затруднено.
Таким образом, стремление обеспечить менеджмент банка необходимой информацией для подготовки и принятия решений с неизбежностью приводит к созданию хранилищ данных (Data Warehouse), непосредственно предназначенных для хранения и представления агрегированной аналитической информации на основе технологии комплексного многомерного анализа данных OLAP (On-Line Analytical Processing).
Процесс создания хранилища данных включает выявление отличий в характеристиках данных в учетных и аналитических системах, определение требований к данным, импортируемым в целевую базу данных, разработку общих принципов ее построения, анализ основных источников данных, разработку рекомендаций по решению потенциальных проблем, возникающих при выгрузке, очистке, согласовании, транспортировке и загрузке данных в целевую базу.
На рис. 2 приведена модель банковского хранилища данных, включающая определенный набор взаимосвязанных таблиц, содержащих объекты соответствующих классов со своими свойствами.
і Clients і
DATE DIM
і SYMBOLS і
:;ACC_PLAn і
Рис. 2. Модель банковского хранилища данных
Сведения о назначении и типах перечисленных таблиц приведены в таб.1. Таблица 1. Основные таблицы хранилища данных
№ Имя таблицы Назначение таблицы Тип таблицы
1 ACC PLAN План счетов ЦБ РФ Классификатор
2 CLIENTS Клиенты банка Классификатор
3 LASTBAL Классификатор лицевых счетов Классификатор
4 SYMBOLS Классификатор символов доходов и расходов Классификатор
5 ACCOUNTS Балансы по лицевым счетам Таблица фактов
6 BALANCE Балансы учреждений банка Таблица фактов
7 SYM_VAL Показатели доходов и расходов банка Таблица фактов
8 DATE DIM Измерение времени Таблица измерений
9 INDEX Справочник показателей Таблица фактов
Приведенный список таблиц не является итоговым, модель банковского информационного пространства должна оставаться открытой в смысле обеспечения возможности добавления новых классов (таблиц объектов), новых свойств (полей в таблицы объектов) и методов (операций) к существующим и новым классам.
В таблицах фактов содержится основная информация хранилищ данных, таблицы измерений являются вспомогательными таблицами, необходимыми для выполнения различных операций с фактами, а классификаторы используются в качестве вспомогательных таблиц, предназначенных для классификации фактов.
Заметим, что таблицы измерений и классификаторы могут использоваться совместно системами СОД и хранилищем данных, например, план счетов, классификатор клиентов, классификатор символов доходов и расходов и т.д.
Банковские хранилища данных создаются в результате периодической выгрузки (обычно ежедневной, но периодичность может быть увеличена) информации из баз данных, накапливаемых различными банковскими ОЬТР-системами (операционный день банка, кредиты, депозиты, система «клиент-банк» и другие), а также, воз-
можно, и внешних источников, и обеспечивают пользователям единый логический взгляд и доступ к информации, возможность преобразования накопленных учетных данных и формирования агрегатных показателей, наглядно отражающих деятельность банка (рис. 3).
Таким образом, применение OLAP-технологии позволяет отделить таблицы СОД от трансакций пользователей, обеспечить быстрый и удобный доступ, а также возможности группировки и агрегирования данных для проведения их многомерного анализа.
К основополагающим принципам OLAP-технологии относятся:
• Интеграция ранее разъединенных детализированных данных, содержащихся в нормализованных таблицах СОД, а также структурированных данных из различных внешних источников (например, электронные платежные документы клиентов банка, полученные по каналам связи) в едином хранилище данных, их согласование и агрегирование.
• Разделение наборов данных (таблиц базы данных), используемых для операционной обработки (добавление, изменение), и наборов данных, используемых для решения задач анализа (чтение).
Рис. 3. Схема технологического процесса аналитической обработки информации с использованием хранилища данных
Несмотря на то что хранилище данных существенно уменьшает зависимость прикладных запросов от данных и делает их существенно более эффективными, оно все же остается весьма сложной структурой, что затрудняет процесс его создания, внедрения и использования, причем этот процесс практически не может быть законченным в связи с изменениями нормативных документов и требований пользователей. В связи с этим в банках находят широкое применение витрины данных (data marts).
Существуют различные точки зрения на понятие «витрина данных», но мы будем рассматривать витрину данных в качестве базы данных или коллекции баз данных, сконструированных специально для систем поддержки принятия решений.
В то время как хранилища данных содержат информацию в масштабе всего банка и всех видов его операций, витрины данных обычно фокусируются на решении отдельных комплексов задач, например, анализе баланса или анализе доходов и расходов. В этом смысле витрины данных зависимы от
хранилища данных и содержат некоторую специальным образом отфильтрованную и/или преобразованную информацию хранилища.
Концепция витрин банковских хранилищ данных исключительно важна для целей логического выделения комплексов задач СППР. Если же говорить о физической структуре хранения данных в витринах, то СУБД Oracle предоставляет, на наш взгляд просто, идеальные средства для их организации - так называемые материализованные представления (materialized views).
Витрины данных создаются с целью удобства работы пользователей, обеспечения их тематической аналитической информацией и повышения скорости доступа к ней (рис. 4).
На рис.4 представлены примеры витрин данных - Баланс (анализ структуры баланса), Форма 102 (анализ доходов, расходов, прибылей и убытков банка), Резервы (анализ фонда обязательного резервирования) и другие. В качестве структур хранения для витрин данных применяются так называемые материализованные представления СУБД Oracle.
Рис. 4. Схема технологического процесса аналитической обработки информации с использованием витрин данных
Например, таблица фактов ACCOUNTS, предназначенная для хранения данных ежедневных балансов, содержит исчерпывающую информацию по счетам доходов и расходов, которые открыты на соответствующих лицевых счетах балансовых счетов 701 и 702. Однако эту информацию намного удобнее можно использовать путем выделения из таблицы ACCOUNTS соответствующей информации, образующей
таблицу фактов БУМ_УЛЬ витрины "Форма 102" (рис. 5).
Полученная в результате модель витрины «Форма 102» содержит всю информацию о результатах деятельности банка и может использоваться самым различным образом: для формирования отчета о прибылях и убытках, анализа структуры доходов и расходов банка, расчета показателей рентабельности, принятия решений, в банковском управленческом учете.
create table sym_val as select day, sym, val, sum(val)
over(partition by sym, to_char(day,'YYYY') order by sym, day) tot from
(select max(dat) as day,
substr(acc,14,5)as SYM, sum (turndt+turnct)as VAL from accounts, date_dim
where (substr(acc,1,3)='701' or substr(acc,1,3)='702')) and dat=day and turndt+turnct<>0
group by mmyyyy, dat, substr(acc,14,5)
)
Рис. 5. Пример создания витрины «Форма 102»
Аналогично на основе таблицы фактов ACCOUNTS, содержащей данные ежедневного баланса банка, можно построить витрину данных «Баланс» (рис. 6). Его таблица фактов BALANCE является материализованным представлением- агрегатом таблицы ACCOUNTS по счетам 2-го порядка и ряда вспомогательных таблиц измерений.
Рассмотренная технология аналитической обработки данных с применением витрин данных в процессе подготовки и принятия решений по управлению банковской деятельностью имеет ряд несомненных достоинств:
• руководители и менеджмент банка видят и работают только с теми данными, которые им реально нужны,
• целевая база данных витрины данных максимально приближена к конечному пользователю,
• витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать,
• для реализации витрин данных не требуется очень мощная вычислительная техника.
Одной из особенностей OLAP-технологий является использование иерархических структур аналитических данных и организация их хранения не в таблицах, а в «кубах решений» (decision cube).
Следует отметить, что иерархия органически присуща банковской информации и широко используется в правилах бухгалтерского учета для кредитных организаций, что создает необходимые предпосылки для применения объектно-ориентированного подхода к моделированию банковского информационного пространства.
Куб решений представляет многомерный набор данных, оси которого содержат параметры, а ячейки - зависящие от них агрегатные данные. Вдоль каждой оси данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Благодаря такой модели данных руководители и специалисты банка могут формулировать сложные запросы, генерировать отчеты, получать необходимые подмножества данных.
create materialized view balance build immediate refresh complete on demand enable query rewrite as
select substr(acc,1,3) as acc1, substr(acc,1,5) as acc2, dat, mon_yyyy, qtr_yyyy, yyyy, sum(round(inbal,2)) as i, sum(round(turndt,2)) as tdt, sum(round(turnct,2)) as tct, sum(round(outbal,2)) as o from accounts a, libra_days d where (inbal+turndt+turnct+outbal <> 0) and (a.dat=d.day) group by substr(acc,1,3), substr(acc,1,5), dat, mon_yyyy, qtr_yyyy, yyyy;
Рис. 6. Пример создания витрины данных «Баланс»
Многомерный куб решений отражает факт наличия у хранилища данных нескольких измерений, например, измерение периода отчетности, измерение организационного подчинения банковских подразделений, измерение счета, измерение клиентов и т.д. Таким образом, куб решений является, с одной стороны, некоей удобной для пользователей формой представления информации, позволяющей им определять запросы к хранилищу данных, используя содержащиеся в нем факты и измерения, а с другой стороны - соответствующим программным средством, реализующим этот процесс удобно и наглядно для пользователей.
Например, таблица ACCOUNTS содержит самую детализированную информацию, поскольку она основывается на данных аналитического учета. Однако для решения большинства задач в банковских системах принятия решений требуется информация, агрегированная в разрезе балансовых счетов.
Поэтому пользователь должен иметь возможность с помощью достаточных средств выполнять преобразование фактической информации (группировку по различным измерениям, одномерную и многомерную кросс- табуляцию), вычислять различные групповые функции (агрегатные, аналитические, статистические, технические), получая результирующую информацию в различных формах (таблицы, отчеты, графики).
Группировка информации хранилищ данных производится как по полям таблиц фактов, так и по полям связанных с ними таблиц измерений, и таким образом обеспечивается построение многомерных кубов решений.
Многие фирмы-разработчики программных систем стремятся включить в состав своих программных продуктов компоненты, обеспечивающие проведение интеллектуального анализа данных. Например, для реализации ана-
литических возможностей по формированию кубов решений программная система Borland Delphi [1.18, Chapter 26. Using Decision support components] содержит следующие компоненты:
• decision cube - многомерную структуру данных, работающую с информацией базы данных;
• decision source - определяющую данные для текущей pivot- таблицы, представленной в виде грида (сетки), то есть многозаписной экранной формы, выводящей на экран пользователя информацию базы данных в табличной форме или (и) графа. Этот компонент связан с соответствующим запросом;
• decision query - специальную форму запроса к базе данных, определяющую данные для куба решений;
• decision pivot - позволяющую управлять кубом решений, простым нажатием кнопок, открывая и закрывая его размерности или поля;
• decision grid - выводящую в табличной форме полученную информацию;
• decision graph - строящую, если необходимо, графики различного вида, используя усеченную версию пакета TeeChart.
Внедрение рассмотренных нами принципиальных основ разработки технологий аналитической обработки данных в СППР позволит реализовать возможности многопользовательского доступа к любой необходимой информации, независимо от места ее хранения, проведение многомерного анализа данных, представление пользователю результатов анализа за приемлемое время и сохранение этих результатов в доступном для пользователя виде.
