Размещено на http://www.allbest.ru/

1

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

по дисципл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. Таблиця - “Клієнт”

ПІБ	Ідентифікаційний номер клієнта	Код організації
Андросенко А.Г.	10012	11
Бабій В.В.	10030	16
Гай .А.В.	10029	18
Гафич О.І.	10025	16
Кагамлик Ю.В.	10020	15
Кириченко А.П.	10026	17
Кіф'як Н.П.	10018	13
Кривонос Є.О.	10023	14
Курило Р.Л.	10028	19
Лагно Н.Л.	10017	11
Ланчак В.Д.	10021	10
Літвінова Н.В.	10019	14
Обуховький Я.Ю.	10014	12
Платонов Д.Д.	10016	15
Святецька В.В.	10022	13
Скоробогата К.Ю.	10011	10
Скоробогатий В.Ю.	10010	10
Ус Р.І.	10027	20
Усатенко О.І.	10024	15
Чегусов В.В.	10015	14
Широбокова Я.О.	10013	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. Дата закінчення договору
10016	130	11.02.2002	11.02.2012
10029	195	03.04.2002	03.04.2012
10017	135	22.05.2002	22.05.2012
10012	115	23.05.2002	23.05.2012
10027	185	05.06.2002	05.06.2012
10020	150	09.09.2002	09.09.2012
10018	140	01.01.2003	01.01.2013
10024	170	05.09.2003	05.09.2013
10019	145	04.10.2003	04.10.2013
10014	120	06.10.2003	06.10.2013
10030	200	09.10.2003	09.10.2013
10011	105	15.10.2003	15.10.2013
10021	155	10.11.2003	10.11.2013
10022	160	12.11.2003	12.11.2013
10010	100	10.12.2003	10.12.2013
10028	190	13.12.2003	13.12.2013
10026	180	21.02.2004	21.02.2014
10023	165	01.04.2004	01.04.2014
10013	110	03.04.2004	03.04.2014
10025	175	10.04.2004	10.04.2014
10015	125	03.09.2004	03.09.2014

4. Таблиця - “Пластикова картка”

№ договору	№ картки	Код назви картки	Код виду картки	Дата видачі картки	Дата по яку діє картка
100	123122121	1	1	15.12.2003	15.12.2006
100	123122129	6	2	01.01.2004	01.01.2007
100	123122122	3	1	03.03.2004	03.03.2007
105	123122123	2	1	20.10.2003	20.10.2006
110	123122125	3	2	07.04.2004	07.04.2007
115	123122127	4	1	30.05.2002	30.05.2005
120	123122128	5	2	10.10.2003	10.10.2006
125	123122130	1	3	11.09.2004	11.09.2007
130	123122132	2	1	13.02.2002	13.02.2005
135	123122133	3	2	26.05.2002	26.05.2005
135	123122135	1	1	30.06.2002	30.06.2005
140	123122136	6	1	07.01.2003	07.01.2006
145	123122139	5	1	10.10.2003	10.10.2006
150	123122140	4	1	03.09.2002	03.09.2005
155	123122142	3	1	14.11.2003	14.11.2006
155	123122144	6	2	12.12.2003	12.12.2006
160	123122145	2	2	17.11.2003	17.11.2006
165	123122146	3	1	05.04.2004	05.04.2007
170	123122150	1	1	10.09.2003	10.09.2006
175	123122153	2	2	16.04.2004	16.04.2007
180	123122157	1	1	28.02.2004	28.02.2007
180	123122158	4	1	05.04.2004	05.04.2007
185	123122159	1	2	10.06.2002	10.06.2005
190	123122160	2	1	17.12.2003	17.12.2006
195	123122161	6	1	09.04.2002	09.04.2005
200	123122163	5	2	14.10.2003	14.10.2006
200	123122164	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. Таблиця - “Операції”

№ картки	Дата та час операції	Сума операції	Код типу операції
123122121	12.01.2004 12:21:31	100,00 грн.	1
123122121	12.01.2004 15:28:23	640,00 грн.	1
123122121	21.02.2004 15:28:09	500,00 грн.	2
123122121	09.03.2004 21:20:04	210,00 грн.	1
123122122	11.03.2004 22:12:32	321,00 грн.	1
123122122	11.03.2004 22:13:32	123,00 грн.	1
123122122	12.03.2004 9:04:14	422,00 грн.	2
123122123	20.10.2003 21:12:34	451,00 грн.	2
123122123	21.10.2003 21:12:34	3 121,00 грн.	1
123122125	17.04.2004 12:31:31	4 123,00 грн.	1
123122127	12.03.2003 15:28:23	123,00 грн.	1
123122128	12.10.2003 17:22:23	221,00 грн.	2
123122129	09.03.2004 21:20:04	319,00 грн.	1
123122129	12.04.2004 21:26:12	155,00 грн.	2
123122130	11.09.2004 21:20:04	213,00 грн.	2
123122136	11.01.2003 14:28:09	521,00 грн.	1
123122140	17.09.2002 23:21:12	86,00 грн.	1
123122144	20.12.2003 12:21:25	123,00 грн.	2
123122150	01.10.2003 11:22:34	123,00 грн.	1
123122161	11.05.2002 18:23:13	1 234,00 грн.	1
123122163	25.11.2003 22:12:33	31,00 грн.	2

Размещено на Allbest.ru