Beruflich Dokumente
Kultur Dokumente
INTRODUCTION
This software 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. 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.
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. 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
OBJECTIVE
In our project, we are developing software 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 users 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.
SYSTEM SPECIFICATION
HARDWARE REQUIREMENT
HARDWARE REQUIREMENT
RAM
Minimum 512 MB
PROCESSOR
Minimum 5 GB or above
OTHERS
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 USED
This project is a web based application that is developed in JAVA and having MySQL 5.1 as back end. JAVA 1.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
Java is simple, easy to design, easy to write, and therefore easy to compile, debug, and learn than any other programming languages.
14
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
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. o Even 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.
17
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 databasedriven 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 DBMSs.
19
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 DBMSs, 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.
20
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 STUDY
23
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.
24
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. Costbased study Its important to identify cost and benefit factors, which can be categorized as follows: 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 acts.
25
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.
26
COST
the cost required in the proposed system is comparatively less to the existing system.
EFFORT
27
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. .
28
SDLC
29
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.
30
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. 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
31
are ever disputes, any ambiguity of what was promised to the client can be clarified.
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 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 republished with 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 developmentto describe a critical view of a commonly used software development practice.
35
WATERFALL MODEL
36
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.
37
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.
38
39
ADVANTAGES
40
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 dont have to think which counter he have to approach for cash withdrawal or cash deposition. It will reduce the time consumed in one transaction. Employees productivity time increases at workplace. It can be used for keeping log i.e. user record, employee record etc.
41
DISADVANTAGES
42
DISADVANTAGES
Since banks are wholly dependent on software, and we all know at any time software can crash, this can lead to chaos.
Since there is no level of security, anyone can breach the software easily.
43
LIMITATION
44
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:
45
FUTURE ENHANCEMENTS
46
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:
47
48
(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 systems 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.
49
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. DFDs 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
50
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.
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 2Level 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 valueadd 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.
52
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.
53
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.
54
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.
55
0-LEVEL DFD
56
0-LEVEL DFD
57
1-LEVEL DFD
58
1-LEVEL DFD
59
2-LEVEL DFD
60
2-LEVEL DFD
61
DATABASE DESIGN
62
DATABASE DESIGN
Database 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. Superimpose a logical structure upon the data on the basis of these relationships.
63
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 tables 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.
64
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
65
USER TABLE
The required fields are: UserID Pwd User name EmpID
Size(Bytes) 15 20 30 30
66
ADMIN TABLE
The required fields are: AdminID Password
Size(Bytes) 15 20
CUSTOMER TABLE
The required fields are: Name PName Address Gender MobNo. A/C Photo
67
Size(Bytes) 30 30 50 6 10 12
Description Name(Customer) Parent Name Address Gender(Customer) Mobile Number Account No. (Primary Key)
1 1 10 30
68
TRANSACTION TABLE
The required fields are: A/C No. Name Amount Ttype Field A/C No. Name Amount Ttype Type int varchar number varchar Size(Bytes) 12 30 15 10 Description Account No. Name(Customer) Amount Transaction Type
69
E-R DIAGRAM
70
E-R DIAGRAM
EntityRelationship 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 entities and 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 entityrelationship diagrams or ER diagrams. Using the three schema approach to software engineering, there are three levels of ER models that may be developed.
71
72
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.
73
74
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:
Person
They would then repeat the process to create a rectangular box for each entity in the data model.
75
That covers the Entity part of Entity-Relationship diagrams. Now lets 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
76
shape that contains the relationship name in the middle of the line. Heres 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 fields 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. Dates 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.
77
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 correspondin g to the persons 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:
FirstName PersonID
LastName BirthDate
PERSON
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 entitys 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 databases primary key.
78
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 entitys attributes in tabular form under the name of the entity.
order to optimize access or limit the visibility of some information. In the college example, such a relationship could be used to keep apart teachers personal or administrative information.
80
E-R DIAGRAM
81
CONCLUSION
82
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.
83
BIBLIOGRAPHY
84
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 (Vikram Vaswani)
85