2 Спеціальний розділ
2.1 Проектування підсистеми, що розробляється
Проектування ІС «Роботі відділення комерційного банку» в програмному середовищі «BPWin» – даний розділ являє собою розробку ІУС в програмному середовищі «BPWin» та складається з 8-ми підрозділів.
2.1.1 Інструментальне середовище врWin
BPwin – це незамінний інструмент менеджерів та бізнес-аналітиків, а починаючи з версії 1.8, в яку включена підтримка діаграм потоків даних і методики IDEF3 (BPwin Professional), стає в руках системних аналітиків і розробників і потужним засобом моделювання процесів при створенні корпоративних інформаційних систем.
BPwin має інтуїтивно-зрозумілий графічний інтерфейс, допомагає швидко створювати і аналізувати моделі з метою оптимізації ділових і виробничих процесів.
За допомогою набору графічних інструментів BPwin дозволяє легко побудувати схему процесу, на якій показані вихідні дані, результати операцій, ресурси, необхідні для їх виконання, управляючі дії, взаємні зв'язки між окремими роботами.
Структурне моделювання бізнес-процесів підсистеми
Побудова контекстної діаграми
Контекстна діаграма є найзагальнішим описом системи і її взаємодії із зовнішнім середовищем.
Приклад такої діаграми зображений на рисунку 2.1.
На даній діаграмі зображено блок з назвою «Відділення банку», на ході в діаграму зображена стрілка "надходження заявки».
В якості елемента управління зображені дві стрілки, а саме: «порядок обслуговування замовлення» та «правила обслуговування клієнтів». В якості механізму зображені стрілки: «обладнання», «комп’ютер», «співробітники». На виході зображені наступні стрілки: «статистичні дані про прийняте замовлення», «виписка», «обслуговані клієнти»[18].
Рисунок 2.1 – Контекстна діаграма
2.1.2.2 Розробка DFD моделі
Діаграми потоків даних (Data flow diagramm, DFD) є засобом моделювання функціональних вимог до проектованої системи і використовуються для опису документообігу і обробки інформації. З їх допомогою ці вимоги представляються у вигляді ієрархії функціональних компонентів (процесів), зв'язаних потоками даних.
Головна мета такого уявлення продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити відносини між цими процесами.
DFD описує:
функції обробки інформації (роботи, процеси);
документи (стрілки, arrow), об'єкти, співробітників або відділи, які беруть участь в обробці інформації;
таблиці для зберігання документів (сховище даних, data store).
У BPwin для побудови діаграм потоків даних використовується нотація Гейна-Сарсона [18,19].
Приклад діаграми DFD зображено на рисунку 2.2.
На даній діаграмі присутні наступні блоки: сховище даних – «база даних», блок – «запит статистики», блок – «аналіз статистичних даних»,
блок – «генерація звіту» та зовнішня сутність – «система звітів».
Дані блоки з’єднані потоками даних. Їхні назви проілюстровано на діаграмі.
Рисунок 2.2 – Діаграма потоків даних DFD.
2.1.2.3 Розробка idef3 моделі
IDEF3 – використовується для опису логіки взаємодії інформаційних потоків.
Ця методологія моделювання використовує графічний опис інформаційних потоків, взаємин між процесами обробки інформації і об'єктами, що є частиною цих процесів. Діаграми Workflow можуть бути використані в моделюванні бізнес-процесів для аналізу закінченості процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації, наприклад, послідовність обробки замовлення або події, які необхідно обробити за кінцевий час [19].
Діаграма «оплата кредита» ілюструє логічну взаємодію процесів, які здійснюються при оплаті кредита (рисунок 2.3).
На даному рисунку зображені зовнішні сутності – «договір», «касир», «комп’ютер», також зображено наступні блоки: «подання клієнтом номеру рахунку», «передача коштів до каси», «пошук договору касиром в БД», «ознайомлення з договором», «внесення коштів на рахунок».
Рисунок 2.3 – Діаграма IDEF3 оплата кредита.
Діаграма «внесення вкладу» ілюструє логічну взаємодію процесів, які здійснюються при внесенні вкладу (рисунок 2.4).
На даному рисунку зображені зовнішні сутності – «договір», «касир», «комп’ютер», також зображено наступні блоки: «внесення коштів до каси», «пошук номера рахунку», «внесення грошей на кошти».
Рисунок 2.4 – Діаграма IDEF3 оплата кредита.
Діаграма «переведення коштів» ілюструє логічну взаємодію процесів, які здійснюються при внесенні вкладу (рисунок 2.5).
На даному рисунку зображені зовнішні сутності – «договір», «касир», «комп’ютер», також зображено наступні блоки: «вказання клієнтом номеру рахунку», «внесення коштів до каси», «внесення коштів на рахунок».
Рисунок 2.5 – Діаграма IDEF3 переведення коштів.
Діаграма «оплати комунальних послуг» ілюструє логічну взаємодію процесів, які здійснюються при оплаті комунальних послуг (рисунок 2.6).
На даному рисунку зображені зовнішні сутності – «договір», «касир», «комп’ютер», також зображено наступні блоки: «подача клієнтом комунальних книг», «внесення коштів по комунальним розрахункам».
Рисунок 2.6 – Діаграма IDEF3 оплата комунальних послуг.
Аналіз логічної та фізичної моделей баз даних
В відділенні банку мається сховище даних, в якому зберігається інформація що до проведених банківських угод, та обслугованих клієнтів.
Сховища даних – предметно-орієнтована, інтегрована, варіантна у часі сукупність даних, що не змінюється і призначена для підтримки прийняття управлінських рішень. Джерелами для сховищ даних є дані OLTP – систем, зовнішні дані та дані ODS оперативних сховищ даних.
Основне призначення сховища даних – це вирішення аналітичних задач для забезпечення підтримки прийняття управлінських рішень.
Особливу увагу слід звернути на ознаки відмінності сховищ даних від баз даних (БД) OLTP-систем: час збереження даних (історичних – у сховищах і поточних у БД), користувач – керівництво і аналітики у сховищах та працівники “переднього краю” у БД, призначення – інтерактивний аналіз у сховищах, обробка трансакцій у БД, ціль – стратегічна і тактична, запити – непередбачувані та передбачувані.
У повсякденній діяльності банки накопичують величезні обсяги інформації, які повинні стати джерелами додаткових прибутків, якщо їх використовувати як вхідну інформацію для прийняття рішень. Практика свідчить, що обсяг даних у банку щорічно зростає удвічі. Банк страждає від зайвої кількості суперечливих даних, які досить складно упорядкувати, до яких складно отримати доступ і які важко використовувати для прийняття рішень. Традиційні інформаційні системи автоматизації банківської діяльності не можуть забезпечити достатній рівень реалізації потреб прийняття рішень та стратегічного керування банками.
Можливими (найперспективнішими) напрямами аналізу банківської діяльності, для яких побудовано сховище даних, можуть бути:
– аналіз клієнтської бази банку, дистанційний аналіз банків, аналіз фінансової діяльності банку, аналіз бюджетування банку, аналіз ризиків, аналіз різноманітної управлінської та фінансової звітності, аналіз загроз економічній безпеці банку.
Після того, як питання часових рамок проекту впровадження СД, його бюджету та цілей визначені, слід прийматися за побудову сховища даних, етапами якого є: моделювання даних, побудова репозиторію метаданих, підвищення якості інформації у сховищі даних, побудова концептуальної та логічної архітектури сховища даних, визначення фізичної архітектури сховища даних, перетворення, очищення та завантаження даних у сховище даних.
Серед перерахованих етапів найбільш “предметно – залежним” є етап моделювання даних. У якості моделі у СД обирають, як правило, моделі типу “зірка”, “об’єднана зірка” чи “сніжинка”, перевагою яких на відміну від реляційних нормалізованих структур є швидкість отримання даних для реалізації запитів. При розробці сховищ даних у банках на роль таблиці фактів можна запропонувати сутність “Контракт”.
Контрактом може вважатися будь’який договір, що укладається з клієнтами, ним же оформляється переважна більшість внутрішньобанківських операції.
На практиці модель типу “зірка” практично неможливо побудувати для банків (забагато сутностей у банківській діяльності), тому краще обирати модель типу “об’єднана зірка”.
Побудова сховища даних потребує вирішення таких основних задач, як вибір та освоєння роботи із засобами доступу до даних, до яких можна віднести географічні інформаційні системи (ГІС), засоби добування даних (data mining), системи оперативного аналізу (OLAP-системи), засоби візуалізації даних, інформаційні системи керівників, засоби оброблення статистики, браузери Internet, браузери метаданих, мови програмування 4-го покоління (4GL), засоби розробки графічного інтерфейсу користувача, електронні таблиці, генератори звітів та ін.
Типи обслуговування в відділенні банку зображено на діаграмі 2.1.
Діаграма 2.1 – Види обслуговування клієнтів банку
2.1.4 Логічна модель
В даний час основним засобом накопичення та використання структурованої інформації служать бази даних. Концептуальний вибір логічної моделі даних в принципі визначає рівень ефективності тієї чи іншої програмної реалізації бази даних.
Розрізняють чотири логічні моделі даних:
- ієрархічні;
- мережеві;
- реляційні;
- багатовимірні.
З точки зору структур даних, що використовуються для зв'язку між собою внутрішніх об'єктів бази, логічні моделі можна об'єднати у дві групи:
- навігаційні моделі даних з адресними покажчиками на дані;
- посилальна модель даних з іменами (ідентифікаторами) даних.
До навігаційним моделям даних відносяться ієрархічна, мережева і багатовимірна логічні моделі, до посилальної моделі даних – реляційна модель.
Основною відмінністю бази даних від файлової системи є універсальність бази – тобто незалежність від будь-якої однієї структури опису предметного світу.
Історично першою стала застосовуватися навігаційна модель даних, заснована на багаторівневої структурі об'єктів, пов'язаних адресними покажчиками за принципом "предок-нащадок" в ієрархію (у кожного нащадка один предок) або мережу (у нащадка може існувати будь-яке число предків).
Однак застосування ієрархічної і мережної різновидів навігаційної моделі даних накладало істотні обмеження на ефективність реалізації основних операцій (запис, читання, змінення або видалення) над даними в базі: у разі ієрархії читання могло бути ефективно реалізовано тільки щодо одного типу атрибута елемента даних, що лежить в основі ієрархії.
Щодо інших типів атрибутів необхідно було застосовувати неефективний метод повного перебору даних в базі.
у випадку мережі ефективність читання не залежала від вибору типу атрибута елемента даних, але при цьому істотно сповільнювалася швидкість виконання записи, зміни та видалення даних через необхідність модифікації численних адресних покажчиків, що утворюють мережеву структуру.
У 1970 році Е. Ф. Коддом теоретично обгрунтував, що більш універсальним рішенням в області баз даних є посилальна модель: "Реляційна модель надає засоби опису даних на основі тільки їх природної структури, тобто без потреби введення будь-якої додаткової структури для цілей машинного вистави "[19].
Первинною структурою зберігання інформації в реляційної моделі даних служить двомірний масив – реляційна таблиця. Порядок розташування поодиноких записів – даних в реляційної таблиці довільний, так само як і порядок розташування атрибутів в складі даних.
Дані в різних реляційних таблицях пов'язані між собою посиланнями на ідентифікатори (зовнішні ключі). Це дає можливість з найбільшою швидкістю виконувати операції запису, зміни та видалення даних.
Проте теоретична модель Е. Ф. Кодда володіє явною неповнотою – у зв'язку з відсутністю в її складі будь-якого механізму пошуку даних для цілей подальшого читання, за винятком механізму, заснованого на повному переборі даних в базі. При досить великому (чи малому, з точки зору сучасного стану) кількості даних в реляційну базу в обов'язковому порядку включається той чи інший механізм пошуку, тобто додаткова структура, відсутність потреби в якій було задекларовано Е. Ф. Коддом.
Ефективність посилальної моделі даних.
Перевага теоретичної посилальної моделі перед навігаційної моделлю даних засноване на двох постулатах:
- довільному порядку розташування даних в реляційних таблицях і атрибутів в складі даних;
- Логічних зв'язках реляційних таблиць між собою на відміну від фізичних адресних зв'язків первинних структур зберігання інформації в навігаційній моделі.
На відміну від теоретичної, повна посилальна модель даних, що претендує на статус універсальної, повинна описувати як можна більш широке коло природних структур даних. Більшість типів природних структур даних являє собою ієрархічні, деревоподібні структури, що включають в свій склад безліч груп і підгруп характеристик, логічно пов'язаних між собою.
Розрив внутрішніх зв'язків атрибутів в спробі забезпечити довільний порядок їх розташування призведе до повної неадекватності подання інформації в базі даних щодо описуваної предметної області.
Для подолання цієї проблеми в посилальної моделі застосовують дезінтеграцію природної структури даних – нормалізацію інформації, тобто подання даних єдиного типу у вигляді кількох реляційних таблиць, кількість типів атрибутів у кожній з яких в межі прагне до одиниці. При збільшенні числа реляційних таблиць прямо пропорційно зростають витрати на дезінтеграцію (на етапі запису) і подальшу інтеграцію (на етапах читання, зміни і видалення) даних. На практиці рівень нормалізації обмежують 3-4 нормальною формою, що, в загальному випадку приблизно відповідає кратності зростання числа реляційних таблиць в базі.
Фізична модель даних
Фізична модель визначає розміщення даних у зовнішній пам’яті,
вона також називається внутрішньою моделлю системи і форма її представлення залежить від обраної БД.
Якщо обрана така БД, яка підтримує реляційну модель даних, то треба таблиці разом з атрибутами і зв’язки між таблицями перенести в середовище БД з врахуванням вимог до відповідних об’єктів БД. Так, ідентифікатори (імена) таблиць і полів мають задовольняти вимогам СКБД, типи даних, розміри полів, обмеження теж мають бути приведені у відповідність до прийнятих у даній БД.
Далі визначаються стратегії індексування, а також взаємозв’язки між таблицями, первинні та зовнішні ключі на основі визначених у даталогічній моделі та врахуванням способів їх завдання в обраній БД.
На етапі фізичного проектування слід приділити особливу увагу забезпеченню цілісності БД. У БД цілісність даних забезпечується обмеженнями цілісності, тобто набором правил, що встановлюють допустимість даних та зв’язків між ними. Наводиться контрольний приклад заповненої БД з урахуванням встановлених обмежень цілісності.
Таким чином, послідовність робіт при створенні фізичної моделі на основі реляційної моделі даних може бути наступною:
- аналіз та вибір БД;
- розробка структури (фізичної моделі) бази даних засобами
вибраної БД з урахуванням типів даних та обмежень
цілісності атрибутів;
- розробка схеми взаємозв’язків бази даних засобами вибраної
БД з урахуванням обмежень посилальної цілісності;
- розробка контрольного приклада заповнення бази даних.
Кінцевим результатом роботи є представлення таблиць та зв’язків між ними, що описані в даталогічній моделі даних, у середовищі обраної СКБД. При цьому мають бути визначені (запрограмовані мовою опису даних) обмеження цілісності як для атрибутів, так и посилальна цілісність.
2.2 Інформаційне забезпечення