Describe the concept of a database in the context of GreenFleet Solutions. Explain any two (2) types of databases. Based on the two (2) types of databases explained in Q.3.2, recommend the most appropriate one for GreenFleet Solutions and provide a reason for your selection. List any two (2) tables that could be added to the GreenFleet Solutions database. For each table listed in Q.3.4.1, identify any three (3) fields that would be associated with each. Provide a sample record for each table. Discuss the relationship between the physical and logical views of a database.

Q3.1 Two types of databases with uses in a business context

Relational Database (e.g., MySQL, PostgreSQL):
Organizes data into structured tables with rows and columns related via keys. Uses SQL for queries. Ensures ACID properties (Atomicity, Consistency, Isolation, Durability).
Business uses: Ideal for Greenfleet Solutions to manage customer rentals, vehicle inventory, and payments with complex joins and transactions to prevent double-booking vehicles.

NoSQL Database (e.g., MongoDB, Cassandra):
Handles unstructured or semi-structured data in collections/documents. Flexible schema, horizontally scalable.
Business uses: Suitable for logging app usage analytics, real-time vehicle GPS data, or user reviews where data volume grows rapidly and structure varies.

Q3.2 Database design hypothesis for Greenfleet Solutions
A relational database is best as data is structured (customers, vehicles, rentals) with relationships and needs transaction integrity for rentals/payments. Conceptual design:

• Entities: Customers, Vehicles, Rentals, Payments, Locations.
• Relationships: One customer to many rentals (1:M), one vehicle to many rentals (1:M), one rental to one payment (1:1).
• Normalization: 3NF to avoid redundancy (e.g., separate locations). Supports app queries like available vehicles near user.

Q3.3 Four tables for Greenfleet Solutions database

1. Customers
2. Vehicles
3. Rentals
4. Payments

Q3.4 Schemas for the four tables

$\begin{array}{|l|l|} \hline Customers \\ \hline CustomerID & INT (PK, AUTO\_INCREMENT) \\ \hline Name & VARCHAR(100) NOT NULL \\ \hline Email & VARCHAR(100) UNIQUE NOT NULL \\ \hline Phone & VARCHAR(20) \\ \hline Address & VARCHAR(200) \\ \hline \end{array}$

$\begin{array}{|l|l|} \hline Vehicles \\ \hline VehicleID & INT (PK, AUTO\_INCREMENT) \\ \hline Type & ENUM('Bike', 'Scooter') NOT NULL \\ \hline Status & ENUM('Available', 'Rented', 'Maintenance') DEFAULT 'Available' \\ \hline BatteryLevel & DECIMAL(3,1) \\ \hline LocationID & INT (FK) \\ \hline \end{array}$

$\begin{array}{|l|l|} \hline Rentals \\ \hline RentalID & INT (PK, AUTO\_INCREMENT) \\ \hline CustomerID & INT (FK) NOT NULL \\ \hline VehicleID & INT (FK) NOT NULL \\ \hline StartDate & DATETIME NOT NULL \\ \hline EndDate & DATETIME \\ \hline RentalFee & DECIMAL(8,2) \\ \hline \end{array}$

$\begin{array}{|l|l|} \hline Payments \\ \hline PaymentID & INT (PK, AUTO\_INCREMENT) \\ \hline RentalID & INT (FK) NOT NULL \\ \hline Amount & DECIMAL(8,2) NOT NULL \\ \hline PaymentDate & DATETIME NOT NULL \\ \hline Method & VARCHAR(50) \\ \hline \end{array}$

Q3.5 Primary keys for each table
Customers: CustomerID
Vehicles: VehicleID
Rentals: RentalID
Payments: PaymentID

Final design summary: Relational schema supports efficient queries for app (e.g., SELECT available vehicles by location). **Relational DB with Customers, Vehicles, Rentals, Payments tables}