Att hyra ut bilar är lika enkelt som att köra:En datamodell för ett biluthyrningsföretag

Du kanske har hyrt en bil på din senaste semester. Du reserverade din bil online och hämtade den sedan från dess angivna plats efter att ha betalat alla tidigare överenskomna avgifter. När du var klar lämnade du tillbaka den till byrån och betalade kanske några extra avgifter. Har du någonsin tänkt på systemet som får alla dessa saker att hända? I den här artikeln ska vi titta på en datamodell för ett biluthyrningssystem.

Varför bygga en annan biluthyrningsdatamodell?

Jag vill designa en datamodell av ett fullt fungerande system för ett internationellt biluthyrningsföretag. Företaget har fordon att hyra i olika segment (mini, ekonomi, mellanliggande, SUV, last och limousine). Den driver sin verksamhet från olika städer i flera länder. Företaget tillåter sina kunder att hyra en bil från en plats (upphämtningsplats) och lämna den på en annan plats (avlämningsplats).

Låt oss nu hänvisa till en tidigare artikel som förklarar en enkel biluthyrningsföretagsmodell. Denna modell tillgodoser alla grundläggande tjänster som erbjuds av ett biluthyrningsföretag.

Innan vi lägger till nya funktioner skulle jag vilja införliva några mindre ändringar i denna modell, nämligen:

• Lägger till city som en kolumn i location bord och ta bort stadsbordet helt och hållet.

• Lägger till ytterligare en kolumn, zip (som i postnummer, eller postnummer), på location tabell. Detta system kommer att identifiera en hämtnings-/lämningsplats genom dess postnummer. Det finns många länder där postnummer är ett alfanumeriskt nummer, så jag kommer att behålla den här kolumnen som en varchar-kolumn.

  

• Lägger till driving license issue date till customer tabell. Det finns vissa länder där den högsta hastighetsgränsen beror på när körkortet utfärdades till föraren.

  

• Byter namn på category tabell till car_category , som beskriver dess innehåll mer exakt.
• Lagra en kunds flyginformation om upphämtningsplatsen är nära en flygplats. Detta gör det möjligt för systemet att göra lämpliga ändringar i kundens bokningsförfrågan i händelse av förseningar eller inställda flyg. För att göra detta lägger jag till en annan tabell som heter flight_detail och anslut den till reservation tabell.

Lägga till kundfakturainformation

För fakturering behöver vi lagra ett hyresvärde för varje lagervara inklusive bilar och utrustning. Hyreskostnaden tilldelas varje kategori, eftersom bokningsprocessen handlar om kategorier snarare än enskilda bilar.

Låt mig lägga till rental_value i car_category och equipment_category tabeller.

På liknande linjer måste det finnas en viss kostnad förknippad med försäkring. Denna kostnad bestäms av försäkringsbolaget. För närvarande lägger jag till ytterligare en kolumn, kostnad, i insurance bord.

För fakturering skapar jag en separat tabell för att lagra alla fakturadetaljer. På så sätt kan samma detaljer enkelt hämtas när det behövs. Eftersom beräkningen av dessa värden är lite knepig, kommer jag inte att upprepa dem om och om igen för en faktura. Jag lägger till en tabell, nämligen rental_invoice , som främst är kopplat till rental tabell.

rental_invoice Tabellen innehåller följande kolumner:

• id – den här tabellens primärnyckel.
• rental_id – den primära nyckeln för rental tabell. Jag kommer att lägga till en unik begränsning i den här kolumnen:det kan bara finnas en post för varje uthyrning.
• car_rent – Den här kolumnen anger hyreskostnaderna för det hyrda fordonet.

• Denna kostnad kan bestämmas med hjälp av följande SQL:

  select a.rental_value from car_category a, car b, rental c
  where  c.car_id = b.car_id and b.category_id = a.id
  and c.id = ;
  

• equipment_rent_total – Den här kolumnen visar beloppet att ta betalt för eventuell utrustning som hyrs ut till kunden

• Den totala kostnaden kan bestämmas med hjälp av följande SQL:

  select sum(a.rental_value) from equipment_category a, equipment b, car_equipment c, car d, rental e
  where  a.id = b.equipment_category_id and b.id = c.equipment_id
  and c.car_id = d.id and d.id = e.car_id 
  and e.id = ;
  

• insurance_cost_total – Denna kolumn är för kundens totala försäkringskostnad. Detta kan fastställas med hjälp av följande SQL

  select sum(a.cost) from insurance a, rental_insurance b, rental c
  where a.id = b.insurance_id and b.rental_id = c.id 
  and c.id = ;
  

• service_tax och VAT – Som namnen antyder lagrar dessa kolumner värden för tillämplig serviceskatt och moms.

• total_amount_payable – Denna kolumn kommer att innehålla värdet på det totala fakturabeloppet. Detta skulle vara summan av följande kolumner:

  total_amount_payable =car_rent + equipment_rent_total + insurance_cost_total

• waiver_amount och net_amount_payable – Dessa kolumner lagrar värden för avståendebelopp (om några) och nettobeloppet som ska betalas. waiver_amount är hur mycket som kommer att avstå från den totala fakturan. Det används ofta när ett uthyrningsföretag erbjuder rabatt till kunder. Formeln för att bestämma net_amount_payable ser ut så här:

  net_amount_payable =total_amount_payable – waiver_amount

Mobilt annonsutrymme – För ett biluthyrningsföretag är dess lager alltid mobilt eftersom det flyttar från en plats till en annan. Om du har märkt en kryssruta som säger "återvänder du till en annan plats?" när du bokar en bil online, har du sett hur den fungerar. Systemet behandlar din förfrågan lite annorlunda om returplatsen INTE är samma som avhämtningsplatsen. Systemet håller alltid koll på sitt lager när det hyrs ut och returneras.

Till exempel hyr en kund en bil från Chicago, bekräftar att avlämningsplatsen kommer att vara annorlunda och kör till sin destination i Saint Louis. Självklart kommer han att lämna bilen på företagets plats i Saint Louis. I det här fallet, så snart han kör bilen från platsen i Chicago, är denna del av inventeringen inte längre bunden till det kontoret. Bilen kommer att registreras igen, denna gång hos Saint Louis-kontoret, så snart han är klar med den.

För att införliva denna mekanism kommer jag att lägga till en kolumn, nämligen current_location_id , i car tabellen samt equipment tabell. Den här kolumnen innehåller endast giltiga ID:n för platser från location bord.

Så, med exemplet ovan, är den ursprungliga platsen för bilen Chicago; den kommer att uppdateras efter att kunden lämnar tillbaka bilen till destinationskontoret.

Ställa in bränslealternativ

1. Förskott på bränsleservice – kunden betalar för full tank bränsle i förväg och lämnar tillbaka bilen med tom tank.
2. Bränsleserviceavgift – kunden får bilen med full bränsletank, men betalar för det baserat på bränsleförbrukning.
3. Fuel Self Service – kunden tar emot bilen med full tank och lämnar tillbaka bilen med full tank. Detta är det mest accepterade alternativet av de tre.

Här bryr vi oss inte om vilket alternativ kunden väljer. Vad vi vill är att registrera deras val samtidigt som hyresförfrågan behandlas.

För att möta detta behov lägger jag till en tabell, fuel_option , som lagrar alla möjliga alternativ för att tanka bilen. Det måste finnas en-till-en-mappning mellan en hyresförfrågan och fuel_option , eftersom kunden ombeds välja en vid bokningstillfället.

Den slutliga datamodellen för biluthyrning

I många områden går biluthyrningsföretagen över till att använda en nyckelfri, självbetjäningsupplevelse för sina kunder. De vill inte få sina kunder att vänta vid en disk bara för att slutföra pappersarbete och hämta bilnycklar. Kan vår nuvarande datamodell tillgodose sådana krav? Vilka förändringar behövs i vår datamodell för att det ska hända?

Har du några tankar om vår datamodell för biluthyrning? Låt oss starta en diskussion! Dela gärna med dig av dina synpunkter i kommentarsfältet.