Проектування інформаційної системи підтримки проведення кредитних операцій

Як правило, розробка логічної моделі являє собою ітераційний  процес, що складається з фаз аналізу, проектування та оцінювання. При цьому  на кожній ітерації додаються нові правила. Добрі засоби проектування баз даних мають бути гнучкими, а організація роботи з ними —  ефективною. ЕР-діаграми повинні доповнюватися  детальнішою інформацією про  бізнес, правила та обмеження посилання  на цілісність, а також давати змогу  керувати наочним поданням деталей  моделі.

Під час створення логічної моделі потрібно насамперед провести важливу роботу з замовником. Найбільший обсяг робіт з базами даних  пов'язаний із запитами. Тож потрібно якнайдокладніше дізнатися від замовника про можливі запити до бази даних. Досвід проектування свідчить про те, що замовники часто не уявляють, які можливості даватиме їм база даних, до вирішення яких нових задач вони зможуть долучитися. Через це під час проектування потрібно якнайраніше показати замовникам їхні можливі горизонти, щоб так само якнайраніше довелося б вносити зміни до логічної моделі.

 

3.2 Побудова ER-діаграми

 

Модель сутність зв’язок (ER-модель) – модель даних, що дозволяє описувати концептуальну схему предметної області. ER-модель використовується при високо рівневому проектуванні баз даних. З її допомогою можна виділити ключові сутності і позначити зв'язки, які можуть встановлюватися між цими сутностями.

З її допомогою можна виділити ключові сутності і позначити  зв'язки, які можуть встановлюватися  між цими сутностями. Під час проектування баз даних відбувається перетворення ER-моделі в конкретну схему бази даних на основі обраної моделі даних (реляційної, об'єктної, мережевої або ін). ER-модель являє собою формальну конструкцію, яка сама по собі не наказує ніяких графічних засобів її візуалізації. У якості стандартної графічної нотації, за допомогою якої можна візуалізувати ER-модель, була запропонована діаграма сутність-зв'язок (ER-діаграма)

Для розробки ER-моделі можна використовувати засоби графічних редакторів векторного типа, наприклад MS Visio.

В результаті роботи була сформована наступна ненормалізована діаграма рівня сутностей:

1  1 n

  

  n

n

 

1

 1

 

 

 

Нормалізуємо діаграму рівня  сутностей

 

 

 

 

4. ПРОЕКТУВАННЯ БАЗИ ДАНИХ

 

4.1 Опис об’єктів, які плануються до використання

 

4.1.1 Структури таблиць

 

Таблиця – об’єкт, який  визначається і використовується для зберігання даних, тобто це поіменоване реляційне відношення, яке зберігає дані про певну сутність предметної області. Таблиця – основа будь-якої бази даних. Метою правильної розробки таблиць є видалення надлишкових (повторюваних) даних. Для досягнення цієї мети таблицю розділяють на багато тематичних таблиць, щоб кожний факт було представлено тільки один раз.

 Коли в банк надходять  дані про позичальника, оператор  заповнює ними відповідні таблиці.  Для вирішення поставленої задачі  необхідно створити 3таблиці: «Баланс», «Актив (пасив)», «Розділ» (Табл. 4.1, 4.2, 4.3)

Таблиця 4.1

БАЛАНС 

Поле	Тип	Розмір	Індексація
№ п/п	Лічильник	Довге ціле	Так(збіги не допускаються)
Код	Числовий	Довге ціле	Ні
Актив (пасив)	Текстовий	50	Ні
Код рядка	Текстовий	10	Ні
Код розділу	Числовий	Довге ціле	Ні
На початок звітного періоду	Числовий	Подвійне з плаваючою  крапкою	Ні
На кінець звітного періоду	Числовий	Подвійне з плаваючою  крапкою	Ні
Відбір	Числовий	10	Ні

 

 

 

 

 

 

Таблиця  4.2

АКТИВ (ПАСИВ)

 

Поле	Тип	Розмір	Індексація
Код	Числовий	Довге ціле	Так(збіги не допускаються)
Тип	Текстовий	50	Ні

 

Таблиця 4.3

РОЗДІЛ

 

Поле	Тип	Розмір	Індексація
Код розділу	Числовий	Довге ціле	Так(збіги не допускаються)
Розділ	Текстовий	50	Ні

 

4.1.2 Створення запитів

 

Запити – це гнучкий і зручний засіб доступу до даних, важливою властивістю якого є те, що при створенні результуючої таблиці можна не тільки вибирати інформацію з бази, але й обробляти її. При роботі запиту дані можуть упорядковуватися (сортуватися), фільтруватися (відсіюватися), об'єднуватися,  розділятися, змінюватися, і при цьому ніяких змін у базових таблицях може не відбуватися.

Механізм запитів є  найуніверсальнішим рішенням, що дозволяє, з одного боку, як завгодно маніпулювати даними, а з іншого боку – знизити  потреби СУБД у системних ресурсах взагалі, тому що активізація бази даних  не призводить до проведення всіх наявних  у ній запитів й інших автоматичних функцій, яке має місце, наприклад, в електронних таблицях.

1. «Ав» - виконує запит на розрахунок високоліквідних активів.
2. «Зп»– виконує запит на розрахунок поточних зобов’язань.
3. «Ал» – виконує запит на розрахунок ліквідних активів.
4. «Ао» – виконує запит на розрахунок оборотних активів.
5. «Вк» – виконує запит на розрахунок власного капіталу підприємства.
6. «Зк» - виконує запит на розрахунок залучених коштів.

 

4.1.3 Побудова форм

 

Основою діалогового інтерфейсу користувача з базою даних  є форма. За її допомогою можуть здійснюватися  завантаження даних у зв'язані  таблиці, переглядатися і коректуватися  дані. Працюючи з формою, користувач може добавляти та вилучати записи в таблицях, змінювати значення даних  у полях, одержувати розрахункові дані, а також здійснювати контроль даних, що вводяться.

Конструкція форми визначається користувачем. При цьому вказується, з яких таблиць і вміст яких полів треба відображати, які  графічні елементи мають бути включені у форму. З цими графічними елементами можуть бути пов'язані такі дії:

• перегляд записів і їх оброблення (додання, вилучення, друкування, відновлення);
• робота з формою (відкривання, закриття, друкування і т. д.);  
• робота із звітами (перегляд, введення у файл, друкування і т. д.);  
• робота з додатками (запуск Word, Excel та інш., вихід з них), а також інші дії.

Усі відомості у формі  містяться в елементах керування  – об'єктах форми, які служать  для виведення даних на екран, виконання макрокоманд або оформлення форми. Наприклад, поле можна використати  для виведення даних на екран, кнопку – для відкривання іншої  форми, а лінію або прямокутник  – для поділу та групування елементів  керування з тим, щоб вони краще  сприймалися користувачем.

1. «Витрати майбутніх періодів» - створена за допомогою конструктора форм. В якості

джерела використано запит  «Витрати майбутніх періодів». Форма  служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (актив)».

2. «Забезпечення наступних витрат і платежів» - створена за допомогою конструктора

форм. В якості джерела  використано запит «Забезпечення наступних витрат і платежів». Форма служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (пасив)».

3. «Звіт про фінансові результати» - створена за допомогою конструктора форм. В

якості джерела використано  таблицю «Звіт про фінансові  результати». Форма служить для  відображення вибіркової інформації, яку містить дана таблиця.

4. «Власний капітал» - створена за допомогою конструктора форм. В якості джерела

використано запит «Власний капітал». Форма служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (пасив)».

5. «Доходи майбутніх періодів» - створена за допомогою конструктора форм. В якості

джерела використано запит  «Доходи майбутніх періодів». Форма  служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (пасив)».

6. «Довгострокові зобов’язання» - створена за допомогою конструктора форм. В якості

джерела використано запит  «Довгострокові зобов’язання». Форма  служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (пасив)».

7. «Необоротні активи» - створена за допомогою конструктора форм. В якості джерела

використано запит «Необоротні  активи». Форма служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (актив)»

8. «Оборотні активи» - створена за допомогою конструктора форм. В якості джерела

використано запит «Оборотні  активи». Форма служить для відображення вибіркової інформації, що міститься в таблиці «Баланс (актив)».

9. «Поточні зобов’язання» - створена за допомогою конструктора форм. В якості

джерела використано запит  «Поточні зобов’язання». Форма служить  для відображення вибіркової інформації, що міститься в таблиці «Баланс (пасив)».

10. «Інформація про розробника» - створена за допомогою конструктора форм. Форма є

інформаційною. Містить дані про розробника бази даних.

11. «Інформація про програмний продукт»  - створена за допомогою конструктора форм.

Форма є інформаційною. Містить  інформацію про базу даних.

12. «Головна форма» - створена за допомогою конструктора форм. З цієї форми

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

 

4.1.4 Створення звітів

 

Кінцевим продуктом більшості  СКБД є звіт. В Access звіт являє собою  спеціальний тип неперервних  форм, що призначені для роздруковування. Для створення звіту, який можна  роздрукувати і розподілити між  користувачами, Access комбінує дані в  таблицях, запитах і навіть у формах. Роздрукована версія форми може слугувати  звітом.

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

1. «КЛ1» - створений на основі запиту. Призначений для перегляду

та друку коефіцієнта  миттєвої ліквідності.

2. «КЛ2» - створений на основі запиту. Призначений для перегляду та друку коефіцієнта

поточної ліквідності.

3. «КП» - створений на основі запиту. Призначений для перегляду та друку коефіцієнта

загальної ліквідності.

4. «КМ» - створений на основі запиту. Призначений для перегляду та друку коефіцієнта 

маневреності власних  коштів.

5. «КН» - створений на основі запиту. Призначений для перегляду та друку коефіцієнта

незалежності.

 

4.1.5 Створення макросів