Information Factory — cif) або більш рання назва корпоративне

сховище даних (Еnterprise Data Warehouses — EDW) вміщують

інтегровану інформацію, зібрану із певної множити оператив-

них БДта зовнішніх джерел, яка характеризує всю корпорацію і

необхідна для виконання консолідованого аналізу діяльності

корпорації у цілому. Такі сховища охоплюють усі багаточисе-

льні напрями діяльності корпорації і використовуються для

прийняття як тактичних, так і стратегічних рішень. Розробка

корпоративного сховища даних дуже трудоємкий процес, який

може становити від одного до кількох років.

Кіоски чи вітрини даних (data marts) це певна підмножина кор-

поративних даних, які характеризують конкретний аспект діяль-

ності, наприклад, роботу якогось підрозділу. Кіоск може вміщу-

вати як агреговані, так і первинні дані певної предметної область

Кіоск може отримувати дані з корпоративного сховища даних

(залежний кіоск) чи бути незалежним і тоді джерелом поповнення

його даними будуть оперативні бази даних. Розробка кіоска даних

потребує значно менше часу і в середньому займає приблизно

3—4 місяці.

Корпоративне сховище даних та вітрини будуються за подіб-

ними принципами і використовують практично одинакові техно-

логії.

Авторами і першими розробниками сховищ даних було за-

пропоновано дві основні архітектури: так звана корпоративна

інформаційна фабрика (Corporate Information Factory, скорочено

CIF) Білла Інмона [5] і сховище даних з архітектурою шини (Data

Warehouse Bus, скорочено BUS) Ральфа Кімболла (Ralph Kim-

ball) [6].

Сховище даних з архітектурою CIF будується поетапно на

базі “спірального” підходу, в основу якого покладено центра-

лізоване сховище іззалежними вітринами даних. Тому іноді цей

підхід називають низхідним, тобто таким при якому створення

сховища виконується за принципом “зверху-вниз”. Така архі-

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

сховищі, їх спочатку вибирають з успадкованих систем-джерел.

Якщо ці детальні атомарні дані не є нормалізованими, то їх

приводять до 3НФ. Тобто детальні атомарні даніз успадкованих

систем джерел зберігаються в реляційній моделі в нормалізо-

ваному представленні. На основі детальних атомарних даних

будується просторова модель для зберігання узагальнених да-

них.

Cховище даних з архітектурою шини (data-mart bus

architecture with linked dimensional data marts — BUS) Ральфа

Кімболла (Ralph Kimball) будується на принципах побудови

незалежних взаємопов’язаних вітрин. Перша вітрина даних

будується для одного бізнес-процесу з використанням вимірів

та показників, що в подальшому будуть використовуватись в

інших вітринах. Наступні вітрини даних розробляються з ви-

користанням попередньо створених вимірів, що в підсумку доз-

воляє створити логічно інтегровану сокупність (шину) вітрин,

яка буде виконувати роль корпоративного сховища даних.

Створення сховище даних при такому підході починається із

відбору даних, необхідних для бізнес-аналізу, з успадкованих

систем-джерел і підготовки їх для просторового зберігання.

Просторова модель при цьому може зберігати як деталізовані

атомарні дані так і агрегати даних. Цей підхід до створення

сховищ даних іноді називають висхідним, тобто таким, при

якому створення сховища виконується за принципом “зни-

зу-вверх”.

Крім цих архітектур, запропонованих основоположниками

концепції сховищ даних, на сьогодні використовується велика кіль-

кість різних архітектур, які описані в роботах [1, 3].

Згідно [4] формалізовано сховище даних можна описати на-

ступним чином:

DW = < DB, rf, RF, rm, RМ, func>,

де DB — множина баз даних — джерел сховища даних;

rf — множина відношень фактів;

RF — схема rf;

rm — множина відношень метаданих;

RМ — схема rm;

func — множина процедур (рішень).

Важливим при побудові сховища даних банку вирішення пи-

тання його концептуальної архітектури. Вибір архітектури побу-

дови сховища для банку обумовлюється організацією обробленняданих у банку: децентралізоване (розподілене) та централізоване

оброблення даних.

Є два можливих варіанти децентралізованої технології:

повна децентралізація та децентралізація на рівні філії банку.

Повна децентралізація полягає в тому, що у кожному з орга-

нізаційних підрозділів банку установлюється окрема незалеж-

на копія АБС, яка працює зі своєю автономною базою даних.

Обмін інформацією виконується підсумковими, консолідо-

ваними даними по завершенню банківського дня електрон-

ними чи паперовими документами. Децентралізація на рівні

філії полягає в тому, що у кожній з філій установлюється

окрема незалежна копія АБС, яка працює зі своєю автономною

базою даних, а всі її безбалансові відділення працюють з нею в

on-line-режимі. Системи організації інформаційної технології

з децентралізацією на рівні філії є найбільш поширеними в

Україні.

Централізована система працює з єдиною базою даних у

головному офісі банку, забезпечуючи режим on-line доступу

до даних всіх інших підрозділів банку. В єдиній базі даних

зберігається вся нормативно-довідкова інформація, а також

дані про всіх клієнтів та про всі операції, що забезпечує від-

сутність дублювання та протирічивості даних, спрощує про-

цедури їх адміністрування та надає можливіcть співставлення

даних та контролю за операціями, які виконані одним клієнтом

у різних підрозділах банку. Тобто централізоване оброблення

даних ліквідує “прив’язку” клієнта до певної дирекції чи філії

банку, надаючи йому можливість виконання операцій у

будь-якому офісі банку. Централізація надає переваги при

виконанні операцій та їх бухгалтерському проведенні в режимі

реального часу.

На перший погляд, для банків з централізованим обробленням

даних підходить централізована архітектура, тобто корпоративне

банківське сховище з залежними вітринами, а для банків з деце-

нтралізованим обробленням даних — сховище даних з архітек-

турою шини.

Не дивлячись на те, що централізація банківських інфор-

маційних систем вимагає значних капіталовкладень на прид-

бання централізованої АБС, обладнання, каналів зв’язку,

створення нових технологій безперебійної роботи системи,

дана тенденція відображає стратегічний напрямок розвитку

інформаційних технологій у банківському бізнесу, яка буде

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

лансу і звітності на рівні головного офісу банку, вважаємо за

доцільне для банків з децентралізованим обробленням фор-

мувати також централізоване корпоративне банківське схо-

вище. Це дозволить централізовано аналізувати діяльність

головного банку та його філій. Крім того такий підхід не буде

потребувати внесення радикальних змін у сховищі даних при

переході банку на централізоване оброблення даних. Аналіз

показав, що на сьогодення українські банки використовують

тематичні вітрини даних для аналізу окремих аспектів бан-

ківської діяльності, тому за цих умов корпоративне банківське

сховище краще будувати з архітектурою шини.

Дуже часто в банках використовується кілька облікових

OLTP-систем, які виступають джерелом для сховища даних. Кіль-

кість таких систем залежить від стану інформатизації банку та

політики щодо впровадження ІT-технологій.

Взаємозв’язок сховищ даних з OLTP-системами показано на

рис. 1.

Тематичні вітрини даних

...

OLTP-система

роздрібного

обслуговування

фізичних осіб

OLTP-система

роздрібного

обслуговування

юридичних осіб

OLTP-система

підтримки

карткових

операцій банку

OLTP-система

формування

звітності для НБУ

Зовнішні

джерела

Файли

звітності

НБУ

Підсумки

про проведені

операції

за день

Підсумки

про проведені

операції

за день

Дані

про виконані

карткові

транзакції

за день

Сиситема

ELT

КОРПОРАТИВНЕ

СХОВИЩЕ ДАНИХ

Деталізовані

дані

Агреговані

дані

Репозитарій

метаданих

OLAP (OLAM) і Data Mining системи

Рис. 1. Взаємозв’язок сховищ даних з OLTP-системами

Сховище даних містить деталізовані дані та агреговані, тобто

узагальнені дані. Ступінь деталізації та узагальнення даних, ви-

значається потребами банківських аналітиків. Обов’язковою ком-

понентою сховища даних є репозиторій метаданих, який склада-ється з бази метаданих і браузера для їх перегляду. Метаданими

називають бізнес-інформацію, що описує елементи сховища да-

них, бізнес-правила, процеси та джерела даних.

Ключовою компонентою при побудові сховища даних

є ETL-система (Extraction, Transformation, Loading), що виконує

процедури відбору, перетворення та завантаження даних до схо-

вища. В першу чергу ETL-системою виконується відбір з баз да-

них OLTP-систем інформації, що необхідна для бізнес-аналізу.

Враховуючи, що дані в сховище надходять з різних джерел, де

вони можуть мати різні імена, формати, одиниці вимірювання і

способи кодування, тому першніжвиконати їх завантаження, дані

перевіряються на коректність, очищаються від помилок, приво-

дяться до одного єдиного способу кодування, виду та формату, в

необхідній мірі узагальнюються і агрегуються. З цього моменту

дані представляються користувачеві у вигляді єдиного інформа-

ційного простору, які набагато простіше аналізувати.

Для здійснення того чи іншого виду банківського аналізу за

допомогою OLAP-технології доцільно виділити окремі тематичні

вітрини даних. У вітринах зберігається необхідна інформація для

певного виду аналізу, наприклад для аналізу кредитного порт-

фелю, причому дуже часто у вітрині може бути відсутні дані ни-

жнього рівня, тобто деталізована інформація, а лише агреговані

дані.

Важливим моментом створення банківського корпорати-

вного сховища є побудова базової моделі сховища, тобто

визначення основних бізнес-цілей для яких створюється

сховище, переліку інформаційних об’єктів (сутностей) та

зв’язків між ними. У практиці впровадження банківських

сховищ відомі дві конценції до побудови моделі сховища

даних [2]: перший варіант оснований на Головній книзі банку,

коли в основу моделі покладено облікова схема “Рахунки +

Клієнти + Проведення”, другий варіант — побудова сховища

на базі банківських угод (модель угод), коли за основу бе-

реться наступна схема “Угода—Рахунки—Операція” чи

“Угода—Операція—Проведення”. При використанні моделі

угод кожній угоді відповідають певні операцій (видача, по-

гашення, нарахування), вид (вимога чи зобов’язання), сума,

фінансовий інструмент і дата виконання, а також рахунки.

Модель угод добре зарекомендувала себе в системі

RS-DataHouses для ресурсних угод: кредити, депозити, між-

банківські кредити (залучені та розміщені), кредитні лінії,

угоди з цінними паперами і репо, Forex-угоди і SWAP, гара-

нтії і акредитиви. Необхідно зауважити, що концепція схо-

вища, яка побудована на обліковій схемі більш підходить для

банків, що використовують вітчизняні АБС, друга концепція

на базі угод — для банків, що експлуатують АБС західних

розробників.

Дані сховища використовуються для аналізу фінансової

діяльності банку, яка охоплює задачі управління активами,

пасивами, ліквідністю, дохідністю, співвідношенням між

активами і пасивами, власним капіталом, кредитним порт-

фелем, портфелем цінних паперів, ризиком (валютним, від-

сотковим, операційним, ризиком позабалансових операцій

тощо).

Кожна з перерахованих задач аналізу фінансової діяльності

характеризується своїми методами здійснення аналізу, і в той же

час вони є взаємопов’язаними. В основному, всі аналітичні бан-

ківськізадачізводяться до наступних напрямів аналізу:

1. Аналіз брутто-показників банку — величини активів, паси-

вів, власного капіталу, прибутків, кредитів тощо. Часто оцінка

здійснюється на основі співставлення власних показників з ана-

логічними показниками інших банків.

2. Аналіз ресурсної бази за обсягами, структурою та основ-

ними тенденціями розвитку складових. При цьому здійснюється

класифікація окремих статей ресурсів банку, розрахунок та ви-

вчення динаміки структурних показників.

3. Аналіз активів банку за обсягами, структурою та основними

тенденціями розвитку складових. Активи банку класифікуються

за окремими статтями, розраховується та вивчається динаміка

структурних показників.

4. Аналіз ліквідності банку на основі розрахунку фінансових

коефіцієнтів та їх порівняння з критеріальним рівнем.

5. Аналіз та визначення ступеня збалансованості активів і па-

сивів за строками та сумами, ГЕП-аналіз, спред-аналіз.

6. Аналіз дохідності банку на основі аналізу даних балансу

та звітів про прибутки та збитки. Розраховуються якісні та кіль-

кісні показники, що характеризують дохідність банку, ефек-

тивність використання активів, структуру доходів та витрат

банку.

Крім вище перерахованих видів аналізу, здійснюється аналіз

окремих видів діяльності: аналіз кредитного портфелю, портфелю

цінних паперів, кредитоспроможності клієнтів, достатності вла-

сного капіталу, відсоткової маржі, прибутковості окремих опера-

цій та підрозділів, показників ліквідності тощо. Розробка сховищ даних потребує їх ретельного проектування

та вибору способу представлення даних на логічному рівні. Пи-

тання проектування сховищданих детально викладені в роботі [9].

Враховуючи те, що переважна більшість банківських

OLTP-систем реалізована під управлінням реляційних СКБД

(Oracle, SQLServer, Sybase, DB2), то для банківських установ пі-

дходять традиційні просторові моделі (dimensional model) сховищ

даних “зірка” (star schema) та “сніжинка” (snowflake schema), що

підтримуються цими системами.

Згідновимог Basel II, банкунеобхіднонакопичуватистатистикуне

меншеніжза сімроків, томунаявність сховища єнеобхідноюумовою

функціонування сучасного банку. Західні банки приступили до ство-

рення сховищоперативноїінформації, що надаєможливість у режимі

реального часу відстежувати шахрайські трансакції, проводити моні-

торинг платіжних операцій для боротьби з відмиванням “брудних”

грошей.

На основі сховищ даних у банках розробляються інформа-

ційно-аналітичні системи, основними типовими компонентами

яких є:

• банківські OLTP-системи, як основне джерело інформації

для сховища даних;

• ELT-засоби відбору, перетворення узгодження та транспор-

тування даних до сховища;

• репозитарій для зберігання моделей даних і метаданих;

• інструментальнізасоби для реалізації OLAP -запитів;

• інструментальнізасоби для реалізації інтелектуальних запитів.

Для побудови інформаційно-аналітичної системи банку краще

використовувати інструменти IBM Cognos і SAP Business Objects,

які признані лідерами ринку OLAP. Для бізнес-аналізу (Business

Intelligence, BI) і використання в банківських інформаційно-ана-

літичних системах також можна використовувати розробки на-

ступних компаній: Actuate, Arcplan, Brio, Computer Associates,

Crystal, Hummingbird, Hyperion, Informatica, Information Builders,

Microsoft, MicroStrategy, Oracle, Peoplesoft, ProClarity, SAP, SAS,

Siebel.

Література

1. АсадуллаевС. “Архитектуры хранилищ данных — I”. —

http://www.ibm.com/developerworks/ru/library/sabir/axd_1/index.html. 2. Михеев А., Савкин Г. Становление модели RS-DataHouse // Жур-

нал RS-Club. — № 4. — 2006. — С. 64—68.

3. Корпоративные хранилища данных. Планирование, разработка,

реализация. Том. 1: Пер. с англ. — М.: Вильямс, 2001

4. Медиковський М.О., Шаховська Н.Б. Формалізація операцій над

джерелами даних у просторі даних.http://www.vstu.vinnica.ua/~oeipt/-

files/index_18.files/6.pdf

5. W. H. Inmon, Building the Data Warehouse, QED/Wiley, 1991 .

6. Data-Warehousing-Kimball-Model-vs-Inmon-Model

http://www.scribd.com/doc/15487492/

7. Hap J. OLAР Mining An Integration of OLAР with Data Mining //

Proc. IFIP Conf jn Data Semantics Switzerland. — 1997

8. Parsaye K. OLAР and Data Mining: Bridging the Gap// Database

Programming and Design. — 1997. — № 2.

9. СитникН. В.Проектування базі сховищданих: Навч. посібник. —

К.: КНЕУ, 2004. — 348 с.

Стаття надійшла до редакції 12.05.2011 р.