Data Base Project

Group Members
NAME ID

1.Abenezer Amado……………………318374/16

2.Surafel Abebe …………………….763649/16

3.Temesgen Abebe…………….328669/16

4.Yeabsra Tesfaye………………….044683/16

5.Biruk Shamena……………………..2678/16
132328/16
132328/16
6.Goner tut.........................................4934/16

1|Page
Table of Content
1. relationship(foreign key )
2. Primary Key and Foreign Key
3. Entities and attributes (Logical Design)
4. Physical design
5. Sql query and graphs
6. Documentation (References)

2|Page
1.relationship(foreign key )

• Entity Identification:
• Bus: Represents a bus used for transportation.
• Route: Represents a path from an origin to a destination.
• Trip: Represents a scheduled journey of a bus along a route.
• Customer: Represents a person who books a trip.
• Booking: Represents a reservation of a seat on a particular trip.
• Payment: Represents the financial transaction for a booking.

• Attribute Definition:
• Bus:
* BusID (unique identifier for each bus)
* BusName
* Capacity (number of seats)
* Type (e.g., luxury, standard, mini)
• Route:
* RouteID (unique identifier for each route)
* Origin (starting location)
* Destination (ending location)
* Distance
• Trip:
* TripID (unique identifier for each trip)
* BusID (foreign key referencing the Bus entity)
Customer:
* CustomerID (unique identifier for each customer)
* Name
* PhoneNumber
* Email
* Booking:
* BookingID (unique identifier for each booking)
* CustomerID (foreign key referencing the Customer entity)
* TripID (foreign key referencing the Trip entity)
* BookingDate (date when the booking is made)
* Status (e.g., pending, confirmed, cancelled)
* Payment:
* PaymentID (unique identifier for each payment)
* BookingID (foreign key referencing the Booking entity)
* Amount (payment amount)

3|Page
 * PaymentMethod (e.g., credit card, mobile money)
* PaymentDate (date of payment)

• Relationship Definition:
* One Bus can have many Trip records (one-to-many)
* One Route can have many Trip records (one-to-many)
* One Customer can have many Booking records (one-to-many)
* One Trip can have many Booking records (one-to-many)
* One Booking record can have one Payment record (one-to-one).

• Conceptual ERD
A visual representation of this diagram has been shown before.

2.Primary Key and Foreign Key

*Primary Key

• Definition: A primary key is a column (or a set of columns) in a table that

uniquely identifies each row in that table. It's like a unique identifier for each
record.

• Characteristics:

• Uniqueness: Every value in the primary key column must be unique. No two
rows can have the same primary key value.

• Not NULL: The primary key column cannot contain NULL values. Every
row must have a primary key value.

• Minimality: The primary key should be as small as possible while still

maintaining uniqueness. This improves database performance.

• Purpose:

• Uniquely identifies each record in a table.

• Ensures data integrity by preventing duplicate records.

• Serves as a reference point for establishing relationships with other tables

(through foreign keys).

4|Page
• Example: In a Customers table, customer_id is often used as the primary key.
Each customer has a unique customer_id.

* Foreign Key:

• Definition: A foreign key is a column (or a set of columns) in one table that
refers to the primary key of another table. It establishes a link or relationship
between the two tables.

• Characteristics:

• References Primary Key: The foreign key column must reference the primary
key column of another table.

• Referential Integrity: The values in the foreign key column must either match
a value in the referenced primary key column or be NULL (depending on how the
foreign key constraint is defined). This ensures that relationships between tables
remain consistent.

• Purpose:

• Establishes relationships between tables.

• Ensures referential integrity by preventing orphaned records (records in one

table that refer to non-existent records in another table).

• Facilitates efficient data retrieval through joins.

• Example: In a Orders table, a customer_id column could be a foreign key

referencing the customer_id primary key in the Customers table. This links each
order to a specific customer.

3. Entities and attributes (Logical Design)

The logical design validates the conceptual model and normalizes the data into
relations. Below is the normalized database schema:

5|Page
• Table Definition:

* Bus: Stores bus information

* Route: Stores route information

* Trip: Stores trip schedule and fare information with foreign keys linking to
Bus and Route tables

* Customer: Stores customer information

* Booking: Stores booking information with foreign keys linking to Customer

and Trip tables

* Payment: Stores payment information with a foreign key linking to the

Booking table.

• Column Definitions:

* Bus:

* BusID INT PRIMARY KEY AUTO_INCREMENT

* BusName VARCHAR(255)

* Capacity INT

* Type VARCHAR(50)

* Route:

* RouteID INT PRIMARY KEY AUTO_INCREMENT

* Origin VARCHAR(255)

* Destination VARCHAR(255)

* Distance DECIMAL(10,2)

* Trip:

* TripID INT PRIMARY KEY AUTO_INCREMENT

* BusID INT, FOREIGN KEY (BusID) REFERENCES Bus(BusID)

6|Page
 * RouteID INT, FOREIGN KEY (RouteID) REFERENCES Route(RouteID)

* Schedule DATETIME

* Fare DECIMAL(10,2)

* Customer:

* CustomerID INT PRIMARY KEY AUTO_INCREMENT

* Name VARCHAR(255)

* PhoneNumber VARCHAR(20)

* Email VARCHAR(255)

* Booking:

* BookingID INT PRIMARY KEY AUTO_INCREMENT

* CustomerID INT, FOREIGN KEY (CustomerID) REFERENCES

Customer(CustomerID)

* TripID INT, FOREIGN KEY (TripID) REFERENCES Trip(TripID)

* BookingDate DATE

* Status VARCHAR(50)

* Payment:

* PaymentID INT PRIMARY KEY AUTO_INCREMENT

* BookingID INT, FOREIGN KEY (BookingID) REFERENCES

Booking(BookingID)

* Amount DECIMAL(10, 2)

* PaymentMethod VARCHAR(50)

* PaymentDate DATE

7|Page
• Logical ERD

The textual diagram for the logical ERD was presented before.

Validation Using Normalization

• Normalization

The above schema is normalized up to 3NF, avoiding data redundancy and

insertion, deletion, and update anomalies.

Normalization ensures that the data model adheres to the following rules:

1. First Normal Form (1NF)

o All attributes contain atomic (indivisible) values.
o Each table has a primary key to uniquely identify records.
o Example: In the Passenger table, Address is a single attribute
and does not store multiple values in one field.
2. Second Normal Form (2NF)
o No partial dependency exists (all non-key attributes are fully
dependent on the primary key).
o Example: In the Schedule table, RouteID and BusID are fully
dependent on ScheduleID.
3. Third Normal Form (3NF)
o No transitive dependency exists (non-key attributes are not
dependent on other non-key attributes).
o Example: In the Booking table, BookingStatus depends only on
the primary key BookingID.

4. Physical Design
• Database System Selection:

MySQL database is selected for this project.

• Storage Structures:

8|Page
 Data will be stored using default MySQL storage engines. Indexing will be added
on the primary keys and the foreign keys.

• Data Types:

Data types for columns have already been defined using specific MySQL syntax.

• Hardware Requirements:

A server with at least 8 GB RAM and 100 GB storage.

• Security:

Implement password protection for the database, and create different user roles
for different staff levels.

• Backup and Recovery:

Implement daily full database backups and transaction logs for rollbacks.
Backups should be stored in a different server for safety.

• Implementation Details:

Database will be hosted on a server and managed using a database management

system, and will be accessed via the application or database client.

Validation Against User Transactions (Mission Objectives)

The following user transactions identified in the mission objectives have been
validated against the relations:

1. Search and Book a Ticket

o Users search for available buses based on Route and Schedule.

9|Page
 Booking details are stored in the Booking table, linked to the
o
Passenger and Schedule tables.
2. View and Update Bus Schedules
o Bus operators can update the Schedule table, which links buses
(BusID) to routes (RouteID).
3. Manage Payments
o Payments are tracked in the Payment table, linked to the Booking
table.
o Attributes like PaymentMethod and PaymentStatus ensure
flexibility and transparency.
4. Retrieve Booking History
o Passengers can view their booking history by querying the Booking
table using their PassengerID.
5. Generate Reports
o Bus operators and administrators can generate reports using joins
between Bus, Route, Schedule, and Booking tables.

5.Sql query and graphs

*Relationship Diagram

10 | P a g e
*ER Diagram

11 | P a g e

page 11
6.Documentation (References)

• Citations:
* Database Normalization
* MySQL Documentation

Simplified Table Example

Here is an example of how the tables interact:

Customer Table

Customer ID Full Name Phone number Email

49 Temesgen Abebe +251925897463 [email protected]

Bus Table

Bus ID Bus Name Capacity Bus type

3210 Selam bus 44 Luxury

Route Table

Route ID Origin Destination Distance

11 Addis Ababa Hawassa 275.0

12 | P a g e
Trip Table

Trip ID Bus ID Route ID Schedule Fare

21 3210 11 2024-01-01 08:00:00.000 850.00

Booking Table

Booking ID Customer ID Trip ID Booking Date Booking Status

31 120 21 2023-12-01 Confirmed

Payment Table

Payment ID Booking ID Payment Amount Payment Method Payment Date

41 31 850.00 Credit Card 2023-12-01

This logical design is both normalized and aligned with the system's mission objectives to ensure
data integrity, efficiency, and user satisfaction.

13 | P a g e