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

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