Designing a Dimensional Model for Sales Analysis and SQL Queries for a car repair shop Using an Invoice.

The image above is the Entity Relationship Diagram as inspired by the invoice sample here. You can access a better view of the image in the Google Drive here.

DESCRIPTION OF EACH TABLE AND COLUMN

Definition of Primary Keys for Each Table

Primary keys are very useful in relational database creation as they uniquely identify each record in a table. The primary keys for each table were defined as follows:

• Dim_Customer: customer_id (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Vehicle: vehicle_id (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Service: service_id (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Part: part_id (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Location: location_id (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Time; time_id (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Subtotals (INT, IDENTITY(1,1), PRIMARY KEY)

• Dim_Date (INT, IDENTITY(1,1), PRIMARY KEY)

• Fact_Invoice: invoice_id (INT, IDENTITY(1,1), PRIMARY KEY)

2. Establish Foreign Key Relationships Between the Fact Table and Dimension Tables

Foreign key relationships ensure that the data in one table corresponds correctly to data in another table. In the given setup:

• customer_id in Fact_Invoice references customer_id in Dim_Customer

• vehicle_id in Fact_Invoice references vehicle_id in Dim_Vehicle

• service_id in Fact_Invoice references service_id in Dim_Service

• part_id in Fact_Invoice references part_id in Dim_Part

• location_id in Fact_Invoice references location_id in Dim_Location

• subtotal_id in Fact_Invoice references subtotal_id in Dim_Subtotal

• date_id in Fact_Invoice references date_id in Dim_Date

• time_id inFact_Invoice references time_id in Dim_Time

These relationships are established in the Fact_Invoice table creation script using the FOREIGN KEY constraints.

3. Ensure All Necessary Relationships Between Tables are Defined

In addition to the relationships defined in the fact table, customer_id in Dim_Vehicle references customer_id in Dim_Customer

This relationship is defined in the Dim_Vehicle table creation script.

4. Ensure Referential Integrity Between Tables

Referential integrity is ensured by defining foreign key constraints between tables. These constraints are already defined in the table creation scripts, making sure that:

• Each customer_id in Dim_Vehicle must exist in Dim_Customer

• Each customer_id, vehicle_id, service_id, part_id, location_id, subtotal_id, date_id, and time_id in Fact_Invoice must exist in their respective dimension tables (Dim_Customer, Dim_Vehicle, Dim_Service, Dim_Part, Dim_Location, Dim_Date, Dim_Subtotal, Dim_Time)

5. Descriptions of Each Table and Column

Dim_Customer

• customer_id: Unique identifier for each customer.

• name: Name of the customer.

• address: Address of the customer.

• phone: Phone number of the customer.

Dim_Vehicle

• vehicle_id: Unique identifier for each vehicle.

• make: Manufacturer of the vehicle.

• model: Model of the vehicle.

• color: Color of the vehicle.

• year: Year the vehicle was manufactured.

• vin: Vehicle Identification Number.

• reg_number: Registration number of the vehicle.

• mileage: Mileage of the vehicle.

• customer_id: Reference to the customer who owns the vehicle (foreign key from Dim_Customer).

Dim_Service

• service_id: Unique identifier for each service.

• service_description: Description of the service provided.

• hours: Number of hours the service took.

• rate: Rate per hour for the service.

• amount: Total amount charged for the service.

• vehicle_id: Reference to the vehicle that received the service (foreign key from Dim_Vehicle).

Dim_Part

• part_id: Unique identifier for each part.

• part_number: Manufacturer's part number.

• part_name: Name of the part.

• qty: Quantity of the part used.

• unit_price: Price per unit of the part.

• amount: Total amount charged for the part.

Dim_Location

• location_id: Unique identifier for each location.

• shop_name: Name of the shop or service location.

• address: Address of the shop or service location.

Dim_Date

• date_issued: Date the invoice was issued.

• due_date: Date the payment is due.

• day: only the day

• month: only the month

• year: the year only

• quarter: the quarter of the

• day_of_week: the day of the week

• is_holiday: whether it is a holiday or not

• holiday_name: the name of the holiday

• season: the season of sales e.g. winter

Dim_Subtotal

• customer_id: Unique identifier for each customer.

• part_subtotal: Subtotal from the part section

• Service_subtotal: Subtotal from the service section

Dim_Time

[if !supportLists]· [endif]time: time of each sale

[if !supportLists]· [endif]hour: hour of each sale

[if !supportLists]· [endif]minute: minute of the sale

[if !supportLists]· [endif]time_of_day: the time of day the sale occurred

Fact_Invoice

• invoice_id: Unique identifier for each invoice.

• customer_id: Reference to the customer (foreign key from Dim_Customer).

• vehicle_id: Reference to the vehicle (foreign key from Dim_Vehicle).

• service_id: Reference to the service (foreign key from Dim_Service).

• part_id: Reference to the part (foreign key from Dim_Part).

• location_id: Reference to the location (foreign key from Dim_Location).

• Subtotal_id: Reference to the subtotal (foreign key from Dim_Subtotal).

• date_id: Reference to the date (foreign key from Dim_Date).

• time_id: Reference to the time (foreign key from Dim_Time).

• total_service_charge: Total charge for services on the invoice.

• total_part_charge: Total charge for parts on the invoice.

• sub_total: Subtotal of charges before tax. This column is the addition of the total_service_charge and the total_part_charge.

• tax_rate: Tax rate applied to the invoice.

• payable_tax: Total tax payable.

• total_revenue: Total revenue from the invoice including tax.

LOGICAL EXPLANATIONS OF DECISIONS IN CREATING THE TABLES FROM THE SALES RECEIPT.

• Dimensional Modeling: The tables were created using a star schema approach, which is a common modeling technique in data warehousing. This approach simplifies querying and reporting by organizing data into fact and dimension tables.

• Primary and Foreign Keys: Defining primary keys for each table ensures that each record can be uniquely identified. Foreign keys are used to create relationships between tables, enforcing referential integrity and enabling join operations for comprehensive data analysis.

• Fact Table (Fact_Invoice): The fact table captures the transactions (invoices) and includes foreign keys to each of the relevant dimension tables. This centralizes the data and allows for efficient querying of invoices by joining with the dimension tables.

Dimension Tables:

• Dim_Customer: Stores customer information which is often reused across multiple transactions.

• Dim_Vehicle: Details about vehicles serviced, linked to customers to associate a vehicle with its owner.

• Dim_Service: Contains details about the services provided. This table captures specific services performed on vehicles.

• Dim_Part: Lists parts used in servicing vehicles, which can be billed separately.

• Dim_Location: Stores information about the locations where services are provided.

• Dim_Date: Stores information about date.

• Dim_Subtotal: Stores subtotals from the parts and service section

• Dim_Time: Stores information about time

This separation allows for detailed analysis and reporting on each dimension.

• Referential Integrity: Ensuring referential integrity between tables prevents orphan records and maintains data consistency. It ensures that each foreign key in the fact table references a valid primary key in the corresponding dimension table.

In conclusion, following these guides ensure that a well-structured database schema is created, one that supports efficient data analysis and reporting based on the sales receipt data.