Get Homework/Assignment Done

Homeworkping.com

Homework Help

https://www.homeworkping.com/

Research Paper help

https://www.homeworkping.com/

Online Tutoring

https://www.homeworkping.com/

click here for freelancing tutoring sites

1

INTRODUCTION

INTRODUCTIONThissoftware is a prototype model and will be provided as a tool to the various

banks of India. The Bank has been working for account information withdraw

(through cash/cheque) deposit amount.

2

The objective of single window based banking system is to prepare a software or

application, which could maintain data & provide a user friendly interface for

retrieving customer related details just in few second with 100% accurate.

Software is completely computerized. So, it is no time consuming process, no

paper work required & can be implemented further.

The application should all facilitate the addition of new customer A/C, deletion of

A/C, modifying & existing of A/C. The transaction & any A/C should be opened

with minimum rest Rs.500 etc.

The single window facilitates dealing like withdrawing cash from a saving A/C,

current A/C, and purchase of draft or pay orders, making fixed deposit of all

banking system at a single counter that is all customer needs are attended to at a

single point of delivery.

Earlier, for this type of transaction, a customer had to approach different staff at

different counter. To use this software all the facilities availed at of one counter or

window.

3

PURPOSE

PURPOSE This application software facilitates its user to let him access or can create

account whenever required to do so.

Administrator has a privilege to update, modify and generate transaction

table, customer table, User Table.

4

User information, login details, employee details are stored accordingly.

This application software reduces the paper job and let it users to perform

all tasks in automatic manner.

User friendly and easily configurable.

OBJECTIVE

5

OBJECTIVEIn our project, we are developingsoftware for solving financial applications of a

customer in banking environment in order to nurture the needs of an end banking

user by providing various ways to perform banking tasks. Also to enable the user’s

workspace to have additional functionalities which are not provided under

conventional banking software.

To allow only authorized user to access various functions and processed

available in the system.

Locate any account wanted by the employee.

Reduced clerical work as most of the work done by computer.

Provide greater speed & reduced time consumption.

6

SYSTEM

SPECIFICATION

7

HARDWARE

REQUIREMENT

8

HARDWARE

REQU IREMENT RAM

Minimum 512 MB

PROCESSOR Processor 1.8 GHz or higher

HARD DISK

Minimum 5 GB or above

OTHERS

9

Monitor

Keyboard

Mouse

SOFTWARE

REQUIRMENT

10

SOFTWARE

REQUIREMENT

FRONT END

Java 1.6

BACK END

MySQL 5.1

OPERATING SYSTEM

Windows XP or later

11

TECHNOLOGY

USED

12

TECHNOLOGY USEDThis project is a web based application that is developed in JAVAand having

MySQL 5.1 as back end.

JAVA1.6

MySQL 5.1

13

JAVA Java is a programming language originally developed by James Gosling at

Sun Microsystems (which is now a subsidiary of Oracle Corporation) and

released in 1995 as a core component of sun Microsystems’ java platform.

The language derives much of its syntax from C and C++ but has a simpler

object model and fewer low-level facilities.

Java applications are typically compiled to byte code (class file) that can

run on any java virtual machine (JVM) regardless of computer architecture.

Java is currently one of the most popular programming languages in use,

and is widely used from application software to web application.

Java is a computer programming language that is concurrent, class-based,

object-oriented, and specifically designed to have as few implementation

dependencies as possible. It is intended to let application developers "write

once, run anywhere" (WORA), meaning that code that runs on one platform

does not need to be recompiled to run on another.

Java applications are typically compiled to byte code (class file) that can run

on any Java virtual machine (JVM) regardless of computer architecture.

Advantages of Java

14

Java is simple, easy to design, easy to write, and therefore easy to compile,

debug, and learn than any other programming languages.

Java is object-oriented, that is used to build modular programs and reusable

code in other application.

Java is platform-independent and flexible in nature. The most significant

feature of Java is to run a program easily from one computer system to

another. 

Java works on distributed environment. It is designed to work on distributed

computing, any network programs in Java is same as sending and receiving

data to and from a file.

Java is secure. The Java language, compiler, interpreter and runtime

environment are securable.

Java is robust. Robust means reliability. Java emphases on checking for

possible errors, as Java compilers are able to detect many error problems in

program during the execution of respective program code.

Java supports multithreaded. Multithreaded is the path of execution for a

program to perform several tasks simultaneously within a program.

The Java comes with the concept of Multithreaded Program. In other

languages, operating system-specific procedures have to be called in order

to work on multithreading.

15

JAVA FEATURES

Platform Independence

o The write-once-run-anywhere ideal has not been achieved (tuning for

different platforms usually required), but closer than with other languages.

Object oriented

o Object oriented throughout- no coding outside of class definitions,

including main ().

o An extensive class library available in the core language packages.

Compiler/interpreter Combination

o Code is complied with byte codes that are interpreted by java virtual

machines (JVM).

o This provides portability to any machine for which a virtual machine has

been written.

o The two steps of compilation and interpretation allow for extensive code

checking and improve security.

Robust

o Exception handling built-in, strong type checking (that is, all data must

be declared an explicit type), local variables must be initialized

16

Several dangerous features of C &C++ eliminated

o No memory pointers

o No pre-processor

o Array index limit checking

Automatic memory management

o Automatic garbage collection- memory management handled by JVM.

Security

o No memory pointers

o Programs run inside the virtual machine sandbox

o Array index limit checking

o Code pathologies reduced by

Byte code verifier – checks classes after loading.

Class loader – confines objects to unique namespaces. Prevents

loading a hacked, i.e. “java.lang.securitymanager” class.

Security manager – determines what resources a class can access such

as reading and writing to the local disk.

Dynamic binding

o The linking of data and methods to where they are located is done at

run-time.

o New classes can be loaded while a program is running .linking is done on

the fly.

17

oEven if libraries are complied, there is no need to recompile code that uses

classes in those libraries. This differs from C++, which uses static binding.

This can result in fragile classes for cases where linked code is changed and

memory pointers then point to the wrong addresses.

Good performance

o Interpretation of byte codes slowed performance in early versions, but

advanced virtual machines with adaptive and just-in-time compilation and

other techniques now typically provide performance up to 50% to 100%

the speed of C++ programs.

Threading

o Lightweight processes, called thread, can easily be spun off to perform

multiprocessing.

o Can take advantages of multiprocessors where available

o Great for multimedia displays

18

MySQL MySQL pronounced either “My S-Q-L” or “My Sequel,” is an open source

relational database management system. It is based on the structure query

language (SQL), which is used for adding, removing, and modifying

information in the database. Standard SQL commands, such as ADD,

DROP, INSERT, and UPDATE can be used with MySQL.

MySQL can be used for a variety of applications, but is most commonly

found on web servers. A website that uses MySQL may include web pages

that access information from a database. These pages are often referred to as

“dynamic,” meaning the content of each page is generated from a database

as the page loads.

Websites that use dynamic web pages are often referred to as database-

driven websites.

Many database-driven websites that use MySQL also use a web scripting

language like PHP to access information from the database. MySQL

19

commands can be incorporated into the PHP code, allowing part or all of a

web page to be generated from database from database information.

Because both MySQL and PHP are open source (meaning they are free to

download and use), the PHP/MySQL combination has become a popular

choice for database-driven websites.

ADVANTAGES

MySQL has few advantages over some other DBMS’s.

1. It is available on many different operating systems. You can use it on

one type of system and it will work the same way on a different

platform, should you ever decide to use a different OS or platform.

Some other DBMS’s, such as SQL server, are only available on specific

operating systems (although only being available on specific systems

may allow it to integrate itself better into that platform and its tools).

2. MySQL is also very widely used. This means if you have a problem,

you will usually be able to find a solution on the net or go to a forum

and have your question answered relatively quickly.

3. MySQL is also and is open source under the GNU licensing agreement.

This means it is cheap and you will often find a lot of other open source

tools, which are free, available to use with it (because it is so popular).

DISADVANTAGES 1. MySQL does not support a very large database size as efficiently.

20

2. MySQL does not support ROLE, COMMIT, and stored procedures in

versions less than 5.0

3. Transactions are not handled very efficiently.

FEATURES

21

FEATURES It allows only authorized user to access the whole software.

It allows employee of the bank to create accounts instantly.

Withdrawal and deposition (of money) tasks is simplified.

Auto report generation.

User friendly design and easily configurable.

22

FEASIBILITY

STUDY23

FEASIBILITY STUDYFeasibility study aim to objectively and rationally uncover the strength and

weaknesses of the existing business or proposed venture, opportunities and threats

as presented by the environment, the resources required to carry through, and

ultimately the prospects for success.

In its simplest term, the two criteria to judge feasibility are cost required and

value to be attained. As such, a well-designed feasibility study should provide a

historical background of the business or project, description of the product or

service, accounting statements, details of the operations and management,

marketing research and policies, financial data, legal requirements and tax

obligation. Generally, feasibility studies precede technical development and

project implementation.

Five common factors (TELOS)

24

Technology and system feasibility

The assessment is based on an outline design of system requirements in terms

of input, processes, output, fields, programs, and procedures. This can be

quantified in terms of volumes of data, trends, frequency of updating, etc.

In order to estimate whether the new system will perform adequately or not.

Technological feasibility is carried out to determine whether the company has

the capability, in terms of software, hardware, personnel and expertise, to

handle the completion of the project.

Economic feasibility

Economic analysis is the most frequently used method for evaluating the

effectiveness of a new system. More commonly known as cost/benefit

analysis, the procedure is to determine the benefits and savings that are

expected from a candidate system and compare them with costs. If benefits

outweigh costs, then the decision is made to design and implement the system.

An entrepreneur must accurately weigh the cost versus benefits before taking

an action.

Cost–based study

It’s important to identify cost and benefit factors, which can be categorized

asfollows: development costs; and operating costs.

This is an analysis of the costs to be incurred in the system and the benefits

derivable out of the system.

Time-based study

25

This is an analysis of the time required to achieve a return on investments.

The future value of a project is also a factor. In our project the software which

we use for develop our project is totally free either it is java or MySQL. So

there is no economically cost.

Legal feasibility

Determines whether the proposed system conflicts with legal requirements,

e.g. a data processing system must comply with the local data protection

acts.Since all the software we are using is free, so we are not violating any

anti piracy law.

Operational feasibility

Operational feasibility is a measure of how well proposed system solves the

problems, and takes advantages of the opportunities identified during scope

definition and how it satisfies the requirements identified in the requirement

analysis phase of system development. This software fulfils all the needs of

car showroom departmental stores.

Schedule feasibility

A project will fail if it takes too long to be completed before it is useful.

Typically this means estimating how long the system will take to develop, and

if it can be completed in a given time period using some methods like payback

period. Schedule feasibility is a measure of how reasonable the project

timetable is. Given our technical expertise, are the project deadlines

reasonable? Some projects are initiated with specific deadlines. You need to

determine whether the deadlines are mandatory or desirable.

26

Since, we are using rapid development tools (Net beans). Therefore the

software will be easily completed on schedule.

WHATARE THE USER’S

DEMONSTRATABLE NEEDS?User needs application software, which will provide him ease from security

threats, flexibility, fast result accessing according to its requirement.

HOW CAN THE PROBLEM BE

REDEFINED?

We proposed our perception of the system, in accordance with the problems of

existing system by making a full layout. We were further updating in the layout in

the basis of redefined the problems. In feasibility study phase we had undergone

through various steps, which are described as under: how feasible is the system

proposed? This was analyzed by comparing the following factors:

Cost

Effort

Time

Labor

27

COSTthe cost required in the proposed system is comparatively less to the existing

system.

EFFORT

Compared to the existing system the proposed system will provide a better

working environment in which there will be ease of work and the effort required

will be comparatively less than the existing system.

TIMEAlso the time required generating a report and cache files will be comparatively

very less than in the existing system.

LABOUR

Also the time required and doing any other work will comparatively very less.

Record updating will take less time. .

28

SDLC

29

SDLCThe systems development life cycle (SDLC), also referred to as the application

development life-cycle, is a term used in systems engineering, information

systems and software engineering to describe a process for planning, creating,

testing, and deploying an information system. The systems development life-cycle

concept applies to a range of hardware and software configurations, as a system

can be composed of hardware only, software only, or a combination of both.

A systems development life cycle is composed of a number of clearly defined and

distinct work phases which are used by systems engineers and systems developers

to plan for, design, build, test, and deliver information systems. Like anything that

is manufactured on an assembly line, an SDLC aims to produce high quality

systems that meet or exceed customer expectations, based on customer

requirements, by delivering systems which move through each clearly defined

phase, within scheduled time-frames and cost estimates.

Computer systems are complex and often (especially with the recent rise of

service-oriented architecture) link multiple traditional systems potentially supplied

by different software vendors. To manage this level of complexity, a number of

SDLC models or methodologies have been created, such as "waterfall"; "spiral";

"Agile software development"; "rapid prototyping"; "incremental"; and

"synchronize and stabilize”.

30

ISO/IEC 12207 is an international standard for software life-cycle processes.It

aims to be the standard that defines all the tasks required for developing and

maintaining software.

SOFTWARE DEVELOPMENT

ACTIVITIES

Planning

Implementation, testing and documentation

Deployment and maintenance

PLANNING

Planning is an objective of each and every activity, where we want to discover

things that belong to the project. An important task in creating a software program

is extracting the requirements or requirements analysis.Customers typically have

an abstract idea of what they want as an end result, but do not know what software

should do. Skilled and experienced software engineers recognize incomplete,

ambiguous, or even contradictory requirements at this point. Frequently

demonstrating live code may help reduce the risk that the requirements are

incorrect.

Once the general requirements are gathered from the client, an analysis of the

scope of the development should be determined and clearly stated. This is often

called a scope document.

31

Certain functionality may be out of scope of the project as a function of cost or as

a result of unclear requirements at the start of development. If the development is

done externally, this document can be considered a legal document so that if there

are ever disputes, any ambiguity of what was promised to the client can be

clarified.

IMPLEMENTATION, TESTING,

DOCUMENTATION

Implementation is the part of the process where software engineers actually

program the code for the project.

Software testing is an integral and important phase of the software development

process. This part of the process ensures that defects are recognized as soon as

possible.

Documenting the internal design of software for the purpose of future

maintenance and enhancement is done throughout development. This may also

include the writing of an API, be it external or internal. The software engineering

process chosen by the developing team will determine how much internal

documentation (if any) is necessary. Plan-driven models (e.g., Waterfall)

generally produce more documentation than agile models.

DEPLOYMENT AND MAINTENANCE

Deployment starts directly after the code is appropriately tested, approved for

release, and sold or otherwise distributed into a production environment. This may

32

involve installation, customization (such as by setting parameters to the customer's

values), testing, and possibly an extended period of evaluation. Software training

and support is important, as software is only effective if it is used correctly.

Maintaining and enhancing software to cope with newly discovered faults or

requirements can take substantial time and effort, as missed requirements may

force redesign of the software.

33

WATERFALL

MODEL

34

WATERFALL MODELThe waterfall model is a sequential design process, often used in software

development processes, in which progress is seen as flowing steadily downwards

(like a waterfall) through the phases of Conception, Initiation, Analysis, Design,

Construction, Testing, Production/Implementation, and Maintenance.

The waterfall development model originates in the manufacturing and construction

industries; highly structured physical environments in which after-the-fact changes

are prohibitively costly, if not impossible. Since no formal software development

methodologies existed at the time, this hardware-oriented model was simply

adapted for software development.

The first known presentation describing use of similar phases in software

engineering was held by Herbert D. Benington at Symposium on advanced

programming methods for digital computers on 29 June 1956. This presentation

was about the development of software for SAGE. In 1983 the paper was

republishedwith a foreword by Benington pointing out that the process was not in

fact performed in a strict top-down fashion, but depended on a prototype.

The first formal description of the waterfall model is often cited as a 1970 article

by Winston W. Royce, although Royce did not use the term "waterfall" in this

35

article. Royce presented this model as an example of a flawed, non-working

model. This, in fact, is how the term is generally used in writing about software

development—to describe a critical view of a commonly used software

development practice.

WATERFALL MODEL

36

PHASES OF WATERFALL MODEL

37

Feasibility study

Requirement Analysis and specification

Design

Implementation and unit testing

Integration and system testing

Operation and maintenance

FEASIBILITY STUDY

The feasibility study activity involves the analysis of the problem and collection of

the relevant information to the product. The main aim of the feasibility study is to

determine whether it would be financially and technically feasible to develop the

product.

REQUIREMENT AND SPECIFICATION

The goal of this phase is to understand the exact requirements of the customer and

to document them properly. This activity is usually executed together with the

customer as the goal is to document all functions performance and interfacing

requirements for the software. The requirements describes the “what” of a system

not the “how”. This phase produces a large document written in a natural

language. The resultant document is known as SRS document.

DESIGN

38

The goal of this phase is to transform the requirement specification into a structure

that is suitable for implementation in some programming language. In this activity,

the functional specifications are use for translating the model into a design of the

desired system. It includes defining of the module and their relationship to one

another called a structure chart.

IMPLEMENTATION AND UNIT TESTING

During this phase the design is implemented. Initially small modules are tested in

isolation from rest of the software product. This is the process in which the

develop system is handed over to the client. Unit testing is that testing of each

individual module. The purpose of unit testing determines the correct working of

the individual modules. Unit testing involves a precise definition of the test cases.

Every company formulates its own coding standards such as layout of programs,

content and formats of the headers etc.

INTEGRATION AND SYSTEM TESTING

This is very important phase effective testing will contribute to the delivery of

higher quality software products, more satisfied users, lower maintenance cost and

more accurate reliable results. During this phases individual program units or

programs are integrated and tested as complete system to ensure that the software

requirement have been met.

OPEARATION & MAINTENANCE

39

Release of software inaugurates the operation and life cycle phase of the operation.

Software maintenance is a task that every development group has to face, where

the software is delivered to the customer’s site installed and is made operational.

Therefore, release of software inaugurates the operation and maintenance phase of

the life cycle. The time spent and effort required keeping the software operational

after release includes error correction enhancement of obsolete capabilities.

40

ADVANTAGES

ADVANTAGES

41

It replaces the traditional way of banking by shifting to it on more

computational side.

This software will eliminate the counter problem i.e., customer don’t have

to think which counter he have to approach for cash withdrawal or cash

deposition.

It will reduce the time consumed in one transaction.

Employee’s productivity time increases at workplace.

It can be used for keeping log i.e. user record, employee record etc.

42

DISADVANTAGES

DISADVANTAGES43

Since banks are wholly dependent on software, and we all know at any time

software can crash, this can leadto chaos.

Since there is no level of security, anyone can breach the software easily.

44

LIMITATION

45

LIMITATIONThe new system has been designed to meet all of the user requirements but it too

has certain limitations. This project has an assumption that our project is used by

only employee and Administrator. Those are registered to our program. In our

particular program employee only view and the administrator is updating all data.

Some of which can be enhanced in the future enhancements or updates:

NO ONLINE BANKING SUPPORT

The existing system supports direct interaction between customers and employee

of the bank. Customers can’t access its account by sitting at his home.

MULTI-BRANCH NOT SUPPORTED

Currently this application only support single branch of bank. In future

enhancement this problem will be faded out.

46

FUTURE

ENHANCEMENTS

47

FUTURE ENHANCEMENTSEnhancements are the perquisite for development of a system. Every existing

system has proposed enhancements which make it better and easier to use and

more secure. The enhancements that have been proposed for this system are listed

here:

FACILITY FOR MULTI-BRANCHES

Along with that, we will enhance this application software from single branch

system to multi-branch system. It means multiple branches can use it at a time and

our system is scalable enough to handle multi request.

ONLINE BANKING SUPPORT FOR USERSThe new system will allow it user to access its own account from any corner, at

any time. User will just need a User ID and password to maintain its account, can

demands for various services available by the bank.

48

DATA FLOW

DIAGRAM

49

DATA FLOW DIAGRAMA data flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system, modeling its process aspects. Often they are a

preliminary step used to create an overview of the system which can later be

elaborated. DFDs can also be used for the visualization of data processing

(structured design).

A DFD shows what kinds of information will be input to and output from the

system, where the data will come from and go to, and where the data will be

stored. It does not show information about the timing of processes, or information

about whether processes will operate in sequence or in parallel (which is shown on

a flowchart).

DFDs are an important technique for modeling a system’s high –level detail by

showing how input data is transformed to output results through a sequence of

functional transformations. DFDs consist of four major components: entities,

processes, data stores, and data flows. The symbols used to depict how these

components interact in a system are simple and easy to understand; however, there

are DFD models to work from, each having its own symbology. DFD syntax does

remain constant by using simple verb and noun constructs.

Such a syntactical relationship of DFDs makes them ideal for object-oriented

analysis and parsing functional specifications into precise DFDs for the systems

analyst.

50

When it comes to conveying how information data flows through systems (and

how the data is transformed in the process), data flow diagrams (DFDs) are the

method of choice over technical descriptions for three principle reasons.

DFDs are easier to understand by technical and non technical audiences.

DFDs can provide a high level system overview, complete with boundaries

and connections to other systems.

DFDs can provide a detail representation of system components.

DFD’s help system designers and others during initial analysis stages visualize a

current system or one that may be necessary to meet new requirements. Systems

analysts prefer working with DFDs, particularly when they require a clear

understanding of the boundary between existing systems and postulated systems.

DFDs represent the following:

External devices sending and receiving data

Processes that change that data

Data flows themselves

Data storage locations

51

The hierarchical DFD typically consists of a top-level diagram (Level 0) underlain

by cascading lower level diagrams (Level 1, Level 2…) that represent different

parts of the system.

VALID AND NON-VALID DATA FLOWS

Before embarking on developing your own data flow diagram, there are some

general guidelines you should be aware of. Data stores are storage areas and are

static or passive; therefore, having data flow directly from one data store to

another doesn’t make sense because neither initiates the communication.

Data stores maintain data in an internal format, while entities represent people or

systems external to them.

Because data from entities would be difficult because it would be impossible for

the system to know about any communication between them. The only type of

communication that can be modeled is that which the system is expected to know

or react to.

Processes on DFDs have no memory, so it would not make sense to show data

flows between two asynchronous processes (between two processes that may or

may not be active simultaneously) because they may respond to different external

events.

Therefore, data flow should only occur in the following scenarios’:

Between a process and an entity (in either direction)

Between a process and a data store (in either direction)

Between two processes that can run simultaneously

52

Data flow diagramming is a highly effective technique for showing the flow of

information through a system. DFDs are used in the preliminary stages of systems

analysis to help understand the current system and to represent a required system.

The DFDs themselves represent external entities sending and receiving

information (entities), the processes that change information (processes), the

information flows themselves (data flows), and where information is stored (data

stores). The hierarchical DFDs consist of a single top layer (Level 0 or the context

diagram) that can be decomposed into many lower level diagrams (Level 1, Level

2…Level N), each representing different areas of the system.

DFDs are extremely useful in systems analysis as they help structure, the steps in

object-oriented design and analysis. Because DFDs and object technology share

the same syntax constructs, DFDs are appropriate for the OO domain only.

DFDs are a form of information development, and as such provide key insight into

how information is transformed as it passes through a system. Having the skills to

develop DFDs from functional specs and being able to interpret them is a value-

add skill set that is well within the domain of technical communications.

DFD NOTATIONSThe DFD may be partitioned into levels that represent increasing formation flow

and functional details. Four simple notations are used to complete a DFD.

53

These notations are given below:-

Data flow

Process

External Entity

Data Store

Output

DATA FLOW

The data flow is used to describe the movement of information from one part of

the system to another part. Flows represent data in motion. It is a pipe line through

which information flows.

PROCESS

A circle or bubble represents a process that transforms incoming data to outgoing

data. Process shows a part of the system that transforms inputs to outputs.

54

EXTERNAL ENTITY

A square defines a source or destination of system data. External entities represent

any entity that supplies or receive information from the system but is not a part of

the system.

DATA FLOW

The data store represents a logical file. A logical file can represent either a data

store symbol which can represent either a data structure or a physical file on disk.

The data store is used to collect data at rest pr a temporary repository of data. It is

represented by open rectangle.

55

OUTPUT

The output symbol is used when a hard copy is produced and the user of the copies

cannot be clearly specified or there are several users of the output.

56

‘0’-LEVEL DFD

57

‘0’-LEVEL DFD

58

USER_ID, passwordAuthentication

messageCustomer details (name,…age)report

Admin_ID, passwordAuthentication

message

Notification message

SINGLE WINDOW

BASED BANKI

NG SYSTE

M

USER

ADMIN

ReportTransaction notification

Customer A/C no.

Display relevant details

‘1’-LEVEL DFD

59

‘1’-LEVEL DFD

60

SWBBS

USER LOGIN

USER

ADMIN

USER TABLE

ADMIN TABLE

ADMIN LOGIN

1

2

User_ID, passwordAuthentication

message

USER_ID, passwordAuthenticationmessage

User

verifiedDisplay relevant

detailsRequest for dataReceive data

Report

Admi

n verified

Admin_ID, password

AdminID, password

Verification message

Authentication message

Authentication messageAuthentication message

report Notification message

3

‘2’-LEVEL DFD

61

‘2’-LEVEL DFD

62

OPEN ACCOUNT

CHECK

ACCOUN

T

SELECT

OPTIONS

CURRENT

ACCOUNT

SELECT

CHOICES

UPDATE

AND VIEW

CUSTOMER TABLETRANSAC

TION TABLE

REPORT

GENERATIO

N

User

verified

Admi

n verified

A/C PROF

ILESAVIN

G ACCOUNT

DEPOSIT

WITHDRAWTRNC.

DETAILS

option 2

option 1

request response

Transaction notification

Request for report

report

Request for dataReceive data

Save transactionSave

transactionresponse

response

Request for details

Option 2

Request for user info.Fetche

d info.

User

info.

DATABASE DESIGN

63

DATABASE DESIGNDatabase design is the process of producing a detailed data model of a database.

This logical data model contains all the needed logical and physical design choices

and physical storage parameters needed to generate a design in a Data Definition

Language, which can then be used to create a database. A fully attributed data

model contains detailed attributes for each entity.

The term database design can be used to describe many different parts of the

design of an overall database system. Principally, and most correctly, it can be

thought of as the logical design of the base data structures used to store the data. In

the relational model these are the tables and views. In an object database the

entities and relationships map directly to object classes and named relationships.

However, the term database design could also be used to apply to the overall

process of designing, not just the base data structures, but also the forms and

queries used as part of the overall database application within the database

management system (DBMS).

The process of doing database design generally consists of a number of steps

which will be carried out by the database designer. Usually, the designer must:

Determine the relationships between the different data elements.

64

Superimpose a logical structure upon the data on the basis of these

relationships.

THE DESIGN PROCESS

1. Determine the purpose of the database

This helps prepare for the remaining steps.

2. Find and organize the information required

Gather all of the types of information to record in the database, such as

product name and order number.

3. Divide the information into tables

Divide information items into major entities or subjects, such as Products or

Orders. Each subject then becomes a table.

4. Turn information items into columns

Decide what information needs to be stored in each table. Each item

becomes a field, and is displayed as a column in the table.

5. Specify primary keys

Choose each table’s primary key. The primary key is a column, or a set of

columns, that is used to uniquely identify each row. An example might be

User ID or Registration ID.

65

6. Set up the table relationships

Look at each table and decide how the data in one table is related to the data in

other tables. Add fields to tables or create new tables to clarify the relationships, as

necessary.

7. Refine the design

Analyze the design for errors. Create tables and add a few records of sample

data. Check if results come from the tables as expected. Make adjustments

to the design, as needed.

8. Apply the normalization rules

Apply the data normalization rules to see if tables are structured correctly.

Make adjustments to the tables.

DATABASE FORMATA properly designed database provides you with access to up-to-date, accurate

information. Because a correct design is essential to achieving your goals in

working with a database, investing the time required to learn the principles of

good design makes sense. In the end, you are much more likely to end up with a

database that meets your needs and can easily accommodate change. This article

provides guidelines for planning a database. You will learn how to decide what

information you need, how to divide that information into the appropriate tables

and columns, and how those tables relate to each other.

66

In this project, we have databases wherever it is required. The databases are

required for the entities (as shown in the DFD diagram) present in the project.

The entities are:

USER TABLE

ADMIN TABLE

CUSTOMER TABLE

TRANSCATION TABLE

USER TABLE

The required fields are:

UserID

Pwd

User name

EmpID

Field Type Size(Bytes) Description

UserID varchar 15 Primary Key

Pwd varchar 20 Password

User Name varchar 30 User Name

EmpID varchar 30 Employee ID

67

ADMIN TABLE

The required fields are:

AdminID

Password

Field Type Size(Bytes) Description

AdminID varchar 15 Primary Key

Pwd varchar 20 Password

CUSTOMER TABLE

The required fields are:

Name

PName

Address

68

Gender

MobNo.

A/C

Photo

Sign

AType

Nname

Field Type Size(Bytes) Description

Name varchar 30 Name(Customer)

PName varchar 30 Parent Name

Address varchar 50 Address

Gender varchar 6 Gender(Customer)

MobNo. number 10 Mobile Number

A/C int 12 Account No.

(Primary Key)

Photo mediumblob 1 Photo

Sign mediumblob 1 Signature

AType varchar 10 Account Type

Nname varchar 30 Nominee Name

69

TRANSACTIONTABLE

The required fields are:

A/C No.

Name

Amount

Ttype

70

Field Type Size(Bytes) Description

A/C No. int 12 Account No.

Name varchar 30 Name(Customer)

Amount number 15 Amount

Ttype varchar 10 Transaction Type

E-R DIAGRAM

71

E-R DIAGRAMEntity–Relationship model (ER model) in software engineering is a data model

for describing a database in an abstract way. This article refers to the techniques

proposed in Peter Chen's 1976 paper.However, variants of the idea existed

previously, and have been devised subsequently such as super type and subtype

data entitiesand commonality relationships.

An ER model is an abstract way of describing a database. In the case of a

relational database, which stores data in tables, some of the data in these tables

point to data in other tables - for instance, your entry in the database could point to

several entries for each of the phone numbers that are yours.

The ER model would say that you are an entity, and each phone number is an

entity, and the relationship between you and the phone numbers is 'has a phone

number'. Diagrams created to design these entities and relationships are called

entity–relationship diagrams or ER diagrams.

Using the three schema approach to software engineering, there are three levels of

ER models that may be developed.

72

LEVELS OF E-R MODEL

THE CONCEPTUAL DATA MODEL:

This is the highest level ER model in that it contains the least granular detail

but establishes the overall scope of what is to be included within the model

set.

The conceptual ER model normally defines master reference data entities

that are commonly used by the organization.

Developing an enterprise-wide conceptual ER model is useful to support

documenting the data architecture for an organization. A conceptual ER

model may be used as the foundation for one or more logical data models.

The purpose of the conceptual ER model is then to establish structural

metadata commonality for the master data entities between the set of logical

ER models.

The conceptual data model may be used to form commonality relationships

between ER models as a basis for data model integration.

THE LOGICAL DATA MODEL:

73

A logical ER model does not require a conceptual ER model, especially if the

scope of the logical ER model includes only the development of a distinct

information system. The logical ER model contains more detail than the

conceptual ER model.

In addition to master data entities, operational and transactional data entities are

now defined. The details of each data entity are developed and the entity

relationships between these data entities are established. The logical ER model is

however developed independent of technology into which it will be implemented.

An entity may be a physical object such as a house or a car, an event such as a

house sale or a car service, or a concept such as a customer transaction or order.

Although the term entity is the one most commonly used, following Chen we

should really distinguish between an entity and an entity-type. An entity-type is a

category.

Logical data models represent the abstract structure of a domain of information.

They are often diagrammatic in nature and are most typically used in business

processes that seek to capture things of importance to an organization and how

they relate to one another. Once validated and approved, the logical data model

can become the basis of a physical data model and inform the design of a database.

An entity, strictly speaking, is an instance of a given entity-type. There are usually

many instances of an entity-type. Because the term entity-type is somewhat

cumbersome, most people tend to use the term entity as a synonym for this term.

74

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a

mathematical theorem.

A relationship captures how entities are related to one another. Relationships can

be thought of as verbs, linking two or more nouns.

THE PHYSICAL MODEL:

One or more physical ER models may be developed from each logical ER model.

The physical ER model is normally developed to be instantiated as a database.

Therefore, each physical ER model must contain enough detail to produce a

database and each physical ER model is technology dependent since each database

management system is somewhat different.

The physical model is normally forward engineered to instantiate the structural

metadata into a database management system as relational database objects such as

database tables, database indexes such as unique key indexes, and database

constraints such as a foreign key constraint or a commonality constraint.

The ER model is also normally used to design modifications to the relational

database objects and to maintain the structural metadata of the database.

The first stage of information system design uses these models during the

requirements analysis to describe information needs or the type of information that

is to be stored in a database.

The data modeling technique can be used to describe any ontology (i.e. an

overview and classifications of used terms and their relationships) for a certain

75

area of interest. In the case of the design of an information system that is based on

a database, the conceptual data model is, at a later stage (usually called logical

design), mapped to a logical data model, such as the relational model; this in turn

is mapped to a physical model during physical design. Note that sometimes, both

of these phases are referred to as "physical design".

E-R MODELLINGThe building blocks are:

Entities

Attributes

Relationships

ENTITIES

In a database model, each object that you wish to track in the database is known as

an entity. Normally, each entity is stored in a database table and every instance of

an entity corresponds to a row in that table. In an ER diagram, each entity is

depicted as a rectangular box with the name of the entity contained within it.

For example, a database containing information about individual people would

likely have an entity called Person. This would correspond to a table with the same

name in the database and every person tracked in the database would be an

instance of that Person entity and have a corresponding row in the Person table.

76

Database designers creating an E-R diagram would draw the Person entity using a

shape similar to this:

They would then repeat the process to create a rectangular box for each entity in

the data model.

Here’s a depiction of the Person entity in that format:

That covers the “Entity” part of Entity-Relationship diagrams. Now let’s take a

look at displaying data relationships.

RELATIONSHIP

77

PK

Person

Person

PersonID

FirstName

LastName

BirthDate

The power of the E-R diagram lies in its ability to accurately display information

about the relationships between entities. For example, we might track information

in our database about the city where each person lives.

Information about the city itself is tracked within a City entity and a relationship is

used to tie together Person and City instances.

Relationships are normally given names that are verbs, while attributes and entities

are named after nouns. This convention makes it easy to express relationships. For

example, if we name our Person/City relationship “Lives In”, we can string them

together to say “A person lives in a city”. We express relationships in E-R

diagrams by drawing a line between the related entities and placing a diamond

shape that contains the relationship name in the middle of the line. Here’s how our

Person/City relationship would look:

In data modeling, collections of data elements are grouped into data tables.

The data tables contain groups of data field names (known in the science world as

database attributes). Tables are linked by key fields. A primary key assigns that

field’s special order to a table: for example, the DoctorLastName field might be

assigned as the primary key of the Doctor table (#correction: PK is supposed to be

unique. People can have same last name. may be introduce a new field called

DoctorID). A table can also have a foreign key which indicates that field is linked

to the primary key of another table.

A complex data model can involve hundreds of related tables. A renowned

computer scientist, C.J. Date, created a systematic method to organize database

models. Date’s steps for organizing database tables and their keys are called

Database Normalization. Database normalization avoids certain hidden database

78

design errors (delete anomalies or update anomalies). In real life the process of

database normalization ends up breaking tables into a larger number of smaller

tables, so there are common sense data modeling tactics called de-normalization

which combine tables in practical ways.

In real world data models careful design is critical because as the data grows

voluminous, tables linked by keys must be used to speed up programmed retrieval

of data. If data modeling is poor, even a computer applications system with just a

million records will give the end-users unacceptable response time delays.

For this reason data modeling is a keystone in the skills needed by a modern

software developer.

ATTRIBUTES

Of course, tracking entities alone is not sufficient to develop a data model.

Databases contain information about each entity. This information is tracked in

individual fields known as attributes, which normally correspond to the columns

of a database table.

For example, the Person entity might have attributes corresponding to the person’s

first and last name, date of birth, and a unique person identifier. Each of these

attributes in an E-R diagram as an oval, as shown in the figure below:

79

LastNameFirstName

Notice that the text in the attribute ovals is formatted slightly differently. There are

two text formatting features used to convey additional information about an

entity’s attributes. First, some fields are displayed in a boldface font. These are

required fields, similar to the NOT NULL database constraint. Each instance of an

entity must contain information in the FirstName, LastName and PersonID

attributes. Also, one attribute is underlined, indicating that it serves as the

database’s primary key.

In this example, personID serves as the primary key.

Using this format can be somewhat cumbersome in a diagram containing

information about entities with many attributes. Therefore, many database

designers prefer to use an alternate format that lists an entity’s attributes in tabular

form under the name of the entity.

CARDINALITY IN E-R MODELIn data modeling, the cardinality of one data table with respect to another data

table is a critical aspect of database design. Relationships between data tables

define cardinality when explaining how each table links to another. In the

relational model, tables can be related as any of: many-to-many, many-to-one

(rev. one-to-many), or one-to-one. This is said to be the cardinality of a given table

80

PERSON

PersonID BirthDate

in relation to another. For example, consider a database designed to keep track of

college records. Such a database could have many tables like:

A Teacher table full of teacher information

A Student table with student information

And a Department table with an entry for each department of the college.

In that model:

There is a many-to-many relationship between the records in the teachers

table and records in the student table (teacher have many students, and a

student could have several teachers);

A one-to-many relation between the department table and the teacher table

(each teacher work for one department, but one department could have

many teachers). One-to-one relationship is mostly used to split a table in

two in order to optimize access or limit the visibility of some information.

In the college example, such a relationship could be used to keep apart

teacher’s personal or administrative information.

81

E-R DIAGRAM

82

83

USER TABLE TRANSACTION TABLE

USER

NAME

AMOUNT

GET ACTION

*A/C No.

Ttype

EmpID NAME

PWDUSER_ID

ADMIN TABLE

CUSTOMER TABLE A/C*

PNAME

PWD

ADMIN_ID

VIEW

VIEW

SIGN

PHOTO

1

1

N

N

1

N

N

NAME

AType Nnam

e

Gender

MobNo.

Address

N

CONCLUSION

CONCLUSIONThis application software (Single Window Based Banking System) facilitates its

user to create accounts of its customers along with several banking transactions.

This project helps users in several ways i.e. by allowing money to deposit, and

withdrawal facility in easy manners and several such features.

Administration has a privilege to create, modify and delete the log history and

various contents available in cache server. User can create, login and operate the

84

software safely. The development of software includes so many people like user

system developer, user of system and the management, it is important to identify

the system requirements by properly collecting required data to interact with user

of the system.

Proper design builds upon this foundation to give a blue print, which is actually

implemented by the developers. On realizing the importance of systematic

documentation all the processes are implemented using a software engineering

approach.

Working in a live environment enables one to appreciate the intricacies involved

in the System Development Life Cycle (SDLC). We have gained a lot of practical

knowledge from this project, which we think, shall make us stand in a good state

in thefuture.

85

BIBLIOGRAPHY

BIBLIOGRAPHY

WEBSITE REFERENCE

http://www.wikipedia.com

http://www.codeproject.com

http://www.logicatwork.com

86

BOOK REFERENCE

Complete reference in JAVA (Herbert Shield)

Complete reference MySQL (VikramVaswani)

87