CHAPTER 1 INTRODUCTION

1.1 ABOUT HIDING SENSITIVE:

Large repositories of data contain sensitive information which must be protected against unauthorized access.Here, we are going to hide sensitive information in large database in order to reduce modifications in database and reduce unwanted side effects. e.g., nonsensitive rules falsely hidden and spurious rules falsely generated may be produced in the rule hiding process. Here, we investigate confidentiality issues of a broad category of rules, which are called association rules. If the disclosure risk of some of these rules are above a certain privacy threshold, those rules must be characterized as sensitive. Sometimes, sensitive rules should not be disclosed to the public since, among other things, they may be used for inferencing sensitive data, or they may provide business competitors with an advantage.
1.2 BENEFITS OF HIDING SENSITIVE:

The experimental results show that the undesired side effects are avoided by using our approach. The results also report that in most cases, all the sensitive rules are hidden without generating false rules. Moreover, the good scalability of our approach in terms of database size and the influence of the correlation among rules on rule hiding are observed.

CHAPTER 2 SYSTEM ANALYSIS

2.1 EXISTING SYSTEM: Although a business might use a set of programs that it knows and trusts, and might train its administrators and Help Desk personnel to support those programs, administrators lose control as soon as users begin running unknown code. The increasing role of the Internet in business puts your network at a greater risk than ever before. Such user-installed programs can conflict with other installed programs, change critical configuration data, or introduce a virus. Users often cannot make safe or informed choices about what software to run because viruses intentionally conceal the malicious purpose of the program. Also, the problems that are associated with running unknown code can increase support costs substantially because they lead to more system maintenance, more help desk time, and lost user productivity 2.2 LIMITATIONS: All the items in a sensitive rule do not appear in any other sensitive rule. With this assumption, hiding a sensitive rule will not affect any other sensitive rule and, therefore, hiding them one at a time or all together will not make any difference. Thus, their algorithms hide one rule at a time and decrease the supports or confidences one unit at a time. Since this work aims at hiding all sensitive rules, it cannot avoid the undesired side effects .
2

2.3 PROPOSED SYSTEM: Sensitive rules are the major advantage of the proposed system. We can get the copy of the database without affecting the original database. For this purpose we are using the sensitive rules. For example, in one organization a salesman always giving the good production means remaining staff those who want to get a good profit can use his database from him. If some one made any changes in that original database means we cannot retrieve the original data again. Because of that purpose we are building the project to get the copy of database using the sensitive rules. It does not affect the original database forever. It provides restricting access to sensitive data and Security to End user. We remove the assumption and allow the user to select sensitive rules from all strong rules such as Minimum support threshold (MST) and Minimum Confidence Threshold (MCT).

CHAPTER 3 PROBLEM FORMULATION

3.1 OBJECTIVES:
Analysis the performance of proposed system heuristic methods for

increasing the number of hidden sensitive rules and reducing the number of modified entries. The project results show the effectiveness of our approach, i.e., undesired side effects is avoided in the rule hiding process. The project results also report that in most cases, all the sensitive rules are hidden without spurious rules falsely generated. Moreover, the good scalability of our approach in terms of database size and the influence of the correlation among rules on rule hiding are observed.

3.2 HARDWARE SPECIFICATION: Hardware: Pentium IV Processor 256MB RAM 40GB Hard disk

3.3 SOFTWARE SPECIFICATION: Operating System Jdk Kit Web Server Database : Win 2000 and above versions : : : Jdk 1.5 Apache Tomcat Server MS-SQL Server JSP

Web Technologies :

3.4 SOFTWARE ENVIRONMENT: Java Technology Java technology is both a programming language and a platform. The Java Programming Language The Java programming language is a high-level language that can be characterized by all of the following buzzwords: Simple Architecture neutral Object oriented Portable Distributed High performance Interpreted Multithreaded
5

 Robust Dynamic Secure With most programming languages, you either compile or interpret a program so that you can run it on your computer. The Java programming language is unusual in that a program is both compiled and interpreted. With the compiler, first you translate a program into an intermediate language called Java byte codes the platform-independent codes interpreted by the interpreter on the Java platform. The interpreter parses and runs each Java byte code instruction on the computer. Compilation happens just once; interpretation occurs each time the program is executed. The following figure illustrates how this works.

You can think of Java bytecodes as the machine code instructions for the Java Virtual Machine (Java VM). Every Java interpreter, whether its a development tool or a Web browser that can run applets, is an implementation of the Java VM. Java bytecodes help make write once, run anywhere possible. You can compile your program into bytecodes on any platform that has a Java compiler. The bytecodes can then be run on any implementation of the Java VM. That means that as long as a computer has a

Java VM, the same program written in the Java programming language can run on Windows 2000, a Solaris workstation, or on an iMac.

The Java Platform A platform is the hardware or software environment in which a program runs. Weve already mentioned some of the most popular platforms like Windows 2000, Linux, Solaris, and MacOS. Most platforms can be described as a combination of the operating system and hardware. The Java platform differs from most other platforms in that its a software-only platform that runs on top of other hardware-based platforms. The Java platform has two components:

The Java Virtual Machine (Java VM) The Java Application Programming Interface (Java API)

Youve already been introduced to the Java VM. Its the base for the Java platform and is ported onto various hardware-based platforms. The Java API is a large collection of ready-made software components that provide many useful capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped into libraries of related
7

classes and interfaces; these libraries are known as packages. The next section, What Can Java Technology Do?, highlights what functionality some of the packages in the Java API provide. The following figure depicts a program thats running on the Java platform. As the figure shows, the Java API and the virtual machine insulate the program from the hardware.

Native code is code that after you compile it, the compiled code runs on a specific hardware platform. As a platform-independent environment, the Java platform can be a bit slower than native code. However, smart compilers, well-tuned interpreters, and just-in-time bytecode compilers can bring performance close to that of native code without threatening portability.

ABOUT J2EE:

The J2EE platform uses a multitiered distributed application model. Application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on the tier in the multitiered J2EE environment to which the application component belongs. Figure 1-1 shows two multitiered J2EE applications divided into the tiers described in the following list. The J2EE application parts shown in Figure 1-1 are presented in J2EE Components. Client-tier components run on the client machine. Web-tier components run on the J2EE server. Business-tier components run on the J2EE server. Enterprise information system (EIS)-tier software runs on the EIS

server. Although a J2EE application can consist of the three or four tiers shown in Figure 1-1, J2EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three different locations: client machines, the J2EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage.

Figure 1-1 Multitiered Applications J2EE COMPONENTS : J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. The J2EE specification defines the following J2EE components:

Application clients and applets are components that run on the client. Java Servlet and JavaServer Pages (JSP ) technology components

are Web components that run on the server.

10

J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and "standard" Java classes is that J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE server. J2EE Clients A J2EE client can be a Web client or an application client. Web Clients A Web client consists of two parts: dynamic Web pages containing various types of markup language (HTML, XML, and so on), which are generated by Web components running in the Web tier, and a Web browser, which renders the pages received from the server. A Web client is sometimes called a thin client. Thin clients usually do not do things like query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, heavyweight operations like these are off-loaded to enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies. Applets A Web page received from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed
11

in the Web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file in order for the applet to successfully execute in the Web browser. Web components are the preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Also, Web components enable cleaner and more modular application design because they provide a way to separate applications programming from Web page design. Application Clients A J2EE application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible. Application clients directly access enterprise beans running in the business tier. However, if application requirements warrant it, a J2EE application client can open an HTTP connection to establish communication with a servlet running in the Web tier. JavaBeans Component Architecture The server and client tiers might also include components based on the JavaBeans component architecture (JavaBeans component) to manage the data flow between an application client or applet and components running on the J2EE server or between server components

12

and a database. JavaBeans components are not considered J2EE components by the J2EE specification. JavaBeans components have instance variables and get and set methods for accessing the data in the instance variables. JavaBeans components used in this way are typically simple in design and implementation, but should conform to the naming and design conventions outlined in the JavaBeans component architecture. J2EE Server Communications Figure 1-2 shows the various elements that can make up the client tier. The client communicates with the business tier running on the J2EE server either directly or, as in the case of a client running in a browser, by going through JSP pages or servlets running in the Web tier. Your J2EE application uses a thin browser-based client or thick application client. In deciding which one to use, you should be aware of the trade-offs between keeping functionality on the client and close to the user (thick client) and off-loading as much functionality as possible to the server (thin client). The more functionality you off-load to the server, the easier it is to distribute, deploy, and manage the application; however, keeping more functionality on the client can make for a better perceived user experience.

13

Figure 1-2 Server Communications Web Components J2EE Web components can be either servlets or JSP pages. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. Static HTML pages and applets are bundled with Web components during application assembly, but are not considered Web components by the J2EE specification. Server-side utility classes can

14

also be bundled with Web components and, like HTML pages, are not considered Web components. Like the client tier and as shown in Figure 1-3, the Web tier might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing. Business Components Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier. Figure 1-4 shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.

Figure 1-3 Web Tier and J2EE Application

15

Figure 1-4 Business and EIS Tiers There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans. A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. In contrast, an entity bean represents persistent data stored in one row of a database table. If the client terminates or if the server shuts down, the underlying services ensure that the entity bean data is saved. A message-driven bean combines features of a session bean and a Java Message Service ("JMS") message listener, allowing a business component to receive JMS messages asynchronously. This tutorial describes entity beans and session beans. Packaging J2EE components are packaged separately and bundled into a J2EE application for deployment. Each component, its related files such as GIF

16

and HTML files or server-side utility classes, and a deployment descriptor are assembled into a module and added to the J2EE application. A J2EE application is composed of one or more enterprise bean, Web, or application client component modules. The final enterprise solution can use one J2EE application or be made up of two or more J2EE applications, depending on design requirements. A J2EE application and each of its modules has its own deployment descriptor. A deployment descriptor is an XML document with an .xml extension that describes a component's deployment settings. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. Because deployment descriptor information is declarative, it can be changed without modifying the bean source code. At run time, the J2EE server reads the deployment descriptor and acts upon the component accordingly. A J2EE application with all of its modules is delivered in an Enterprise Archive (EAR) file. An EAR file is a standard Java Archive (JAR) file with an .ear extension. In the GUI version of the J2EE SDK application deployment tool, you create an EAR file first and add JAR and Web Archive (WAR) files to the EAR. If you use the command line packager tools, however, you create the JAR and WAR files first and then create the EAR

Files, and related Each EJB JAR file contains a deployment

descriptor, the enterprise bean files.

17

Each application client JAR file contains a deployment descriptor, Each WAR file contains a deployment descriptor, the Web

the class files for the application client, and related files. component files, and related resources. Using modules and EAR files makes it possible to assemble a number of different J2EE applications using some of the same components. No extra coding is needed; it is just a matter of assembling various J2EE modules into J2EE EAR files. Development Roles Reusable modules make it possible to divide the application development and deployment process into distinct roles so that different people or companies can perform different parts of the process. The first two roles involve purchasing and installing the J2EE product and tools. Once software is purchased and installed, J2EE components can be developed by application component providers, assembled by application assemblers, and deployed by application deployers. In a large organization, each of these roles might be executed by different individuals or teams. This division of labor works because each of the earlier roles outputs a portable file that is the input for a subsequent role. For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server.
18

The different roles are not always executed by different people. If you work for a small company, for example, or if you are prototyping a sample application, you might perform the tasks in every phase. J2EE Product Provider The J2EE product provider is the company that designs and makes available for purchase the J2EE platform, APIs, and other features defined in the J2EE specification. Product providers are typically operating system, database system, application server, or Web server vendors who implement the J2EE platform according to the Java 2 Platform, Enterprise Edition Specification.

Tool Provider The tool provider is the company or person who creates development, assembly, and packaging tools used by component providers, assemblers, and deployers. See the section Tools for information on the tools available with J2EE SDK version 1.3. Application Component Provider The application component provider is the company or person who creates Web components, enterprise beans, applets, or application clients for use in J2EE applications.

19

Web Component Developer A Web component developer performs the following tasks to deliver a WAR file containing the Web component: Writes and compiles servlet source code Writes JSP and HTML files Specifies the deployment descriptor for the Web component Bundles the .class, .jsp, .html, and deployment descriptor files in the

WAR file. J2EE Application Client Developer An application client developer performs the following tasks to deliver a JAR file containing the J2EE application client:

Writes and compiles the source code Specifies the deployment descriptor for the client Bundles the .class files and deployment descriptor into the JAR file

Application Assembler The application assembler is the company or person who receives application component JAR files from component providers and assembles them into a J2EE application EAR file. The assembler or deployer can edit the deployment descriptor directly or use tools that correctly add XML tags according to interactive selections. A software developer performs the following tasks to deliver an EAR file containing the J2EE application:

20

Assembles EJB JAR and WAR files created in the previous phases Specifies the deployment descriptor for the J2EE application. Verifies that the contents of the EAR file are well formed and

into a J2EE application (EAR) file.

comply with the J2EE specification. Application Deployer and Administrator The application deployer and administrator is the company or person who configures and deploys the J2EE application, administers the computing and networking infrastructure where J2EE applications run, and oversees the runtime environment. Duties include such things as setting transaction controls and security attributes and specifying connections to databases. During configuration, the deployer follows instructions supplied by the application component provider to resolve external dependencies, specify security settings, and assign transaction attributes. During installation, the deployer moves the application components to the server and generates the container-specific classes and interfaces. A deployer/system administrator performs the following tasks to install and configure a J2EE application: Adds the J2EE application (EAR) file created in the preceding phase Configures the J2EE application for the operational environment by

to the J2EE server. modifying the deployment descriptor of the J2EE application.

21

Verifies that the contents of the EAR file are well formed and Deploys (installs) the J2EE application EAR file into the J2EE

comply with the J2EE specification. server. Reference Implementation Software The J2EE SDK is a noncommercial operational definition of the J2EE platform and specification made freely available by Sun Microsystems for demonstrations, prototyping, and educational use. It comes with the J2EE application server, Web server, relational database, J2EE APIs, and complete set of development and deployment tools. The purpose of the J2EE SDK is to allow product providers to determine what their implementations must do under a given set of application conditions, and to run the J2EE Compatibility Test Suite to test that their J2EE products fully comply with the specification. It also allows application component developers to run their J2EE applications on the J2EE SDK to verify that applications are fully portable across all J2EE products and tools. Database Access The relational database provides persistent storage for application data. A J2EE implementation is not required to support a particular type of database, which means that the database supported by different J2EE products can vary. See the Release Notes included with the J2EE SDK download for a list of the databases currently supported by the reference implementation.

22

ODBC Microsoft Open Database Connectivity (ODBC) is a standard programming interface for application developers and database systems providers. Before ODBC became a de facto standard for Windows programs to interface with database systems, programmers had to use proprietary languages for each database they wanted to connect to. Now, ODBC has made the choice of the database system almost irrelevant from a coding perspective, which is as it should be. Application developers have much more important things to worry about than the syntax that is needed to port their program from one database to another when business needs suddenly change. Through the ODBC Administrator in Control Panel, you can specify the particular database that is associated with a data source that an ODBC application program is written to use. Think of an ODBC data source as a door with a name on it. Each door will lead you to a particular database. For example, the data source named Sales Figures might be a SQL Server database, whereas the Accounts Payable data source could refer to an Access database. The physical database referred to by a data source can reside anywhere on the LAN. The ODBC system files are not installed on your system by Windows 95. Rather, they are installed when you setup a separate database application, such as SQL Server Client or Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a file called ODBCINST.DLL. It is also possible to administer your ODBC data sources through a stand-alone program called ODBCADM.EXE. There is a 16-bit and a 32-bit version of this program, and each maintains a separate list of
23

ODBC

data

sources.

From a programming perspective, the beauty of ODBC is that the application can be written to use the same set of function calls to interface with any data source, regardless of the database vendor. The source code of the application doesnt change whether it talks to Oracle or SQL Server. We only mention these two as an example. There are ODBC drivers available for several dozen popular database systems. Even Excel spreadsheets and plain text files can be turned into data sources. The operating system uses the Registry information written by ODBC Administrator to determine which low-level ODBC drivers are needed to talk to the data source (such as the interface to Oracle or SQL Server). The loading of the ODBC drivers is transparent to the ODBC application program. In a client/server environment, the ODBC API even handles many of the network issues for the application programmer. The advantages of this scheme are so numerous that you are probably thinking there must be some catch. The only disadvantage of ODBC is that it isnt as efficient as talking directly to the native database interface. ODBC has had many detractors make the charge that it is too slow. Microsoft has always claimed that the critical factor in performance is the quality of the driver software that is used. In our humble opinion, this is true. The availability of good ODBC drivers has improved a great deal recently. And anyway, the criticism about performance is somewhat analogous to those who said that compilers would never match the speed of pure assembly language. Maybe not, but the compiler (or ODBC) gives you the opportunity to write cleaner programs, which means you finish sooner. Meanwhile, computers get faster every year.
24

JDBC In an effort to set an independent database standard API for Java, Sun Microsystems developed Java Database Connectivity, or JDBC. JDBC offers a generic SQL database access mechanism that provides a consistent interface to a variety of RDBMSs. This consistent interface is achieved through the use of plug-in database connectivity modules, or drivers. If a database vendor wishes to have JDBC support, he or she must provide the driver for each platform that the database and Java run on. To gain a wider acceptance of JDBC, Sun based JDBCs framework on ODBC. As you discovered earlier in this chapter, ODBC has widespread support on a variety of platforms. Basing JDBC on ODBC will allow vendors to bring JDBC drivers to market much faster than developing a completely new connectivity solution. JDBC was announced in March of 1996. It was released for a 90 day public review that ended June 8, 1996. Because of user input, the final JDBC v1.0 specification was released soon after. The remainder of this section will cover enough information about JDBC for you to know what it is about and how to use it effectively. This is by no means a complete overview of JDBC. That would fill an entire book. JDBC Goals Few software packages are designed without goals in mind. JDBC is one that, because of its many goals, drove the development of the API. These goals, in conjunction with early reviewer feedback, have finalized the JDBC class library into a solid framework for building database applications in Java.
25

The goals that were set for JDBC are important. They will give you some insight as to why certain classes and functionalities behave the way they do. The design goals for JDBC are as follows: 1. SQL Level API The designers felt that their main goal was to define a SQL interface for Java. Although not the lowest database interface level possible, it is at a low enough level for higher-level tools and APIs to be created. Conversely, it is at a high enough level for application programmers to use it confidently. Attaining this goal allows for future tool vendors to generate JDBC code and to hide many of JDBCs complexities from the end user. 2. SQL Conformance SQL syntax varies as you move from database vendor to database vendor. In an effort to support a wide variety of vendors, JDBC will allow any query statement to be passed through it to the underlying database driver. This allows the connectivity module to handle non-standard functionality in a manner that is suitable for its users.
3. JDBC must be implemental on top of common database

interfaces The JDBC SQL API must sit on top of other common SQL level APIs. This goal allows JDBC to use existing ODBC level drivers by the use of a software interface. This interface would translate JDBC calls to ODBC and vice versa. 4. Provide a Java interface that is consistent with the rest of the Java system
26

Because of Javas acceptance in the user community thus far, the designers feel that they should not stray from the current design of the core Java system. 5. Keep it simple This goal probably appears in all software design goal listings. JDBC is no exception. Sun felt that the design of JDBC should be very simple, allowing for only one method of completing a task per mechanism. Allowing duplicate functionality only serves to confuse the users of the API. 6. Use strong, static typing wherever possible Strong typing allows for more error checking to be done at compile time; also, less errors appear at runtime. JDBC API 2.0 The JDBC API lets you invoke SQL commands from Java programing language methods. You use the JDBC API in an enterprise bean when you override the default container-managed persistence or have a session bean access the database. With container-managed persistence, database access operations are handled by the container, and your enterprise bean implementation contains no JDBC code or SQL commands. You can also use the JDBC API from a servlet or JSP page to access the database directly without going through an enterprise bean. The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform.

27

Java Servlet Technology 2.3 Java Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by Web servers. JavaServer Pages Technology 1.2 JavaServer Pages technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static template data, which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements, which determine how the page constructs dynamic content. J2EE Connector Architecture 1.0 The J2EE Connector architecture is used by J2EE tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged into any J2EE product. A resource adapter is a software component that allows J2EE application components to access and interact with the underlying resource manager. Because a resource adapter is specific to its resource manager, there is typically a different resource adapter for each type of database or enterprise information system.

28

Tools The J2EE reference implementation provides an application deployment tool and an array of scripts for assembling, verifying, and deploying J2EE applications and managing your development and production environments. Application Deployment Tool The J2EE reference implementation provides an application deployment tool (deploytool) for assembling, verifying, and deploying J2EE applications. There are two versions: command line and GUI. The GUI tool includes wizards for:

Packaging, configuring, and deploying J2EE applications Packaging and configuring enterprise beans Packaging and configuring Web components Packaging and configuring application clients Packaging and configuring resource adaptors

In addition, configuration information can be set for each component and module type in the tabbed inspector panes. INTRODUCTION TO JSP: The goal of the java server page specification is to simplify the creation and management of dynamic web page by separating content and presentation jsp as basically files that combine html and new

scripting tags. the jsp there look somewhat like HTML but they get
29

translated into java servlet the first time are invoked by a client. The resulting servlet is a combination of the html from the jsp file and embedded dynamic content specified by the new tag.

For our example in this c:/projavaserver/chapter11/jsp example hold our web application save the above in the file called simple jsp. Jsp and place it in the root of the web application (in the words save it as) C:/localhost/project folder name/sourcename.jsp You should output similar to the following. In other words the first time jsp is loaded by the jsp container (also called the jsp engine) The servlet code necessary to fulfill the jsp tages is automatically generated compiled and loaded into the servlet container. From then on as long as the jsp source for the page is not modified this compiled servlet process any browser request for the jsp page. If you modify the mouse source code for the jsp it is automatically recompiled and relocated the next time that page is request.

What is a Database? A database is a collection of information that's related to a particular subject or purpose, such as tracking customer orders or maintaining a music

30

collection. If your database isn't stored on a computer, or only parts of it are, you may be tracking information from a variety of sources that you're having to coordinate and organize yourself. Using Microsoft Access, you can manage all your information from a single database file. Within the file, divide your data into separate storage containers called tables; view, add, and update table data by using online forms; find and retrieve just the data you want by using queries; and analyze or print data in a specific layout by using reports. Allow users to view, update, or analyze the database's data from the Internet or an intranet by creating data access pages. To store your data, create one table for each type of information that you track. To bring the data from multiple tables together in a query, form, report, or data access page, define relationships between the tables. To find and retrieve just the data that meets conditions that you specify, including data from multiple tables, create a query. A query can also update or delete multiple records at the same time, and perform predefined or custom calculations on your data. To easily view, enter, and change data directly in a table, create a form. When you open a form, Microsoft Access retrieves the data from one or more tables, and displays it on the screen with the layout you choose in the Form Wizard, or a layout that you create from scratch. To analyze your data or present it a certain way in print, create a report. For example, you might print one report that groups data and

31

calculates totals, and another report with different data formatted for printing mailing labels. To make data available on the Internet or an intranet for interactive reporting, data entry, or data analysis, use a data access page. Microsoft Access retrieves the data from one or more tables and displays it on the screen with the layout you choose in the Page Wizard, or a layout that you create from scratch. Users can interact with the data by using features on the data access page. Tables: What they are and how they work A table is a collection of data about a specific topic, such as products or suppliers. Using a separate table for each topic means that you store that data only once, which makes your database more efficient, and reduces data-entry errors.Tables organize data into columns (called fields) and rows (called records). A common field relates two tables so that Microsoft Access can bring together the data from the two tables for viewing, editing, or printing. In table Design view, you can create an entire table from scratch, or add, delete, or customize the fields in an existing table. In table Datasheet view, you can add, edit, view, or otherwise work with the data in a table. You can also display records from tables that are related to the current table by displaying subdatasheets within the main datasheet. With some restrictions, you can work with the data in subdatasheets in many of the same ways that you work with data in the main datasheet.
32

Queries: What they are and how they work You use queries to view, change, and analyze data in different ways. You can also use them as the source of records for forms, reports, and data access pages. The most common type of query is a select query. A select query retrieves data from one or more tables by using criteria you specify and then displays it in the order you want. Forms: What they are and how they work You can use forms for a variety of purposes.Most of the information in a form comes from an underlying record source. Other information in the form is stored in the form's design. You create the link between a form and its record source by using graphical objects called controls. The most common type of control used to display and enter data is a text box. Modules: What they are and how they work What is a module? A module is a collection of Visual Basic for Applications declarations and procedures that are stored together as a unit. There are two basic types of modules: class modules and standard modules. Each procedure in a module can be a Function procedure or a Sub procedure.

33

Class modules Form and report modules are class modules that are associated with a particular form or report. Form and report modules often contain event procedures that run in response to an event on the form or report. You can use event procedures to control the behavior of your forms and reports, and their response to user actions, such as clicking the mouse on a command button. When you create the first event procedure for a form or report, Microsoft Access automatically creates an associated form or report module. Procedures in your form and report modules can call procedures you have added to standard modules. In Access 95, class modules exist in association only with a form or report. In Access 97 or later, class modules can also exist independent of a form or report, and this type of class module is listed in Modules under Objects on the Database window. You can use a class module in Modules to create a definition for a custom object. Standard modules Standard modules contain general procedures that aren't associated with any other object and frequently used procedures that can be run from anywhere within your database. You can view the list of standard modules in your database by clicking Modules under Objects in the Database window. Form, report, and standard modules are also listed in the Object Browser.

34

Why define relationships? After you've set up different tables for each subject in your Microsoft Access database, you need a way of telling Microsoft Access how to bring that information back together again. The first step in this process is to define relationships between your tables. After you've done that, you can create queries, forms, and reports to display information from several tables at once. How do relationships work? In the previous example, the fields in five tables must be coordinated so that they show information about the same order. This coordination is accomplished with relationships between tables. A relationship works by matching data in key fields usually a field with the same name in both tables. In most cases, these matching fields are the primary key from one table, which provides a unique identifier for each record, and a foreign key in the other table. For example, employees can be associated with orders they're responsible for by creating a relationship between the Employees table and the Orders table using the EmployeeID fields. A one-to-many relationship A one-to-many relationship is the most common type of relationship. In a one-to-many relationship, a record in Table A can have many matching records in Table B, but a record in Table B has only one matching record in Table A.

35

A many-to-many relationship In a many-to-many relationship, a record in Table A can have many matching records in Table B, and a record in Table B can have many matching records in Table A. This type of relationship is only possible by defining a third table (called a junction table) whose primary key consists of two fields the foreign keys from both Tables A and B. A many-tomany relationship is really two one-to-many relationships with a third table. For example, the Orders table and the Products table have a many-to-many relationship that's defined by creating two one-to-many relationships to the Order Details table. A one-to-one relationship In a one-to-one relationship, each record in Table A can have only one matching record in Table B, and each record in Table B can have only one matching record in Table A. This type of relationship is not common, because most information related in this way would be in one table. You might use a one-to-one relationship to divide a table with many fields, to isolate part of a table for security reasons, or to store information that applies only to a subset of the main table. For example, you might want to create a table to track employees participating in a fundraising soccer game. Defining relationships You define a relationship by adding the tables that you want to relate to the Relationships window, and then dragging the key field from one table and dropping it on the key field in the other table. You can also define relationships by using the keyboard.

36

The kind of relationship that Microsoft Access creates depends on how the related fields are defined:

A one-to-many relationship is created if only one of the related fields

is a primary key or has a unique index.

A one-to-one relationship is created if both of the related fields are

primary keys or have unique indexes.

A many-to-many relationship is really two one-to-many relationships

with a third table whose primary key consists of two fields the foreign keys from the two other tables. Offered System The existing system is the harder one to bid the product. The bluecollar (manual) system is prone to blunder. It is time consuming. It is very intricate for a person to turn out the testimony. There are odds for changing the scheme testimony and do malpractice. This system engages a lot of blue-collar entries with the appliance to achieve the preferred task. This existing system is intricate to be aware of. Usage of documents in the imbursement process leads to less competence, less accurateness and less productivity. And other shortcomings in blue-collar system are as follows: Increased disbursement for papers shuffle and storage. Less control of Amounts

37

Personnel who are sited in poles apart of the world

cannot transact resourcefully. Anticipated System: The anticipated system is premeditated to eradicate the negative aspect of the offered system. The anticipated system is designed by keeping to eradicate the negative aspect of the offered system in order to afford an enduring solution to the tribulations. The primary aim of the new system is to accelerate business dealings. The testimony is primed for the schemes and put into practice under the regulation of the concerned bureaucrat. This anticipated System is used to trim down the difficulties. Anticipated system is very constructive and is trouble-free. Dozens of companies are in the race to convince auction and bidding that a pot of auction product awaits those who conduct their business on the Internet. In this fast battle of commerce and moneymaking, no country, no corporation and no creature would like to descend back. One and all want to lead the group. Now, no more individual aspires at the local market is also just a click of button away. Hence, everyone is trying to make the best use of Internet; our anticipated system also meets up the desires of the patron who can bid all the way through online.

38

CHAPTER 4 SYSTEM DESIGN

4.1 DESIGN OVERVIEW: Analysis the performance of proposed system heuristic methods for increasing the number of hidden sensitive rules and reducing the number of modified entries. The projects results show the effectiveness of our approach, i.e., undesired side effects is avoided in the rule hiding process. The project results also report that in most cases, all the sensitive rules are hidden without spurious rules falsely generated. Moreover, the good scalability of our approach in terms of database size and the influence of the correlation among rules on rule hiding are observed.

39

4.2 CONTEXT ANALYSIS DIAGRAM:

Performance of User Buying process

Performance of Admin Control

Performance of user Registrations

Updating of the users account and the product details

40

4.3 DATA FLOW DIAGRAM / USE CASE DIAGRAM / FLOW DIAGRAM:

Share Automation
Home Share Buyer Reg Admin Share Buyer Details Seller Details Seller Reg Share Details and view only Non sensitive Details only Buy Share View Share Seller Share

Data Base

View correspondin g sensitive details

41

4.4 ARCHITECTURE DIAGRAM:

42

CHAPTER 5 PERFORMANCE ANALYSIS

5.1 SYSTEM TESTING: The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or weakness in a work product. It provides a way to check the functionality of components, sub assemblies, assemblies and/or a finished product It is the process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and does not fail in an unacceptable manner. There are various types of test. Each test type addresses a specific testing requirement. TYPES OF TESTS Unit testing Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program input produce valid outputs. All decision branches and internal code flow should be validated. It is the testing of individual software units of the application .it is done after the completion of an individual unit before integration. This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component level and test a specific business process, application, and/or system configuration. Unit tests ensure that each unique path of a business process performs accurately to the documented specifications and contains clearly defined inputs and expected results.
43

Integration testing Integration tests are designed to test integrated software components to determine if they actually run as one program. Testing is event driven and is more concerned with the basic outcome of screens or fields. Integration tests demonstrate that although the components were individually satisfaction, as shown by successfully unit testing, the combination of components is correct and consistent. Integration testing is specifically aimed at combination of components. Functional test Functional tests provide a systematic demonstrations that functions tested are available as specified by the business and technical requirements, system documentation , and user manuals. Functional testing is centered on the following items: Valid Input Invalid Input Functions Output exercised. Systems/Procedures : interfacing systems or procedures must be invoked. Organization and preparation of functional tests is focused on requirements, key functions, or special test cases. In addition, systematic coverage pertaining to identify Business process flows, data fields, predefined processes, and successive processes must be considered for testing. Before functional testing is
44

exposing the problems that arise from the

: identified classes of valid input must be accepted. : identified classes of invalid input must be rejected. : identified functions must be exercised. : identified classes of application outputs must be

complete, additional tests are identified and the effective value of current tests is determined. System Test System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. An example of system testing is the configuration oriented system integration test. System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points. White Box Testing White Box Testing is a testing in which the software tester has knowledge of the inner workings, structure and language of the software, or at least its purpose. It is used to test areas that cannot be reached from a black box level . Black Box Testing Black Box Testing is testing the software without any knowledge of the inner workings, structure or language of the module being tested . Black box tests, as most other kinds of tests, must be written from a definitive source document, such as specification or requirements document. It is a testing in which the software under test is treated, as a black box .you cannot see into it. The test provides inputs and responds to outputs without considering how the software works.

45

5.1.1 UNIT TESTING: Unit testing is usually conducted as part of a combined code and unit test phase of the software lifecycle, although it is not uncommon for coding and unit testing to be conducted as two distinct phases. Test strategy and approach Field testing will be performed manually and functional tests will be written in detail. Test objectives All field entries must work properly. Pages must be activated from the identified link. The entry screen, messages and responses must not be delayed. Features to be tested Verify that the entries are of the correct format No duplicate entries should be allowed All links should take the user to the correct page. 5.1.2 INTEGRATION TESTING: Software integration testing is the incremental integration testing of two or more integrated software components on a single platform to produce failures caused by interface defects. The task of the integration test is to check that components or software applications, e.g. components in a software system or one step up software applications at the company level interact without error.

46

5.1.3 ACCEPTANCE TESTING: User Acceptance Testing is a critical phase of any project and requires significant participation by the end user. It also ensures that the system meets the functional requirements.

47

CHAPTER 6 IMPLEMENTATION
Implementation is the stage of the project when the theoretical design is turned out into a working system. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective. The implementation stage involves careful planning, investigation of the existing system and its constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods. Implementation is the process of converting a new system design into operation. It is the phase that focuses on user training, site preparation and file conversion for installing a candidate system. The important factor that should be considered here is that the conversion should not disrupt the functioning of the organization. The implementation can be preceded through the Java Swings and Applets. We are using core java IO concepts for retrieving input source codes and provide ranking for the resulted data. For the feature location java will be more suitable for platform independence and searching concepts. For maintaining some searched documents we are using SQL-SERVER as database back end.

48

CHAPTER 7 CONCLUSION
In proposed approach that modifies the database to hide sensitive rules with limited side effects. We propose to classify all the valid modifications such that every class of modifications is related with the sensitive rules, non sensitive rules, and spurious rules that can be affected after the modifications. With the methods proposed in this paper, we can modify the transactions in an order so that both the numbers of hidden sensitive rules and modified entries are considered. The experimental results show that our approach is scalable in terms of database size. Moreover, our approach to the avoidance of undesired side effects in rule hiding is effective in two well-designed experiments. In most cases, all the sensitive rules are hidden without false rules generated. In addition, it is observed that the common items and the overlapping degrees among sensitive rules have a great impact on the performance of rule hiding.

49

APPENDIX SCREEN SHOTS

BUYER LOGIN:

50

51

SELLER LOGIN:

52

53

54

55

56

ADMINISTRATOR LOGIN:

57

58

59

60

61

REFERENCES
1.

D.Aggarwal and C.C.Aggarwal,On the design quantification of

privacy preserving data mining algorithms,proc.ACM symp. Principles of database systems, pp.247-255,2001. 2. R.Aggarwal,T.Imielinski, and A.Swami,Mining Association Rules Between Sets Of Items in Large Database, proc.ACM Conf. Management of data, pp.207-216,1993. 3. 4. R.Aggarwal and R.Srikant,Privacy Preserving Data Mining, Information storage and retrieval systems theory and proc.ACM Conf.Management of data,pp.14-19,2000. implementations,G.J.kowlalski and M.T.Maybury,eds.Kluwer Academic publishers,1997. 5. 6. 3. S.J.Rizvi and J.R.Haritza,Maintaining privacy in dataassociation rule http://www.almaden.ibm.com/software/quest/resources/index.shtml,200 mining ,proc. Conf . very large databases,pp.682-693,2002.

62