Ride Transportation Service Database Design

CSEg 2208: Database Systems

Adama Science & Technology University

Contents
Introduction

Planning Phase

Entities & their relevant attributes

Entity list.

Entity structures with relevant attributes: Primary Keys & Foreign Keys.

Data Definition Language implementations:

Relationship between all entities

Cardinality.

Final ER Diagram

References
Introduction

Ride Transportation Service is the leading ride-hailing company in Ethiopia, with over 500,000
satisfied customers and a fleet of over 1,000 vehicles operating in Addis Ababa and other major
cities. Their commitment to safety, reliability, and customer satisfaction has earned them a
reputation as the go-to transportation service in Ethiopia. With a strong presence in major cities
across the country, their dedicated team of drivers and customer support staff are passionate
about providing exceptional service to their customers. They offer competitive pricing,
convenient payment options, and a range of vehicle types to suit every need.

However, due to their rapid growth and increasing popularity, their manual systems are
struggling to keep up with the demand. To ensure they continue to provide the highest level of
service to their customers, they recognize the need for a comprehensive database system to
manage their operations efficiently. This system will enable them to streamline their processes,
improve their response times, and provide a more personalized experience for their customers.

Ride Transportation Service has asked our team to design a database system that will support
their continued growth and success. This project involves creating an Entity-Relationship (ER)
model, a relational diagram derived from the ER model, a normalized relational schema, sample
data, and SQL queries. The ER model will help us understand and analyze the entities,
relationships, and cardinalities of their data, while the relational schema will ensure data
redundancy is eliminated and data storage and retrieval are optimized. The final step will be to
create sample data to test the design and demonstrate its effectiveness. By implementing this
database system, Ride Transportation Service aims to enhance their customer service, improve
their operational efficiency, and maintain their position as the leading ride-hailing company in
Ethiopia.
1. Planning Phase

1.1 Define the Scope and Objective

A. Define the Objectives and Goals

 Primary Goal: The primary goal of the Ride Transportation Service database to support
the operations of the "Ride" Transportation Service company, which provides ride-
hailing services to customers. The database will store information about customers,
drivers, vehicles, trips, payments, and other relevant data to facilitate the efficient and
reliable operation of the service. By designing a database that addresses these
requirements, the company can improve their operational efficiency and provide better
service to their customers.

 Secondary Goals:

 Improve the accuracy and reliability of data management, reducing errors and
inconsistencies.
 Provide real-time access to data for better decision-making and operational
efficiency.
 Enhance security and privacy of customer and driver information.
 Facilitate the integration of additional features such as promotions, discounts, and
customer feedback mechanisms.

B. Identify Stakeholders

 Primary Stakeholders:
Management Team: Responsible for overseeing the implementation of the
database and ensuring it aligns with the company’s strategic goals.
IT and Development Team: Tasked with the design, development, and
maintenance of the database system.
 Operations Team: End-users who will interact with the database on a daily basis
to manage rides, drivers, customers, and payments.
 Secondary Stakeholders:
Drivers: Who will benefit from more efficient trip management and payment
processing.
Customers: Who will experience improved service reliability and better access to
ride-hailing services.
Customer Support Team: Who will use the database to resolve customer issues
more effectively.

C. Define Functional Requirements

 The database must be able to:

 Manage Customer Information: Store and update customer profiles, including
contact details and payment methods.
 Employee Management: Manage personnel involved in logistics operations,
including drivers, dispatchers, and warehouse staff, to ensure seamless
coordination and execution.
 Track Trips: Log trip details such as pickup/drop-off locations, times, trip status,
and fare amounts.
 Process Payments: Record and process payments, track payment status, and
generate receipts.
 Vehicles Management: Store vehicle information, including make, model,
license plate number, and capacity.
 Handle Customer Feedback: Record customer ratings and reviews for drivers
and trips.

2. Analysis Phase

2.1 Feasibility Analysis

 Technical Feasibility:
 The database system will be implemented using a robust relational database
management system (RDBMS) that can handle large volumes of data and
transactions. The chosen technology should support scalability to accommodate
future growth, offer strong security features to protect sensitive data, and provide
high availability to minimize downtime.
The Ride Transportation Service's existing IT infrastructure, including servers,
network capabilities, and data storage solutions, will be assessed to ensure
compatibility with the new database system. If necessary, upgrades or additional
resources may be recommended.

 Operational Feasibility:
The database system is designed to integrate seamlessly into the company’s
current operations, enhancing the efficiency of ride management, payment
processing, and customer service. The transition from manual to automated
processes will be carefully managed to minimize disruption.
Training will be provided to the operations team, drivers, and customer support
staff to ensure they are proficient in using the new system. Ongoing support will
be available to address any issues that arise during and after implementation.

 Economic Feasibility:
The cost of developing and implementing the database system will be evaluated
against the expected benefits, such as improved operational efficiency, reduced
errors, and enhanced customer satisfaction.
A cost-benefit analysis will be conducted, factoring in the initial investment,
ongoing maintenance costs, and potential savings from increased efficiency. The
database system is expected to offer a positive return on investment by enabling
Ride Transportation Service to handle more customers and trips with fewer
resources.

2.2 Requirement Determination

 User Requirements:
 Operations Team: Needs a user-friendly interface to manage day-to-day
operations, including booking rides, assigning drivers, and monitoring trip
progress. The system should provide real-time data access to ensure efficient
decision-making.
Drivers: Require a system that provides timely notifications about assigned trips,
payment processing, and customer feedback. They should be able to easily update
their availability and receive support when needed.
Customers: Expect a reliable service with accurate booking information, prompt
payment processing, and the ability to rate and review their experience. The
system should allow easy access to ride history and payment details.

 System Requirements:
Hardware: The database will require servers with sufficient processing power,
memory, and storage to handle large volumes of data and transactions. Redundant
systems will be implemented to ensure high availability.
Software: The system will be built on an RDBMS that supports the required
functionalities, such as MySQL, PostgreSQL, or Microsoft SQL Server.
Additional software may include data backup solutions, security tools, and user
interface development platforms.
Networking: Reliable network infrastructure will be needed to ensure seamless
communication between the database, the operations team, drivers, and
customers.

 Functional Requirements:
Customer Management: The system must store and retrieve customer details
efficiently, supporting updates and providing quick access to customer profiles.
Driver Management: The database should track driver information, including
their availability and assigned vehicles, and facilitate easy updates.
Trip Management: The system must record and manage trip details, ensuring
that all relevant information is accessible to both the operations team and drivers.
 Payment Processing: The database must handle payment records, track payment
statuses, and support various payment methods, ensuring secure and accurate
transactions.
Reporting: The system should generate reports on operations, such as ride
statistics, driver performance, and financial summaries, to assist management in
decision-making.

3. Design Phase

3.1 Conceptual Design

Entities and their relevant attributes

Entity List

1. Employee: An office person working for the company.

2. Customer: An individual person that uses the service.
3. Driver: A person driving a vehicle for the company.
4. Vehicle: A car or other vehicle used for transporting customers.
5. Trips- Represent a completed ride from a pickup location to a drop-off location.
6. Payments: An exchange of money for a service provided.
7. Rides- Represent a requested ride, which may or may not have been completed.
8. Feedback: A review or rating provided by a customer about their experience.
9. Discounts: A reduction in the price of a ride offered to customers.

3.2 Relational Database Schema

Entity Structures with relevant attributes and their constraints:

1. Employee

Field Data Type Description Constraints

EmployeeID INT Unique identifier for each employee Primary Key
FName VARCHAR FirstName of the employee NOT NULL
LName VARCHAR LastName of the employee NOT NULL
Email VARCHAR Employee's email address UNIQUE, NOT
NULL
PhoneNumber VARCHAR Contact number of the employee NOT NULL
Position VARCHAR Employee's job position NOT NULL
DateOfHire DATE Date when the employee was hired NOT NULL

2. Customer

Field Data Type Description Constraints

CustomerID INT Unique identifier for each customer Primary Key

FName VARCHA FirstName of the customer NOT NULL

R
LName VARCHA LastName of the customer NOT NULL
R
Email VARCHA Customer's email address UNIQUE, NOT
R NULL
PhoneNumber VARCHA Contact number of the customer NOT NULL
R
PaymentInfo VARCHA Customer's preferred payment method NOT NULL
R

3. Driver

Field Data Type Description Constraints

DriverID INT Unique identifier for each driver Primary Key

FName VARCHAR FirstName of the driver NOT NULL

LName VARCHAR LastName of the driver NOT NULL

Email VARCHAR Driver's email address UNIQUE, NOT

 NULL
PhoneNumber VARCHAR Contact number of the driver NOT NULL

LicenseNumber VARCHAR Driver's license number UNIQUE, NOT

NULL
VehicleID INT Foreign key to the Vehicle table Foreign Key

4. Vehicle

Field Data Type Description Constraints

VehicleID INT Unique identifier for each vehicle Primary Key
Brand VARCHA Vehicle's make (e.g., Toyota) NOT NULL
R
Model VARCHA Vehicle's model (e.g., Corolla) NOT NULL
R
LicensePlat VARCHA Vehicle's license plate number UNIQUE, NOT
e R NULL
DriverID INT Foreign key to the Driver table Foreign Key

5. Trips

Field Data Type Description Constraints

TripID INT Unique identifier for each trip Primary Key
RideID INT Foreign key to the Rides table Foreign Key
StartTime DATETIM Time when the trip started NOT NULL
E
EndTime DATETIM Time when the trip ended NOT NULL
E
Distance FLOAT Distance covered during the trip NOT NULL
Fare FLOAT Fare charged for the trip NOT NULL
PaymentMethod VARCHAR Method of payment used (e.g., cash, card) NOT NULL
 6. Payment

Field Data Type Description Constraints

PaymentID INT Unique identifier for each payment Primary

Key
TripID INT Foreign key to the Trips table Foreign Key

Amount FLOAT Amount paid for the trip NOT NULL

PaymentDate DATETIM Date and time of the payment NOT NULL

E
PaymentMethod VARCHAR Method of payment used (e.g., cash, card) NOT NULL

7. Rides

Field Data Type Description Constraints

RideID INT Unique identifier for each ride Primary Key

PickupLocation VARCHAR Starting location of the ride NOT NULL

DropoffLocatio VARCHAR Destination of the ride NOT NULL

n
PickupTime DATETIME Time when the ride was requested NOT NULL

DropoffTime DATETIME Time when the ride was completed NOT NULL

CustomerID INT Foreign key to the Customer table Foreign Key

DriverID INT Foreign key to the Driver table Foreign Key

VehicleID INT Foreign key to the Vehicle table Foreign Key

Status VARCHAR Status of the ride (e.g., requested, NOT NULL

completed)
 8. Feedback

Field Data Type Description Constraints

FeedbackID INT Unique identifier for each feedback Primary Key
TripID INT Foreign key to the Trips table Foreign Key
CustomerID INT Foreign key to the Customer table Foreign Key
DriverID INT Foreign key to the Driver table Foreign Key
Rating INT Rating given by the customer (1-5) NOT NULL
Review TEXT Review text provided by the customer NULL

9. Discount
 Field Data Type Description Constraints

DiscountID INT Unique identifier for each discount Primary Key

CustomerID INT The customer benefited from the discount Foreign Key

Description VARCHAR Description of the discount NOT NULL

DiscountAmount FLOAT Amount or percentage discount offered NOT NULL

StartDate DATETIME Start date of the discount period NOT NULL

EndDate DATETIME End date of the discount period NOT NULL

Relationship And Cardinality

Entity Relationships:

1. Customer and Rides:

o Relationship: One-to-Many
o Explanation: A customer can request multiple rides over time, but each ride is
associated with only one customer.

2. Driver and Rides:

o Relationship: One-to-Many
o Explanation: A driver can complete multiple rides, but each ride is completed by
only one driver.

3. Vehicle and Rides:

o Relationship: One-to-Many
o Explanation: A vehicle can be used for multiple rides, but each ride is completed
with only one vehicle.
4. Trips and Rides:
o Relationship: One-to-One (or One-to-Many depending on design)
o Explanation: If a trip is defined as a segment of a ride, then a ride could have
multiple trips. Otherwise, each ride corresponds to one trip.

5. Rides and Payments:

o Relationship: One-to-One (or One-to-Many if customers split payments)
o Explanation: Each ride is associated with one payment, but a payment could
cover multiple rides if designed that way (e.g., batch payments).

6. Customer and Payments:

o Relationship: One-to-Many
o Explanation: A customer can make multiple payments for different rides.

7. Driver and Feedback:

o Relationship: One-to-Many
o Explanation: A driver can receive multiple feedback entries, one for each ride
completed.

8. Customer and Feedback:

o Relationship: One-to-Many
o Explanation: A customer can give feedback for each ride they take.

9. Discounts and Rides:

o Relationship: Many-to-One
o Explanation: A ride may have one associated discount, but a discount can be
applied to many rides.

10. Discounts and Payments:

o Relationship: One-to-One (or One-to-Many)
o Explanation: A discount can be applied to a payment, possibly affecting the total
fare. A payment might have one or more discounts applied.
 11.

E-R Diagram

Cardinality

No Entities Cardinality
1 Customer and Rides: 1:N
2 Driver and Rides 1:N
3 Vehicle and Rides 1:M
4 Trips and Rides 1:1
5 Rides and Payments 1:1
6 Customer and Payments 1:M
7 Driver and Feedback 1:M
8 Customer and Feedback 1:M
9 Discounts and Rides M:1
10 Discounts and Payments 1:1

Normalization Process

To normalize your database and ensure data integrity, we will go through the process of applying
the three normal forms (1NF, 2NF, and 3NF). Here's a detailed step-by-step normalization
process for your entities:

Step 1: First Normal Form (1NF)

Objective: Ensure that each table contains only atomic values, meaning each column must
contain a single value, and each record must be unique.

 Employee: Already in 1NF.

 Customer: Already in 1NF.
  Driver: Already in 1NF.
 Vehicle: Already in 1NF.
 Trips: Already in 1NF.
 Payment: Already in 1NF.
 Rides: Already in 1NF.
 Feedback: Already in 1NF.
 Discount: Already in 1NF.

Step 2: Second Normal Form (2NF)

Objective: Ensure that all non-key attributes are fully functional dependent on the primary key.

Since all entities in your database have a single-column primary key and there are no partial
dependencies (i.e., non-key attributes dependent only on a part of a composite key), they are
already in 2NF.

Step 3: Third Normal Form (3NF)

Objective: Ensure that all attributes are directly dependent on the primary key, and there are no
transitive dependencies (i.e., non-key attributes should not depend on other non-key attributes).

Detailed Normalization Process:

1. Employee Table:
o Already in 3NF. No transitive dependencies.

2. Customer Table:
o Already in 3NF. No transitive dependencies.

3. Driver Table:
o Transitive dependency: VehicleID is dependent on DriverID.
o Solution: Remove VehicleID from the Driver table. The relationship between
Driver and Vehicle should be handled in the Vehicle table.
 4. Vehicle Table:
o Transitive dependency: DriverID is dependent on VehicleID.
o Solution: If drivers are assigned specific vehicles and vice versa, it's a valid
relationship. However, this should be modeled as a one-to-one or one-to-many
relationship in a separate table. For now, you can keep it in Vehicle.

5. Trips Table:
o Already in 3NF. No transitive dependencies.

6. Payment Table:
o PaymentMethod is functionally dependent on PaymentID.
o Solution: If each payment can have only one payment method, the table is in
3NF.

7. Rides Table:
o Already in 3NF. No transitive dependencies.

8. Feedback Table:
o Already in 3NF. No transitive dependencies.

9. Discount Table:
o Already in 3NF. No transitive dependencies.

Creating Additional Relations (If Necessary)

New Relationship Table:

 Driver_Vehicle: Handles the relationship between drivers and vehicles.

This table resolves the transitive dependency between Driver and Vehicle and allows a more
flexible association, such as assigning multiple vehicles to a driver over time.

Final Normalized Schema:

 Employee Table: Remains unchanged.

 Customer Table: Remains unchanged.
 Driver Table: VehicleID removed to eliminate transitive dependency.
 Vehicle Table: DriverID remains to show association.
 Trips Table: Remains unchanged.
 Payment Table: Remains unchanged.
 Rides Table: Remains unchanged.
 Feedback Table: Remains unchanged.
 Discount Table: Remains unchanged.
 Driver_Vehicle Table: Added to handle the relationship between drivers and vehicles.

By following these steps, your database structure is normalized to the third normal form (3NF),
ensuring minimal redundancy and maximum data integrity.

Data Definition Language implementations:

/* 0. Create Database & use it */

1.Create Employee Table

2.Create Customer Table

3.Create a Vehicle Table

4. Create Driver Table

5. Create Rides ID
6. Create Trips Table

7.Create Payment Table

8. Create Feedback Table

9.Create Discount Table

10. Insert into Employee table

11. Insert into Customer table

12. Insert into Vehicle table

13. Insert into Driver table

14. Insert into Rides table

15. Insert into Trips table

16. Insert into Payment table

 17. Insert into Feedback table

18. Insert into Discount table

2. Read Operations (Select)

Retrieve all customers' names and emails

Retrieve all drivers and their vehicles

3. Update Operations

Update customer phone number

Update a driver's vehicle

4. Delete Operations

Delete a ride record

Delete a feedback record

2. Queries to Retrieve Information

Query 1: List of all Rides with Customer and Driver Information
Query 2: Customers who Paid by Cash

Query 3: Total Revenue for Each Driver

Query 4: Average Customer Rating per Driver

Query 5: Upcoming Scheduled Rides

Query 6: Customer and Driver List for Rides from Bole

3. Queries to Generate Reports

Report 1: Vehicle Utilization Report

Report 2: Top 5 Drivers by Total Fare

Query Optimization
Lets analyze our queries:

Query: Customer and Driver List for Rides from Bole

Initially in MySQL its time duration is:

So lets use Heuristic Approach to optimize our query:

Heuristic Query Optimization: Steps and Implementation

In our recent efforts to enhance query performance, we’ve outlined a systematic approach to
heuristic query optimization. This process transforms an initial query tree into a more efficient
execution plan. Below are the steps we followed:

1. Initial Query Tree Construction

We began with a canonical query tree derived from the SQL query. In this structure, operations
such as SELECT, PROJECT, and CARTESIAN PRODUCT are arranged in the order they
appear in the query. This initial tree serves as our starting point for optimization.

2. Moving SELECT Operations Down

To improve efficiency, we pushed SELECT operations closer to the base tables. This strategy
reduces the size of intermediate results and ensures that only relevant data is processed in
subsequent operations.

3. Applying More Restrictive SELECT First

Next, we prioritized the application of more restrictive SELECT conditions. By executing the
most selective filters earlier, we minimized the data being processed, further enhancing
performance.

4. Replacing CARTESIAN PRODUCT with JOIN Operations

We replaced CARTESIAN PRODUCT operations with JOINs, linking tables based on key
columns. This change not only improved efficiency but also leveraged database optimization for
relational data.

5. Moving PROJECT Operations Down

Finally, we pushed PROJECT operations down the query tree. This adjustment limits the number
of columns in intermediate results, reducing the overhead for data processing. The DISTINCT
operation was applied last to ensure that duplicates were removed after all joins and filters were
applied.

Optimized Query Result

After implementing these steps, we rewrote the SQL query as follows:

Its time duration is: