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 |l|l| Customers \\ CustomerID & INT (PK, AUTO\_INCREMENT) \\ Name & VARCHAR(100) NOT NULL \\ Email & VARCHAR(100) UNIQUE NOT NULL \\ Phone & VARCHAR(20) \\ Address & VARCHAR(200) \\ |l|l| Vehicles \\ VehicleID & INT (PK, AUTO\_INCREMENT) \\ Type & ENUM('Bike', 'Scooter') NOT NULL \\ Status & ENUM('Available', 'Rented', 'Maintenance') DEFAULT 'Available' \\ BatteryLevel & DECIMAL(3,1) \\ LocationID & INT (FK) \\ |l|l| Rentals \\ RentalID & INT (PK, AUTO\_INCREMENT) \\ CustomerID & INT (FK) NOT NULL \\ VehicleID & INT (FK) NOT NULL \\ StartDate & DATETIME NOT NULL \\ EndDate & DATETIME \\ RentalFee & DECIMAL(8,2) \\ |l|l| Payments \\ PaymentID & INT (PK, AUTO\_INCREMENT) \\ RentalID & INT (FK) NOT NULL \\ Amount & DECIMAL(8,2) NOT NULL \\ PaymentDate & DATETIME NOT NULL \\ Method & VARCHAR(50) \\ 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