A robust data warehouse schema for a ride-sharing service should prioritize a dimensional model, likely a star or snowflake schema, to support analytical queries efficiently. Key dimensions would include Dim_Rider, Dim_Driver, Dim_Location (for pickup and dropoff), Dim_Time (for ride start and end), and Dim_Vehicle. The central fact table, Fact_Rides, would capture core metrics such as ride_id, rider_id, driver_id, pickup_location_id, dropoff_location_id, start_time_id, end_time_id, fare_amount, distance, duration, and rating.
For driver onboarding and verification, a separate set of tables or dimensions might be necessary. A Dim_Driver_Status could track the driver's current state (e.g., active, inactive, suspended). A Fact_Driver_Approvals table could log the history of document submissions and their approval status, linking to Dim_Driver and potentially a Dim_Document_Type. This fact table could include attributes like approval_id, driver_id, document_type_id, submission_timestamp, approval_status (e.g., pending, approved, rejected), and rejection_reason (if applicable). This structure allows for analysis of driver onboarding efficiency, approval bottlenecks, and the impact of document issues on driver availability.