Contents

INTRODUCTION........................................................................................................... 2
USER REQUIREMENTS:................................................................................................ 3
DATABASE DESIGN:..................................................................................................... 4
CREATING THE DATABASE........................................................................................... 7
DATABSE ACCESS....................................................................................................... 8
GUI............................................................................................................................. 9
CONCLUSIONS.......................................................................................................... 16
FUTURE SCOPE......................................................................................................... 17
REFERENCES:........................................................................................................... 17

BANKING DATABASE MANAGEMENT SYSTEM

INTRODUCTION
Banking databases involve a large amount of information that needs to be
updated or modified very frequently with every transaction made or every
new customer added. Designing such a database system with proper
relations

between

each

entities

is

very

important

for

the

proper

implementation of the system. Apart from handling of the data, data analysis
is also becoming increasingly significant in the current scenario.
With the introduction of credit score system bank managers are now
interested in analyzing the spending pattern of the account holders to decide
their credit scores. These credit scores are used to decide the interest rates
given to the customers on their credit cards or loan rates. The customers are
also interested in their spending patterns so that they can understand how to
balance their spendings to improve their credit score.
The banking systems these days are required to calculate the credit scores
using a complex set of calculations. Such a decision support system takes in
to account many factors to calculate the credit score. This application is
based upon a similar system by making use of the number of transactions a
customer makes and their current balance the account. The score calculated
is termed as credit points. The banker can use this credit points of the
customer to make decision on the loan value he/she is eligible for the
customer.

BANKING DATABASE MANAGEMENT SYSTEM

BANKING DATABASE MANAGEMENT SYSTEM

USER REQUIREMENTS:
The application is designed as an entry level banking database management
system with controls for both the customer and the banker. A user is required
to input the correct combination of ID and password to access the system.
The customer and banker has different levels of access. The banker has
control over almost the entire system whereas the customers control is
limited to his/her account.
The customer on clicking on the start image in the welcome page is asked for
his account number and password. The customer is given the option of
checking his balance and his transaction pattern.
For the banker the application allows him to have control over all
functionalities. The banker can make additions to the customer database, or
modify the data of any customer. Apart from that the banker should be able
to make transaction for a particular customer and the transaction should be
stored in the database along with the ID of the banker. The application
should enable the banker to look the transaction pattern for any customer
account with graphs.
This application should also incorporate a decision support system where it
helps the banker in deciding the eligible loan amount for an account holder.
This can be done using the number transactions made by the customer and
his account balance level.

BANKING DATABASE MANAGEMENT SYSTEM

DATABASE DESIGN:
CONCEPTUAL DESIGN

The design of the database system consisting all the entities and attributes
is shown in figure 1. The diagram is an enhanced entity relationship diagram
as it contains super classes and sub classes. While developing the physical
database, this diagram was refers to as the base of the database model.

Figure 1: Enhanced ER Diagram

BANKING DATABASE MANAGEMENT SYSTEM

Cardinalities:
1)
2)
3)

Every customer can view his or her one or multiple accounts.

An account can be owned by one and only one account.
A banker makes the transaction and transaction is an associative

4)
5)

entity.
Banker can make transactions for multiple accounts.
An account can have one or more transactions made by multiple

6)

bankers.
Employee is a superclass which has two complete disjoint sub class
banker and non-banker.

The super class employees has two complete-disjoint sub classes; banker
and non-banker. The relation transaction is made an associate entity. This
makes it possible to keep track of each transaction made by any banker for a
given account number.
Assumptions:
For the efficient working of the system a few assumptions were made. They
are
1)
2)

Transactions are made by the banker only

Customers and non-bankers do not have access to parts handled by

3)

banker.
A customer can view only one account owned by him/her at a given
time. The login ID for the customer is, therefore, account number.

LOGICAL DESIGN:
The relational database model involves the use of tables as relations with
fields in the tables defining the attributes of each relation. Figure 2 shows the

BANKING DATABASE MANAGEMENT SYSTEM

logical layout of the banking database along with the connection between
relations using foreign keys.
Customer
FIRS
T
NAM
E

LAS
T
NAM
E

C_I
D

PAS
SWOR
D

ID
TY
PE

ID_N
O

ADDR
ESS

PH.N
O.

E-MAIL
ID

Accounts
AC. NO.

AC.
TYPE

C_ID

BALANCE

REWARD POINTS

Transactions
TRANSACTIO
N_ID

EMP_I
D

AC.
NO.

DAT
E

TYPE OF
TRANSACTION

AMOUNT

Banker
EMP_ID

PASSWORD

Non-Bankers
EMP_ID

POSITION

Employees
EMP_ID

FIRST NAME

LAST NAME

SSN

PH. NO.

ADDR
ESS

Figure 2: Tables in the banking database with their fields

BANKING DATABASE MANAGEMENT SYSTEM

All the primary keys in each table is underlined. Other than the primary keys
there are foreign keys that the tables account, transaction, banker, nonbanker have which are referred from other tables in the database. Since such
systems are required to generate the instance identifiers automatically some
of the primary keys were generated by the database itself. The primary keys
like transaction_ID, C_ID, AC.NO were defined as auto increment. This meant
that whenever a new record was added to the tables containing these
attributes

as

primary keys, the attributes

on auto-increment

would

automatically be saved as a number with value more than the value in

previous record by 1.

CREATING THE DATABASE

Since the system is created for a fictitious bank the data had to be
generated. The customer database was obtained from the internet with fake
credentials. These data was inserted in to an excel document and saved as
.csv file. The MySQL workbench was used to import the data in the csv files
in to the banking database. The other data tables were populated by us
manually using the import csv file function of the workbench. This helped us
to insert large number of records in to the SQL tables quickly.
Once the tables were created and populated with the required data queries
were run on workbench to check for the correct retrieval of data. These
tested queries were then embedded in the VBA script later to get data from
SQL to excel.

BANKING DATABASE MANAGEMENT SYSTEM

Figure 3. Description of
Customer Table

Figure 4. Description of
Account table

Figure 5. Description of
Employee table

Figure 6. Description of
Transaction table

BANKING DATABASE MANAGEMENT SYSTEM

Figure 7. Description of nonbanker table

Figure 7. Description of banker

table

DATABSE ACCESS
Figure 3 shows how the data is retrieved from the SQL database to display in
the VBA GUI or in excel sheets. For viewing of customer information the data
is retrieved and stored in a hidden excel sheet during form initialization.
Once the search criteria has been entered in the form and the enter
command button is clicked the required filter is applied to the excel sheet
and the sheet is made visible. However, for other searches like transaction
query, balance check, transaction queries are dynamically retrieved from the
database according the data entered in the forms.

DATA IN CSV
FILE

SQL DB TABLES

DISPLAY
REQUIRED DATA
IN VBA FORMS
OR EXCEL
SHEETS

STORE
REQUIRED DATA
IN EXCEL
SHEEETS

BANKING DATABASE MANAGEMENT SYSTEM

Figure 8. Flow of data from SQL to Excel

For retrieving the data from SQL the ADODB connection is made to the right
database in SQL, the appropriate SQL query is executed. The data returned is
stored in a recordset and the values in the recordset is stored in the
respective excel worksheet one by one.

GUI
The user interface was created using a mixture of both user forms in VBA
and excel worksheets. The user forms are used for entering data in to the
database or for entering search queries. The excel sheets are used for
displaying the search results and to display the graphs for showing the
transaction pattern of an account to the account holder or banker.
Since the goal of the application is to provide database access to both
customers and bankers there are forms of different controls depending upon
the user. The homepage for the application is welcome worksheet in excel.
A snapshot of the welcome page is shown in figure 9.

10

BANKING DATABASE MANAGEMENT SYSTEM

Figure 9. The homepage of the application

The homepage contains the logo of the bank which is also the start button
for a user. On clicking the logo a form for selecting between a banker and
customer shows up. The user on selecting either of the 2 command buttons
is taken to their respective authorization form.

11

BANKING DATABASE MANAGEMENT SYSTEM

Figure 10. Database management layout

12

BANKING DATABASE MANAGEMENT SYSTEM

Figure 10. User form for selecting

type of user

Figure 11. User form for customer

authorization

Figure 10 and 11 shows the user forms for the user selection and
authorization. The account number and password combination is checked by
selecting data from the SQL customer table that matches the value input by
the user. If no record is returned from SQL, the ADODB recordset is empty
and for that condition a message saying Wrong ID/password is displayed.
On entering the right account number password combination the user taken
to the customer Account history
page.
The account history user form is
shown in figure 12. The account
number that the user enters in the
authorization window is passed to
this form which is displayed as a

13

BANKING DATABASE MANAGEMENT SYSTEM

label. There are three options here for the customer. The check balance
button displays the current balance in the account on a message box.
The other two option buttons are for looking at the deposit and withdrawal
histories for the account. This is done by making the transaction spreadsheet
for that account visible with type of transaction filtered by withdraw or
Deposit.
On clicking the option for deposit or withdraw history transaction history is
Figure 12. User form for customer
account info

fetched from the database table and stored in the custransaction

spreadsheet and the sheet is made visible.

Figure 13. Deposit history for an account shown in excel sheet.

The excel sheet contains two command buttons embedded in them. The get
chart button shows the amount versus graph bar chart. The chart is
displayed on a different sheet where a chart object was already created.
Every time the get chart button is clicked the data values used in the chart
14

BANKING DATABASE MANAGEMENT SYSTEM

objects is selected as the date and amount column values. So the source
data for the graph is refreshed on every click on the get chart button.
The chart rendered for the transaction is shown in figure 14. The chart is
created in a new sheet and is 3D bar chart.

Figure 14. Bar char of transaction history

A back button is provided on the chart sheet to return to the transaction
records sheet. This button erases the chart so chart is blank after clicking it.
The sheet visibility property is made false and the transaction sheet is made
active. Hence, the chart generated for the transaction is dynamic.
The banker authorization is done similarly but once in to the system the
banker has many different controls and options to choose from. The bankers
option page is shown in figure 15. All the command buttons takes the banker
15

BANKING DATABASE MANAGEMENT SYSTEM

to new user page where he can input new data or modify existing data. The
transaction query option in the banker control page works similar to the way
of customer transaction. However, the banker select the account number he
wishes to see.

Figure 15. Banker operations control window

16

BANKING DATABASE MANAGEMENT SYSTEM

Figure 16 and 17 shows the user forms for creating a new account and
customer in the database. Both forms creates a new record in the respective
database tables.

Figure 18. User form for displaying

customer info

Figure 19. User form for updating

customer info

The user forms for displaying customer information and updating customer
information is shown in figure 18 and 19. Both the operations can be done on
the basis of various parameters as visible from the figure.

Figure 16. User form for creating new

account

Figure 17. User form for creating new

customer
17

BANKING DATABASE MANAGEMENT SYSTEM

For

transaction

query

of

any

account the banker is taken to a

Figure 20. User form for transaction

query

new form. Here the banker is

required

to

input

the

account

number and select whether he

wants

to

view

deposit

or

withdrawal history for that account. The functioning of the transaction table
display and graphs is same as the customer part of the application. The user
form is shown in figure 20.
The calculate score button asks for the account number for which the credit
points are to be calculated. Once the account number is entered the
application calculates the score for the account number at that moment
depending upon the number of transactions made by the customer and the
balance available in the account. The user forms is shown in figure 21.

Figure 21. The Credit points calculator

18

BANKING DATABASE MANAGEMENT SYSTEM

CONCLUSIONS
The application created as an entry level banking database system can be
used to perform low level operations in a banking environment. Operations
like adding a new customer or new account can be done easily. The main
part of the application is its ability to display the transactions made on
account in excel as wells as in the form of bar charts. This can help the
banker and the customer in analyzing the performance that account which
can be helpful in making decisions regarding loan eligibility. Apart from
analyzing the application also has the ability to calculate the credit points
the account has depending on the number of transactions made and the
balance in the account. Making this a decision support system.

FUTURE SCOPE
1) Automatic generation of credit score and credit history.
2) Interfacing VBA with third party statistical software (e.g.. JMP) we can
forecast the spending pattern of customers and how their credit history
will change.

REFERENCES:
1) https://www.youtube.com/user/MySQLChannel
2) www.w3schools.com.

19