The Vehicle Service Management System can be designed as a relational database in which customers, vehicles, mechanics, services, and spare parts are stored in separate but related tables. The main objective of the design is to avoid data redundancy, maintain data integrity, and represent the relationships between customers, their vehicles, mechanics, service transactions, and spare parts. The database can be implemented using SQL and can later be connected with a C++ program in the DBMS and C++ Lab for inserting, updating, searching, and displaying records. The main entities in the system are Customer, Vehicle, Mechanic, Service, Spare Part, and Service Part. A Customer can own many Vehicles, but every Vehicle belongs to one Customer. A Vehicle can have many Service transactions, while each Service transaction is related to exactly one Vehicle. A Mechanic can handle many Service transactions, but each Service transaction must be assigned to one Mechanic. A Service can use multiple Spare Parts, and the same Spare Part can be used in multiple service transactions. Therefore, a many-to-many relationship exists between Service and Spare Part, which is resolved using an intermediate table called Service_Part. The ER diagram can be represented as follows: ```text ┌──────────────────────┐ │ CUSTOMER │ ├──────────────────────┤ │ Contact_ID PK │ │ Customer_Name │ │ Address │ │ Mobile_Number │ │ Email_Address │ └──────────┬───────────┘ │ 1 │ │ N ┌──────────▼───────────┐ │ VEHICLE │ ├──────────────────────┤ │ Vehicle_ID PK │ │ Contact_ID FK │ │ Registration_Number │ │ Model │ │ Manufacturer │ │ Year_of_Manufacture │ │ Fuel_Type │ └──────────┬───────────┘ │ 1 │ │ N ┌──────────▼───────────┐ │ SERVICE │ ├──────────────────────┤ │ Service_ID PK │ │ Vehicle_ID FK │ │ Mechanic_ID FK │ │ Service_Date │ │ Service_Type │ │ Labour_Charges │ │ Spare_Parts_Cost │ │ Total_Bill_Amount │ └──────────┬───────────┘ │ 1 │ │ N ┌──────────▼───────────┐ │ SERVICE_PART │ ├──────────────────────┤ │ Service_ID PK,FK │ │ Part_ID PK,FK │ │ Quantity │ │ Unit_Price │ └──────────┬───────────┘ │ N │ │ 1 ┌──────────▼───────────┐ │ SPARE_PART │ ├──────────────────────┤ │ Part_ID PK │ │ Part_Name │ │ Unit_Price │ └──────────────────────┘ ┌──────────────────────┐ │ MECHANIC │ ├──────────────────────┤ │ Mechanic_ID PK │ │ Mechanic_Name │ │ Specialization │ │ Experience │ │ Contact_Number │ └──────────┬───────────┘ │ 1 │ │ N └──────────── SERVICE ``` The CUSTOMER table stores information about each customer. Its primary key is Contact_ID, which uniquely identifies every customer. The important attributes are Customer_Name, Address, Mobile_Number, and Email_Address. A possible definition is `CUSTOMER(Contact_ID, Customer_Name, Address, Mobile_Number, Email_Address)`, where Contact_ID is the primary key. The VEHICLE table stores information about vehicles owned by customers. Vehicle_ID is the primary key because every vehicle must have a unique identification number. Contact_ID is a foreign key referencing CUSTOMER(Contact_ID). This foreign key establishes the one-to-many relationship between customers and vehicles. The remaining attributes are Registration_Number, Model, Manufacturer, Year_of_Manufacture, and Fuel_Type. Registration_Number should normally be declared UNIQUE because two vehicles should not have the same registration number. The MECHANIC table contains details of mechanics working in