SYNOPSIS

The Project is entitled as “PONLAIT MANAGEMENT SYSTEM” has been

developed for “Ponlait Co-operative Milk Society”, Pondicherry.

The Project contains Four Modules namely Dispatch, Maintenance,

Agent Ledger, Report Generation.

Dispatch system is used to maintain the Booth details, Route Details, Milk
Details, Supplying, Return Details, and Leakage Details.

The maintenance system is used to maintain the agent details route wise, milk
supplying details route wise, institution details, and other product details.

Institution details deals with the special order of milk for the schools,
hospitals, functions, funds etc. other product details deals with Ghee, Milk-gova,
Curd, Padham Milk.

The Agent Ledger system used to maintain the agent details, collection list,
date wise balance, ledger, cash payment, party wise balance, agent commission.

The agent ledger deals with the cash payment of the agent for the purchased
milk and to maintain their details, and the ledger for the management

The Report generation system is used to generate the report for daily
sales, monthly sales, institution sales, agent commission report.

The Project is more interactive and more exploit for person to Work with It.
This system is designed in such a way that it provides faster access, more efficiency,
less cost and effort. It satisfies user needs and occupies less storage thus helping in
faster transaction.

The project is developed using Visual basic 6.0 as front end and Oracle 8 as
backend under Microsoft Windows environment.
INTRODUCTION
 SYSTEM
SPECIFICATION
2.
 SYSTEM DESIGN

3. SYSTEM DESGINING

The process of design involves “conceiving and planning in the mind” and
making a drawing, pattern, as a sketch of. In software design, there are three distinct
types of activities such as external design, architectural design, and detailed design.
Architecture and detailed design. Architecture and detailed designs are collectively
referred to as internal design.
 3.1 EXTERNAL DESIGN

External design of software involves conceiving, planning out and specifying

the externally observable characteristics of a software product. This characteristics
includes user displays and report format, external data sources and data sinks, and
the functional characteristics, performance requirements and high-level process
structure for the product. It begins during analysis phase and continues into the design
phase.

3.1.1 MENU LAYOUT

MAIN MENU

Entry Dispatch Billing Report X

Booth Details
Root Details
Customer Details
Institution Details
Parlour Details
Customer Rate
Card Details
Item Details
DISPATCH MENU

X
Entry Dispatch Billing Report

Customer
Parlour
Institution
Others

BILLING MENU

X
Entry Dispatch Billing Report

Payment

Institution

Parlour

Other Products
REPORT MENU

X
Entry Dispatch Billing Report

Daily Dispatch

Monthly Dispatch

Salary

Institution Supply

Leakage

Root-wise

3.1.2. FORM LAYOUT

BOOTH MASTER

BOOTH CODE

BOOTH NAME
 ROUTE CODE

ROUTE NAME

CUSTOMER MASTER

CODE

NAME

BOOTH CODE

BOOTH NAME

ADDRESS

PHONE NUMBER
INSTITUTION MASTER

NAME

CODE NUMBER

ADDRESS

PHONE NUMBER
PARLOUR MASTER

NAME

CODE NUMBER

ADDRESS

PHONE NUMBER
CUSTOMER RATE MASTER

CUSTOMERCODE

CUSTOMER NAME

ITEM CODE

ITEM NAME

CUSTOMER RATE
CARD MASTER

CARD CODE

CARD NAME

ITEM NAME

ITEM CODE
ROOT MASTER
MASTER

ROUTE CODE

ROUTE NAME

ITEM MASTER

ITEM CODE

ITEM NAME

ITEM RATE
SUPPLY MASTER

SUPPLY NO

CUSTOMER CODE

SUPPLY DATE

ITEM NAME

ITEM QTY

PERIOD

CARD NO
LEAKAGE & RETURN MASTER

ITEM CODE

ITEM NAME

BOOTH CODE

CUSTOMER CODE

CUSTOMER NAME

ITEM QTY

RETURN TYPE

RETURN DATE

PERIOD
INSTITUTION SUPPLY

SUPPLY NO

SUPPLY DATE

PERIOD

ITEM CODE

ITEM NAME

ITEM QTY

AMOUNT

PAYMENT

BALANCE
3.1.3 REPORT LAYOUT

AGENT LEDGER

TM TM
DATE SUP DATE PERIOD CUS CODE 200 500 PM 500 TOTAL

CUSTOMER DETAILS

CUSCOD NAME ROUTE NAME BOOTH NAME ADDRESS PHONE

INSTITUTION LEDGER

DATE SUP DATE CUSCODE TM 500 PM500 TOTAL

SALARY DETAILS

BOOTH
DATE CUSCODE CODE CUS NAME TM 200 TM 500 PM 500 COMISSION
LEAKAGE DETAILS

BOOTH
DATE SUP DATE CODE TM200 TM500 PM 500 VALUE

RETURN DETAILS

BOOTH
DATE SUP DATE CODE TM200 TM500 PM 500 VALUE

SUPPLY DETAILS

BOOTH
DATE SUP DATE ROUTE NO CODE TM200 TM 500 PM 500
3.2 INTERNAL DESIGN

Internal design involves conceiving, planning out and specifying the internal
structure and processing details of the software product. The goals of internal design
are to specify internal source and processing detail, to record design decisions and
indicate why certain alternatives and trade-off was chose, to elaborate the test plan
and to provide a blue-print for implementation, testing and maintenance activities.
The work products of internal design include a specification or process hierarchy,
table design and functional requirements.
3.2.2 PROCESS HIERARCHY:

SYSTEM FLOW

LEVEL 1

MENUS

ENTRY DISPATCH BILLING REPORT

LEVEL 2

BOOTH DETAILS

ROUTE DETAILS

CUSTOMER DET

INSTITUTIONDE
ENTRY T

PARLOUR DET

CUSTOMER RATE

CARD
DETAIILS

ITEM DETAILS
LEVEL 3

DISPATCH

ENTRY DISPATCH BILLING REPORT

LEVEL 4

BILLING

CUSTOMER PARLOUR INSTITUTION OTHERS

LEVEL 5

AGENT LEDGER

CUSTOMER DETAILS

INSTITUTION LGR

SALARY DETAILS
REPORT

LEAKAGE DETAILS

RETURN DETAILS

SUPPLY DETAILS
DETAIILS
CUSTOMER SUPPLY PROCESS

LEVEL 1

SUP NO CHECK SUP NO UPDATION

FOR PROCESS
Supply
UNIQUE

NAME
INVALID
CODE NO

VALID ADDRESS

PHONE NO

SUPPLIER DATABASE
LEVEL 2

SUPPLIER DATA

SUP NO CHECK
FOR
Supply PRIEOD
(FN/AN)

FN/AN

FN/AN+MILKDETAILS
ALLOTING
MILK

SUPPLY
 LEVEL 3

SUPPLIER DATA

SUP NO
DATE
CHECK FOR
MILK
Supply DETAILS

IT EM CODE

QUANTITY

LEAKAGE & RETURN TABLE

DATE, CODE
BILLING SALLARY
PAYMENT QUANTITY COMISSION

BILLING SALARY TABLE

OTHER PRODUCT PROCESS

LEVEL 1

SUP NO CHECK SUP NO UPDATION

FOR PROCESS
supply
UNIQUE

NAME
INVALID
CODE NO

VALID ADDRESS

PHONE NO

SUPPLY DATABASE
LEVEL 2:-

SUPPLY DATA

SUP NO CHECK
SUPPLY FOR
PRIEOD
(FN/AN)

FN/AN

FN/AN+OTHERPRODUCT
ALLOTING
OTHER
PRODUCTS

SUPPLY MASTER
 LEVEL 3

SUPPLIER DATA

SUP NO
DATE
CHECK FOR
Supply OTHER
PRODUCTS
DETAILS

LEAKAGE & RETURN TABLE

Item Name
Item Code
Qty

BILLING
PAYMENT

BILLING
INSTITUTION PROCESS

LEVEL 1:-

SUP NO CHECK SUP NO UPDATION

ISTITUTION FOR PROCESS
SUPPLY UNIQUE

NAME
INVALID
CODE NO

VALID ADDRESS

PHONE NO

SUPPLIER DATABASE
LEVEL 2:-

SUPPLY

SUP NO CHECK
FOR
ISTIUTION PRIEOD
SUPPLY (FN/AN)

FN/AN

FN/AN+MILKDETAILS
ALLOTING
MILK

INSTITUTION SUPPLY
LEVEL 3:-

SUPPLY DATA

SUP NO DATE

CHECK FOR
INSTITUTION MILK
SUPPLY DETAILS

LEAKAGE & RETURN TABLE

BILLING
PAYMENT

BILLING
PARLOUR PROCESS

LEVEL 1:-

SUP NO CHECK SUP NO UPDATION

PARLOUR FOR PROCESS
SUPPLY UNIQUE

NAME
INVALID
CODE NO

VALID ADDRESS

PHONE NO

PARLOUR
SUPPLY DATABASE
LEVEL 2:-

PARLOURSUPPLY

SUP NO CHECK
FOR
PARLOUR PRIEOD
SUPPLY (FN/AN)

FN/AN

FN/AN+MILKDETAILS
ALLOTING
MILK

PARLOUR SUPPLY
LEVEL 3:-

SUPPLY DATA

SUP NO DATE

CHECK FOR
PARLOUR MILK
SUPPLY DETAILS

LEAKAGE & RETURN TABLE

BILLING
PAYMENT

BILLING
TABLE DESIGN

Table design is a collection of interrelated data items. The table for the new system is
designed by the techniques of the relational table management system. It provides flexibility
in the storage and relational of the data in order to anticipate the need to meet unexpected
requirements. Normalization can be done which is the process of simplifying the relationship
between data elements to produce successive structures. The following tables are used in the
system.
BoothMaster

Primary Key: BCOD

Foreign Key: RTCOD
Field Name Type Size Description
*BCOD VarChar 5 Booth Code
RTCOD VarChar 5 Root Code
BNAM VarChar 20 Booth Name

CustomerMaster

Primary Key: CUSCOD

Foreign Key: BCOD
Field Name Type Size Description
*CUSCOD VarChar 5 Customer Code
BCOD VarChar 5 Booth Code
CNAM VarChar 20 Customer Name
ADDRS VarChar 40 Address
PHNO Number 10 Phone Number

CustRateMaster

Foreign Key: CUSCOD

Field Name Type Size Description
CUSCOD VarChar 5 Booth Code
ITMCOD varChar 5 Item Code
CUSRAT Number 5,2 Customer Rate

ItemMaster

Primary Key: ITMCOD

Field Name Type Size Description

*ITMCOD varChar 5 Item Code
ITMNAM VarChar 15 Item Name
ITMRAT Number 5,2 Item Rate
RootMaster

Primary Key: RTCOD

Field Name Type Size Description

RTCOD* VarChar 5 Root Code
RTNAM VarChar 25 Root Name

LeakageReturnMaster

Foreign Key: ITMCOD, CUSCOD

Field Name Type Size Description

ITMCOD VarChar 5 Item Code
CUSCOD VarChar 5 Customer Code
ITMQTY Number 5 Item Quantity
RETRNTYP VarChar 10 Return Type
RETRNDAT Date 8 Return Date
PERIOD VarChar 2 Period FN/AN

SupplyMaster

Primary key:SUPNO
Foreign Key: CUSCOD, ITMCOD, CRDNO

Field Name Type Size Description

SUPNO number 3 Supply number
CUSCOD VarChar 5 Customer Code
SUPDAT Date 8 Date of Supply
ITMCOD VarChar 5 Item Code
ITMQTY Number 5 Item Quantity
PERIOD VarChar 2 Period FN/AN
CRDNO Number 5 Card Number
CRDQTY Number 5 Card Quantity
CardMaster

Primary Key: CRDNO

Foreign Key: ITMCOD

Field Name Type Size Description

*CRDNO Number 5 Card Number
CRDNAM VarChar 5 Card Name
ITMCOD VarChar 5 Item Code

Salary
Foreign Key: CUSCOD

Field Name Type Size Description

CUSCOD Number 5 Customer code
COMISSION Number 5 Total commission
MONTH varChar 10 Month
YEAR number 4 Year

Commission
Foreign Key: CUSCOD

Field Name Type Size Description

CUSCOD Varchar 5 Customer code
DCOM Number 5 Daily commission
CDATE Date 8 Date
AgentLedger

Foreign Key: SUPNO

Field Name Type Size Description

DATE Date 5 Date
SUPNO Number 5 Supply Number
PERIOD VarChar 2 AN/FN
AMT Number 5,2 Amount to be paid
PAMT Number 5,2 Paid amount
BAMT Number 5,2 Balance amount

Institution

Primary key: ICODE

Field Name Type Size Description

ICODE Number 4 Institution code
INAME VarChar 25 Institution name
ADDRESS VarChar 35 Institution address
PHNO Number 10 Institution phone number

INSTITUTION SUPPLY

Primary key: ISUPNO

Field Name Type Size Description

ISUPNO Number 5 Supply No
DATE Date 8 Customer code
PERIOD VarChar 2 AN /FN
ITMCOD VarChar 5 Item Code
QTY number 3 Quantity
AMT number 5,2 Amount to be paid
PAMT number 5,2 Paid amount
BAMT number 5,2 Balance amount
ParlorMaster

Primary key: PCOD

Field Name Type Size Description

PCOD Number 4 Parlour code
PNAME VarChar 25 Parlour name
ADDRESS VarChar 35 Parlour address
PHNO Number 10 Parlor phone number

ParlorSupply

Primary key: PSUPNO

Foreign Key: PCOD

Field Name Type Size Description

PSUPNO Number 5 Supply No
PCOD Number 4 Parlour Code
DATE Date 8 Date
PERIOD VarChar 2 AN /FN
ITMCOD VarChar 5 Item Code
QTY Number 3 Quantity
AMT Number 5,2 Total Amount to be paid
PAMT Number 5,2 Paid amount
BAMT Number 5,2 Balance amount
4. SYSTEM DEVELOPMENT AND OPERATIONS

4.1 SYSTEM DEVELOPMENTS

System development is a process of converting the specifications specified in

the designing stage into source code. Careful study and observation about system designing
were made and accordingly the system was coded to convert from designing to source code,
wee used Visual Basic as the front-end and Oracle as a back-end. The system was developed
such that it should be used for future enhancement.

4.2 SYSTEM OPERATIONS

To use this system, the user has to first enter the password. If the password is valid,
then he enters into the execution process of the system else he is rejected. When the Ponlait
management information is maintained, the main menu opens which consist of the following
menus:

 Entry
 Dispatch
 Billing
 Reports

Entry has the following sub menus:

I. Booth Details
II. Route Details
III. Customer Details
IV. Item Details
V. Customer Rate
VI. Institution Details
VII. Parlour Details
VIII. Card Details

Entry

The entry menu contains eight sub-menus which provides details of the booth official
details, route details in the form of location, customer details which contains the personal
information of the agents, item details which provides different variety of the diary products
and their rates. The Institution details deals with the supply of milk for the institution like
schools, colleges, hospitals etc. The Card Details provides the details of the office staffs who
are all working in the organization to get milk for free of cost.
Dispatch

The dispatch menu that contains four sub-menus which mainly deals with
the supplying of milk to the customers, parlour, institutions and others. These tables are
updated twice in a day for forenoon and afternoon section. As per the dispatch the products
are supplied to the customers.

Billing

Billing is the menu which contains four sub-menus which deals with the billing
process for the agents, parlour, institutions and others.
5. SAMPLE SCREEN:

SCREEN NO: 1

SCREEN NAME: LOGIN FORM

SCREEN NO: 2

SCREEN NAE: MAIN WINDOW

SCREEN NO: 3

SCREEN NAME: BOOTH MASTER

SCREEN NO: 4

SCREEN NAME: CUSTOMER MASTER

SCREEN NO: 5

SCREEN NAME: INSTITUTION MASTER

SCREEN NO: 6

SCREEN NAME: PARLOUR MASTER

SCREEN NO: 7

SCREEN NAME: CUSTOMER RATE MASTER

SCREEN NO: 8

SCREEN NAME: CARD MASTER

SCREEN NO: 9

SCREEN NAME: ROUTE MASTER

SCREEN NO: 10

SCREEN NAME: ITEM MASTER

SCREEN NO: 11

SCREEN NAME: SUPPLY MASTER

SCREEN NO: 12

SCREEN NAME: LEAKAGE & RETURN MASTER

SCREEN NO: 13

SCREEN NAME: INSTITUTION SUPPLY

5.1 REPORT SCREENS:
SYSTEM TESTING
6. SYSTEM DEVELOPMENT AND TESTING

About Testing

Testing involves operation of a system or application under controlled

conditions and evaluating the results (eg, 'if the user is in interface A of
the application while using hardware B, and does C, then D should happen').
The controlled conditions should include both normal and abnormal conditions.
Testing should intentionally attempt to make things go wrong to determine if things
happen when they shouldn't or things don't happen when they should. It is oriented to
'detection'.

Organizations vary considerably in how they assign responsibility for QA and

testing. Sometimes they're the combined responsibility of one group or individual.
Also common are project teams that include a mix of testers and developers who work
closely together, with overall QA processes monitored by project managers. It will
depend on what best fits an organization's size and business structure.

6.1TYPES OF TESTING DONE:

6.1.1 Black Box Testing

Testing 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 a specification or
requirements document.

Black Box Testing is testing without knowledge of the internal workings of

the item being tested. For example, when black box testing is applied to software
engineering, the tester would only know the "legal" inputs and what the expected
outputs should be, but not how the program actually arrives at those outputs. It is
because of this that black box testing can be considered testing with respect to
the specifications, no other knowledge of the program is necessary. For this reason,
the tester and the programmer can be independent of one another, avoiding
programmer bias toward his own work. For this testing, test groups are often used,
"Test groups are sometimes called professional idiots...people who are good at
designing incorrect data." 1 Also, do to the nature of black box testing, the test
planning can begin as soon as the specifications are written. The opposite of this
would be glass box testing, where test data are derived from direct examination of
the code to be tested. For glass box testing, the test cases cannot be determined until
the code has actually been written. Both of these testing techniques have advantages
and disadvantages, but when combined, they help to ensure thorough testing of the
product.

Advantages of Black Box Testing

 More effective on larger units of code than glass box testing

 Tester needs no knowledge of implementation, including specific
programming languages
 Tester and programmer are independent of each other
 Tests are done from a user's point of view
 Will help to expose any ambiguities or inconsistencies in the specifications
 Test cases can be designed as soon as the specifications are complete

6.1.2 White Box TESTING

White box testing strategy deals with the internal logic and structure of
the code. White box testing is also called as glass, structural, open box or clears box
testing. The tests written based on the white box testing strategy incorporate coverage
of the code written branches paths statements and internal logic of the code etc.

In order to implement white box testing, the tester has to deal with the code
and hence is needed to possess knowledge of coding and logic i.e. internal working of
the code. White box test also needs the tester to look into the code and find out which
unit/statement/chunk of the code is malfunctioning

Advantages of White box testing are:

 o As the knowledge of internal coding structure is prerequisite, it becomes very
easy to find out which type of input/data can help in testing the application
effectively.
o The other advantage of white box testing is that it helps in optimizing the
code
o It helps in removing the extra lines of code, which can bring in hidden defects.

6.1.3 UNIT TESTING:

Unit testing deals with testing a unit as a whole. This would test
the interaction of many functions but confine the test within one unit. The exact scope
of a unit is left to interpretation. Supporting test code, sometimes called scaffolding,
may be necessary to support an individual test. This type of testing is driven by
the architecture and implementation teams. This focus is also called black-box testing
because only the details of the interface are visible to the test. Limits that are global to
a unit are tested here.

Unit test is designed to ensure that each unit works on its own and that
the purpose for which it was designed for is fulfilled. Each and every module was
tested individually with the test data and error message were displayed for incorrect
and sufficient data for entry works. All validation was tested to correctness. Test data
were fed in and results were checked for the maintenance module, to ensure that all
the tables created contained nothing but valid data. Reverential integrity constraints
specified as part of the table definition was also tested.

6.1.4 RECOVERY TESTING

Many computer-based systems must recover from faults and resume

processing within pre-specified time. In some cases a system must be fault tolerant,
i.e. processing faults must not cause overall system must not cause overall system
function to cease. In the cases, a system failure must be corrected within a specified
period of time or severe economic damage will occur.

6.1.5 SECURITY TESTING

Any computer-based system that manages sensitive information or causes that
can improperly harm individual is a tablet for improper or illegal penetration.
 Security testing attempts to verify that protection mechanisms built into a
system will, in facts protect it from improper penetration. During security testing, the
tester plays the role of the individual who desire to penetrate the system. The tester
may attempt to acquire passwords through external clerical means; may attack
the system with custom software designed to break down any defenses that have been
construct; may overwhelm the system, thereby denying services to others, may
through insecure data, hoping to find the key system entry.

6.1.6 PERFORMANCE TESTING

For real time and embedded system, software that provides required functions
but not confirm to performances requirements is unacceptable. Performances testing
are designed to test the run-time performance of software within the context of an
integrated system. Performance testing occurs throughout all steps in the testing
process. Even at until level, the performances of an individual module may be
accessed as white box test re-conducted. However, it is not unit all system elements
are sully integrated that true performance of a system can be ascertained.

Performance test are sometimes coupled with stress testing and often required
other hardware and software instrumentation. It is often necessary to measure
resource utilization. By incrementing a system, the tester can uncover situations that
lead to degradation and possible system failure.
CONCLUSION
7. CONCLUSION

So far the life cycle of the project right from the initialization to its
implementation has been described. This need not mean that the project has reached
its ultimate end. The maintenance of the software developed occupies a very
important part in the life of a software product.

The software development can be introduced to the user in the phased manner.
Usability of the system is assured and the performance in better than that of the
existing system.

Changes is inevitable when computer based systems are built. So the least
technology development for evaluation controlling and making modification can be
carried out.

The Ponlait Management System has achieved its primary goal such as speed,
accuracy and in generating the reports to help the management to take crucial
decisions. The software has been implemented to incorporate all the requirements,
specified so as to eradicate the manual table maintenance and report preparations.
Data validation is performed in all data entry sections and proper guidance is
displayed in the status bar the software has been developed in a structured modular
manner, so it allows easy accommodation of future implementation and
modifications.

The result has come up to the level of satisfaction of concerned people.

Provisions are available for easy conversion and modification of information. The
system has security equivalence and it is tamper proof.

As the system is fully menu driven and user friendly, it allows the user to
select the needed choice from the menu. It also has facilities at all the stages and lets
the user to retrieve information without much difficulty.
APPENDIX
8. APPENDIX

8.1 VISUAL BASIC 6.0

INTRODUCTION

Visual Basic is an ideal programming language for developing sophisticated

professional application for Microsoft windows. It makes use of graphical user
interface as the name suggests uses illustration to test with enable uses to interact
With applications.

This features makes it is a to comprehend things in a quicker and easier way.

The system environment is proposed to be developed in Visual Basic 6.0 under
windows operating system environment. The features of the software are given below.

Visual Basic 6.0

Visual Basic is one of the most existing programs for micro computer system
in market today. This revolutionary programming language from Microsoft was
released in the mid of 1991. With the introduction of visual Basic a new era had begin
“Event Driven programming”. With Visual Basic u can write full-fledged windows
application.

EVENT DRIVEN PROGRAMMING

Application built Visual Basic event driven, i.e., the process depends on
the user. Visual Basic as a set off tool, used to create the object making upon
application. Visual Basic applications consist of a set of object, each object can
respond to certain events.

GRAPHICAL USER INTERFACE (GUI)

 Visual Basic is a GUI product running under various windows environment.
A GUI acts as a friendly “FRONT-END” making it carrier to interface with
the computer.

MAIN ASPECTS

Instead of typing command lines, this operations or carried out by pointing at

icons on the screen are selecting form menus and this greatly reduce the amount to
learn and remember. It allows us to run several programs at ones each in its own
“windows”. You can switch rapidly between them and transfer data easily from one to
another.

In a GUI environment the number of options open to a user is much greater,

allowing more freedom to the user and thereby accessing the GUI in an efficient way.

INTEGRATED DEVELOPMENT ENVIRONMENT (IDE)

The Visual Basic integrated Development Environment consists of the

followings elements:

MENU BAR

Display the commands you see to work with Visual Basic besides the standard
File, Edit, View, Window & Help Menus. Menus are provided to access functions
specific to programming such as project format or debug.

TOOL BAR

It provides quick access to commonly in commands in the programming

environment. You click button on the tool bar once, to carry out the action represented
by the button.

TOOL BOX
 Toll Box contains a set of tool that are used to place controls on a form design.
The printer provides a way to move and resize the controls and the controls and
forms.

Label displays a text that the user can’t modify or interact. Frame control serves
as a virtual and functional container for controls. Check box displays a true/false or
yes/no option. List box displays a list of items from which a user can select one.
Combo Box contains a text box and a list box. Timer control executes the timer events
at a special interval within the specified range of values. Shape control Adds a shape
(rectangle, square, and circle ) to a form. Image control is used to link or embed
object, displays and manipulates choices. Drive list box displays a set of files from
which a user can select the desired one Line control draws a straight line to the from.
Data Control enables the user to connect to an existing table and display information
from it.

PROJECT EXPLORE WINDOW

List the forms & modules in your current project. A project is collection of
files. You can use to build an applications. For example you can quickly make visible
the program code for any form or module. As you add, delete, and create new file the
project window updates the file list.

PROPERTIES WINDOW

List the property setting for the selected from or control. A property is
characterized of an object, such as size, caption or color. Property window specifies
the attributes or various objects in your applications. These objects include forms and
the graphical controls you place on them.

CODE WINDOW

For forms, the object box lists the current form and all the controls(objects) on
the current form.

PROCEDURE BOX
 It lists all the events recognized by Visual Basic for the forms/controls
displayed in the object box. When you select an event, either event is displayed.

VB COMPONENTS

The backbone of most every application in visual Basic is a form.

PROCEDURE BOX

The designed forms are the interface to the user. Forms encompass everything
that happens within a window, like drawing of the window, display and entry of data
processing of results of user input.

MULTIPLE DOCUMENT INTERFACE

An MDI is used for opening many forms at the same time. VB applications
can have only one container form[MDI form], which contains all the child forms.
Child forms are displayed within the intervals are of an MDI form at a run time.

CONTROLS

These are objects put on the form to display information, graphics or to get
response form the user or both. Every practical Visual Basic applications user control
is placed on the form. Visual Basic controls Are classifieds as

1. Standard controls
2. Custom controls

1. STANDARD CONTROLS

POINTERS, Timers, Label, Frame, check Box, scroll Bar, Dirlist Box, File list
box, shape, image , OLE picture Box, command Button, Options Button, List Box,
Line , Data control . these controls are EXE controls. They are included in the tool
bar. It cannot be removed.
 2. CUSTOM CONTOLS
An object that you place on a form to enable or enhance user’s interaction with
an application. These controls have an OCX file name extension.

MENU INTERFACE

Adding a custom menu for the application and defining their properties can
enhance Visual Basic operations. It offers a convenient and consistent way to group
commands and easy way for users to access them.

DIALOG BOX

Dialog box are used to display information to the user and to prompt to
the user for the data needed to continue an application. It can be classified as
1. Predefined dialog box
2. Custom dialog box
3. Standard dialog box

PRE-DEFINED DIALOG BOX

Create using Input box () and Msgbox () function.

CUSTOM DIALOG BOX

Created by adding controls to the form or by customizing an existing dialog

box.

CONTROL ARRAY

It is a group controls that share the same type and same name and also shares
same events/procedure and properties. Adding controls with control array using fewer
resources then we use multiple control of same type at design time. One control is
much design time.

PROCEDURES
 Procedures are useful for condensing required operations such as frequently
use calculations, text and control manipulates etc. Procedures can be function
property procedures.

EVENT PROCEDURES

An event procedure is a procedure block that contains controls name,

underscore and the event name and declared as public.

GENERAL PROCEDURES

It is declared when several event procedures perform the same action.

MODULES

When used in host applications that allow references across multiple projects,
option provide module prevents modules content from being outsides its project.

CLASS MODULES

Classes can be built by adding custom properties to a form and then templates
for use objects. But more often the most common way to build a new class for a new
object in VBG is it uses a class module. A class module objects contains the code for
the custom properties and method that objects defined. We can create new instances
of the class from any module or form in our project..

1. STANDARD MODULES

A module contains only procedures, types and data declarations and definitions
module level declarations and definitions in a standard module or public by default.

FEATURES OF NEWEST VERSION OF VISUAL BASIC 6.0

These are some of Visual Basic 6.0 advantage over the previous versions:
 The User can generate 32-bit applications both in window 2000 and Windows
NT with no extra work.
The user can take the advantage of MS-OLE and ActiveX designers, Active x
controls, ActiveX documents and active DLLS.
The user can built programs using some technique of OOPS.
8.2 ORACLE

INTRODUCTION TO ORACLE

Oracle8 is an Object Relational Database Management System (ORDBMS). It

offers capabilities of relational and object oriented database system. Oracle products
are based on Client/Server Technology. In this technology server performs al
activities related to the database and the client performs activities that help the user to
interact with the application.

TOOLS OF ORACLE

 SQL *Plus
 PL/SQL
 Forms
 Reports

SQL *PLUS

SQL *Plus is a Structured Query Language supported by Oracle. Through

SQL *Plus we can store, retrieve, edit and run SQL commands and PL/SQL blocks.
Using SQL *Plus we can perform calculations, list column definitions for any table
and can also format query results in the form of a report.

PL/SQL

PL/SQL is an extension of SQL. PL/SQL block can contain any number of

SQL statements integrated with flow of control statements. PL/SQL is a procedural
language for the oracle server and its client. In a PL/SQL program, SQL statements
are used for data manipulation and transaction processing.

FORMS

Form is a graphical tool used for generating and executing forms based
applications. A form basically consists of block and fields. Multiple tables can be
accessed over a single form base application with the help of transaction commands.
Oracle form builder is the design component of oracle forms.

REPORTS

It is an application development tool of oracle for developing, executing,

displaying and printing reports. We can create wide variety of reports, which have
various modes. Oracle Reports are powerful and easy to use.

CODD’S RULES FOR A FULLY RELATIONAL DBMS

According to Elmasri and Navathe (1994), Dr. E.F.Codd, the originator of the
relational data model, published a two-part article in Computer World (Codd, 1985)
that lists 12 rules for how to determine whether a DBMS is relational and to what
extent it is relational. These rules provide a very useful yardstick for evaluating a
relational system. Codd also mentions that, according to these rules, no fully
relational system is available yet. In particular, rules 6, 9, 10, 11 and 12 are difficult to
satisfy.

THE 12 RULES

Rule 1: The Information Rule

All information in a relational database is represented explicitly at the logical

level in exactly one way-by values in tables.

Rule 2: Guaranteed Access Rule

Each and every datum (atomic value) in a relational database is guaranteed to

be logically accessible by resorting to a table name, primary key value, and column
name.

Rule 3: Systematic Treatment of Null Values

Null values (distinct from empty character string or a string of blank

characters and distinct from zero or any other number) are supported in the fully
relational DBMS for representing mission information in a systematic way,
independent of data type.
Rule 4: Dynamic On-line Catalog Based on the Relational Model

The database description represented at the logical level in the same way as
ordinary data, so authorized users can apply the same relational language to its
interrogation as they apply to regular data.

Rule 5: Comprehensive Data Sublanguage Rule

A relational system may support several languages and various modes of

terminal use (for example, the fill-in-blanks mode). However, there must be at least
one language whose statements are expressible per some well-defined syntax, as
character strings and whose ability to support all of the following is comprehensible:
data definition, view definition, data manipulation (interactive and b program),
integrity constraints, and transaction boundaries (begin, commit and rollback).

Rule 6: View Updating Rule

All views that are theoretically updateable are also updateable by the system.

Rule 7: High-level Insert, Update and Delete

The capability neither of handling a base relation or a derived relation as a

single operand applies nor only to the retrieval of data but also to the insertion,
update, and deletion of data.

Rule 8: Physical Data Independence

Application programs and terminal activities remain logically unimpaired

whenever any changes are made in either storage representation or access methods.

Rule 9: Logical Data Independence

Application programs and terminal activities remain logically unimpaired

when information preserving changes of any kind that theoretically permit
unimpairment are made to the base tables.
Rule 10: Integrity Independence

Integrity constraints specific to a particular relational database must be definable in

the relational data sublanguage and storable in the catalog, not in the application
programs.

A minimum of the following two integrity constraints must be supported:

1. Entity integrity: No components of a primary key is allowed to have a null

value.
2. Referential integrity: For each distinct non-null foreign key value in a
relational data-base, there must exist a matching primary key value from the
same domain.

Rule 11: Distribution Independence

A relational DBMS has distribution independence. Distribution independence implies

that users should not have to be aware of whether a database is distributed.

Rule 12: Non-subversion Rule

If a relational system has a low-level (single-record-at-a-time) language, that low-

level language cannot be used to subvert or bypass the integrity rules or constraints
expressed in the higher-level (multiple-records-at-a-time) relational language.

File System Data Management

 Requires extensive programming, typically in Third Generation Language

(3GL)
 Leads to islands of information and data redundancy
 Difficult to make ad hoc queries to obtain information
  Difficult to maintain data integrity

Data and Structural Dependence

 Data characteristics are embodied in programs not stored with the data.
 Changes in data characteristics requires modifying programs
 Changes in file structures require modification of related programs

Data Redundancy

 Different and possibly conflicting versions of same data

 Results in problems during data:
o Modification (e.g. address changes)
o Insertion
o Deletion
 Data inconsistency: Lack of integrity

Database Systems

 Database consists of logically related data stored in a single repository

 Advantages over file system management approach:
o Eliminates inconsistency, data anomalies, data dependency, and
structural dependency problems
o Stores data structures, relationships, and access paths

Uses of Databases

 Transactional (or production):

o Supports a company’s day-to-day operations
 Data warehouse:
o Stores data used to generate information required to make tactical or
strategic decisions
o Such decisions typically require “data massaging”
 o Often used to store historical data
o Structure is quite different

DBMS Functions

 Metadata/Data Dictionary Management

 Data storage management
 Data transformation and presentation
 Security management and Multiuser access control
 Backup and recovery management
 Data integrity management
 Database language and application programming interfaces
 Database communication interfaces

Database Models

Collection of logical constructs used to represent data structure and relationships

 Conceptual Models: logical nature of data representation

 Implementation Models: how data are represented

Database Models

The hierarchical and network models are of historical interest only.

 Relational

 Entity-Relationship

 Object oriented

Relational Model

 Most common model

 Perceived by user as collection of tables containing data
  Actually has a formal definition based on set theory
 Tables are a series of row/column intersections
 Tables related by sharing common entity characteristic(s)

Limitations on System Assigned Keys

 System-assigned primary key may not prevent confusing entries

 Data entries in Table 5.2 are inappropriate because they duplicate existing
records
 Yet there has been no violation of either entity integrity or referential integrity
 Perhaps Job Description needs to be unique
BIBLIOGRAPHY
BIBLIOGRAPHY

The following books have been referred during the project work and have been
recommended for future reading:

DATABASE MANAGEMENT SYSTEM

- By James Martin

SOFTWARE ENGINEERING
- By Richard Fairley

VISUAL BASIC 6.0 FROM GROUND UP

- By Gary Cornell

ANALYSIS AND DESIGN OF INFORMATION SYSTEM

- By James A. Sem

ORACLE 8 THE COMPLETE REFERENCE

- By Kevin Loney