Інформаційні системи та бази даних

Ім'я файлу: РГЗ_КП_Варіант14.doc
Розширення: doc
Розмір: 217кб.
Дата: 15.12.2022
скачати
Пов'язані файли:
Білети_Маркетингові_дослідження_2022_3.docx

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ

“ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ”

КУРСОВА РОБОТА
з дисципліни «Інформаційні системи та бази даних»

Виконав: студент групи
Петренко М. О.
Перевірив:
Харків 2022
Завдання до курсової роботи

Варіант 14

Керівництву національного банку необхідна інформація з обліку обслуговування клієнтів державних банків. Центральні відділення банків знаходяться в різних містах України, філії банків можуть знаходитися в містах, відмінних від міст, де знаходяться центральні відділення. Клієнти банку можуть знаходитися в містах, відмінних від міст, де знаходяться банки і філії. Клієнти можуть обслуговуватися у всіх філіях тих банків, де у них є розрахункові рахунки.
ЗМІСТ
ВСТУП..............................................................................................................................4

Словесний опис та системний аналіз предметної області.................................6
Проектування бази даних для ІБС......................................................................10

2.1 Постановка задачі...........................................................................................11

2.2 Концептуальне проектування моделі БД......................................................13

2.3 ЕR-діаграма концептуальної моделі..............................................................15

2.3 Проектування логічної (реляційної) моделі БД............................................18

Розробка програмного додатку.............................................................................21
Створення запитів на мові SQL............................................................................22

ВСТУП

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

Створення і підтримка ефективної системи управління банківськими бізнес-процесами — одне з пріоритетних завдань стратегічного розвитку кожного державного чи комерційного банку. Вирішення завдання ефективного управління багато в чому залежить від можливостей інформаційної банківської системи (ІБС), впровадженої в банку. А якість її роботи, у свою чергу, безпосередньо пов’язана з архітектурною моделлю, покладеною в основу побудови системи.

Обробка інформації базується на інформаційних технологіях — технологіях, що пов’язані зі збиранням, обробкою, передачею та використанням інформації. Найчастіше мова йде про комп’ютерні інформаційні технології — обробка інформації з використанням ЕОМ. Інструментами обробки здебільшого є прикладні програмні засоби (ППЗ), які дають змогу здійснювати певний набір операцій та дій над інформацією.

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

У ході виконання роботи потрібно провести:

• словесний опис і системний аналіз предметної області;

• проектування і створення бази даних;

• створення форм, звітів та запитів;

• створення головної кнопкової форми.

Пояснення щодо проектування та реалізації програмного продукту надані у вигляді письмового звіту (пояснювальної записки).
1 СЛОВЕСНИЙ ОПИС І СИСТЕМНИЙ АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

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

Опис предметної області. До функцій працівників державних та Національного банків входить робота з клієнтами, а саме: оформлення клієнтів, прийом вкладів, оформлення рахунків, контроль оплати і виконання банківських розрахунків з клієнтами та іншими організаціями. Центральні відділення державних банків в різних містах України виконують різні види банковських операцій: прийом вкладів (на депозитні та поточні рахунки, тощо), обмін валют, видачу кредитів чи ссуд, виконання фінансових операцій з іншими організаціями, підприємствами та банками за замовленням клієнтів, проводять облік обслуговування клієнтів державних банків.

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

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

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

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

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

Результатом аналізу є постановка задачі, яка включає:

мету розробки;

Створити інформаційну банківську систему (ІБС) для функціювання Національного та державних банків, що буде забеспечувати цілодобовий доступ користувачив та персоналу до фінансової інформації (БД);

опис предметної області;
перелік користувачів та робіт, що ними будуть проводитися за допомогою інформаційної банківської системи. Наприклад:

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

Касир – контроль і оплата банківських операцій в касі банку.

перелік документів, що буде генерувати ІС.

«Банківський договір», «Перелік банківських послуг, що надаються клієнам»,

«Чек про виконання банківської операції» тощо.

У додатках наведено приклади проектування інформаційної системи і БД (етапи постановки задачі, концептуального і реляційного проектування).
2 ПРОЕКТУВАННЯ БАЗИ ДАНИХ ДЛЯ ІНФОРМАЦІЙНОЇ БАНКІВСЬКОЇ СИСТЕМИ

Проектування бази даних ґрунтується на результатах системного аналізу предметної області і включає три етапи:

Концептуальне проектування БД:

− опис сутностей;

− опис атрибутів;

− опис зв'язків, обґрунтування потужності зв'язків;

− побудова ER-діаграми.

Зауваження. На діаграмі можна не вказувати атрибути незалежних сутностей.

Проектування реляційної моделі БД:

− опис порядку перетворення концептуальної моделі на реляційну;

− визначення первинних ключів;

− повна реляційна схема.

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

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

C. Фізичне проектування БД, тобто розміщення БД на зовнішніх носіях (реалізація бази даних у СУБД Access) включає такі етапи:

1. Створення таблиць бази даних:

− визначення імен полів;

− визначення ключового поля;

− визначення властивостей полів;

− визначення властивостей таблиці;

− створення полів підстановок.

Для всіх таблиць моделі треба визначити і описати характеристики і властивості полів. До обов'язкових характеристик відносяться: ім'я поля; тип даних; розмір поля; чи є поле обов'язковим (тобто чи може воно мати значення NULL). Необхідно описати ті властивості полів, які встановлювались розробником: формат поля; маска введення; умова на значення; значення, що приймає поле за умовчанням (якщо таке є); підпис для поля (якщо він не співпадає з ім'ям поля), характеристики підстановки, якщо вона є.

2. Створення схеми даних:

− встановлення зв'язків;

− визначення потужностей зв'язків.

3. Заповнення таблиць даними.

2.1 Постановка задачі на проектування ІБС

Мета роботи: розробка інформаційної системи Національного банку України та системи державних банків для обліку і контролю банківських операцій.

Функції, які повинна виконувати ІС:

• реєстрація і облік клієнтів та їх банківських договорів;

• розрахунок вартості банківських послуг і дати їх виконання;

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

• формування списків зареєстрованих банківських договорів, сплачених договорів, тих, що виконані та закінчилися, тощо;

• облік банківських послуг, що виконуються одночасно;

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

• розрахунок суми штрафів за невчасне виконання договору з боку клієнта;

• облік роботи менеджерів з клієнтами;

• друк договорів, рахунків, чеків, квитанцій.

Перелік користувачів і банківських операцій, що проводяться ними в ІБС, наведено в таблиці 1.

Таблиця 1

Перелік користувачів і банківських операцій

Користувач	Роботи, що проводяться
Клієнт банку	переглядання прайс-листа банківських послуг, укладання і отримання банківського договору
Менеджер	реєстрація клієнта, надання інформації про банківські послуги і оформлення договору з клієнтом, друк рахунку для оплати банківських послуг, введення дати фактичної оплати, друк повідомлення про виконання договору, застосування штрафних санкцій у разі порушення умов договору з боку клієнта.
Старший менеджер	укладання і оновлення прайс-листа; контроль виконання договорних забов’язань з обох сторін.
Управляючий державним банком	перегляд і аналіз звітів, контроль за виконанням службових обов’язків персоналу банка.
Касир	Облік грошових коштів по оплаті договору, видача чека про введення дати на компенсацію за невчасне виконання замовлення
Управляючий Національним банком	перегляд і аналіз звітів, що терміново надаються державними банками, контроль за виконанням службових обов’язків персоналу Нацбанка, мониторить роботу державних банків, тощо.

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

• договір на виконання банківських послуг;

• рахунок про оплату банківської операції;

• касовий чек про оплату банківської операції;

• повідомлення про виконання замовлення;

• фінансові звіти за певний період (місячні, квартальні, річні) ;

• поточні звіти за певний період (місячні, квартальні, річні).
2.2 Концептуальне проектування бази даних

На основі аналізу предметної області для побудови концептуальної моделі було виділено такі сутності (табл. 2).

Таблиця 2

Визначення сутностей

Сутність	Опис сутності
Вид банківської послуги	Дані про види банківських послуг, що надаються державним банком (прайс-лист)
Клієнт	Відомості про клієнта
Менеджер	Інформація про службовця, який складає банківський договір
Договір	Відомості про вид та умови банківського договору, оплату банківської послуги і інформація про виконання договору
Банк	Інформація про реквізити державного банку, види ліцензованих банківських послуг, відповідна фінансова звітність

Встановимо зв'язки, що існують між сутностями, потужності цих зв'язків і ступінь участі в них кожній із сутностей.

1) МЕНЕДЖЕР для КЛІЄНТА оформлює банківський договір на виконання вибраного ВИДУ БАНКІВСЬКОЇ ПОСЛУГИ. Кожен клієнт в різний час може замовляти банківські послуги різних видів видань за участю різних менеджерів. На кожен вид банківської послуги може бути оформлено декілька банківських договорів різними менеджерами для різних клієнтів. Кожен менеджер може оформляти банківський договір різним клієнтам на різні види банківських послуг. Між сутностями КЛІЄНТ, МЕНЕДЖЕР і ВИД БАНКІВСЬКОЇ ПОСЛУГИ можна встановити трибічний зв'язок з потужністю «багато» з усіх боків і об'єднати їх в складену сутність ДОГОВІР.

2) ДОГОВІР укладає КЛІЄНТ. Кожному договору відповідає одне значення клієнта. Кожне значення клієнта може відповідати декільком договорам. Між сутностями КЛІЄНТ і ДОГОВІР існує зв'язок «один до багатьох».

3) ДОГОВІР складає МЕНЕДЖЕР. Кожному договору відповідає одне значення менеджера. Кожне значення менеджера може відповідати декільком договорам. Між сутностями МЕНЕДЖЕР і ДОГОВІР існує зв'язок «один до багатьох».

4) ДОГОВІР укладається у конкретному БАНКУ. Кожному договору відповідає одне значення банку. Кожне значення банку може відповідати декільком договорам. Між сутностями БАНК і ДОГОВІР існує зв'язок «один до багатьох».

5) НАЦІОНАЛЬНИЙ БАНК контролює роботу конкретного БАНКУ. Кожному державному банку відповідає одне значення НБУ. Одне значення НБУ може відповідати декільком банкам. Між сутностями НАЦІОНАЛЬНИЙ БАНК і БАНК існує зв'язок «один до багатьох».
Після визначення сутностей і зв'язків між ними може бути створена ERдіаграма, яка відображає концептуальну модель даних і характеризує уявлення користувачів про предметну область (рис. 1).

2.3 ER-діаграма концептуальної моделі БД

МЕНЕДЖЕР

*

ВИД

БАНКІВСЬКОЇ

ПОСЛУГИ

БАНК

1

*

*

*

*

КЛІЄНТ

ДОГОВІР

1

НБУ

1

Номер договора

Рисунок 1 – ER-діаграма концептуальної моделі

Атрибути сутностей визначені і описані в таблиці 3.

Таблиця 3

Атрибути сутностей

Назва сутності	Назва і тип атрибута	Стандартний домен	Розмір	Обмеження, допустимі значення і операції
МЕНЕДЖЕР	Код менеджера	Integer	4	Лічильник, ключове
	Прізвище	Char	20
	Ім'я	Char	20
	По батькові	Char	20
	Паспортні дані (складений)	Char	200
	Ідентифікаційний код	Integer	10	Маска введення
	Адреса (складений)	Char	100
	Телефон	Char	15	Маска введення
КЛІЄНТ	Код клієнта	Integer	4	Лічильник, ключове
	Найменування клієнта	Char	60
	Адреса (складений)	Char	100
	Телефон	Char	15	Маска введення
	Факс	Char	15	Маска введення
	ПІБ представника	Char	60
ВИД БАНКІВСЬКОЇ ПОСЛУГИ	Код послуги	Integer	4	Лічильник, ключове
	Найменування послуги	Char	30	Список значень
	Максимальна сума	Real	10	Грошовий тип, два знака після коми
	Валюта	Char	4
	Термін дії (днів)	Integer	3	Список значень
	Банківський відсоток	Real	14	Грошовий тип, шість знаків після коми
	Примітки	Varchar	100
ДОГОВІР	Номер договору	Integer	4	Лічильник, ключове
	Код клієнта	Integer	4	Лічильник
	Код менеджера	Integer	4	Лічильник
	Код послуги	Integer	4	Лічильник
	Дата заключення договору	Date	Короткий формат дати	Поточна дата
	Час заключення договору	Time	Короткий формат часу	Поточний час
	Сума грошова	Real	10	Грошовий тип, два знака після коми
	Валюта	Char	4
	Термін дії (днів)	Integer	3	Список значень
	Банківський відсоток	Real	14	Грошовий тип, шість знаків після коми
	Подовження договору	Char	3
	Код банку	Integer	4	Лічильник
БАНК	Код банку	Integer	4	Лічильник, ключове
	Назва банку	Char	20
	Центральне відділення/філія	Boolean	1	Логічне (0-філія, 1-центральне)
	Національний/дер-жавний банк	Boolean	1	Логічне (0-державний, 1-національний)
	ПІБ управдяючого банку (складений)	Char	60	Список значень
	Реквізіти банку (складений)	Char	100	Список значень
	Адреса (складений)	Char	100	Список значень
	Кількість ліцензованих банківських послуг	Integer	4
	Кількість співробітників	Integer	4

2.4 Проектування логічної (реляційної) моделі БД

На основі створеної ER-діаграми визначимо таблиці і їх поля.

1. Сутностям МЕНЕДЖЕР, КЛІЄНТ, ДОГОВІР, БАНК, ВИД БАНКІВСЬКОЇ ПОСЛУГИ відповідають однойменні таблиці. Поля таблиць відповідають атрибутам сутностей.

2. Трибічний зв'язок між сутностями КЛІЄНТ, МЕНЕДЖЕР, ВИД БАНКІВСЬКОЇ ПОСЛУГИ, представлений у вигляді складеної сутності ДОГОВІР, перетворюється в таблицю ДОГОВІР. Для реалізації трибічного зв'язку в таблицю ДОГОВІР включені поля Код Менеджера, Код вида банківської послуги, Код Клієнта.

3. Для реалізації зв'язку між сутностями БАНК і ДОГОВІР (потужність «один до багатьох») необхідно ключовий атрибут Код банку таблиці БАНК помістити в таблицю ДОГОВІР як зовнішній ключ.
В таблиці 4 представлено визначення первинних ключів таблиць реляційної моделі.

Таблиця 4

Ключові атрибути

Назва сутності	Потенційні ключі	Назва таблиці	Первинний ключ
Менеджер	Прізвище, паспортні дані, ідентифікаційний код, телефон	Менеджер	Код менеджера (штучний)
Клієнт	Найменування клієнта, телефон	Клієнт	Код клієнта (штучний)
Вид банківської послуги	-	Вид банківської послуги	Код банківської послуги (штучний)
Банк	Код банку, назва	Банк	Код банку
Договір	Номер договіру, назва	Договір	Номер договору

В результаті отримана реляційна схема БД:

МЕНЕДЖЕР (Код менеджера, Прізвище, Ім'я, По батькові, Паспортні дані, Ідентифікаційний код, Адреса, Телефон)

КЛІЄНТ (Код клієнта, Найменування клієнта, Адреса, Телефон, Факс, ПІБ представника)

ВИД БАНКІВСЬКОЇ ПОСЛУГИ (Код послуги, Найменування послуги, Максимальна сума, Валюта, Термін дії (днів), Банківський відсоток, Примітки).

ДОГОВІР (Номер договору, Код клієнта, Код менеджера, Код послуги, Дата заключення договору, Час заключення договору, Сума грошова договору, Валюта, Термін дії (днів), Банківський відсоток, Подовження договору, Код банку)

БАНК (Код банку, Назва банку, Центральне відділення/філія, Національний/державний банк, ПІБ управдяючого банку (складений), Реквізіти банку (складений), Адреса банку(складений), Кількість ліцензованих банківських послуг, Кількість співробітників).
Зовнішні ключі: поле «Код менеджера» посилається на таблицю МЕНЕДЖЕР, поле «Код послуги» – на таблицю ВИД БАНКІВСЬКОЇ ПОСЛУГИ, поле «Код клієнта» – на таблицю КЛІЄНТ, поле «Код банка» – на таблицю БАНК.
3. РОЗРОБКА ПРОГРАМНОГО ДОДАТКА

Програмний додаток повинен забезпечувати реалізацію бізнес-функцій. Він має включати: - форми для введення, перегляду та оновлення даних; - звіти, тобто документи, підготовлені для друку. Інтерфейс користувача реалізується у вигляді Головної кнопкової форми. Призначення та кількість форм та звітів визначаються виключно з точки зору функцій, необхідних для функціонування інформаційної системи.

Фізичну реалізацію ІБС можно виконати з використанням СУБД MS ACCESS, але нажаль в зв’язку з військовою агресією не має практичної мождивості для виконання ІБС використати ПК.

4. СТВОРЕННЯ ЗАПИТІВ

Самостійно сформулювати умови та створити наступні запити. Представити їх на мові SQL:

1. Запит на вибірку із завданням умов відбору записів.

2. Запит на вибірку із завданням умов відбору записів (за двома або більше взаємопов'язаними таблицями). Реалізувати з'єднання таблиць двома способами: за допомогою внутрішнього з'єднання та завданням умови з'єднання в команді WHERE

3. Запит із завданням умов відбору записів за допомогою параметрів.

4. Запит з обчислюваним виразом.

5. Запит із групуванням та вбудованими статистичними функціями.

6. Запит із завданням умов обробки груп.

7. Запит на створення таблиці.

8. Запит на оновлення.

9. Запит на видалення.

10. Запит на додавання.

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

скачати

© Усі права захищені
написати до нас