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

Тип работы:
Курсовая
Предмет:
Программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

КУРСОВИЙ ПРОЕКТ

по дисциплiнi «Проектування баз і сховищ даних»

на тему: «Проектування бази даних для аналізу користувачів пластикових карток в комерційних банках»

КИЇВ

Анотація

У курсовому проекті обґрунтовано вибір теми дослідження, доведено її актуальність.

Основною ідеєю створення даного проекту є полегшення роботи в процесі аналізу користувачів пластикових карток в комерційних банках. А також отримання навичок по проектуванню баз даних, роботи з сучасними case засобами та сучасними СКБД, зокрема Erwin 4.0 та Access 97.

В курсовому проекті освітлені основні питання проектування БД, описані структура предметної області, вхідні та вихідні повідомлення. Розроблено інфологічну та датологічну моделі, реалізовано БД на фізичному рівні.

Зміст

Вступ

1. Дослідження предметної області

1.1 Характеристика функціональної структури ПО

1.2 Опис вхідних повідомлень

1.3 Опис вихідних повідомлень

1.4 Опис основних процедур перетворення даних

2. Розробка інфологічної моделі

3. Розробка даталогічної моделі

4. Проектування та реалізація БД на фізичному рівні

Висновки

Список використаної літератури

Додатки

Вступ

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

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

1. Дослідження предметної області

1.1 Характеристика функціональної структури ПО

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

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

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

Банк-емітент — установа банку, яка випускає в обіг платіжні картки.

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

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

Схему взаємодії учасників платіжної системи з використанням пластикових карток наведено на рис.

Рис 1. — Схема взаємодії учасників карткового проекту

1 -- оформлення і видача картки клієнту;

2 -- надання картки для оформлення покупки чи оплати послуг;

3−4 -- запит на авторизацію;

5−6 -- результати авторизації;

7 -- передача товару та чека на нього власнику картки;

8 -- передача чеків на куплені товари;

9 -- зарахування коштів за куплені товари на рахунок торговельного закладу;

10--13 -- розрахунки банка-емітента з банком-еквайром за проведені трансакції;

14 -- надання виписки про проведені трансакції;

15 -- розрахунки власника картки з банком-емітентом.

Пластикові картки підрозділяються на дебетові і кредитні.

Кредитні картки дають змогу отримувати кредит під час купівлі товарів чи оплати певних послуг, а також отримувати готівкову позику. Кредитні картки бувають банківськими чи картками туризму та розваг. Кредитна картка — це картка з PIN-кодом.

Банківські кредитні картки використовуються для оплати за товари чи певні послуги з використанням банківського кредиту чи для отримання авансу у готівковій формі. Клієнт користується кредитом без сплати відсотків протягом 4−8 тижнів. Крім того, за бажанням він може продовжити термін кредиту за межі пільгового періоду, сплачуючи в такому разі відсотки. При цьому банком встановлюється ліміт овердрафту, а також може встановлюватись ліміт на суму одноразової витрати.

Кредитні картки видаються платоспроможним клієнтам. Вони бувають індивідуальними та корпоративними. Індивідуальні картки поділяються на стандартні та золоті. Золоті картки надаються лише клієнтам з високим і стабільним рівнем доходів.

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

Дебетні картки можуть використовуватись для:

отримання готівки через банкомат;

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

сплати за послуги чи товари в торговельних закладах.

1.2 Опис вхідних повідомлень

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

Таблиця № 1

Назва вхідного повідомлення

Ідентифікатор

Форма подання

Термін і частота надходження

Джерело

Договір

Dogovor

Первинний документ

За потребою

Клієнт

Анкета

Anketa

Первинний документ

За потребою

Клієнт

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

1.3 Опис вихідних повідомлень

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

Виходячи з функціональних задач, можна виділити такі вихідні повідомлення:

Найактивніший клієнт (сума вкладу > 300 грн., а сума зняття > 200 грн.). Дає змогу серед усіх клієнтів, виділи тих, які активно використовують пластикову картку. Для таких VIP клієнтів можна застосувати спеціальні умову.

Популярна пластикова картка (клієнти, які є власниками пластикової картки VISA Classic).

Прогресія росту клієнтів в 2004 році порівняно з минулими роками. (клієнти, які уклали договір, для одержання пластикової картки, протягом 2004 року).

Перехід від дебетової до кредитної пластикової картки (клієнти, які є власниками дебетової пластикової картки та активно її використовують).

1.4 Опис основних процедур перетворення даних

Атрибут залишок коштів буде розрахунковим, обчислюється він такими формулами:

1) при перерахуванні коштів на картку.

2) при знятті коштів з картки.

2. Розробка інфологічної моделі

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

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

В результатi дослiдження предметної областi в першому роздiлi курсового проекту був виявлений наступний перелiк атрибутів, що пiдлягають збереженню в БД:

Код виду картки

Назва виду картки

Ідентифікаційний номер клієнта

№ договору

Дата підписання договору

Дата закінчення договору

Код організації

Назва організації

Адреса організації

ПІБ клієнта

Код назви картки

Назва картки

Код типу операції

Тип операції

№ картки

Дата та час операції

Сума операції

Дата видачі картки

Дата по яку діє картка

Дата (поточна)

Залишок

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

На другому етапi виконується агрегацiя атрибутiв в об'єкти — деякi сутностi реального свiту, що мають сенс з точки зору предметної областi: процес, поняття i т.д. Видiлення об'єктiв виконується на основi аналiза вiдношень мiж атрибутами. Якщо серед них є такi, що знаходяться в спiввiдношеннi 1: 1, то вони агрегуються в один iнформацiйний об'єкт, якому надається унiкальне iм’я. Пiсля багаторазового виконання цієї операції, в перелiку атрибутiв залишаться такi, що не належать нi одному iз створених об'єктів. Цi атрибути аналiзуються на тип спiввiдношення 1: Б, але вже з видiленими об'єктами. Якщо пiсля цього знов залишились атрибути, не приєднанi нi до одного з об'єктiв, то доцiльно провести до обстеження предметної областi для поповнення перелiку атрибутiв.

На другому етапі були сформовані такі інформаційні об'єкти:

Клієнт

ПІБ клієнта

Ідентифікаційний номер клієнта

Код організації

Організація

Код організації

Назва організації

Адреса організації

Договір

Ідентифікаційний номер клієнта

№ договору

Дата підписання договору

Дата закінчення договору

Пластикова картка

№ договору

№ картки

Код назви картки

Код виду картки

Дата видачі картки

Дата по яку діє картка

Вид картки

Код виду картки

Назва виду картки

Назва картки

Код назви картки

Назва картки

Типи операцій

Код типу операції

Тип операції

Операції

№ картки

Дата та час операції

Сума операції

Код типу операції

Залишок

№ картки

Дата

Залишок

На третьому етапi iнфологiчного проектування необхiдно перевiрити створеннi iнформацiйнi об'єкти на виконання умов нормалізації та привести їх до 3-ї або 4-ї нормальної форми.

Iнформацiйний об'єкт знаходиться в 1-й нормальнiй формi, якщо усi атрибути атомарнi (неподiльнi).

Об'єкт у 2НФ не повинен мiстити неповних функцiональних залежностей. Якщо такi залежностi присутнi, то необхiдно виконати декомпозицiю об'єкта з метою їх усунення.

На третьому кроцi нормалiзацiї проводиться аналiз на наявнiсть транзитивних залежностей (мiж неключовими атрибутами). Якщо транзитивна залежнiсть iснує, необхiдно роздiлити об'єкт так, щоб усi його атрибути напряму залежали вiд первинного ключа. Цей крок приведе об'єкт до 3НФ.

Щоб привести об'єкт до 4НФ потрiбно проаналiзувати його на присутнiсть багатозначних залежностей i, якщо вони є, вилучити iх шляхом декомпозиції.

В результатi видiлення iнформацiйних об'єктiв та операцiй нормалiзацiї, отримуємо наступнi вiдношення, якi знаходяться в 3НФ або 4НФ.

Клієнт

ПІБ клієнта *

Ідентифікаційний номер клієнта

Код організації

Організація

Код організації *

Назва організації

Адреса організації

Договір

Ідентифікаційний номер клієнта *

№ договору

Дата підписання договору

Дата закінчення договору

Пластикова картка

№ договору *

№ картки

Код назви картки

Код виду картки

Дата видачі картки

Дата по яку діє картка

Вид картки

Код виду картки *

Назва виду картки

Назва картки

Код назви картки *

Назва картки

Операції

№ картки *

Дата та час операції *

Сума операції

Код типу операції

Типи операцій

Код типу операції *

Тип операції

Залишки

№ картки *

Дата та час

Залишок

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

П’ятий крок. Формалізований опис інформаційних запитів у вигляді запитувальних зв’язків.

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

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

Видати список клієнтів, в яких сума вкладу > 300 грн., а сума зняття > 200 грн.

ПІБ

№ картки

Сума вкладу

Сума зняття

Видати інформацію по залишкам на пластикових картках.

№ картки

Назва виду картки

Дата та час

Залишок

Видати список клієнтів, які є власниками пластикової картки VISA Classic

ПІБ

Назва картки

Видати список клієнтів, які уклали договір, для одержання пластикової картки, протягом 2004 року.

ПІБ

№ договору

Дата підписання договору

Видати список клієнтів, які є власниками кредитної пластикової картки на яку загальна сума вкладу перевищувала 300 грн.

ПІБ

№ договору

Дата підписання договору

Шостий крок. На даному кроці проводиться аналіз і зведення запитувальних зв’язків до канонічного вигляду (всі відношення повинні бути 1:1 чи Б: Б). Якщо умова канонічності не виконується, необхідно скористатися правилами перетворення запитувальних зв’язків.

Перетворення 1.

Нехай співвідношення між початковими об'єктами 1: Б, тоді запитувальний зв’язок необхідно перетворити на тотожний ланцюжок запитувальних зв’язків:

Zy x1, x2,…xn = Zx1x2 Z yx2, x3, … xn

Перетворення 2.

Нехай існує багатовимірний запитувальний зв’язок, співвідношення якого між початковим і кінцевим об'єктами 1: Б, тоді потрібно виконати перетворення:

Z yx1, x2,… xn = Z yx2, x3, … xnZx1y

Перетворення 3.

Співвідношення між початковим і кінцевим об'єктами Б: 1, тоді потрібно перетворити запитувальний зв’язок:

Z yx1, x2,… xn = Zx1y Z x2x1, x3,… xn

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

Сьомий крок. Побудова структурних зв’язків і графічне зображення інфологічної моделі.

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

Структурний зв’язок — це графічне представлення інфологічної моделі. Таке представлення базується на аналізі запитувальних зв’язків і на правилах побудови структурних зв’язків.

Правило 1

Правило 2

Правило 3

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

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

Для графічного відображення моделі даних будемо використовувати модель Чена. Дану модель побудуємо за допомогою Case засобу Erwin. Erwin — це дуже зручний засіб для проектування баз даних, оскільки він дозволяє проводити як інжирінг так і реінжирінг. Case засіб Erwin автоматизує розробку бази даних.

В Erwin існує два рівня представлення і моделювання баз даних: логічний і фізичний. Для початку будемо працювати з логічним (інфологічним) рівнем. За допомогою графічних інструментів створюємо сутності (інформаційні об'єкти). Також надається можливість описувати сутності.

Далі заповнюємо створені сутності атрибутами. На цьому кроці вказуємо ключі. Тут же ми конкретизуємо домен — тобто обираємо відповідні типи даних для кожного атрибута.

Erwin підтримує такі типи даних:

? < unknown> - невизначений

Blob — великий двійковий об'єкт

Datetime — датачас

Number — число

String — стрічка

Після того як сутності заповнили атрибутами, встановлюємо зв’язки між ними. В Erwin використовуються чотири типи зв’язків:

— ідентифікуючий;

— зв'зок Б: Б;

— неідинтифікуючий;

— категоріальний;

Використаємо неідинтифікуючі обов’язкові зв’язки. В результаті встановлення зв’язків отримаємо граф інфологічної моделі, який буде мати такий вигляд:

Рис. 2. Граф інфологічної моделі, побудований Case засобом Erwin

Граф інфологічної моделі є метою інфологічного проектування. Опис складових інфологічної моделі можна записати у вигляді таблиці-звіту. Erwin дозволяє автоматизувати процес створення такого звіту.

За допомогою майстра генерації звітів побудуємо звіт (Tools Report Builder Report Builder…). Звіт може бути виконаний у таких форматах: NONE, RTF, TEXT, HTML.

Створимо звіт у ТЕХТ форматі. Таблиця № 2

Table

Name

Column

Name

Column Datatype

Column Null Option

Column

Is PK

Column

Is FK

Вид картки

Код виду картки

Long Integer

NOT NULL

Yes

No

Вид картки

Назва виду картки

Text (20)

NULL

No

No

Договір

№ договору

Long Integer

NULL

Yes

No

Договір

Дата підписання договору

Date/Time

NULL

No

No

Договір

Дата закінчення договору

Date/Time

NULL

No

No

Договір

Ідентифікаційний номер клієнта

Long Integer

NOT NULL

No

Yes

Клієнт

Ідентифікаційний номер клієнта

Long Integer

NOT NULL

Yes

No

Клієнт

ПІБ

Text (20)

NULL

No

No

Клієнт

Код організації

Long Integer

NOT NULL

No

Yes

Назва картки

Код назви картки

Long Integer

NOT NULL

Yes

No

Назва картки

Назва картки

Text (20)

NULL

No

No

Операції

№ картки

Long Integer

NOT NULL

Yes

Yes

Операції

Сума операції

Currency

NULL

No

No

Операції

Дата операції

Date/Time

NULL

No

No

Операції

Код типу операції

Long Integer

NOT NULL

No

Yes

Організація

Код організації

Long Integer

NULL

Yes

No

Організація

Назва організації

Text (20)

NULL

No

No

Пластикова картка

№ картки

Long Integer

NULL

Yes

No

Пластикова картка

№ договору

Long Integer

NOT NULL

No

Yes

Пластикова картка

Код виду картки

Long Integer

NOT NULL

No

Yes

Пластикова картка

Код назви картки

Long Integer

NOT NULL

No

Yes

Пластикова картка

Дата видачі картки

Date/Time

NULL

No

No

Пластикова картка

Дата по яку діє картка

Date/Time

NULL

No

No

Типи операцій

Код типу операції

Long Integer

NOT NULL

Yes

No

Типи операцій

Тип операції

Text (20)

NULL

No

No

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

3. Розробка даталогічної моделі

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

тип логічної моделі, що його підтримує вибрана СКБД;

особливості фізичної організації даних у середовищі вибраної СКБД;

кількісні обмеження, які накладає СКБД;

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

СКБД Access 97 підтримує реляційну модель БД і працює в середовищі Windows. Access може використовуватись в локальних обчилю валь них мережах і вона має механізм підтримки реплікацій. У Access 97 усі відомості, що стосуються певної предметної області, подаються у вигляді сукупності пов’язаних між собою таблиць і на фізичному рівні зберігаються в одному файлі з розширенням — mdb. У цьому самому файлі разом з таблицями зберігаються всі інструментальні засоби для роботи з ними (форми, запити, макроси і модулі). База даних у середовищі Access 97 — це сукупність пов’язаних між собою таблиць, які належать до однієї теми чи предметної області, та інструментальних засобів роботи з ними.

В даній СКБД є механізм, за допомогою якого можна виконати перевірку відношень на відповідність їх умовам нормалізації. Можливий імпорт даних із інших СКБД таких як Dbase, Clipper, FoxPro. Також дозволяється експорт в перераховані системи.

СКБД Access має засоби адміністрування БД та захисту від несанкціонованого доступу, засоби відновлення БД у випадку їх зруйнування.

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

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

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

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

Access 97 має в своєму арсеналі деякі засоби захисту інформації. У меню Access 97 є спеціальна команда для відновлення БД. Якщо за допомогою цієї команди не вдалося відновити втрачених даних, то необхідно скористатися останнього страховою (резервною) копією.

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

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

Необхідно перевірити виконання таких умов:

усі атрибути повинні бути атомарними, тобто неподільними;

відношення не повинно мати дублюючих рядків і стовпчиків;

усі атрибути у відношенні повинні мати унікальні імена;

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

Для відображення інфологічної моделі на даталогічну модель, слід знову повернутися до case засобу Erwin. Розроблену інфологічну модель слід перетворити у фізичний рівень. У сутностях, сформованих на інфологічному рівні, відбудуться зміни. Напроти кожного атрибута сутностей з’явиться його тип даних.

Рис. 3. Фізичний рівень, орієнтований на СКБД Access

За допомогою Erwin підрахуємо розмір майбутньої бази. Обов’язково потрібно зазначити початкову кількість записів, максимальну кількість записів і зростання записів за місяць. Це треба виконати по кожній таблиці. В результаті отримаємо такі дані про обсяг бази даних через 6 місяців.

Рис. 4

Рис. 5

В Erwin настроїмо опції передачі моделі в Access 97. Після цього необхідно створити в Access 97 пусту базу даних та настроїти панель управління. Фізична модель бази даних готова до генерації з Erwin в Access 97.

Після генерації розкриємо схему даних в Access 97 і проаналізуємо чи передача моделі відбулася без помилок.

Рис. 6

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

Тепер потрібно переходити до фізичного проектування.

Рис. 7. Схема даних в Access 97

4. Проектування та реалізація БД на фізичному рівні

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

Проектування та реалізація бази даних здійснена за допомогою СУБД Access 97. Створена база даних містить такі таблиці:

Клієнт

Організація

Договір

Пластикова картка

Вид картки

Назва картки

Типи операцій

Операції

Опис цих таблиць наведено у додатку. Для зручності роботи з цими таблицями створені форми: «Головне меню» (форма, за допомогою якої краще вести базу даних).

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

Видати список клієнтів, в яких сума вкладу > 300 грн., а сума зняття > 200 грн.

Видати інформацію по залишкам на пластикових картках.

Видати список клієнтів, які є власниками пластикової картки VISA Classic

Видати список клієнтів, які уклали договір, для одержання пластикової картки, протягом 2004 року.

Видати список клієнтів, які є власниками кредитної пластикової картки на яку загальна сума вкладу перевищувала 300 грн.

Для надання більшої наочності запитам створені звіти, які побудовані на основі відповідних запитів.

Форми, запити та звіти та наведені у додатках.

база дані аcess платіжний

Висновки

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

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

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

Створення БД забезпечує:

ь обробку великого обсягу даних, яка зберігається в БД;

ь підвищення швидкості опрацювання інформації;

ь скорочення часу на розв’язання певної задачі;

ь підвищену достовірність даних при розв’язанні певної задачі;

ь підвищення ефективності роботи,

ь формування та друкування необхідних документів,

Список використаної літератури

Єрьоміна Н.В. — Проектування баз даних: Навчальний посібник. — К.: КНЕУ, 1998. — 208 с.

Єрьоміна Н.В. — Банківські інформаційні системи: Навчальний посібник. — К.: КНЕУ, 2000. — 220 с.

Рогач І.Ф., Сендзюк М. А., Антонюк В. А. — Інформаційні системи у фінансово кредитних установах: Навчальний посібник. — 2-ге вид., перероб. І доп. — К. :КНЕУ, 2001. — 239с.

Закон України — «Про платіжні системи та переказ грошей в Україні» (Відомості Верховної Ради, 2001, N 29, ст. 137)

Додатки

1. Відомість суми залишку на рахунку клієнта станом на ________

Дата та час

ПІБ

№ картки

Сума залишку

2. Відомість здійснених операцій клієнтом станом на __________

ПІБ

№ картки

Дата та час операції

Тип операції

Сума операції

1. Таблиця — «Клієнт»

ПІБ

Ідентифікаційний номер клієнта

Код організації

Андросенко А.Г.

10 012

11

Бабій В.В.

10 030

16

Гай .А.В.

10 029

18

Гафич О.І.

10 025

16

Кагамлик Ю.В.

10 020

15

Кириченко А.П.

10 026

17

Кіф'як Н.П.

10 018

13

Кривонос Є.О.

10 023

14

Курило Р.Л.

10 028

19

Лагно Н.Л.

10 017

11

Ланчак В.Д.

10 021

10

Літвінова Н.В.

10 019

14

Обуховький Я.Ю.

10 014

12

Платонов Д.Д.

10 016

15

Святецька В.В.

10 022

13

Скоробогата К.Ю.

10 011

10

Скоробогатий В.Ю.

10 010

10

Ус Р.І.

10 027

20

Усатенко О.І.

10 024

15

Чегусов В.В.

10 015

14

Широбокова Я.О.

10 013

13

2. Таблиця — «Організація»

Код організації

Назва організації

Адреса

10

ТОВ «Мрія»

вул. Красикова 6

11

ЗАТ «ТОРГМАШ»

вул. Кудряшова 20

12

фірма «Оріон»

вул. Басейна 34

13

фірма «Максі-Віта»

пр-кт Перемоги 102

14

ТОВ «Швидко»

вул. Нагірна 5, 4 поверх, офіс 5

15

фірма «DTK»

пров. Сафроновський 34

16

ЗАТ «Більшовик»

вул. Салютна 9

17

фірма «Samsung»

пл. Слави 21

18

фірма «Sven»

пров. Салютний

19

ТОВ «Ростикс»

пл. Тараса Шевченка

20

фірма «Toshibs»

вул. Чорнобильська

3. Таблиця — «Договір»

Ідентифікаційний номер клієнта

№ договору

Дата підписання договору

I. Дата закінчення договору

10 016

130

11. 02. 2002

11. 02. 2012

10 029

195

03. 04. 2002

03. 04. 2012

10 017

135

22. 05. 2002

22. 05. 2012

10 012

115

23. 05. 2002

23. 05. 2012

10 027

185

05. 06. 2002

05. 06. 2012

10 020

150

09. 09. 2002

09. 09. 2012

10 018

140

01. 01. 2003

01. 01. 2013

10 024

170

05. 09. 2003

05. 09. 2013

10 019

145

04. 10. 2003

04. 10. 2013

10 014

120

06. 10. 2003

06. 10. 2013

10 030

200

09. 10. 2003

09. 10. 2013

10 011

105

15. 10. 2003

15. 10. 2013

10 021

155

10. 11. 2003

10. 11. 2013

10 022

160

12. 11. 2003

12. 11. 2013

10 010

100

10. 12. 2003

10. 12. 2013

10 028

190

13. 12. 2003

13. 12. 2013

10 026

180

21. 02. 2004

21. 02. 2014

10 023

165

01. 04. 2004

01. 04. 2014

10 013

110

03. 04. 2004

03. 04. 2014

10 025

175

10. 04. 2004

10. 04. 2014

10 015

125

03. 09. 2004

03. 09. 2014

4. Таблиця — «Пластикова картка»

№ договору

№ картки

Код назви картки

Код виду картки

Дата видачі картки

Дата по яку діє картка

100

123 122 121

1

1

15. 12. 2003

15. 12. 2006

100

123 122 129

6

2

01. 01. 2004

01. 01. 2007

100

123 122 122

3

1

03. 03. 2004

03. 03. 2007

105

123 122 123

2

1

20. 10. 2003

20. 10. 2006

110

123 122 125

3

2

07. 04. 2004

07. 04. 2007

115

123 122 127

4

1

30. 05. 2002

30. 05. 2005

120

123 122 128

5

2

10. 10. 2003

10. 10. 2006

125

123 122 130

1

3

11. 09. 2004

11. 09. 2007

130

123 122 132

2

1

13. 02. 2002

13. 02. 2005

135

123 122 133

3

2

26. 05. 2002

26. 05. 2005

135

123 122 135

1

1

30. 06. 2002

30. 06. 2005

140

123 122 136

6

1

07. 01. 2003

07. 01. 2006

145

123 122 139

5

1

10. 10. 2003

10. 10. 2006

150

123 122 140

4

1

03. 09. 2002

03. 09. 2005

155

123 122 142

3

1

14. 11. 2003

14. 11. 2006

155

123 122 144

6

2

12. 12. 2003

12. 12. 2006

160

123 122 145

2

2

17. 11. 2003

17. 11. 2006

165

123 122 146

3

1

05. 04. 2004

05. 04. 2007

170

123 122 150

1

1

10. 09. 2003

10. 09. 2006

175

123 122 153

2

2

16. 04. 2004

16. 04. 2007

180

123 122 157

1

1

28. 02. 2004

28. 02. 2007

180

123 122 158

4

1

05. 04. 2004

05. 04. 2007

185

123 122 159

1

2

10. 06. 2002

10. 06. 2005

190

123 122 160

2

1

17. 12. 2003

17. 12. 2006

195

123 122 161

6

1

09. 04. 2002

09. 04. 2005

200

123 122 163

5

2

14. 10. 2003

14. 10. 2006

200

123 122 164

1

1

20. 11. 2003

20. 11. 2006

5. Таблиця — «Вид картки»

Код виду картки

Назва виду картки

1

Депозитна

2

Кредитна

6. Таблиця — «Назва картки

Код назви картки

Назва картки

1

VISA Classic

2

VISA Electron

3

VISA Classic Domestic

4

VISA Electron Domestic

5

Cirrus-Maestro

6

MasterCard Mass

7. Таблиця — «Типи операцій

Код типу операції

Тип операції

1

Вклад

2

Зняття

8. Таблиця — «Операції»

№ картки

Дата та час операції

Сума операції

Код типу операції

123 122 121

12. 01. 2004 12: 21:31

100,00 грн.

1

123 122 121

12. 01. 2004 15: 28:23

640,00 грн.

1

123 122 121

21. 02. 2004 15: 28:09

500,00 грн.

2

123 122 121

09. 03. 2004 21: 20:04

210,00 грн.

1

123 122 122

11. 03. 2004 22: 12:32

321,00 грн.

1

123 122 122

11. 03. 2004 22: 13:32

123,00 грн.

1

123 122 122

12. 03. 2004 9: 04:14

422,00 грн.

2

123 122 123

20. 10. 2003 21: 12:34

451,00 грн.

2

123 122 123

21. 10. 2003 21: 12:34

3 121,00 грн.

1

123 122 125

17. 04. 2004 12: 31:31

4 123,00 грн.

1

123 122 127

12. 03. 2003 15: 28:23

123,00 грн.

1

123 122 128

12. 10. 2003 17: 22:23

221,00 грн.

2

123 122 129

09. 03. 2004 21: 20:04

319,00 грн.

1

123 122 129

12. 04. 2004 21: 26:12

155,00 грн.

2

123 122 130

11. 09. 2004 21: 20:04

213,00 грн.

2

123 122 136

11. 01. 2003 14: 28:09

521,00 грн.

1

123 122 140

17. 09. 2002 23: 21:12

86,00 грн.

1

123 122 144

20. 12. 2003 12: 21:25

123,00 грн.

2

123 122 150

01. 10. 2003 11: 22:34

123,00 грн.

1

123 122 161

11. 05. 2002 18: 23:13

1 234,00 грн.

1

123 122 163

25. 11. 2003 22: 12:33

31,00 грн.

2

ПоказатьСвернуть
Заполнить форму текущей работой