Спосіб зберігання та обробки даних в банківській сфері

Реферат: UA 83755 U UA 83755 U 5 10 15 20 25 30 35 40 45 50 55 60 Корисна модель належить до способів обробляння даних, спеціально пристосованих для адміністративних, комерційних, фінансових, управлінських, спостережних або прогнозувальних цілей, а саме до систем зберігання даних та може бути використана для зберігання історичних даних по предметним областям, що належать до банківської сфери, а також для підготовки звітностей комерційного банку, необхідних для аналізу бізнес процесів і підтримки прийняття управлінських рішень. Необхідність розробки способів зберігання та обробки даних обумовлена проблемами, які існують в банківській сфері. Через розрізненість первинної інформації, що зберігається в різноманітних оперативних системах банку, постає проблема формування консолідованої звітності. Також виникає складність подальшої обробки доступних даних через суперечливість та різний рівень їх достовірності. Таким чином, система сховища даних стає необхідною як єдине джерело інформації, що потребується для формування банківської звітності. Зазвичай для рішення викладених проблем використовують наступні сховища даних та способи: - способи на основі вбудованих сховищ даних, що входять до складу автоматизованих банківських систем (далі - АБС); - способи власної розробки сховищ даних ІТ-службами банків; - способи на основі готових рішень крупних західних вендорів (IBM, SAP - Informatica, Oracle Financial Services Data Warehouse); - способи на основі сховищ даних, розроблених системними інтеграторами для конкретних банків; Недоліками способів на основі вбудованих сховищ даних, що входять до складу автоматизованих банківських систем є орієнтованість моделі даних на одне основне джерело даних, а саме - АБС, що ускладнює збір та консолідацію з інших джерел. Найбільш типовими недоліками способів на основі сховищ даних власної розробки, що розроблені IT- службами банків, є неможливість відстеження й зберігання історії змін первинних облікових даних, відсутність перевірених та задокументованих алгоритмів розрахунку фінансових показників, складність під'єднання нових джерел через відсутність єдиної моделі зберігання даних та єдиного технологічного способу організації процесів витягу, трансформації та приведення даних до єдиного формату та відсутність можливості контролю достовірності інформації. Недоліком способів на основі готових рішень крупних західних вендорів є те, що вони не враховують специфіку національного законодавства, що значно відрізняється від західного, де саме і розроблені ці системи. Впровадження такої системи пов'язано із значною її переробкою, що збільшує вартість її впровадження. Близькими до запропонованого способу є способи на основі сховищ даних, розроблених системними інтеграторами для конкретних банків, недоліками цих способів є їхня унікальність для кожного окремого випадку, і, як наслідок, дуже висока вартість супроводу в процесі роботи. Найбільш близьким до запропонованого рішення (найближчим аналога), є спосіб, що описаний у відкритій до загального доступу книзі (Inman W. Building the Data Warehouse. - New York: John Willey & Sons, 1992), який включає в себе дії, пов'язані зі сховищем даних та зовнішніми джерелами даних, сервером баз даних з модулем робочого сховища даних та моделі даних, що містить логічну модель, фізичну модель та блок метаданих ведення. Недоліком найбільш близького рішення є його загальна форма, не адаптована під вирішення конкретних задач, специфіку документів і специфіку сфери. Задачею корисної моделі є створення такого способу зберігання та обробки даних в банківській сфері, який би дозволяв комплексно виконувати завантаження даних з облікових систем (джерел первинних даних банку) в єдине сховище, довготривале зберігання історичних даних в єдиній моделі даних, організованої по предметним областям, розрахунок фінансових показників, необхідний для аналізу та прийняття рішень і підготовку внутрішньої та зовнішньої звітності банку та зручний і універсальний доступ до інформації. Поставлена задача вирішується тим, що завдяки послідовності дій, прописаних програмним забезпеченням над апаратною частиною та за її допомогою, а саме: згідно з корисною моделлю, із банківських джерел даних первинні дані по каналах зв'язку за допомогою блока виконання ETL-процесів модуля завантаження даних сервера інтеграції даних, використовуючи програмне забезпечення "Oracle Data Integrator", приводять до єдиної структури, зберігають історію змін та заносять до оперативного сховища даних сервера інтеграції даних, у блоці верифікації даних сервера інтеграції даних за допомогою програмного забезпечення "Oracle Database" та "Oracle Business Intelligence" виконують перевірку якості завантажених і консолідованих даних у відповідності до заздалегідь обумовлених правил, у блоці аудиту 1 UA 83755 U 5 10 15 20 25 30 сервера інтеграції даних виконують протоколювання всіх дій модуля завантаження даних, інформують користувачів про хід роботи модуля та виявляють помилки, далі дані направляють по каналах зв'язку до робочого сховища сервера баз даних, де за допомогою програмного забезпечення "Oracle Database" їх розподіляють по предметним банківським областям, накопичують та зберігають, з робочого сховища даних сервера баз даних дані направляють в модуль регуляторної звітності сервера формування звітів, де за допомогою програмного забезпечення "Oracle Business Intelligence" будують статистичну звітність, яку направляють до певного кінцевого користувача, також дані з робочого сховища даних сервера баз даних направляють до модуля управлінської звітності, в якому за допомогою програмного забезпечення "Oracle Financial Services Analytical Applications (OFSAA)" аналізують бізнес процеси й підтримують прийняття рішень і направляють кінцеві дані певним користувачам, при цьому права доступу користувачів до даних регулюють у модулі розмежування доступу й системи безпеки за допомогою програмного забезпечення "Oracle Database". Як модель даних, робоче сховище даних використовує типову модель даних РДТЕХ для банків, при цьому логічна модель являє собою набори пов'язаних між собою сутностей (атрибутів, зв'язків, доменів та інше), фізична модель відображає логічну модель на рівні таблиць баз даних і виконана з можливістю зберігання історії змін даних за допомогою ведення в таблицях дати початку та дати закінчення дії даних в історії запису і флагу фіксації логічного видалення (спеціальне поле, добавлене в кожну таблицю сховища даних, по значенню якого можна визначити факт видалення даних із джерела даних), та з можливістю забезпечення зворотного трасування до первинного запису у джерелах даних за допомогою зберігання коду джерела даних та ключа первинного запису, а метадані ведення моделі включають в себе глосарії, засоби розмітки моделі для побудування матриць "суть-задача", засоби розмітки моделі для побудування матриць "суть-джерело", автотести моделі та допоміжні звіти для роботи з моделлю. Як канали зв'язку використовують мережеві протоколи зв'язку TCP/IP. ETL-процес - це процес вилучення даних із зовнішніх джерел, перетворення і приведення даних до єдиного формату та завантаження даних у кінцеве сховище. Корисна модель пояснюється фігурами, на яких зображено: Фіг. 1 - спосіб зберігання та обробки даних в банківській сфері, загальна схема. Фіг. 2 - спосіб зберігання та обробки даних в банківській сфері, концептуальна схема. Завдяки втіленню запропонованого способу підвищується ефективність керування бізнесом банку засобами систематизації основних показників його діяльності й представлення користувачам засобів аналізу даних, скорочується час і трудомісткість підготовки звітностей та звільняються ресурси оперативних систем банку від невластивих їм аналітичних функцій. 35 ФОРМУЛА КОРИСНОЇ МОДЕЛІ 40 45 50 55 1. Спосіб зберігання та обробки даних банківської сфери, що включає в себе дії, пов'язані з сховищем даних та зовнішніми джерелами даних, сервером баз даних з модулем робочого сховища даних та моделі даних, що містить логічну модель, фізичну модель та блок метаданих ведення, який відрізняється тим, що згідно зі способом з зовнішніх джерел даних первинні дані по каналах зв'язку за допомогою блока виконання ETL- процесів модуля завантаження даних сервера інтеграції даних, використовуючи програмне забезпечення "Oracle Data Integrator", приводять до єдиної структури, зберігають історію змін та заносять до оперативного сховища даних сервера інтеграції даних, у блоці верифікації даних сервера інтеграції даних за допомогою програмного забезпечення "Oracle Database" та "Oracle Business Intelligence" виконують перевірку якості завантажених даних в оперативне сховище відповідно до заздалегідь обумовлених правил, у блоці аудиту сервера інтеграції даних виконують протоколювання всіх дій модуля завантаження даних, інформують користувачів про хід роботи модуля та виявляють помилки, далі дані направляють по каналах зв'язку до робочого сховища сервера баз даних, де за допомогою програмного забезпечення "Oracle Database" їх розподіляють по предметним банківським областям, накопичують та зберігають, з робочого сховища даних сервера баз даних, дані направляють в модуль регуляторної звітності сервера формування звітів, де за допомогою програмного забезпечення "Oracle Business Intelligence" будують статистичну звітність, яку направляють до певного кінцевого користувача, також дані з робочого сховища даних сервера баз даних направляють в модуль управлінської звітності, в якому за допомогою програмного забезпечення "Oracle Financial Services Analytical Applications (OFSAA)" аналізують бізнес процеси й підтримують прийняття рішень та направляють кінцеві дані певним користувачам, при цьому права доступу користувачів до даних регулюють в модулі 2 UA 83755 U 5 10 15 розмежування доступу й системи безпеки за допомогою програмного забезпечення "Oracle Database". 2. Спосіб зберігання та обробки даних банківської сфери за п. 1, який відрізняється тим, що як модель даних, робоче сховище даних використовує типову модель даних РДТЕХ для банків, при цьому логічна модель являє собою набори пов'язаних між собою сутностей (атрибутів, зв'язків, доменів та інше), фізична модель відображає логічну модель на рівні таблиць баз даних та виконана з можливістю зберігання історії змін даних за допомогою ведення в таблицях дати початку та дати закінчення дії даних в історії запису і флагу фіксації логічного видалення даних та з можливістю забезпечення зворотного трасування до первинного запису у джерелах даних за допомогою зберігання коду джерела даних та ключа первинного запису, а метадані ведення моделі включають в себе глосарії, засоби розмітки моделі для побудування матриць "суть-задача", засоби розмітки моделі для побудування матриць "суть-джерело", автотести моделі та допоміжні звіти для роботи з моделлю. 3. Спосіб зберігання та обробки даних банківської сфери за п. 1, який відрізняється тим, що як канал зв'язку використовують мережеві протоколи зв'язку TCP/IP. 3 UA 83755 U Комп’ютерна верстка Л. Литвиненко Державна служба інтелектуальної власності України, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601 4