Konstruera en datamodell för ett parkeringshanteringssystem

Forskning visar att bilar förblir parkerade under 95 % av sin livstid, vilket tyder på att parkeringshanteringssystem bör vara smarta, effektiva och robusta. I den här artikeln kommer vi att konstruera en datamodell för ett sådant system.

Introduktion

Innan vi börjar konstruera vår datamodell bör vi först förstå hur parkeringsplatser är uppbyggda och hur de fungerar. Låt oss ta en kort titt på dessa två nyckelområden.

1. Hur är parkeringsplatser uppbyggda?

   En typisk parkeringsplats består av ett eller flera kvarter som ytterligare är indelade i våningar. Varje våning innehåller flera vingar som hjälper förare att orientera sig och komma ihåg sina parkeringsplatser. Dessa är vanligtvis märkta med bokstäver, som "A", "B", "C" och så vidare. Ett golv har vanligtvis en höjdgräns som hindrar vissa fordon från att komma in på parkeringen. Dessutom innehåller en våning flera unikt numrerade parkeringsplatser. Vissa av dessa platser är reserverade för handikappade; andra kan reserveras av vanliga besökare till en viss kostnad.

2. Hur fungerar parkeringsplatser?

   För att förstå hur parkeringsplatser fungerar måste vi veta mer om vilka typer av människor som besöker parkeringsplatser. Kunder som går in på parkeringsplatser tillhör någon av följande grupper:

   • En vanlig kund som har köpt ett varannan vecka, månad eller årskort.
   • En förbetald kund som bokat en slot på distans (på telefonen eller online).
   • En ingångskund som varken har ett pass eller bokat en plats på distans. En plats kommer att tilldelas en sådan kund baserat på tillgänglighet.

   Vanliga kunder får vanligtvis kort/klistermärken att placera någonstans synligt på sin instrumentbräda eller vindruta så att parkeringsledningen enkelt kan avgöra att kunderna inte bryter mot några parkeringsregler. Till skillnad från tillfälliga besökare får stamkunder aldrig dagligen p-kuponger. En parkeringsplats reserverar vanligtvis ett helt kvarter eller våning för sina vanliga besökare för att säkerställa att de alltid har platser att parkera. Vanliga kunder kan också reservera platser för sig själva så att de kan parkera sina fordon på samma angivna platser varje dag, men detta kostar vanligtvis extra.

   De som gör fjärrparkeringsreservationer kan vanligtvis bara använda sina utsedda platser under ett begränsat tidsfönster på ett par timmar, varefter platserna frigörs. När dessa besökare går in på parkeringen måste de parkera i sina reserverade platser. En straffavgift debiteras kunder som inte lämnar parkeringen efter att deras tidsfönster har gått ut, men kunder kan säkert lämna innan deras reservationer löper ut. Vissa parkeringsplatser har ett fast minimitidsfönster (t.ex. kan kunden behöva boka en plats i tre timmar även om de bara kommer att vara borta i en timme).

   Walk-in kunder får p-lappar när de går in på en parkeringsplats. En parkeringsplats tilldelas sedan kunden när lappen genereras, baserat på preferenser som de har angett. Bokningsprocessen här är i huvudsak densamma som för förbetalda kunder. En inträdesreservation beror dock helt på tillgänglighet. En slot kan kosta dig mer än om du skulle boka en plats i förväg, särskilt om det finns begränsad tillgänglighet och hög efterfrågan.

Datamodell

Med dessa krav i åtanke, låt oss gå vidare och skapa vår datamodell. Den här gången kommer vi att arbeta med tre huvudsektioner:

• Parkeringsplats
• Kund
• Parkeringsbokning

Låt oss ta en närmare titt på vart och ett av dessa områden i vår datamodell.

Avsnitt 1:Parkeringsplats

Parkeringssektionen samlar inte bara all viktig information om själva parkeringsplatsen utan förenklar också sättet på vilket den minsta enheten på parkeringsplatsen (en plats) kan hanteras av företaget. Vissa tabellkolumner har lagts till i syfte att göra parkeringsreservationer och drift mer effektiv i senare avsnitt.

I enlighet med parkeringsplatsens struktur som vi diskuterade i inledningen har vi skapat följande tabeller för att fånga varje detalj vi behöver.

parking_lot – lagrar grundläggande information om en parkeringsplats. Kolumnerna för denna tabell är:

• id – primärnyckeln för denna tabell. Den tilldelar ett unikt nummer till varje parkeringsplats.
• number_of_blocks – spårar antalet kvarter på en parkeringsplats.
• is_slot_available – anger om parkeringsplatsen för närvarande har några lediga platser.
• address – lagrar hela adressen till en parkeringsplats.
• zip – lagrar postnumret för en parkeringsplats, så att kunderna lättare kan söka efter tillgängliga parkeringsplatser inom ett visst område genom att helt enkelt fråga efter önskat postnummer.
• is_reentry_allowed – anger om en kund får lämna parkeringen och gå in igen med samma parkeringssedel. Observera att många parkeringsplatser vanligtvis inte tillåter kunder att göra detta. På sådana parkeringsplatser måste du köpa en ny lapp varje gång du går in igen en viss dag.
• operating_company_name – lagrar namnet på företaget som driver parkeringen.
• is_valet_parking_available – anger om parkeringsplatsen erbjuder bemannad parkering.

block – en parkeringsplats är uppdelad i ett eller flera kvarter. Den här tabellen lagrar information om varje kvarter på en parkeringsplats. Kolumnerna för denna tabell är:– en parkeringsplats är uppdelad i ett eller flera block. Den här tabellen lagrar information om varje kvarter på en parkeringsplats. Kolumnerna för denna tabell är:

• id – primärnyckeln för denna tabell.
• parking_lot_id – den refererade kolumnen från parking_lot tabell som identifierar parkeringsplatsen som blocket tillhör.
• block_code – lagrar koden som är kopplad till detta block. Block ges vanligtvis unikt identifierande koder, som "A", "B", "C", "11", "22", "33" och så vidare.
• number_of_floors – lagrar antalet våningar i detta block. Siffran "1" indikerar att detta är ett markplansblock utan golv.
• is_block_full – anger om blocket för närvarande är fullt.

floor – på flerplansparkeringar kan block ha mer än en våning. Men denna tabell kan också refereras till marknivåblock. Kolumnerna för denna tabell är:

• id – primärnyckeln för denna tabell.
• block_id – identifierar blocket som en våning tillhör.
• floor_number – representerar numret på en våning (där 1 =marknivå).
• max_height_in_inch – på en parkeringsplats med flera nivåer har varje våning en höjdbegränsning. Denna kolumn lagrar den högsta tillåtna höjden för fordon på ett golv.
• number_of_wings – ett golv är ytterligare uppdelat i vingar, vilket hjälper kunderna att komma ihåg var de parkerade. Den här kolumnen lagrar antalet vingar som finns på ett golv.
• number_of_slots – lagrar antalet platser som finns på en våning.
• is_covered – identifierar om ett golv är täckt. Den översta våningen på en parkeringsplats med flera nivåer eller en parkeringsplats på marknivå kommer aldrig att täckas.
• is_accessible – indikerar om golvet är lättillgängligt, särskilt för handikappade. Om ett flervåningsparti har en hiss i drift, anses var och en av dess våningar vara tillgängliga.
• is_floor_full – indikerar om ett våningsplan är fullt upptaget.
• is_reserved_reg_cust – indikerar om en våning är strikt reserverad för vanliga kunder.

parking_lot – denna tabell lagrar all information om parkeringsplatserna på en parkeringsplats. Kolumnerna för denna tabell är:

• id – primärnyckel för den här tabellen.
• floor_id – identifierar våningen som en plats tillhör.
• slot_number – lagrar den unika identifieraren för luckan på en viss våning.
• wing_code – identifierar den vinge där en slits är placerad.

Avsnitt 2:Kunder

När vi går vidare börjar vi nu detaljera all relevant information om kunder. Observera att parkeringsplatser inte är angelägna om att fånga och lagra personlig information som namn, adresser, etc., eftersom de kan komma åt sina lokala DMV-portaler när som helst för att få sådan information om det behövs.

customer – lagrar all relevant information om alla typer av kunder som kan besöka parkeringsplatsen (vanligt, engångs- och förbetalt). Kolumnerna för denna tabell är:

• id – unik identifierare för kunden.
• vehicle_number – lagrar registreringsskyltnumret för en kunds fordon.
• registration_date – lagrar datumet då fordonet först registrerades på parkeringen.
• is_regular_customer – indikerar om en kund har vanligt pass. Om kolumnen lagrar värdet true måste det finnas en giltig post i regular_pass tabell. När ett pass går ut och kunden ännu inte har förnyat det, uppdateras värdet i den här kolumnen till falskt.
• contact_number – lagrar en kunds kontaktnummer. Eftersom vissa människor är ovilliga att dela sina kontaktnummer med parkeringsplatser har vi hållit denna kolumn nullbar.

regular_pass – lagrar information om vanliga pass som utfärdas till kunder. Kolumnerna för denna tabell är:

• id – primärnyckel för den här tabellen.
• customer_id – en refererad kolumn från kundtabellen.
• purchase_date – lagrar datumet då passet köptes.
• start_date – lagrar det datum då passet kommer att anses giltigt, vilket inte nödvändigtvis är inköpsdatumet, eftersom vissa kunder köper pass i förväg.
• duration_in_days – lagrar antalet dagar som ett pass är giltigt. Ett månadskort är vanligtvis giltigt i 30 dagar.
• cost – lagrar kostnaden, i lokal valuta, som en kund måste betala för att köpa ett pass.

Avsnitt 3:Bokningar

Vår sista sektion är tillägnad detaljerad bokning av parkeringsplatser. När en kund gör en bokning måste en kund vanligtvis ange vissa detaljer, såsom förväntat datum och tid för ankomst, hur lång tid som de vill reservera spelautomaten och så vidare. Vi diskuterar de två huvudtabellerna i detta avsnitt nedan.

parking_slot_reservation – upprätthåller reservationsdetaljer. Kolumnerna för denna tabell är:

• id – tilldelar ett unikt referensnummer till en individuell bokningsförfrågan.
• customer_id – hänvisning till identifieraren för den kund som gör denna reservation.
• start_timestamp – lagrar förväntat datum och tid för kundens ankomst.
• duration_in_minutes – lagrar den tid som reservationen gjordes.
• booking_date – lagrar datumet då bokningen gjordes.
• parking_lot_id – intern kolumn som tilldelar en parkeringsplats till en kund när deras begäran har registrerats och betalningen har gjorts.

parking_slip – lagrar information om kundens in- och utpasseringstider, samt eventuella relevanta avgifter. Vi skapade den här tabellen för parkeringsplatser som tillåter flera in- och utgångar under samma reservation. Kolumnerna för denna tabell är:

• id – primärnyckeln för denna tabell.
• parking_slot_reservation_id – refererad kolumn som identifierar den associerade reservationsbegäran.
• actual_entry_time – lagrar kundens ankomstdatum och tidsstämpel.
• actual_exit_time – lagrar kundens avresedatum och tidsstämpel.
• basic_cost – lagrar grundkostnaden för bokningen.
• penalty – lagrar ett värde på 0 som standard. Om en kund försenar sin utträde kommer en straffavgift att tas ut och värdet i den här kolumnen uppdateras.
• total_cost – den här kolumnen lägger bara till värdena för basic_cost och straffkolumner.
• is_paid – Återinträde är vanligtvis endast tillåtet när en kund har betalat sin parkeringsavgift. Denna kolumn anger om denna betalning har gjorts.

Slutsats

I den här artikeln presenterade vi en översikt över en datamodell för ett parkeringshanteringssystem. Det finns många appar som hjälper användare att hitta parkeringsplatser genom att extrahera, bearbeta och sammanställa data (som tillgänglighet och kostnader) för parkeringsplatser i en specificerad närhet. Detta är särskilt användbart för människor som besöker storstäder som New York, Los Angeles och andra där det kan vara en mardröm att hitta en parkeringsplats om du inte planerar ditt besök noggrant. Sådana applikationer förlitar sig på väldesignade datamodeller och API:er för databaser för att hämta denna information.

I vår nästa artikel kommer vi att omvandla vår nuvarande datamodell till en lösning för ett parkeringstillgänglighetssystem i realtid. Skriv gärna dina tankar, feedback och rekommendationer i kommentarsfältet nedan.