Database design is the process of producing a detailed data model of a database.

This logical data model contains all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database. A fully attributed data model contains detailed attributes for each entity. The term database design can be used to describe many different parts of the design of an overall database system. Principally, and most correctly, it can be thought of as the logical design of the base data structures used to store the data. In the relational model these are the tables and views. In an object database the entities and relationships map directly to object classes and named relationships. However, the term database design could also be used to apply to the overall process of designing, not just the base data structures, but also the forms and queries used as part of the overall database application within the database management system (DBMS).[1] The process of doing database design generally consists of a number of steps which will be carried out by the database designer. Usually, the designer must:

Determine the relationships between the different data elements. Superimpose a logical structure upon the data on the basis of these relationships.[2]

ER Diagram (Entity-relationship model)

A sample Entity-relationship diagram Database designs also include ER(Entity-relationship model) diagrams. An ER diagram is a diagram that helps to design databases in an efficient way. Attributes in ER diagrams are usually modeled as an oval with the name of the attribute, linked to the entity or relationship that contains the attribute. Within the relational model the final step can generally be broken down into two further steps, that of determining the grouping of information within the system, generally determining what are the basic objects about which information is being stored, and then determining the relationships between these groups of information, or objects. This step is not necessary with an Object database.[2]

The design process consists of the following steps[3]:

steps.
2. Find and organize the information required - Gather all of the types of information

you might want to record in the database, such as product name and order number.
3. Divide the information into tables - Divide your information items into major entities

or subjects, such as Products or Orders. Each subject then becomes a table.

5. 6.

7.

8.

each table. Each item becomes a field, and is displayed as a column in the table. For example, an Employees table might include fields such as Last Name and Hire Date. Specify primary keys - Choose each tables primary key. The primary key is a column that is used to uniquely identify each row. An example might be Product ID or Order ID. Set up the table relationships - Look at each table and decide how the data in one table is related to the data in other tables. Add fields to tables or create new tables to clarify the relationships, as necessary. Refine your design - Analyze your design for errors. Create the tables and add a few records of sample data. See if you can get the results you want from your tables. Make adjustments to the design, as needed. Apply the normalization rules - Apply the data normalization rules to see if your tables are structured correctly. Make adjustments to the tables

Description

Bus Reservation System Introduction

The bus reservation system would allow any user to make a reservation and, eventually pay for the ticket. As a result, a reservation reco the user can select a seat. There are different models of buses therefore a bus configuration interface has to be created. Based on a par configuration, an itinerary will be selected. There can be a variety of itineraries; therefore an Itinerary interface would have to be created. A combination of an itinerary and bus configuration for a particular date is called a trip. Tickets can be bought for one way or round trip.

Bus Configuration

The Bus configuration interface would allow to enter the fleet of buses available for a particular company. The following are characteristic 1. Name (i.e. Neoplan Spaceliner) 2. Number of seats. 3. Number of seats per row. 4. Has TV 5. Has Air Conditioning 6. Has Sleeper 7. Has Meal 8. Seat space category (normal, wide, spacey, big recline) 9. Status (Active, Inactive)

Itinerary Configuration The Itinerary configuration would allow to enter all the possible itineraries available for this company. 1. Identification (Kansas City, Laredo) 2. Start Day (Monday, Tuesday) 3. length (72 hours) 4. Stops (1 through 99) 5. Itinerary Stops a. Stop Id (1,2,) b. Stop City c. Arrival Time d. Departure Time e. Trip Price

Trip File The Trip File has information about each portion of an itinerary. 1. Id 2. From 3. To 4. Departure Date 5. Departure Time 6. Trip Length (Hours & Minutes) 7. Itinerary ID

8. Bus ID

Reservations File The reservations File contains a reservation for each trip or combination of trips. 1. Record ID 2. Reservation Id 3. Trip ID 4. Client ID 5. Amount 6. Paid Amount 7. Paid Date 8. Receipt Number 9. Change Seat Approve

Scenarios

A client may make a reservation for a particular trip or several trips at the same time and can be one way or round trip. There will be seve reservation file with the same reservation ID. There has to be a way to make sure that the seat will be available for the whole duration of passenger needs to change seats during the trip, a warning has to be displayed for the passenger to approve it. Reservation Interface

The reservation interface will first display the itineraries for a departure date and time, the departure city and arrival city. The system will or a portion of itinerary. (i.e. for the itinerary Oklahoma City to Laredo with stops in Dallas, Austin, San Antonio), the passenger only wan Austin to San Antonio.

The system will search the trip database to select all records that stop in San Antonio and Austin with the same itinerary ID and will list th

The passenger will select one and continue to the seat assignment interface. If there are seats available for the entire segment that the p requests, only those seats will be displayed. If the seat has to change in the middle of the trip, it has to be marked in the seat assignmen The seat assignment interface has to show graphically the layout of the bus. Ajax has to be used as much as possible for this interface and also for the selection of the departure and arrival city. There will be an opening and closing of day procedures based on the sales. Any standard procedure suggested will be accepted. Interface available in Spanish and English strongly desired. For questions and suggestions please write to: