TERM PAPER

OF
DATA BASE MANAGEMENT
SYSTEM
ON
DATA BASE SYSTEM OF
BANKING

SUBMITTED TO: SUBMITTED BY:

MR.NANDAN SUJATI LOVEE KUMAR (B
38)
 DECLARATION

I, LOVEE KUMAR student of Lovely Professional University have

completed the Project on:

DATA BASE SYSTEM OF BANK

The information given in this project is true to the best of my

knowledge.
 ACKNOWLEDGEMENT

First of all I would like to thank the Lovely University and take the opportunity to
do this project as a part of the M.B.A.

Many people have influenced the shape and content of this project, and many
supported me through it. I express my sincere gratitude to Mr. NANDAN
SUJATI for assigning me a project on DATABASE MANAGEMENT
SYSTEM, which is an interesting and exhaustive subject.

He has been an inspiration and role model for this topic. His guidance and active
support has made it possible to complete the assignment.

I also would like to thank my Friends who have helped and encouraged me
throughout the working of the project.

Last but not the least I would like to thank the Almighty for always helping me.
 INTRODUCTION

Database Management System (DBMS)

 Collection of interrelated data
 Set of programs to access the data
 DBMS contains information about a particular enterprise
 DBMS provides an environment that is both convenient and efficient to use.

Purpose of Database System

 Data redundancy and inconsistency
 Multiple file formats, duplication of information in different files
 Difficulty in accessing data
 Need to write a new program to carry out each new task
 Data isolation
 Multiple files and formats
 Integrity problems
 Integrity constraints (e.g. account balance > 0) become part of program code
 Hard to add new constraints or change existing ones

 Atomicity of updates

Levels of Abstraction

 Physical level: describes how a record (e.g., customer) is stored.

 Logical level: describes data stored in database, and the relationships among the data.
 View level: application programs hide details of data types.
 BANKING SYSTEM

This software will be provided as a tool to the BANK. The BANK has been working for
Accounts information, Withdrawal (through Cash/Draft). Deposit amount. In this Software you
can keep record for daily Banking transactions.

THE OBJECTIVE is to prepare a software or application, which could maintain data & provide
a user friendly interface for retrieving customer related details just in few seconds, with 100%
accuracy. Software is completely computerized, so it is not time consuming process. No paper
work required & can be implemented further.

THE OBJECTIVE & GOALS OF THE BANKING SYSTEM ARE

• To allow only authorized user to access various functions and processed available in the
system.
• Locate any A/C wanted by the user.
• Reduced clerical work as most of the work done by computer. Provide greater speed &
reduced time consumption.
• To increase the number of A/C and customer. This will reduced the manual workload and
give information instantly.
• The software will maintain the list of A/C and customer record and balance status.
• The software will be user friendly so that even a beginner can operate the package and
thus maintain the status of A/C and balance status easily.
ENTITY RELATIONSHIP MODEL

An entity-relationship (ER) diagram is a specialized graphic that illustrates the interrelationships

between entities in a database. ER diagrams often use symbols to represent three different types
of information. Boxes are commonly used to represent entities. Diamonds are normally used to
represent relationships and ovals are used to represent attributes. An entity-relationship model
(ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a
database modeling method, used to produce a type of conceptual schema or semantic data model
of a system, often a relational database, and its requirements in a top-down fashion. Diagrams
created by this process are called entity-relationship diagrams, ER diagrams, or ERDs.

ENTITY

An entity is a real-world item or concept that exists on its own. The set of all possible values for an entity
is the entity type.

ATTRUBUTE

An attribute of an entity is a particular property that describes the entity. The set of all possible
values of an attribute is the attribute domain.

RELATIONSHIP

A relationship type is a set of associations among entity types. A relationship or relationship

instance is an ordered pair consisting of particular related entities.
 ENTITY RELATIONSHIP DIAGRAM

Branch
city
Branch
Asset
name
s
Branch

Payment
Customer Loan date
id branch Loan
Customer Payment
amount
name amt
Amount
Custome Borro Loan
r w Loan Paymen
payment
t
Customer
Street
Loan I.D Serial no.

Deposito
r

Employee

Employee
name

Employee
Depende id
nt name

Employem Start
entstrengt date
h
RELATIONAL MODEL

The Relational Model is a clean and simple model that uses the concept of a relation using a
table rather a graph or shapes. The information is put into a grid like structure that consists of
columns running up and down and rows that run from left to right, this is where information can
be categorized and sorted.

The relational model used the basic concept of a relation or table. The columns or fields in the
table identify the attributes such as name, age, and so. A tulip or row contains all the data of a
single instance of the table such as a person named Doug. In the relational model, every tulip
must have a unique identification or key based on the data. In this figure, a social security
account number (SSAN) is the key that uniquely identifies each tulip in the relation. Often, keys
are used to join data from two or more relations based on matching identification. The relational
model also includes concepts such as foreign keys, which are primary keys in one relation that
kept in another relation to allow for the joining of data.

RELATIONAL MODEL

BRANCH

Branch name Branch city Assets Loan I.D

A Dehra dun 1 101

B Punjab 2 102

C Delhi 3 103

D Kanpur 4 104
Branch Name – Primary key

Loan I.D – Foreign key

LOAN

Loan amt Amount Loan I.D Branch Serial no Customer

name I.D
100000 W 101 A 10 201
200000 X 102 B 11 202
300000 Y 103 C 12 203
400000 Z 104 D 13 204

Branch Name – Primary key

Customer I.D – Foreign key

PAYMENT

Payment amt Payment date Serial no. Loan I.D

W 10 JUNE 10 101
X 11 JULY 11 102
Y 12 AUGUST 12 103
Z 13 SEPTEMBER 13 104

Serial number – Primary key

Loan I.D – Foreign key

CUSTOMER

Customer Customer Customer Loan I.D Emp I.D

I.D name street
301 Lovee 15 101 401
302 Naman 18 102 402
303 Ankit 21 103 403
304 Amit 24 104 404

Customer I.D – Primary key

Loan I.D – Foreign key

EMPLOY

Emp name Dep name Emp name Start date Emp I.D
Pradeep K Lakhan 1 401
Manu L Sudhir 2 402
Bhaskar M Anil 3 403
Ashok N Rohan 4 404

Employ I.D – Primary key

Customer I.D – Foreign

DATA FLOW DIAGRAM

The Data Flow Diagram is commonly used also for the visualization of structured design data
processing. The normal flow is represented graphically. A designer typically draws context level
DFD first showing interaction between the system and the outside entities. Then this context
level DFD will then be exploded in order to further show the details of system being modeled.

The system may be automated, manual, or mixed. The DFD portrays the system in terms of its
component pieces, with all interfaces among the components indicated."

Focus on the movement of data between external entities and processes, and between processes
and data stores

Data flow diagrams are used to describe how the system transforms information. They define
how information is processed and stored and identify how the information flows through the
processes.

SOME OF THE ADVANTAGES OF USING DFD ANALYSIS

• Data flows and process consequences. Note how this representation of the data
characteristics of banking operations enables us to start at any point in the operation (e.g.,
deposits, withdrawals, or bill payment), and follow the consequences of that activity
through to the point where all appropriate account balances have been adjusted and
reconciled. Wherever we start in the process, we can understand the processing steps that
the bank would need to take to complete the relevant transaction(s) and to inform its
constituents of the results.

• Data inputs and outputs. The DFD also makes it possible to understand what data are
needed to provide appropriate inputs to any processing step. If, for example, we were to
build an information system to support this individual's banking activities (in the days
before Quicken and/or Microsoft Money), we would need to understand exactly what
 data items are represented by data flows such as "Monthly Statement", "Pay earned",
"Withdraw or transfer", and other arrows shown in the diagram.

• Simplifying complexity by isolating process components. Note how the DFD would
make it easier to capture the detail of such data flows. By isolating "Withdraw or
Transfer" within the larger scheme of the banking process, the DFD makes it possible to
consider the details of the data items included in this flow without reference to the flows
affecting other processing steps. All of the flows affecting withdrawals (e.g., processing
step 3.0, "Withdraw funds from account") are isolated as entering or leaving processing
step 3.0. At the time that DFDs were developed, this shift towards modularizing data
flows and processing elements represented a major step forward in enabling systems
analysts to add useful structure to process representations rapidly and easily.
 DFD MODEL

Receives Statements

Customer Writes Checks

Issues

Initiates Has Debit

Transactions Updates Accounts