Методика проектирования банковского хранилища данных на основе конфигурируемой многокомпонентной модели данных Текст научной статьи по специальности «Компьютерные и информационные науки»

Методика проектирования банковского хранилища данных на основе конфигурируемой многокомпонентной модели данных

Солянов Кирилл Сергеевич,

аспирант, кафедра «Бизнес-информатика», Финансовый университет при Правительстве Российской Федерации, kirsol4@yandex.ru

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

Ключевые слова: хранилище данных; проектирование; компонентный подход; информационно-аналитические системы; моделирование данных; банковская автоматизация

Введение

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

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

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

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

Затем следует обозначить задачу скоринга и построения кредитного конвейера. Данные о кли-

х

X

о

го А с.

X

го т

о

ю

М О

а>

о

сч

№ OI

О Ш

m х

<

m о х

X

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

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

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

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

Современный тренд консолидации банковского сектора в России, который сохранится в ближайшие годы [6], также приводит к резкому возрастанию сложности и неоднородности информационного ландшафта организации.

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

1. Методика проектирования банковского хранилища данных на основе конфигурируемой многокомпонентной модели данных

Предлагаемая в данной статье авторская методика в том числе базируется на методе GRAnD. GRAnD - goal-oriented approach to requirement analysis in data warehouses (подход к анализу требований к ХД, ориентированный на достижение целей бизнеса) [7]. Ключевая мысль заключается в том, что ХД - это бизнес-ориентированная система и должна разрабатываться исходя из бизнес-потребностей, а не каким-либо другим способом. [8] Руководствуясь данным постулатом, сформулированы следующие шаги перехода от бизнес-описания предметной области к сущностям логической модели данных.

1.1. Описание процесса перехода от бизнес-описания предметной области к сущностям логической модели данных

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

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

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

1.2. Определение типов бизнес-объектов

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

• Измерение. Бизнес-объекты данного типа соответствуют объектам или участникам бизнес-процессов, например, сделки, счета или контрагенты. В терминах объектно-ориентированного программирования бизнес-объектам типа «Измерение» соответствуют классы.

• Транзакция. Бизнес-объекты данного типа соответствуют фактически совершенным событиям и не могут изменяться во времени. Примерами бизнес-объектов типа «Транзакция» могут служить проводки по счетам, операции по сделкам и др.

• Интервальный факт. Бизнес-объекты данного типа соответствуют значениям какого-либо показателя, определяемые одной или несколькими транзакциями. Например, интервальным фактом являются остатки по счетам, которые определяются множеством проводок по этим счетам.

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

1.3. Определение типов сущностей

На уровне ЛМД каждый бизнес-объект состоит из одной или нескольких сущностей. В разработанной автором универсальной многокомпонентной модели данных предусмотрены следующие виды сущностей.

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

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

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

- для связи двух бизнес-объектов (являясь частью бизнес-объекта типа «Внешний бридж»), например, «Связь сделки и счета»;

- для связи двух сущностей внутри одного бизнес-объекта, например, «Связь сделки и обеспечения»;

- для связей экземпляров одной сущности, в том числе для отражения иерархии объектов, например, «Связь сделок».

Многие атрибуты бизнес-объектов могут изменяться во времени, например, статус сделки или рейтинг контрагента. Для таких параметров вводятся специальные сущности типа «Таблица вер-сионного атрибута». Без выделения такого типа сущностей версионные параметры являлись бы атрибутами основных или типовых таблиц, что приводило к их частому изменению и необходимости создания в них большого количества версий, что привело бы к сильной денормализации данных. [9]

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

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

- версионные и неверсионные.

Справочные таблицы представляют собой

сущности-классификаторы, среди которых также можно выделить группы:

- общие внешние классификаторы, наполнение которых определено на более высоком

х

X

о

го А с.

X

го т

о

ю

М О

а>

о

см

№ О!

О Ш

т х

<

т о х

X

уровне, чем организация (отраслевом, страновом или международном). примеры: «справочник валют», «справочник ОКАТО» и т.д.;

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

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

Таблица 2, где:

• В первом столбце перечислены типы сущностей;

• В первой строке перечислены типы бизнес-объектов;

• На пересечении указано допустимое использование типа сущности в соответствующем типе бизнес-объекта, при этом возможны следующие варианты:

- «0 - *» означает, что бизнес-объект может содержать любое количество сущностей соответствующего типа или не содержать таковых.;

- «1 - *» означает, что бизнес-объект должен содержать одну или более сущность соответствующего типа;

- «1» означает, что бизнес-объект должен содержать одну и только одну сущность соответствующего типа;

- «0 - 1» означает, что бизнес-объект может содержать не более одной сущности соответствующего типа или не содержать таковых;

- «0» означает, что использование сущностей соответствующего типа не допустимо для бизнес-объекта.

Таблица 2

Матрица соответствия типов бизнес-объектов и типов

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

2. Базовый перечень компонентов и бизнес-объектов

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

Измере- Транзак- Интерваль- Внеш-

ние ция ный факт ний бридж

Основная таб- 1 1 1 0

лица

Типовая таб- 0 - * 0 - * 0 0

лица

Таблица-бридж 0 - * 0 - * 0 1

Таблица вер- 0 - * 0 0 0

сионного ат-

рибута

Таблица до- 0 - 1 0 - 1 0 0

полнительных

атрибутов

Справочная таблица 0 - * 0 - * 0 - * 0 - *

Рисунок 5 - Базовый набор компонентов и бизнес-объектов

Общие классификаторы. Вырожденный компонент, который не содержит в себе бизнес-объектов, но содержит все справочные таблицы следующих групп: «Общий внешний классификатор» и «Общий внутренний классификатор».

Главная книга. Компонент, определяющий ядро банковского учета, без реализации которого невозможно решить ни одну серьезную аналитическую задачу в в кредитной организации. Ключевыми бизнес-объектами здесь являются: «Счета», «Остатки по счетам», «Проводки», «Платежные документы», «Обороты по счетам».

Контрагенты. Компонент, определяющий различных участников бизнес-процессов, протекающих в банке: от эмитентом ценных бумаг до собственных сотрудников. Ключевыми бизнес-объектами данного компонента являются: «Контрагенты» (очень обширный бизнес-объект, который характеризуется большим количеством сущностей и атрибутов в связи с большим количеством типов контрагентов), «Контакты с контрагентами», «Анкеты контрагентов», «Контактные

данные контрагентов», «Документы контрагентов», «Финансовые показатели», «Деятельность контрагентов», «Рисковые показатели контрагентов», «Обязательства контрагентов», «Денежные потоки контрагентов», «Собственность контрагентов».

Сделки. Наряду с компонентом «Контрагенты» данный компонент является чрезвычайно обширным в силу большого разнообразия банковских продуктов и огромного количества их особенностей. Данный компонент предоставляет широкие возможности адаптации под потребности конкретной организации. Ключевые бизнес-объекты компонента «Сделки»: «Сделки», «Связи сделок со счетами», «Связи сделок с контрагентами», «Остатки по сделкам», «Заявки по сделкам», «Связи заявок и анкет», «Операции по сделкам», «Тарифы», «Процентные ставки», «Графики платежей», «Изменения сделок», «Документы по сделкам», «Обеспечения», «Объекты сделок на финансовом рынке», «Рисковые параметры сделок», «Лимиты по сделкам», «Торговые площадки», «Котировки объектов сделок на финансовом рынке».

Банковские карты. В силу множества особенностей карточный бизнес выделен в отдельный компонент. Базовые бизнес-объекты, характеризующие данный компонент: «Пластиковые карты», «Связь карт и сделок», «Связь карт и контрагентов», «Транзакции», «Услуги по пластиковым картам», «Лимиты по картам», «Устройства обслуживания пластиковых карт», «Связь транзакции и проводки».

Заключение

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

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

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

• Формализация типов атрибутов и доменов данных;

• Обогащение базового набора компонент и бизнес-объектов;

• Формализация правил нейминга объектов универсальной многокомпонентной модели банковского ХД;

• Апробация предложенной методики и универсальной модели на примере решения конкретной бизнес-задачи.

Литература

1. Т. Е. Точилкина и А. А. Громова, Хранилища данных и средства бизнес-аналитики, Москва: Финансовый университет, 2017, p. 161.

2. Oracle, «Evolving the Data Warehouse: The Next Generation for Financial Services Institutions,» An Oracle White Paper, 2011.

3. Ю. В. Амириди, «Почему банки переплачивают за хранилище данных?,» Bankir.ru, 26 августа 2015.

4. The Economist, «Messy IT systems are a neglected aspect of the financial crisis,» 2009.

5. W. H. Inmon, Building the Data Warehouse, Third Edition ред., New York: John Wiley & Sons Inc., 2002.

6. Э. С. Набиуллина, Interviewee, Процесс консолидации банковского сектора продолжится. Интервью.. 18 октября 2018.

7. P. Giorgini, S. Rizzi и M. Garzetti, «GRAnD: A goal-oriented approach to requirement analysis in data warehouses,» Decision Support Systems, pp. 421,2008.

8. E. Alhyasat и M. Al-Dalahmeh, «Data Warehouse Success and Strategic Oriented Business Intelligence: A Theoretical Framework,» Journal of Management Research, 2013.

9. C. Ballard, D. Herreman, D. Schau, R. Bell и E. Kim, Data Modeling Techniques for Data Warehousing, Valencic, 1998.

10. R. Kimball и M. Ross, The Data Warehouse Toolkit. Second Edition. The Complete Guide to Dimensional Modeling, Wiley Computer Publishing, 2002.

Bank data warehouse design technique based on

configurable multicomponent data model Solianov K.S.

Financial University under the Government of the Russian Fedaration

This paper presents the author's methodology a bank data warehouse (DWH) design based on a universal multicomponent data model. The article defines the role of DWH in modern credit organizations, describes the key tasks that can be solved with the help of DWH, and also outlines the problems of designing such systems. To solve these problems, a technique is proposed, which involves a sequential transition from a high-level description of a subject area to a detailed logical data model. This study describes the structure of the author's universal multicomponent data model of the banking DWH, as well as a basic set of warehouse components and business objects. This basic set can be used as a basis or template that can be configured to fit the needs of a particular organization.

X X О го А С.

X

го m

о

ю

М О

to

Keywords: data warehouse; design; component approach; information analytical systems; data modelling; bank automation

Reference

1. Tochilkina T.E., Gromova A.A. Data warehouses and business intelligence tools; Hranilishcha dannyh i sredstva biznes-analitiki

2. Evolving the Data Warehouse: The Next Generation for Financial Services Institutions / An Oracle White Paper // 2011. - http://www.oracle.com/us/industries/financial-services/evolving-datawarehouse-wp-400257.pdf

3. Amiridi Yu.V. Why do banks overpay for data warehouse? / Bankir.ru; Pochemu banki pereplachivayut za hranilishche dannyh?

4. The Economist, «Messy IT systems are a neglected aspect of the financial crisis,» 2009.

5. W. H. Inmon, Building the Data Warehouse, Third Edition ред., New York: John Wiley & Sons Inc., 2002.

6. Nabiullina E.S. The process of consolidation of the banking sector will continue / 2018; Process konsolidacii bankovskogo sektora prodolzhitsya

7. P. Giorgini, S. Rizzi u M. Garzetti, «GRAnD: A goal-oriented approach to requirement analysis in data warehouses,» Decision Support Systems, pp. 4-21, 2008.

8. E. Alhyasat u M. Al-Dalahmeh, «Data Warehouse Success and Strategic Oriented Business Intelligence: A Theoretical Framework,» Journal of Management Research, 2013.

9. C. Ballard, D. Herreman, D. Schau, R. Bell u E. Kim, Data Modeling Techniques for Data Warehousing, Valencic, 1998.

10. R. Kimball u M. Ross, The Data Warehouse Toolkit. Second Edition. The Complete Guide to Dimensional Modeling, Wiley Computer Publishing, 2002.

a>

о

СЧ

№ OI

О Ш

m х

<

m о x

X