DATABASE DESIGN

3.1 System Design

The design is a solution, the translation of requirements into center ways of meeting. The design is actually the process of analyzing, organizing and developing a database model that accurately reflects the organization functioning in the real world and implementing that model by creating a database requires an appropriate methodology. System can be divided into two phases.

1. Logical Design
2. Physical Design

3.2 Logical Design

The logical design describes the detail specification for the proposed system. We can say that it describes its own feature. Input, output, file (table) and database in manner that meets the project needs. In logical design work with users is done to develop general design, choose best design, develop system flow charts, identify hardware, software and personal needs and revise estimates etc.

3.3 Physical Design

The purpose of physical design is to translate the logical description of data into the technical specification for storing and retrieving data. The goal is to create design for storing data that will provide adequate performance and ensure database integrity, security and recovery. Physical database design does not include implementing files and databases (i.e. creating them and loading data into them).

3.4 Input Design

The input design specifies the number in which the user enters the data to the system for processing at later stage. Input design can insure the reliability of the system and provide an accurate result. The input determines whether the user interacts with the system efficiently or not. The input design can also be explained as a link between the user and the world. Input design consists of those steps necessary to put transactions data into usable form of processing. While designing the input for the Sale Supply Application information system has the following objectives were kept in mind as guidelines.

1. Reducing the amount of input
2. Avoiding errors in data
3. Keeping extra steps
4. Keeping the process simple

3.5 Data Capturing

In input design only those items are captured which must actually be the subject of input while designing the input, following points were kept in mind.

1. Customer information/record
2. Supplier information/record
3. Business Information
4.  Sales Order record
5. Users information

3.6 Input Validation

Input validation is general term given to method, aim for detecting errors in the input. The main thing, which is considered in the input, is that what the chances of error are?

Following are input validation used for Sale Supply Application.

1. Empty entry Control
2. Data Type Validation
3. Not Null

3.7 Output Design

A system is considered to be successful or unsuccessful on the basis of output design. The term “output” means that after compilation of physical design what errors come out of the computer system for the user. The output in project is considered as the backbone of the project. The major form of output is hard copy from the printer. All managerial design is actually made through these reports. Basically the reports are very important aspect of the output. The user creates various reports in response to queries and these reports can be printed.

3.8 Data base Design

• Database Design is a creative process of transforming:
• Problems into Solution
• The description of solution
• Intelligent database design is perhaps the most critical element of an optimal solution with respect to performance. In fact, poor design is usually the culprit for poorly performing solutions.
• Designer of the database should satisfy the user.

3.9 Architectural Design

The primary objective of architectural design is to develop a modular program structure and represent the control relationship between them.

3.10 Conceptual Database Design

Tells the user exactly what the system will do? It describe the functions of the systems, the system will work in the following areas.

• Unique authorized access to all registered users
• Purchasing of products
• Data Validation checks
  The system is defined by its boundaries, entities, attributes, and relationship.

3.11 Software Process Model

A software process model is a structure on the development of a software product. Several models exist to streamline the development process. Each one has its own advantages and it’s up to the development team to adopt the most appropriate one for the project sometime a combination of the models may be more suitable.

So a software process model is an abstraction of actual process, which is being described. Process model may include activities, which are parts of the software process; software product and the role of people involved in the software engineering

Software development process includes the following activities as discussed earlier that there are several software development models some major type of these models are.

• Water fall model
• Iterative and incremental development
• Agile development
• Spiral development model etc

3.12 Model used in this project

In our project we used Evolutionary development model because the requirements is not fill full we meet with a group of Users and interview a large number of Customer/Supplier to collect information. and then start analysis after analysis we start our project design when the project design is complete then come back to the group of doctors and show the design when they become satisfy from our design then we start the implementation when the implementation is complete then again came to meet with doctors group and show our project implementation when they satisfy then we cover our project. We use Evolutionary development model because in first the requirements is not fill full. Evolutionary prototyping model is a software development lifecycle model in which software prototype created for demonstration and requirements elaboration. Evolutionary prototyping model includes the four main phases.

• Definition the basic requirements
• creating the working prototype
• Verification of the working prototype
  Evolutionary prototyping model allows create working software prototypes fast and may be applicable to projects where:

• System requirements early are not known in advance
• creating fundamentally new software
• Developers are not confident in software architecture and algorithms

3.13 Types of Evolutionary Development

1. Exploratory Development
2. Throwaway prototyping

3.13.1 Exploratory Development

In this model the objective of the process is to work with the customer to explore their requirements and deliver a final system. The development starts with the parts of system that are understood. The system evolves by adding new features proposed by the customer.

3.13.1.1 Steps in the exploratory model

• A starting point is determined for the work. All the information available is gathered
• Together in an attempt to get an idea of what the new system will be expected to do, and how it can be done.
• A rudimentary first-generation system is put together, based on the information gathered and the ideas formulated in the first step.
• The first-generation system is tested to see how it performs, what it can and cannot do, and what might be done to improve it.
• A second-generation system is developed from the first one, based on the improvements proposed in the previous step.
• The second-generation system is tested, as was the first. Its performance is evaluated, and possible improvements determined.
• The process is repeated as many times as necessary to obtain user satisfaction, or until it is decided that the project is unworkable.

3.13.2 Throwaway Prototyping

In this model where the objective of the evolutionary development process is to understand the customer’s requirements and hence develop a better requirements definition for the system. The prototype concentrates on the experimenting with the customer requirements that are poorly understood. An evolutionary approach to software development is often more effective then the waterfall approach in producing systems. That meets the intermediate need of customers. The advantage of a software process that is based on evolutionary approach is the specification can be developed incrementally. However from an engineering and management perspective the evolutionary approach has two problems. The process is not visible managers need regular deliverable to measure progress. If systems are developed quickly it is not cost-effective to produce document that reflect every version of the system. Systems are often poorly structured continual change tends to corrupt the software structure incorporating software changes becomes increasingly difficult and costly.

3.14 Modular Design

Modular design occurs after data; architecture and interface designs have been established. In and world, the modular specification required to be define algorithmic details would be stated in a natural language such as English because it is easily understandable. And then that straight forward plain English are converted to diagrams. There is no question that graphics tools such as flow charts or box diagrams provide excellent pictorial patterns that readily depict modular details. However graphical tools are misused, the wrong picture may lead to wrong software. In this section we will demonstrate some of our basic modules by using Flow Charts. Such as form entry, searching, deletion, insertion, updating and reports.