198970820 p-oooooooooo

1
Get Homework/Assignment Done
Homeworkping.com
Homework Help
https://www.homeworkping.com/
Research Paper help
Online Tutoring
click here for freelancing tutoring sites

2
INTRODUCTION
INTRODUCTION
Thissoftware 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.

3
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.

4
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.

5
 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.

6
OBJECTIVE
OBJECTIVE
In 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.

7
 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.

9
HARDWARE
REQUIREMENT
HARDWARE
REQUIREMENT
RAM

10
 Minimum 512 MB
PROCESSOR
 Processor 1.8 GHz or higher
HARD DISK
 Minimum 5 GB or above
OTHERS
 Monitor
 Keyboard
 Mouse

12
SOFTWARE
REQUIREMENT
FRONT END
 Java 1.6
BACK END
 MySQL 5.1
OPERATING SYSTEM
 Windows XP or later

14
TECHNOLOGY USED
This project is a web based application that is developed in JAVAand having
MySQL 5.1 as back end.
 JAVA1.6
 MySQL 5.1

15
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
 Java is simple, easy to design, easy to write, and therefore easy to compile,
debug, and learn than any other programming languages.

16
 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.

17
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
Several dangerous features of C &C++ eliminated
o No memory pointers
o No pre-processor
o Array index limit checking
Automatic memory management

18
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.
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.

19
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

20
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
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.

21
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.
2. MySQL does not support ROLE, COMMIT, and stored procedures in
versions less than 5.0
3. Transactions are not handled very efficiently.

23
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.

25
FEASIBILITY STUDY
Feasibility 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)
 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.

26
 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 costand 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
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

27
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.
Since, we are using rapid development tools (Net beans). Therefore the
software will be easily completed on schedule.

28
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
COST
the cost required in the proposed system is comparatively less to the existing
system.
EFFORT

29
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.
TIME
Also 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. .

31
SDLC
The 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”.
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.

32
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 codemay 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.
Certain functionality may be out of scopeofthe project as a function of costor 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

33
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
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.

34
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.

36
WATERFALL MODEL
The 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
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.

38
PHASES OF WATERFALL MODEL
 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.

39
DESIGN
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.

40
OPEARATION & MAINTENANCE
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.

42
ADVANTAGES
 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.

44
DISADVANTAGES
 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.

46
LIMITATION
The 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 supportsingle branch of bank. In future
enhancement this problem will be faded out.

48
FUTURE ENHANCEMENTS
Enhancements 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 USERS
The 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.

50
DATA FLOW DIAGRAM
A 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.

51
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

52
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

53
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 NOTATIONS
The DFD may be partitioned into levels that represent increasing formation flow
and functional details. Four simple notations are used to complete a DFD.

54
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.

55
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.

56
OUTPUT
The output symbol is used when a hard copyis produced and the user of the copies
cannot be clearly specified or there are several users of the output.

64
DATABASE DESIGN
Database design is the process ofproducing 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.
 Superimpose a logical structure upon the data on the basis of these
relationships.

65
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.
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.

66
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 FORMAT
A 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.
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

67
 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

68
ADMIN TABLE
 AdminID
 Password
AdminID varchar 15 Primary Key
Pwd varchar 20 Password
CUSTOMER TABLE
 Name
 PName
 Address
 Gender
 MobNo.
 A/C
 Photo

69
 Sign
 AType
 Nname
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

70
TRANSACTIONTABLE
 A/C No.
 Name
 Amount
 Ttype
A/C No. int 12 Account No.
Name varchar 30 Name(Customer)
Amount number 15 Amount
Ttype varchar 10 Transaction Type

72
E-R DIAGRAM
Entity–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.

73
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:
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.

74
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.
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.

75
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
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".

76
E-R MODELLING
The 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.
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.
Person

77
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
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
PK
Person
PersonID
FirstName
LastName
BirthDate

78
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
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.

79
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:
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.
PERSON
LastNameFirstName
PersonID
BirthDate

80
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 MODEL
In data modeling, the cardinality of one data table with respect to another data table
is a critical aspectof 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
in relation to another. For example, consider a databasedesigned to keep track of
college records. Sucha 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

81
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.

84
CONCLUSION
This 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
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.

86
BIBLIOGRAPHY
WEBSITE REFERENCE
 http://www.wikipedia.com
 http://www.codeproject.com
 http://www.logicatwork.com
BOOK REFERENCE
 Complete reference in JAVA (Herbert Shield)
 Complete reference MySQL (VikramVaswani)

198970820 p-oooooooooo

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 198970820 p-oooooooooo

Similar to 198970820 p-oooooooooo (20)

More from homeworkping4

More from homeworkping4 (20)

Recently uploaded

Recently uploaded (20)

198970820 p-oooooooooo