Contents:

1.0 Introduction 2

1.1 Purpose 2

1.2 Scope 2

1.3 Definition, Acronyms 2

1.4 Technologies to be Used 3

1.4.1 NetBeans 3

1.4.2 Glassfish 4

1.4.3 UML Designing Tool 4

1.4.4 Back End DB2 4

1.4.5 Front End JSP 8

1.5 Overview 9

1.6 Use Case Design 9

1.7 Class Diagram 12

1.8 Sequence Diagram 13

1.9 ER Diagram 16

2.0 Tables Description 19

2.1 Activity Diagram 22

2.2 Screen Shots 24

Insurance System With Tracking Manager Page 2

1.0 INTRODUCTION 1.1 Purpose-

Insurance system with tracking manager is a web application software which provides insurance

services to users in different fields which includes Life insurance, Medical insurance, Motor insurance and

House insurance. It also provides the loan facility for motor purchasing.

1.2 Scope-

This application software has three types of users

A. Policy Holders

B. Company officials

C. Administrator

The existing policy holders can login and view their profile, pay premium and view the

existing policy details.

The companies officials can login to the system and can generate new policies grant

loans to the existing policy holders and add new schemes but it should be approved

legally by administrator and then these policies will be updated.

The administrator approves the policies generated by company officials and only the

administrator has the right to update any information.

1.3 Definition, Acronyms & Abbreviations-

Policy Holders-

They are the existing policy holders, they are provided with particular username and

password to access their profile.

Company Officials- The company officials will be given a particular username and password from which they can

login and generate policies and view policy holder details.

Administrator- There will be an admin, who will have an admin id and password and he/she can give

approval of new policies generated and can alter information.

XML (Extensible Markup Language)-

It is a flexible way to create common information formats and share both the format and

data on the World Wide Web (WWW), internets or elsewhere.

DB-2 express edition ‘C’- A database management system that provides a flexible and efficient database platform to

maintain records of policy holders, company officials and administrator.

J2EE- Java 2 enterprise edition is a programming platform which is a part of a java platform for developing

and running distributed java.

Insurance System With Tracking Manager Page 3

1.4 Technologies to be used-

1.4.1 NETBEANS IDE-

NetBeans IDE

NetBeans IDE 7.2 in Microsoft Windows 7.

Developer(s) Oracle Corporation

Stable release 7.3 / February 21, 2013

Written in Java

Operating system Cross-platform (multi-platform)

Platform Java SE

Available in Multilingual

Type Java IDE

License CDDL or GPL2 + "certain source

files" allowclasspath exception

Website netbeans.org

NetBeans is an integrated development environment (IDE) for developing primarily with Java, but

also with other languages, in particular PHP,C/C++, and HTML5. It is also an application

platform framework for Java desktop applications and others. The NetBeans IDE is written in Java and can

run on Windows, OS X, Linux, Solaris and other platforms supporting a compatible JVM. The NetBeans

Platform allows applications to be developed from a set of modular software components called modules.

Applications based on the NetBeans Platform (including the NetBeans IDE itself) can be extended by third

party developers.

Insurance System With Tracking Manager Page 4

1.4.2 Glassfish Server-

Glassfish is an open-source application server project started by Sun Microsystems for the Java

EE platform and now sponsored by Oracle Corporation. The supported version is called Oracle Glassfish

Server. Glassfish is free software, dual-licensed under two free software licenses: the Common (CDDL)

and the GNU General Public License (GPL) with the class path. Glassfish is the reference

implementation of Java EE and as such supports Enterprise JavaBeans, JPA, Java Server

Faces, JMS, RMI, JavaServer Pages, servlets, etc. This allows developers to create enterprise

applications that are portable and scalable, and that integrate with legacy technologies. Optional

components can also be installed for additional services. Glassfish is based on source code released by

Sun and Oracle Corporation's TopLink persistence system. It uses a derivative of Apache Tomcat as

the servlet container for serving Web content, with an added component called Grizzly which uses

Java New I/O (NIO) for scalability and speed.

1.4.3 UML MODELLING TOOL

RATIONAL ROSE-

Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool

intended for visual modeling and component construction of enterprise-level software applications. In much

the same way a theatrical director blocks out a play, a software designer uses Rational Rose to visually

create (model) the framework for an application by blocking out classes with actors (stick figures), use

case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence diagram

using drag-and-drop symbols. Rational Rose documents the diagram as it is being constructed and then

generates code in the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition

Language.

Two popular features of Rational Rose are its ability to provide iterative development and round-trip

engineering. Rational Rose allows designers to take advantage of iterative development (sometimes called

evolutionary development) because the new application can be created in stages with the output of one

iteration becoming the input to the next. (This is in contrast to waterfall development where the whole

project is completed from start to finish before a user gets to try it out.) Then, as the developer begins to

understand how the components interact and makes modifications in the design, Rational Rose can

perform what is called "round-trip engineering" by going back and updating the rest of the model to ensure

the code remains consistent.

1.4.4 DATABASE PLATFORM- DB2

Developer(s) IBM

Insurance System With Tracking Manager Page 5

Initial release 1983

Development status Active

Written in C, C++

Operating system Cross-platform

Available in English

Type RDBMS

License Proprietary EULA

The name DB2 was first given to the Database Management System or DBMS in 1983 when IBM released DB2 on its MVS mainframe platform

[1]. Prior to this, a similar product was named SQL/DS on the

VM platform. Prior to that in the mid 1970's IBM released the QBE relational database product for the VM platform with a table-oriented "Query By Example" front-end which produced a linear-syntax language that was a recognizable precursor to QBE and drove transactions to its relational database. Later the QMF feature of DB2 produced real SQL and brought the same "QBE" look and feel to DB2. The System 38 platform also contained a relational DBMS. System Relational, or System R, was a research prototype developed in the 1970s. DB2 has its roots back to the beginning of the 1970s when E.F. Codd, working for IBM, described the theory of relational databases and in June 1970 published the model for data manipulation.

To apply the model Codd needed a relational database language he named Alpha. At the time IBM didn't believe in the potential of Codd's ideas, leaving the implementation to a group of programmers not under Codd's supervision, who violated several fundamentals of Codd's relational model; the result was Structured English QUEry Language or SEQUEL. When IBM released its first relational database product, they wanted to have a commercial-quality sublanguage as well, so it overhauled SEQUEL and renamed the basically new language (System Query Language) SQL to differentiate it from SEQUEL. IBM bought Metaphor Computer Systems to utilize their GUI interface and encapsulating SQL platform that had already been in use since the mid 80's.

When Informix acquired Illustra and made their database engine an object-SQL DBMS by introducing their Universal Server, both Oracle and IBM followed suit by changing their database engines to be capable of object-relational extensions. In 2001, IBM bought Informix and in the following years incorporated Informix technology into the DB2 product suite. Today, DB2 can technically be considered to be an object-SQL DBMS.

For some years DB2, as a full-function DBMS, was exclusively available on IBM mainframes. Later IBM brought DB2 to other platforms, including OS/2, UNIX and Windows servers, then Linux (including Linux on zSeries) and PDAs. This process occurred through the 1990s. The inspiration for the mainframe version of DB2's architecture came in part from IBM IMS, a hierarchical database, and its dedicated

Insurance System With Tracking Manager Page 6

database manipulation language, IBM DL/I. DB2 is also embedded in the i5/OS operating system for IBM System i (iSeries, formerly the AS/400), and versions are available for z/VSE and z/VM.

An earlier version of the code that would become DB2 LUW (Linux, Unix, Windows) was part of an Extended Edition component of OS/2 called Database Manager. IBM extended the functionality of Database Manager a number of times, including the addition of distributed database functionality that allowed shared access to a database in a remote location on a LAN. Eventually IBM declared that insurmountable complexity existed in the Database Manager code, and took the difficult decision to completely rewrite the software in their Toronto Lab. The new version of Database Manager, called DB2 like its mainframe parent, ran on the OS/2 and RS/6000 platforms, was called DB2/2 and DB2/6000 respectively. Other versions of DB2, with different code bases, followed the same '/' naming convention and became DB2/400 (for the AS/400), DB2/VSE (for the DOS/VSE environment) and DB2/VM (for the VM operating system). IBM lawyers stopped this handy naming convention from being used and decided that all products needed to be called "product FOR platform" (for example, DB2 for OS/390).

The next iteration of the mainframe and the server-based products were named DB2 Universal Database (or DB2 UDB), a name that had already been used for the Linux-Unix-Windows version, with the introduction of widespread confusion over which version (mainframe or server) of the DBMS was being referred to. At this point, the mainframe version of DB2 and the server version of DB2 were coded in entirely different languages (PL/S for the mainframe and C++ for the server), but shared similar functionality and used a common architecture for SQL optimization: the Starburst Optimizer.

Over the years DB2 has both exploited and driven numerous hardware enhancements, particularly on IBM System z with such features as Parallel Sysplex data sharing. In fact, DB2 UDB Version 8 for z/OS now requires a 64-bit system and cannot run on earlier processors, and DB2 for z/OS maintains certain unique software differences in order to serve its sophisticated customers. Although the ultimate expression of software-hardware co-evolution is the IBM mainframe, to some extent that phenomenon occurs on other platforms as well, as IBM's software engineers collaborate with their hardware counterparts.

In the mid-1990s, IBM released a clustered DB2 implementation called DB2 Parallel Edition, which initially ran on AIX. This edition allowed scalability by providing a shared nothing architecture, in which a single large database is partitioned across multiple DB2 servers that communicate over a high-speed interconnect. This DB2 edition was eventually ported to all Linux, UNIX, and Windows (LUW) platforms and was renamed to DB2 Extended Enterprise Edition (EEE). IBM now refers to this product as the Database Partitioning Feature (DPF) and sells it as an add-on to their flagship DB2 Enterprise product.

In mid 2006, IBM announced "Viper," which is the codename for DB2 9 on both distributed platforms and z/OS. DB2 9 for z/OS was announced in early 2007. IBM claimed that the new DB2 was the first relational database to store XML "natively". Other enhancements include OLTP-related improvements for distributed platforms, business intelligence/data warehousing-related improvements for z/OS, more self-tuning and self-managing features, additional 64-bit exploitation (especially for virtual storage on z/OS), stored procedure performance enhancements for z/OS, and continued convergence of the SQL vocabularies

Improved operational efficiencies for "out-of-the-box" DB2 CPU savings

Unsurpassed resiliency for business-critical information

Rapid application and warehouse deployment for business growth

Enhanced business analytics and data visualization solutions with QMF

Selected features that deliver these valuable benefits to any business include:

When compared to running on DB2 9, depending on the workload, customers may experience reduced CPU utilization

When compared to running DB2 9, up to five to ten times more concurrent users on a single subsystem by avoiding memory constraints

Greater concurrency for data management, data definition, and data access, including DDL, BIND, REBIND, PREPARE, utilities, and SQL

Insurance System With Tracking Manager Page 7

Additional online changes for data definitions, utilities, and subsystems

Improved security with better granularity for administrative privileges, data masking, and audit capabilities

Temporal or versioned data to understand system and business times at the database level (Bi-temporal feature is not available on Oracle or any other competing RDBMS products)

pureXML™ and SQL enhancements to simplify portability from other database solutions

Productivity improved for database administrators, application programmers, and systems administrators

QMF Classic Edition, an optional for-charge feature, providing greater interoperability with other programs plus improved queries, forms, diagnostics, performance, and resource control

QMF Enterprise Edition, an optional for-charge feature, supporting QMF-based dashboards with visually rich page-based reports, an enhanced security model, support for HTML, PDF, or Flash QMF report and dashboard outputs and simplified content authoring

IBM and SAP have cooperated very closely on DB2 10 for z/OS, so now SAP users can benefit from DB2's scalability and performance enhancements significantly that allow for further growth of SAP applications and consolidation of hardware landscape at the same time.

Competition

IDC's Worldwide Database Management Systems 2009–2013 Forecast and 2008 Vendor Shares[2]

ranks Oracle database as the leader in DBMS marketing share, followed by IBM DB2 and then Microsoft SQL Server. Other competitors include open source products such as Firebird, PostgreSQL, MySQL and Ingres, and niche players such as Sybase and MaxDB.

Technical information

DB2 can be administered from either the command-line or a GUI. The command-line interface requires more knowledge of the product but can be more easily scripted and automated. The GUI is a multi-platform Java client that contains a variety of wizards suitable for novice users. DB2 supports both SQL and XQuery. DB2 has native implementation of XML data storage, where XML data is stored as XML (not as relational data or CLOB data) for faster access using XQuery. DB2 has APIs for REXX, PL/I, COBOL, RPG, FORTRAN, C++, C, Delphi, .NET CLI, Java, Python, Perl, PHP, Ruby, and many other programming languages. DB2 also supports integration into the Eclipse and Visual Studio integrated development environments.

Error processing

An important feature of DB2 computer programs is error handling. The SQL communications area (SQLCA) structure was once used exclusively within a DB2 program to return error information to the application program after every SQL statement was executed. The primary, but not singularly useful, error diagnostic is held in the field SQLCODE within the SQLCA block.

The SQL return code values are:

0 means successful execution.

A positive number means successful execution with one or more warnings. An example is +100 , which means no rows found.

A negative number means unsuccessful with an error. An example is -911, which means a lock timeout (or deadlock) has occurred, triggering a rollback.

Later versions of DB2 added functionality and complexity to the execution of SQL. Multiple errors or warnings could be returned by the execution of an SQL statement; it may, for example, have initiated a Database Trigger and other SQL statements. Instead of the original SQLCA, error information should now be retrieved by successive executions of a GET DIAGNOSTICS statement.

Insurance System With Tracking Manager Page 8

1.4.5 About Front End.

About JSP-

JSP technology offers a simple way to create dynamic web pages that are platform independent and server independent. It includes html language embedded within it. Java Server Pages (JSP) technology provides a simplified, fast way to create web pages that display dynamically-generated content. The JSP specification, developed through an industry-wide initiative led by Sun Microsystems, defines the

interaction between the server and the JSP page, and describes the format and syntax of the page. JSP

pages use XML tags and script lets written in the Java programming language to encapsulate the logic that generates the content for the page. It passes any formatting (HTML or XML) tags directly back to the response page. In this way, JSP pages separate the page logic from its design and display. JSP technology is part of the Java technology family. JSP pages are compiled into servlets and may call JavaBeans components (beans) or Enterprise JavaBeans components (enterprise beans) to perform processing on the server. As such, JSP technology is a key component in a highly scalable architecture for web-based applications. JSP pages are not restricted to any specific platform or web server. The JSP specification represents a broad spectrum of industry input.

Java Server Pages (JSP) is a technology that helps software developers create dynamically

generated web pages based on HTML, XML, or other document types. Released in 1999 by Sun

Microsystems], JSP is similar to PHP, but it uses the Java programming language. To deploy and run, a

compatible web server with a servlet container (such as Apache Tomcat) is required with it.

Overview:

Architecturally, JSP may be viewed as a high-level abstraction of Java servlets. JSPs are translated into

servlets at runtime; each JSP's servlet is cached and re-used until the original JSP is modified. JSP can be

used independently or as the view component of a server-side model–view–controller design, normally

with JavaBeans as the model and Java servlets (or a framework such as Apache Struts) as the controller.

This is a type of Model 2 architecture. JSP allows Java code and certain pre-defined actions to be

interleaved with static web markup content, with the resulting page being compiled and executed on the

server to deliver a document. The compiled pages (and any dependent Java libraries) use Java byte code

rather than a native software format. Like any other Java program, they must be executed within a Java

virtual machine (JVM) that integrates with the server's host operating system to provide an abstract

platform-neutral environment. JSP pages are usually used to deliver HTML and XML documents, but

through the use of Output Stream, they can deliver other types of data as well. JSP pages use several

delimiters for scripting functions. The most basic is <% ... %>, which encloses a JSP script let. A script let

is a fragment of Java code that is run when the user requests the page. Other common delimiters include

<%= ... %> for expressions, where the value of the expression is placed into the page delivered to the

user, and directives, denoted with <%@ ... %>. Java code is not required to be complete (self contained)

within its script let element block, but can straddle markup content providing the page as a whole is

syntactically correct. For example, any Java if/for/while blocks opened in one script let element must be

correctly closed in a later element for the page to successfully compile. Markup which falls inside a split

block of code is subject to that code, so markup inside an if block will only appear in the output when the if

condition evaluates to true; likewise, markup inside a loop construct may appear multiple times in the

output depending upon how many times the loop body runs.

Comparison with similar technologies

JSP pages are similar to PHP pages and ASP.NET Web Forms, in that all three add server-side code to an HTML page. However, all three terms refer to a different component of the system. JSP refers to the JSP pages, which can be used alone, with Java servlets, or with a framework such as Apache Struts. PHP is itself a programming language, designed for dynamic Web pages. ASP.net is a framework comparable to Struts or Java Server Faces that uses pages called Web Forms. While JSP pages use the Java language, ASP.NET pages can use any .NET-compatible language (usually C#).ASP.NET is designed for

Insurance System With Tracking Manager Page 9

a Microsoft Windows web server, while PHP and Java server technologies (including JSP) support Windows or GNU/Linux, among other platforms.

Criticism

In 2000, Jason Hunter criticized JSP for either tempting or requiring the programmer to mix Java code and HTML markup, although he acknowledged it would "wean people off of" Microsoft's Active Server Pages. Later, he added a note to his site saying that JSP had improved since 2000, but also cited its competitors, Apache Velocity and Tea.

1.5 Overview-

Existing System-

Policy holders can view the details about policies.

Discussion forum.

Proposed System-

Existing policy holders can track policies, pay premium and calculate EMI (on loans)

Admin is responsible for authentication

Company officials generate policies and respond to the queries asked by users in

discussion forum

Drawbacks-

People of remote areas who don’t have knowledge about internet can’t use this application.

Our plan-

To connect all policy holders to company officials through discussion forum

To interact users by providing attractive policies and loan schemes

To provide online premium paying facility to the policy holder

1.6 USE CASE MODEL

In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying use cases. In 1992 his co-authored book[1] helped to popularize the technique for capturing functional requirements, especially in software development. Originally he used the terms usage scenarios and usage case – the latter being a direct translation of his Swedish term användningsfall – but found that neither of these terms sounded natural in English, and eventually he settled on use case.[2] Since then, others have contributed to improving this technique, notably including Alistair Cockburn.

Cockburn recognizes that projects may not always need detailed "fully-dressed" use cases. He describes a Casual use case with the fields

Title (goal)

Primary Actor

Scope

Level

(Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.

Insurance System With Tracking Manager Page 10

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both." Actors are always stakeholders, but many stakeholders are not actors, since they "never interact directly with the system, even though they have the right to care how the system behaves." For example, "the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance" could all be stakeholders but are unlikely to be actors. Similarly, a person using a system may be represented as different actors because he is playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank. Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales rep for the customer' or 'clerk for the marketing department' to capture that the user of the system is acting for someone else." This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results. A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product). In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system). For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf. Cockburn advises to look for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design (SuD) itself, and finally among the "internal actors", namely the components of the system under design.

Use case notation

In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are represented in a Use Case Diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system block level.

Limitations

Limitations of Use cases include:

Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.

Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).

Use cases are complex to write and to understand, for both end users and developers.

As there are no fully standard definitions of use cases, each project must form its own interpretation.

Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.

In Agile, simpler user stories are preferred to use cases.

Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix.

Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques.

Use cases are a starting point for test design, but since each test needs its own success criteria, use cases may need to be modified to provide separate post conditions for each path.

Insurance System With Tracking Manager Page 11

Customer (Policy Holder) - He or she can view details of the policies and they can also

calculate EMI, interest and pay premium as well as participate in discussion forum.

Company officials- The company officials generate policies and give responses to the

queries asked by users in the discussion forum.

Admin- He is responsible for approval of policies generated by company officials and also

updates information like new schemes policies etc.

Approve Policies

Update Information

calculate EMI

Calculate Interest

Pay Premium

Administrator

Customer

(from Actors)

Discussion Forum

Login

View Profile

View Details

Grant Loans

Generate Policies

Company

Officials

Insurance System With Tracking Manager Page 12

1.7 Class Diagram-

Insurance System With Tracking Manager Page 13

1.8 Sequence Diagram-

A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram that

shows how processes operate with one another and in what order. It is a construct of a Message

Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts

the objects and classes involved in the scenario and the sequence of messages exchanged between the

objects needed to carry out the functionality of the scenario. Sequence diagrams typically are associated

with use case realizations in the Logical View of the system under development.

Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.

Sequence Diagram for Policy Holders-

Insurance System With Tracking Manager Page 14

Sequence Diagram for Company Officials-

Insurance System With Tracking Manager Page 15

Sequence Diagram for Admin-

Insurance System With Tracking Manager Page 16

1.9 ER DIAGRAM-

In software engineering, an entity-relationship model (ER model for short) is an abstract and

conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database,

and its requirements in a top-down fashion. Diagrams created by this process are called entity-

relationship diagrams or ER diagrams.

Overview

Using the three schema approach to software engineering, there are three levels of ER models that may be developed. The conceptual data model 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.

A logical ER model does not require a conceptual ER model especially if the scope of the logical ER model is to develop a single disparate 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.

One or more physical ER models may be developed from each logical ER model. The physical ER model is normally developed 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".

Primary key

An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. When we speak of an entity we normally speak of some aspect of the real world which can be distinguished from other aspects of the real world.[3]

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

Insurance System With Tracking Manager Page 17

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. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proved relationship between a mathematician and a theorem.

The model's linguistic aspect described above is utilized in the declarative database query language ERROL, which mimics natural language constructs. ERROL's semantics and implementation are based on Reshaped relational algebra (RRA), a relational algebra which is adapted to the entity-relationship model and captures its linguistic aspect.

Entities and relationships can both have attributes. Examples: an employee entity might have a Social Security Number (SSN) attribute; the proved relationship may have a date attribute.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set. In other words, a relationship set corresponds to a relation in mathematics, while a relationship corresponds to a member of the relation.

Certain cardinality constraints on relationship sets may be indicated as well.

Relationships, roles and cardinalities

In Chen's original paper he gives an example of a relationship and its roles. He describes a relationship "marriage" and its two roles "husband" and "wife".

A person plays the role of husband in a marriage (relationship) and another person plays the role of wife in the (same) marriage. These words are nouns. That is no surprise; naming things requires a noun.

However as is quite usual with new ideas, many eagerly appropriated the new terminology but then applied it to their own old ideas. Thus the lines, arrows and crows-feet of their diagrams owed more to the earlier Bachman diagrams than to Chen's relationship diamonds. And they similarly misunderstood other important concepts.[citation needed]

In particular, it became fashionable (now almost to the point of exclusivity) to "name" relationships and roles as verbs or phrases.

Relationship names

A relationship expressed with a single verb implying direction, makes it impossible to discuss the model using the following proper English. For example:

the song and the performer are related by a 'performs'

the husband and wife are related by an 'is-married-to'.

Expressing the relationships with a noun resolves this:

the song and the performer are related by a 'performance'

the husband and wife are related by a 'marriage'.[original research?]

Traditionally, the relationships are expressed twice, (using present continuous verb phrases), once in each direction. This gives two English statements per relationship. For example:

the song is performed by the performer

the performer performs the song[citation needed]

Role naming

Insurance System With Tracking Manager Page 18

It has also become prevalent to name roles with phrases e.g. is-the-owner-of and is-owned-by etc. Correct nouns in this case are "owner" and "possession". Thus "person plays the role of owner" and "car plays the role of possession" rather than "person plays the role of is-the-owner-of" etc.

The use of nouns has direct benefit when generating physical implementations from semantic models. When a person has two relationships with car then it is possible to very simply generate names such as "owner_person" and "driver_person" which are immediately meaningful.[citation needed].

Cardinalities

Some modifications to the original specification are beneficial. Chen described look-across cardinalities. UML perpetuates this. (As an aside, the Barker-Ellis notation, used in Oracle Designer, uses same-side for minimum cardinality (analogous to optionality) and role, but look-across for maximum cardinality (the crows foot)).[clarification needed]

In Merise, Elmasri & Navathe and others there is a preference for same-side for roles and both minimum and maximum cardinalities. Recent researchers (Feinerer, Dullea et al.) have shown that this is more coherent when applied to n-ary relationships of order > 2.

In Dullea et al. one reads "A 'look across' notation such as used in the UML does not effectively represent the semantics of participation constraints imposed on relationships where the degree is higher than binary."

In Feinerer it says "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann investigates this situation and shows how and why different transformations fail." (Although the "reduction" mentioned is spurious as the two diagrams 3.4 and 3.5 are in fact the same) and also "As we will see on the next few pages, the look-across interpretation introduces several difficulties which prevent the extension of simple mechanisms from binary to n-ary associations."

ER MODEL-

Insurance System With Tracking Manager Page 19

2.0 Tables Description-

Login:

Company Official:

Policy:

Health Insurance:

Life Insurance:

Insurance System With Tracking Manager Page 20

House Insurance:

House Members:

Vehicle Insurance:

Query:

Insurance System With Tracking Manager Page 21

Reply:

Nominee:

Customer:

Receipt:

Insurance System With Tracking Manager Page 22

Loan:

2.1 Activity Diagrams:

Activity diagrams are graphical representations of workflows of stepwise activities and actions with

support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be

used to describe the business and operational step-by-step workflows of components in a system. An

activity diagram shows the overall flow of control. Activity diagrams are constructed from a limited number

of shapes, connected with arrows. The most important shape types:

rounded rectangles represent activities;

diamonds represent decisions;

bars represent the start (split) or end (join) of concurrent activities;

a black circle represents the start (initial state) of the workflow;

an encircled black circle represents the end (final state).

Arrows run from the start towards the end and represent the order in which activities happen. Hence they can be regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing concurrency. However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops.

Insurance System With Tracking Manager Page 23

User Login:

The activities involved in the above diagram are:

Visit the site: Initially the user visits the site.

Username and Password: Then the user enters the username and password.

Verification: The entered username and password are verified.

Login successful: If the entered details are valid then login successful.

If the entered details are invalid then he reenters the username and password.

Homepage: After successful login the user visits the homepage.

Insurance System With Tracking Manager Page 24

2.2 ScreenShots

Home Page:

Employee Login:

Insurance System With Tracking Manager Page 25

Generate Policies:

Policy Details Home:

Insurance System With Tracking Manager Page 26

Insurance Detail:

Loan Calculator:

Insurance System With Tracking Manager Page 27

Payment Schedule:

Payments:

Insurance System With Tracking Manager Page 28

Change Password:

Discussion Forum: