The PetrolPump Management System database is built on 11 MySQL tables that together model every entity and relationship in a petrol pump operation. Seven of these are primary entity tables —Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Adarsh275/PetrolPump-Management-System/llms.txt
Use this file to discover all available pages before exploring further.
PetrolPump, Owners, Employee, Customer, Invoice, Tanker, and Sales — each representing a real-world object with its own primary key. The remaining four are relational join tables — Owns, Contacts, Serves, and Sales_Manage — which encode the many-to-many and multi-valued relationships between the primary entities. All tables use the InnoDB storage engine with the utf8mb4 character set, giving full Unicode support including emoji.
Primary Entity Tables
PetrolPump
PetrolPump
Stores registration and location information for each petrol pump outlet. Sample data:
Registration_No is the primary key and is referenced as a foreign key across Tanker, Employee, Sales, and Owns.Primary key. Unique registration identifier for the pump (e.g.
HPC805103).Trading name of the petrol pump outlet. Cannot be NULL.
Parent petroleum company (e.g.
Hindustan Petroleum Corporation). Nullable.Year the outlet opened for business. Nullable.
Indian state where the pump is located. Nullable.
City of operation. Cannot be NULL.
Owners
Owners
Represents individual or partnership owners of one or more petrol pumps. Sample data:
Owner_Name is the primary key, and the Partnership field records that owner’s percentage stake. An owner can be linked to multiple pumps via the Owns join table.Primary key. Full name of the owner.
10-digit contact phone number. Cannot be NULL.
Date of birth of the owner. Nullable.
Single-character gender indicator (
M or F). Nullable.Residential address of the owner. Nullable.
Ownership percentage stake held by this owner. Cannot be NULL.
Employee
Employee
Holds all staff members across every pump outlet. Employees belong to a pump via Sample data:
Petrolpump_No and may report to a manager via the self-referential Manager_ID column. The Contacts join table extends this entity with multiple phone numbers.Primary key. Unique identifier for the employee (e.g.
MANG957).Full name of the employee. Cannot be NULL.
Single-character gender indicator (
M or F). Nullable.Job role (e.g.
MANAGER, NOZZEL PERSON, COOKING). Nullable.Date of birth. Nullable.
Monthly salary in Indian Rupees. Nullable. Subject to the
salary_check trigger (minimum ₹3,00,000).Residential address of the employee. Cannot be NULL.
Email address used as a secondary lookup key in queries. Cannot be NULL.
Foreign key →
PetrolPump.Registration_No. The pump this employee works at. Nullable.Self-referential foreign key →
Employee.Employee_ID. The direct manager of this employee. Nullable (top-level managers may reference themselves).Customer
Customer
Represents customers who purchase fuel at the pump. Customer records link to Sample data:
Invoice (for their purchase history) and Serves (for which employees attended them).Primary key. Unique identifier for the customer (e.g.
SFG252).Full name of the customer. Cannot be NULL.
10-digit contact number. Nullable.
Email address. Nullable.
Single-character gender indicator (
M or F). Nullable.City of residence. Nullable.
Age in years. Nullable.
Invoice
Invoice
Records each fuel sale transaction. Every invoice is tied to a date (which must exist in the Sample data:
Sales table) and optionally to a customer. Payment type, fuel details, discount, and total price are all captured here.Primary key. Unique invoice identifier (e.g.
XC34).Date of the transaction. Cannot be NULL. Foreign key →
Sales.Date.Mode of payment (e.g.
Cash, UPI, Credit Card, Debit Card). Cannot be NULL.Quantity of fuel dispensed in litres. Nullable.
Type of fuel purchased (e.g.
PetrolE10, Diesel, Gasoline91). Nullable.Discount applied to the transaction (percentage or flat amount). Nullable.
Final billed amount in Indian Rupees after any discount. Cannot be NULL.
Foreign key →
Customer.Customer_Code. Nullable (walk-in customers may not be registered).Tanker
Tanker
Represents fuel tankers that supply each pump. Each tanker carries a single fuel type, and its total bill can be computed using the Sample data:
TOTAL_AMOUNT stored function (Fuel_Price × Fuel_Amount).Primary key. Unique identifier for the tanker (e.g.
BR6872).Maximum storage capacity of the tanker in litres. Nullable.
Operating pressure of the tanker. Nullable.
Internal identifier for the fuel batch. Cannot be NULL.
Current quantity of fuel held in the tanker in litres. Nullable.
Human-readable fuel name (e.g.
PetrolE10, Diesel, CNG, Kerosene). Nullable.Price per litre in Indian Rupees. Cannot be NULL. Used by
TOTAL_AMOUNT function.Foreign key →
PetrolPump.Registration_No. The pump this tanker supplies. Nullable.Sales
Sales
Records daily nozzle-level sales readings at each pump. The composite primary key Sample data:
(Sales_No, Date) allows the same sales record identifier to appear on multiple dates. Sales_Manage links each sales record back to the employee who managed it.Part of the composite primary key. Unique sales record identifier (e.g.
FGHGE32).Part of the composite primary key. Date of the sales shift. Cannot be NULL. Referenced as FK by
Invoice.Date and Sales_Manage.Date.Nozzle number at the pump that was active for this record. Cannot be NULL.
Meter reading at the start of the shift in litres. Cannot be NULL.
Meter reading at the end of the shift in litres. Cannot be NULL.
Total volume of fuel sold during the shift (litres). Cannot be NULL.
Total revenue for the shift in Indian Rupees. Cannot be NULL.
Foreign key →
PetrolPump.Registration_No. The pump at which sales occurred. Nullable.Relational Join Tables
These four tables model multi-valued attributes and many-to-many relationships. They carry no standalone meaning outside of the entities they connect, and their primary keys are always composite.Owns
Owns
Implements the many-to-many relationship between petrol pumps and their owners. A single pump can have multiple partners, and a single owner can hold stakes in multiple pumps. Both columns together form the composite primary key.Sample data:
Part of composite primary key. Foreign key →
PetrolPump.Registration_No.Part of composite primary key. Foreign key →
Owners.Owner_Name.Contacts
Contacts
Models the multi-valued attribute of employee phone numbers. Because an employee can have more than one contact number, this is stored as a separate table rather than as a column on Sample data:
Employee.Part of composite primary key. Foreign key →
Employee.Employee_ID.Part of composite primary key. A 10-digit phone number belonging to the employee.
Serves
Serves
Captures the many-to-many relationship between employees and customers — specifically, which employees have served which customers at the pump.Sample data:
Part of composite primary key. Foreign key →
Employee.Employee_ID.Part of composite primary key. Foreign key →
Customer.Customer_Code.Sales_Manage
Sales_Manage
Links employees to the specific sales shift records they managed. The three-column composite primary key Sample data:
(Employee_ID, Sales_No, Date) reflects the composite primary key of the Sales table.Part of composite primary key. Foreign key →
Employee.Employee_ID.Part of composite primary key. Foreign key →
Sales.Sales_No.Part of composite primary key. Foreign key →
Sales.Date.