ONLINE BANKING

INDEX
1. ABSTRACT 2. SOFTWARE REQUIREMENT SPECIFICATION 6 7 8 8 8 8 9 9 9 9 9 10 11 12 12 14

2.1 INTRODUCTION 2.1.1 PURPOSE 2.1.2 SCOPE 2.1.3 3 LIFE TIME 2.2
FUNCTIONAL REQUIREMENTS

2.3 NON-FUNCTIONAL REQUIREMENTS 2.3.1 USABILITY 2.3.2 RELIABILITY 2.3.3 SUPPOTABILITY 2.4
HARDWARE REQUIREMENT SPECIFICAITION

3. CONCEPTUAL DATABASE DESIGN

3.1 E-R MODEL 3.1.1 BASIC CONCEPTS 3.1.2 RELATIONSHIP SETS 3.2 CONSTRAINTS 3.2.1 MAPPING CARDINALITIES 3.2.2 PARTICIPATION CONSTRAINTS 3.3
KEYS

14 14 14 15

ANITS CSE

ONLINE BANKING

3.4

IDENTIFYING RELATIONSHIP SETS

18 23 29 30 30 31 31 32 32 33 39 40 52 61 62

4. LOGICAL DATABASE DESIGN 5. SCHEMA REFINEMENT

5.1 5.2 5.3

PROBLEMS CAUSED BY DEPENDENCY FUNCTIONAL DEPENDENCY USE OF DECOMPOSITION

5.4 NORMAL FORMS 5.4.1 BOYCE-CODD NORMAL FORM 5.4.2 THIRD NORMAL FORM
6. PHYSICAL DATABASE DESIGN 7. OPERATIONS ON DATABASE

7.1 7.2

CONTENTS OF DATABASE AFTER INSERTING VALUES QUERIES AND PROCEDURES ON DATABASE

8. CONCLUSION 9. BIBLIOGRAPHY

ANITS CSE

ONLINE BANKING

ABSTRACT
The purpose of this project is to develop online banking system that provides customer with facility to check their accounts and do various transactions online which saves and the time. PREVIOUS SYSTEM: Previously, all the transactions are done by the customers by at the particular bank organizations office for making the transactions. This became tedious since they have to wait long time making each transaction and should wait for their turn to come for a particular transaction to occur. PROPOSED SYSTEM: The system will provide many bank facilities to its customers when their authentication is verified; such as viewing account information, performing money transfers, giving the customer an option of changing address, paying bills online, performing transactions, viewing transactions and the location of the bank and its branches. ADVANTAGES OF THE PROPOSED SYSTEM: The system is able to help customers to access their account from any place and at any time, provided the users have access to the Internet. Hence only authorized users are able to access the database. The security or the information of the user is not easily compromised since the database provides security for the stored information. Data loss is also not a problem since the database management system provides the crash recovery. It features to manage the data in a robust and efficient manner.

ANITS CSE

ONLINE BANKING

SOFTWARE REQUIREMENT SPECIFICATION

ANITS CSE

ONLINE BANKING

2.1 INTRODUCTION:
2.1.1 PURPOSE:

The project of Online Banking System is aimed at computerizing the activities involved in a Bank. The primary transactions of the customer such as enquiry of the balance, transfer of funds and payment of bills are provided by the system. 2.1.2 SCOPE:

The main motive in designing this product is to provide a friendly environment for bank and customer to maintain data in a more efficient manner. The product is mainly composed of two groups : admin and users(customers). The admin has full access to the system. By using this system we can access any random customer information in more efficient manner. 2.1.3 LIFE TIME: This software version can be used until the language features used here exist and are not deprecated. When such cases arise, you are always allowed to update to newer versions of the software.

ANITS CSE

ONLINE BANKING

2.2 FUNCTIONAL REQUIREMENTS:

To maintain complete details about customers, their accounts and other services it is essential to maintain the complete information of customer in the database. The software requires the following functions and information to be maintained for the user and the administrators ease. 1. This can be used by customers for accessing their information from the database. 2. The customers are able to perform the enquiry of balance present in the bank account. 3. Administrator provides login to customers through identification number and password which are unique. 4. The customers are able to transfer money from one account to other account. 5. The customers able to pay bills like current bill, income tax, water tax and any other bill that can be paid online from their accounts. 6. The customers are provided with well defined user interface.

2.3 NON-FUNCTIONAL REQUIREMENTS:

2.3.1 USABILITY: The product could be used by two categories of people: administrator and customer. 2.3.2 RELIABILITY: Customers can perform the operations without any constraints regarding the outcome of the operation. Even the updating transactions provide reliability to the company. The system as a whole is highly reliable. 2.3.3 SUPPORTABLILITY: All kinds of information which can be supported in the database are supported by the system and the application supports the utilities of the system over which it is deployed.
ANITS CSE 6

ONLINE BANKING

2.4 HARDWARE REQUIREMENT SPECIFICATION:

Processor: Intel Pentium III or above. Hard disk: 30 GB or above RAM: 512 MB or above

ANITS CSE

ONLINE BANKING

CONCEPTUAL DATABASE DESIGN

ANITS CSE

ONLINE BANKING

The information gathered in the requirements analysis step is used to develop a highlevel description of the data to be stored in the database, along with the constraints that are known to hold over this data. This step is often carried out using the ER-model, or similar highlevel data model.

3.1 THE ENTITY-RELATIONSHIP MODEL:

The entity-relationship (E-R) data model perceives in the real world as consisting of basic objects called entities and relationships among these objects. It is developed to facilitated database design by allowing specification of an intermediate schema, which represents the overall logical structure of the database. The E-R data model is one of the several semantic data models; the semantic aspect of the lies in its representation of the meaning of the data. The E-R data model is very useful in mapping the meanings and interactions of real world enterprises on to a conceptual schema. Because of this usefulness, many database design tools draw on concepts from the E-R model.

3.1.1BASIC CONCEPTS
The E-R model employs three basic notions: entity sets, relationship sets and attributes. An entity is a thing or object in the real world that is distinguishable from all the objects. For example each in an enterprise is an entity. An entity has a set of properties and values for some set of properties may uniquely identify an entity. For instance a person may have personid property whose value uniquely identifies that person. An entity may be concrete such as a person or a book or it may be abstract such as a loan or a holiday. An entity set is a set of entities of the same type that share the same properties or attributes. The set of all persons who are customers at a given bank can be defined as entity set customer. The individual entities that constitute a set are said to be the extension of the entity set. An entity is represented by a set of attributes. Attributes are descriptive properties possess by each member of entity set. The designation of an attribute for an entity set express that the database store similar information concerning each entity in the entity set. However each
ANITS CSE 9

ONLINE BANKING

entity may have its own value for each attribute. Possible attributes of the customer entity set are customer id, customer name, customer Street, and customer city. For each attribute the set of permuted values called the domain or value set of the attribute. The domain of attribute customer name might be the set of all text frames of a certain length. An attribute as used in the E-R model can be characterized by the following attribute types.

SIMPLE AND COMPOSITE ATTRIBUTES:

The attributes in the examples so far have been simple, i.e., they are not divided into sub parts. Composite attributes can be divided into sub parts. For example an attribute name could be structured as a composite attribute consisting of first name, middle name and last name. Using composite attributes in a design schema is a good choice of a user will wish to refer to an entire attribute on some occasions and to only a component of the attribute on other occasions.

SINGLE-VALUED AND MULTIVALUED ATTRIBUTES:

The attributes in our examples have a single value for a particular entity. For instance, the loan-number attribute for a specific loan entity refers to only one loan number. Such attributes are said to be single valued. There may be instances where an attribute has a set of values for a specific entity. Consider an employee entity set with the attribute phonenumber. An employee may have zero, one or several numbers and different employees may have different numbers of phones. This type of attribute is said to multi-valued.

DERIVED ATTRIBUTE:
The value for this type of attribute can be derived from the value of other related attributes or entities. For instance the customer entity set has the attribute loans held which represents how many loans a customer had from the bank. We can derive the value for this attribute by counting the number loan entities associated with that customer.

ANITS CSE

10

ONLINE BANKING

3.1.2 RELATIONSHIP SETS:

A relationship is an association among two or more entities. Collection of similar relationships is a relationship set. A relationship set can be thought as set of n-tuples.

3.2 CONSTRAINTS
An E-R enterprise schema may define certain constraints to which the contents of the database may be conforming.

3.2.1MAPPING CARDINALITIES:
Mapping cardinalities of cardinality ratios express the number of entities to which another entity can be associated via a relationship set. For a binary relationship set R between entity sets A and B the mapping cardinality must be one of the following; One To One: An entity in A is associated with at most one entity is B and an entity in B is associated with at most one entity in A. One To Many: An entity in A is associated with any number of entities in B. An entity in b however can be associated with at most one entity in A. Many To One: An entity in A associated with at most one entity B. An entity in B however can be associated with any number of entities in A. Many To Many: An entity in A is associated with any number of entities in B and an entity in B is associated with any number of entities in A.

3.2.2 PARTICIPATION CONSTRAINTS:

The participation of an entity set E in a relationship set r is said to be total if every entity in E participates at least in one relationship in R. If only some entities in E
ANITS CSE 11

ONLINE BANKING

participate in relationships in R, the participation of entity set E in relationship R is said to be partial. For example, we expect every loan entity to be related to at least one customer through the borrower relationship. Therefore, the participation of the loan in the relationship set borrower is total. In contrast, an individual can be a bank customer whether or not he/she has a loan with the bank. Hence it is possible that only some of the customer entities are related to the loan entity set through the borrower relationship, and the participation of the customer in the borrower relationship set is therefore partial.

3.3 KEYS:
We must have to specify how entities within a given entity set are distinguished. A key allows us to identify a set of attributes that suffice to distinguish entities from each other. Keys also help uniquely identify relationships, and distinguish relationships from each other. A super key is a set of one or more attributes that, taken collectively, allow us to identify an entity in the entity set. For example the customer id attribute of the entity set customer is sufficient to distinguish one customer entity from another. Thus customer id is a super key. We are often interested in super keys for which no proper subset is a super key. Such minimal super keys are called candidate keys. The term primary key to denote a candidate key that is chosen a database designer as the principle means of identifying entities within an entity set. The primary key of an entity set allows us to distinguish among the various entities of the set. We need a similar mechanism to distinguish among the various relationships of a relationship set. If the relationship set R has no attributes associated with it,then the set of attributes primary key (E1),,primary key(En) describes an individual relationship in set R. If the relationshipset Rhas attributes a1,a2am associated with it, then the set of attributes primary key(E1),,primary key(En) {a1,a2am} describes an individual relationship

ANITS CSE

12

ONLINE BANKING

SYMBOLS USED IN ER DIAGRAM ARE:

ANITS CSE

13

ONLINE BANKING

ER-DIAGRAM:

ANITS CSE

14

ONLINE BANKING

RELATIONAL MODEL:
admin(adminid,password) customer(cid,cname,password,dob,sex,dno,street,city,pincode,phonenum) branches(bid,loc,phonenum) accounts(acid,cid,bid,bal) transaction(tid,cid,tname,tdate,ttime) fund_transfer(fid,tid,from_accno,to,accno,amount) bal_enquiry(eid,tid,accno,balance) payments(pid,tid,pname,paid_for,amount) has_account(cid,acid,since)

ENTITIES IDENTIFIED:
1. admin 2. customer 3. branch 4. account 5. transaction 6. balance enquiry 7. payments 8. fund transfer.

3.4 IDENTIFYING RELATIONSHIP SETS:

1. Customer-Accounts: 2.Accounts-Branches: 3. Customer-Transactions: 4.Transactions-(Fund_transfer-Bal_Enquiry-Payments) Has_account Belong_To Performs Can_be

ANITS CSE

15

ONLINE BANKING

ATTRIBUTES PERFORMED ADMIN

CUSTOMER

ANITS CSE

16

ONLINE BANKING

ACCOUNT

BRANCH

ANITS CSE

17

ONLINE BANKING

TRANSACTION

FUND TRANSFER

ANITS CSE

18

ONLINE BANKING

BAL_ENQUIRY

PAYMENT

ANITS CSE

19

ONLINE BANKING

LOGICAL DATABASE DESIGN

ANITS CSE

20

ONLINE BANKING

DESCRIPTION OF ENTITY SETS ADMINISTRATOR: This entity represents the Administrators who manage the whole process
of Online banking transactions where the customers use their account to perform the required functions. He is also in charge of the branches and the accounts of the customers. An administrator logs in using his adminid and password. adminid: This is the name with which the administrator logs in to the Database. It is unique to each administrator for each administrator; hence it is a primary key. password: This is password of the particular administrator who logs in to the Database. The adminid is the primary key for the administrator entity. ATTRIBUTE adminid password DATATYPE varchar2(10) varchar2(10) CONSTRAINT primary key

CUSTOMER: This entity is represents the users who make use of the facility of the online
banking procedures. cid: Each customer is identified uniquely with his identification no cid; Hence it is used as the primary key. cname: This is the name of the customer. password: The is the password of the particular user. dob: This is the date of birth of the customer. sex: This is the gender of the customer and identifies whether he is male or female. phonenum: This is the mobile phone number of the customer to make a call to him. address: This is multivalve attribute. This stores three values: dno: The door number of the customers address. street: The street in which the customer lives.
ANITS CSE 21

ONLINE BANKING

city: The city where the customer is living. pin code: This is the pin code of the city where the customer lives. ATTRIBUTE cid cname password dob sex dno street city pincode phonenum DATATYPE varchar2(10) varchar2(30) varchar2(10) date char varchar2(5) varchar2(10) varchar2(20) number(6) number(12) CONSTRAINT primary key

BRANCHES: This entity stands for the branch of the bank in a particular city and stores the
information about them. bid: This the branch identification number which uniquely indentifies each branch. loc: This is the location in which the branch is situated. phonenum: This is the phone number of the particular banks branch. ATTRIBUTE bid loc phonenum DATATYPE varchar2(10) varchar2(20) number(12) CONSTRAINT primary key

ACCOUNTS: This particular entity is used for storing information about the customers
account in the branch of the bank. acid: This stores the account number of the customer who is making the transactions. This is also the primary key of the account entity.

ANITS CSE

22

ONLINE BANKING

cid: This is the identification number of the customer who is making transactions. This is the foreign key which references the entity set customers. bal: This represents the amount of money remaining in the customers account. bid: This is the branch identification no of the branch which is used to identify the branch in which the customer is having his account.

ATTRIBUTE acid cid bid bal

DATATYPE varchar2(10) varchar2(10) varchar2(10) number(20,2)

CONSTRAINT primary key foreign key foreign key

TRANSACTION: This the entity set in which the details about each and every transaction
which the customer performs is stored. Those details about the transaction include: tid: This is unique identification number for every transaction that has occurred. Hence it is primary key. tdate: It stores the date on which the transaction has been performed. ttime: It stores the time at which the transation has started over the website. cid: It store the customers identification number to store the details about one who performed the transaction. It is the foreign key which references the table customers. tname: It stores the name of the type of transaction performed by the customer such as fund transfer, balance enquiry and bill payments. ATTRIBUTE tid cid tname tdate ttime
ANITS CSE

DATATYPE varchar2(10) varchar2(10) varchar2(10) date varchar2(10)

23

CONSTRAINT primary key foreign key

ONLINE BANKING

FUND_TRANSFER: This stores the information about the entity set of the transaction
fund_transfer. fid: This identification number uniquely identifies each fund transfer transaction . This is the primary key. tid: This is the transaction id number of the particular transaction. It is the foreign key which references the entity set transaction. from_accno: This is the account number of the customer from which the money is to be transferred. to_accno: This is the account number of the customer to which the money is to be transferred. amount: This is the amount of money that is to be transferred from one customers account to the other.

ATTRIBUTE fid tid from_accno to_accno amount

DATATYPE varchar2(10) varchar2(10) varchar2(10) varchar2(10) number(20,2)

CONSTRAINT primary key foreign key

BAL_ENQUIRY: This is the entity set which represents the entire transaction balance enquiry.
This stores information about required details of the enquired balance. eid: This is attribute which is used as the primary key for the transaction bal_enquiry for identifying each and every enquiry of balance made by the customer. tid: This is the transaction id number of the particular transaction. It is the foreign key which references the entity set transaction.
ANITS CSE 24

ONLINE BANKING

accno: This stores the account number for which the balance is to be known. bal: This is balance available in the particular customers account during the enquiry. ATTRIBUTE eid tid accno balance DATATYPE varchar2(10) varchar2(10) varchar2(10) number(20,2) CONSTRAINT primary key foreign key

PAYMENTS: This is the entity set which tells about the transaction payment and stores the
results about the transaction that has occurred. pid: This uniquely identifies each and every payment that has been made by the customer and it is used as the primary key. tid: This is the transaction id number of the particular transaction. It is the foreign key which references the entity set transaction. pname: This is the name of the payment made by the customer such as current bill, income tax, municipal water tax, phone bill. amount: This is the amount of money that is paid by the customer for the tax or bill.

ATTRIBUTE pid tid pname paid_for amount

DATATYPE varchar2(10) varchar2(10) varchar2(10) varchar2(10) number(20,2)

CONSTRAINT primary key foreign key

ANITS CSE

25

ONLINE BANKING

SCHEMA REFINEMENT

ANITS CSE

26

ONLINE BANKING

INTRODUCTION
The fourth step in database design is to analyze the collection of relations in our relational database schema to identify potential problems like dependencies, anomalies, and to refine it. In contrast to the requirements analysis and conceptual design steps, which are essentially subjective, schema refinement can be guided by some elegant and powerful theory. We discuss the theory of normalizing relations restructuring them to ensure some desirable properties.

5.1 PROBLEMS CAUSED BY REDUNDANCY

Storing the same information redundancy, that is, in more than one place within a database, can lead to several problems, Redundant Storage: Some information is stored repeatedly. Update anomalies: If one copy of such repeated data is updated, an inconsistency is created unless all copies are similarly updated. Insertion anomalies: It may not be possible to store some information unless some other information is stored as well. Deletion anomalies: It may not be possible to delete some information without losing some other information as well.

5.2 FUNCTIONAL DEPENDENCIES

A functional dependency (FD) is a kind of IC that generalizes the concept of a key. Let R be a relation schema and let X and Y be nonempty sets of attributes in R. We say that an instance r of R satisfies the FD X!Y 1if the following holds for every pair of tuples t1 and t2 in r.

ANITS CSE

27

ONLINE BANKING

5.3 USE OF DECOMPOSITION

Intuitively, redundancy arises when a relational schema forces an association between attributes that is not natural. Functional dependencies (and, for that matter, other ICs) can be used to identify such situations and to suggest refinements to the schema. The essential idea is that many problems arising from redundancy can be addressed by replacing a relation with a collection of smaller relations. Each of the smaller relations contain a (strict) subset of the attributes of the original relation. We refer to this process as decomposition of the larger relation into the smaller relations.

5.4 NORMAL FORMS: Given a relation schema, we need to decide whether it is a good design or whether we
need to decompose it into smaller relations. Such a decision must be guided by an understanding of what problems, if any, arise from the current schema. To provide such guidance, several normal forms have been proposed. If a relation schema is in one of these normal forms, we know that certain kinds of problems cannot arise. The normal forms based on FDs are first normal form (INF), second normal form (2NF), third normal form (3NF), and BoyceCodd normal form (BCNF). These forms have increasingly restrictive requirements: Every relation in BCNF is also 3NF, every relation in 3NF is also in 2NF, and every relation in 2NF is in 1NF. A relation is in first normal form if every field contains only atomic values, that is, not lists or sets. This requirement is implicit in our definition of the relational model. Although some of the newer database systems are relaxing this requirement, in this chapter we will assume that it always holds. 2NF is mainly of historical interest. 3NF and BCNF are important from a database design standpoint. While studying normal forms, it is important to appreciate the role played by FDs. Consider a relation schema R with attributes ABC. In the absence of any ICs, any set of ternary tuples is a legal instance and there is no potential for redundancy. On the other hand, suppose that we have the FD A! B. Now if several tuples have the same Avalue, they must also have the same B value. This potential redundancy can be predicted using the FD information. If more detailed ICs are specified, we
ANITS CSE 28

ONLINE BANKING

may be able to detect more subtle redundancies as well. We will primarily discuss redundancy that is revealed by FD information. In Section we discuss more sophisticated ICs called multi valued dependencies and join dependencies and normal form based on them.

5.4.1 BOYCE-CODD NORMAL FORM:

Let R be a relation schema, X be a subset of the attributes of R, and let A be an attribute of R. R is in Boyce-Codd normal form if for every FD X! A holds over R, one of the following statements is true: A 2X; that is, it is trivial FD, or X is a super key.

5.4.2 THIRD NORMAL FORM

Let R be a relation schema, X be a subset of the attributes of R, and A be an attributes of R. R is in third normal form if for every FD X! A holds over R, one of the following statements is true: A2 X; that is, it is a trivial FD, or X is a super key for R.

ANITS CSE

29

ONLINE BANKING

PHYSICAL DATABASE DESIGN

ANITS CSE

30

ONLINE BANKING

CREATION OF ENTITIES FROM TABLES:

Admin Table
create table admin ( adminid varchar2(10), password varchar2(10), primary key(adminid) );

Customer Table
create table customer ( cid varchar2(10), cname varchar2(30), password varchar2(10), dob date, sex char, dno varchar2(10), street varchar2(20), city varchar2(20), pincode number(6), phonenum number(12),
ANITS CSE 31

ONLINE BANKING

primary key(cid)

Branches Table
create table branches ( bid varchar2(10), loc varchar2(20), phonenum number(12), primary key(bid) );

Accounts Table
create table accounts ( acid varchar2(10), cid varchar2(10), bal number(20,2), bid varchar2(10), primary keY(acid), foreign key(cid) references customer, foreign key(bid) references branches );

ANITS CSE

32

ONLINE BANKING

Transaction Table
create table transaction ( tid varchar2(10), cid varchar2(10), tname varchar2(20), tdate date, ttime varchar2(10), primary key(tid), foreign key(cid) references customer );

Fund Transfer
create table fund_transfer ( fid varchar2(10), tid varchar2(10), from_accno varchar2(10), to_accno varchar2(10), amount number(20,2), primary key(fid), foreign key(tid) references transaction );

ANITS CSE

33

ONLINE BANKING

Bal_Enquiry
create table bal_enquiry ( eid varchar2(10), tid varchar2(10), accno varchar2(10), balance number(20,2), primary key(eid), foreign key(tid) references transaction );

Payments
create table payments ( pid varchar2(10), tid varchar2(10), pname varchar2(20), paid_for varchar2(10), amount number(20,2), primary key(pid), foreign key(tid) references transaction );

ANITS CSE

34

ONLINE BANKING

Has_Account

create table has_account ( cid varchar2(10), acid varchar2(!0), since date, primary key(cid,acid), foreign key(cid) references customer, foreign key(acid) references accounts );

ANITS CSE

35

ONLINE BANKING

OPERATIONS ON DATABASE

ANITS CSE

36

ONLINE BANKING

SAMPLE DATABASE ADMIN

INSERT into admin values(&admin,&password); SELECT * from admin; ADMINID m0001 m0002 m0003 PASSWORD xy860p9 lm54pu uvq54l

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this adminid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C
ANITS CSE 37

ONLINE BANKING

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

CUSTOMER
INSERT into customer values (&cid,&cname,&password,&date,&sex,&dno,&street,&city,&pincode,&phonenum); SELECT * from customer;
CID CN AM E P ASSW ORD DOB SEX DNO STREE T CITY PINCODE PHONENUM

c0001

ganesh

a1857

30-MAY-91

3/83

canal road

bikkavolu

533343

9030593056

c0002

bharat

c1035

04-AUG-91

7/81

gandhi st

rajahmundry

533101

9533240816

c0003

banu

l6052

12-AUG-90

2/53

joseph st

gajuwaka

531212

9030240213

c0004

sameera

q7643

01-AUG-91

4/54

ramnagar

vizag

533102

9030432154

c0005

gayatri

p9645

03-JUL-91

3/65

beach road

vizag

533103

9030654123

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form
38

ANITS CSE

ONLINE BANKING

1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this cid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

BRANCH
INSERT into branch values(&bid,&loc,&phonenum); SELECT * from branch;

ANITS CSE

39

ONLINE BANKING

BID b0001 b0002 b0003 b0004 b0005

LOC rajahmundry vizag kakinada hyderabad vijayawada

PHONENUM 236572 290256 234678 231254 232142

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this bid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists
40

ANITS CSE

ONLINE BANKING

The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

ACCCOUNT
INSERT into account values(&acid,&cid,&bal,&bid); SELECT * from accounts; ACID a0001 a0002 a0003 a0004 a0005 a0006 CID c0001 c0002 c0003 c0001 c0005 c0004 BAL 10000 15000 20000 20000 25000 18000 BID b0001 b0001 b0002 b0002 b0003 b0005

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this adminid is the key attribute and all other are non-key attributes

ANITS CSE

41

ONLINE BANKING

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

TRANSACTION
INSERT into transaction values(&tid,&cid,&tname,&date,&ttime); SELECT * from transaction;

ANITS CSE

42

ONLINE BANKING

TID t0001 t0002 t0003 t0004 t0005 t0006 t0007 t0008 t0009

CID c0001 c0002 c0001 c0003 c0005 c0003 c0004 c0002 c0005

TNAME bal_enquiry Payments fund transfer fund transfer payments bal_enquiry payments fund_transfer bal_enquiry

TDATE 01-JAN-11 02-MAR-11 23-JAN-10 01-MAR-11 04-MAY-10 23-SEP-10 30-DEC-10 12-NOV-10 24-OCT-10

TTIME 01:23:30 02:01:20 03:21:34 11:06:09 03:08:34 12:04:45 11:11:11 12:05:06 12:12:24

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this tid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

ANITS CSE

43

ONLINE BANKING

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables

Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

BALANCE ENQUIRY
INSERT into bal_enquiry values (&eid,&tid,&accno,&bal); SELECT * from bal_enquiry: EID e0001 e0002 e0003 TID t0001 t0006 t0009 ACCNO a0001 a0003 a0005 BALANCE 12000 24000 26000

ANITS CSE

44

ONLINE BANKING

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this eid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

PAYMENTS
INSERT into payment values (&pid,&tid,&pname,&paid_for,&amount); SELECT * from payment;

ANITS CSE

45

ONLINE BANKING

PID p0001 p0002 p0003

TID t0002 t0005 t0007

PNAME phone bill current bill house tax

PAID_FOR 9030593056 08b1019 ap01023

AMOUNT 600 800 1500

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this pid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap

ANITS CSE

46

ONLINE BANKING

Hence this table is in BCNF also

FUND TRANSFER
INSERT into fund_ transfer values (&fid,&tid,&from_accno,&to_accno,&amount); SELECT * from fund_transfer;

FID f0003 f0001 f0002

TID t0008 t0003 t0004

FROM_ACCNO a0002 a0001 a0003

TO_ACCNO a0005 a0004 a0001

AMOUNT 2000 1000 4000

NORMALIZATIONTHEORY: 1ST NORMAL FORM:

Here no record contains non-atomic values. Hence, it is satisfying First Normal Form 1st Normal Form checks multi valued dependency

2ND NORMAL FORM:

Non-key attributes depend on key attribute In this fid is the key attribute and all other are non-key attributes

3RD NORMAL FORM:

Here no non-key attribute should identify another non-key attribute, which is avoiding transitive dependencies of the tables
ANITS CSE 47

ONLINE BANKING

Eg. If there are field names A, B, C and A->B and B->C and A->C then we create table with A->B and A->C there is no need to store information of A->C

BOYCE-CODD NORMAL FORM:

The relation doesnt contain more than one composite candidate key There is no interdependency exists The relation is disjoint and there exists no common overlap Hence this table is in BCNF also

ANITS CSE

48

ONLINE BANKING

QUERIES

Display the details of the customers having accounts in the branch located at rajahmundry.

SQL> select * from customer where cid in(select cid from accounts where bid=(select bid from branches where loc='rajahmundry'));

OUTPUT:
CNA CID c00 01 c00 02 ME ganes h bhara t PASSW ORD a1857 DOB 30-MAY91 04-AUG91 SEX M DN O 3/8 3 7/8 1 STREE T canal road gandhi st CITY bikkavol u rajahmu ndry PINCO DE 533343 PHONENU M 9030593056

c1035

533101

9533240816

Display the customer names having balance more than 15000.

SQL> select cid,cname from customer where cid in(select cid from accounts where bal>15000);

ANITS CSE

49

ONLINE BANKING

OUTPUT:

CID c0003 c0001 c0005 c0004

CNAME banu ganesh gayatri sameera

Display the names of the customers who performed fund transfer transactions where amount transferred is more than 1000 on date 12-NOV-10.

SQL> select cid,cname from customer where cid in(select cid from transaction where tid in(select tid from fund_transfer where amount>1000)and tdate='12-NOV-10');

OUTPUT:

CID c0002

CNAME bharat

Display the number of payment transactions during the period 12-jul-10 and 12-jul11.

SQL> select count(tid) from transaction where tname =payments' and (tdate between '12-JUL-10' and '12-JUL-11');

ANITS CSE

50

ONLINE BANKING

OUTPUT:

COUNT(TID) 2

Display the names of customers who performed bal_enquiry transaction between 01-jan-11 and 01-feb-11.

SQL> select cid,cname from customer where cid in(select cid from transaction where tname='bal_enquiry' and (tdate between '01-JAN-10' and '01-jan-11'));

OUTPUT:
CID c0001 c0003 c0005 CNAME ganesh banu gayatri

Display the account numbers of the customers who belong to city Vizag. SQL> select acid from accounts where cid in(select cid from customer where city='vizag');
ANITS CSE 51

ONLINE BANKING

OUTPUT:

ACID a0005 a0006

Display the total balance of all accounts branch wise.

SQL> select bid,sum(bal) from accounts group by bid;

OUTPUT:

BID b0001 b0003 b0005 b0002

SUM(BAL) 25000 25000 18000 40000

ANITS CSE

52

ONLINE BANKING

Display the total number of transactions in transaction type wise.

Sql> select tname,count(tid) from transaction group by tname;

OUTPUT:

TNAME bal_enquiry payments fund _transfer

COUNT(TID) 3 3 3

Display the name,cid,account number &bal of each customer.

Sql> select customer.cname,customer.cid,accounts.acid,accounts.bal from customer inner join accounts on customer.cid=accounts.cid;

ANITS CSE

53

ONLINE BANKING

OUTPUT:

CNAME ganesh bharat banu ganesh gayatri sameera

CID c0001 c0002 c0003 c0001 c0005 c0004

ACID a0001 a0002 a0003 a0004 a0005 a0006

BAL 10000 15000 20000 20000 25000 18000

Display the name,account number &bal of each customer in the ascending order of their balance.

Sql> select customer.cname,accounts.acid,accounts.bal from customer inner join accounts on customer.cid=accounts.cid order by accounts.bal;

ANITS CSE

54

ONLINE BANKING

OUTPUT:

CNAME ganesh bharat sameera ganesh banu gayatri

ACID a0001 a0002 a0006 a0004 a0003 a0005

BAL 10000 15000 18000 20000 20000 25000

ANITS CSE

55

ONLINE BANKING

PROCEDURES

Procedure to display balace of an account when the account number is given.

create or replace procedure balance(p_acid in accounts.acid%type) is p_bal accounts.bal%type; begin select bal into p_bal from accounts where acid=p_acid; dbms_output.put_line('Balance Details'); dbms_output.put_line(p_acid||' '||p_bal); end;

Procedure created.

Execute balance(a0001); Balance Details a0001 10000

ANITS CSE

56

ONLINE BANKING

Procedure to update the balance of account of a customer when he performs payment transaction.

create or replace procedure payment(p_pid payments.pid%type) is p_amt payments.amount%type; p_cid customer.cid%type; begin select cid into p_cid from transaction where tid=(select tid from payments where pid=p_pid); select amount into p_amt from payments where pid=p_pid; update accounts set bal=bal+p_amt where cid=p_cid; end; procedure created. Select * from accounts;

ACID a0001 a0002 a0003 a0004 a0005 a0006

CID c0001 c0002 c0003 c0001 c0005 c0004

BAL 10000 15000 20000 20000 25000 18000

BID b0001 b0001 b0002 b0002 b0003 b0005

Execute payment(a0003); Pl/sql procedure successfully completed.

ANITS CSE 57

ONLINE BANKING

CONLCUSION
This project is developed based on the basic requirements and facilities needed by the customers of the bank. The software can be applied to any bank which provides the online banking facilities for its customers. We have created the project user friendly and to make the customers feasible for handling the transactions. Internet is the medium through which all the computing devices in the world connect with each other with the help of communication satellites and exchange data. We are all aware of how the internet has become an unavoidable necessity in our lifestyles and how it has influenced the lives of those living in the INFORMATION AGE. The internet has surpassed the geographical communication predicament and brought the world much closer. Information is now available as and when it is generated.

ANITS CSE

58

ONLINE BANKING

BIBLIOGRAPHY
1. Database Management Systems-Third Edition (IE) - Raghu Ramakrishnan, Johannes Gerkhe, Mc Graw Hill Edition. 2. Database System concepts-Fifth Edition (IE) -Abraham Silberschatz, Henry F.Korth, S.Sudarshan, Mc Graw Hill Edition. 3. Fundamentals of Database Systems-Fifth Edition (IE) Ramez Elamasri, Shamkanth B.Navathe, Pearson Education. 4. Oracle 9i, The Complete Reference Oracle Press - Kevin Loney, George Koch, Tata Mc Graw Hill Edition.

ANITS CSE

59