Een gegevensmodel construeren voor een parkeerbeheersysteem

Onderzoek toont aan dat auto's 95% van hun leven geparkeerd blijven staan, wat suggereert dat parkeerbeheersystemen slim, efficiënt en robuust moeten zijn. In dit artikel bouwen we een datamodel voor zo'n systeem.

Inleiding

Voordat we beginnen met het construeren van ons datamodel, moeten we eerst begrijpen hoe parkeerplaatsen zijn gestructureerd en hoe ze werken. Laten we een korte blik werpen op deze twee belangrijke gebieden.

Hoe zijn parkeerplaatsen gestructureerd?

Een typische parkeerplaats bestaat uit een of meer blokken die verder zijn onderverdeeld in verdiepingen. Elke verdieping bevat meerdere vleugels die bestuurders helpen zich te oriënteren en hun parkeerplaatsen te onthouden. Deze zijn meestal gelabeld met letters, zoals "A", "B", "C", enzovoort. Een verdieping heeft meestal een hoogtelimiet die bepaalde voertuigen verhindert om de parkeerplaats te betreden. Daarnaast bevat een verdieping meerdere uniek genummerde parkeervakken. Sommige van deze slots zijn gereserveerd voor gehandicapten; andere kunnen tegen een bepaalde prijs worden gereserveerd door vaste bezoekers.
Hoe werken parkeerplaatsen?

Om te begrijpen hoe parkeerplaatsen werken, moeten we meer weten over de soorten mensen die parkeerplaatsen bezoeken. Klanten die parkeerplaatsen betreden, behoren tot een van de volgende groepen:
- Een vaste klant die een tweewekelijkse, maandelijkse of jaarlijkse pas heeft gekocht.
- Een prepaid-klant die op afstand een slot heeft geboekt (telefonisch of online).
- Een inloopklant die geen pas heeft en ook geen slot op afstand heeft geboekt. Er wordt een slot toegewezen aan een dergelijke klant op basis van beschikbaarheid.
Vaste klanten krijgen meestal kaartjes/stickers om ergens zichtbaar op hun dashboard of voorruit te plakken, zodat het parkeerterreinbeheer gemakkelijk kan vaststellen dat de klanten geen parkeerregels overtreden. In tegenstelling tot incidentele bezoekers krijgen vaste klanten nooit dagelijks parkeerbonnen. Een parkeerplaats reserveert meestal een heel blok of een hele verdieping voor zijn vaste bezoekers om ervoor te zorgen dat ze altijd een parkeerplaats hebben. Vaste klanten kunnen ook plaatsen voor zichzelf reserveren, zodat ze hun voertuigen elke dag op dezelfde aangewezen plaatsen kunnen parkeren, maar dit kost meestal extra.

Degenen die parkeerplaatsen op afstand reserveren, mogen hun toegewezen slots meestal slechts gedurende een beperkt tijdvenster van een paar uur gebruiken, waarna de slots vrijkomen. Wanneer deze bezoekers de parkeerplaats betreden, moeten ze parkeren op hun gereserveerde plaatsen. Er wordt een boete aangerekend aan klanten die de parkeerplaats niet verlaten nadat hun tijdvensters zijn verstreken, maar klanten kunnen zeker vertrekken voordat hun reservering verloopt. Sommige parkeerplaatsen hebben een vast minimumtijdvenster (de klant moet bijvoorbeeld mogelijk een slot van drie uur reserveren, zelfs als hij maar één uur weg is).

Inloopklanten krijgen parkeerbonnen als ze een parkeerplaats oprijden. Een parkeerplaats wordt vervolgens toegewezen aan de klant wanneer de slip wordt gegenereerd, op basis van voorkeuren die ze hebben opgegeven. Het reserveringsproces is hier in wezen hetzelfde als dat voor prepaid-klanten. Een inloopreservering is echter geheel afhankelijk van beschikbaarheid. Een slot kan je meer kosten dan wanneer je van tevoren een plek reserveert, vooral als er een beperkte beschikbaarheid en veel vraag is.

Gegevensmodel

Laten we met deze vereisten in gedachten doorgaan en ons datamodel maken. Deze keer werken we met drie hoofdsecties:

Parkeerplaats
Klant
Parkeerplaatsreservering

Laten we elk van deze gebieden van ons datamodel eens nader bekijken.

Sectie 1:Parkeerplaats

De sectie Parking Lot bevat niet alleen alle belangrijke informatie over de parkeerplaats zelf, maar vereenvoudigt ook de manier waarop de kleinste eenheid van de parkeerplaats (een slot) door het bedrijf kan worden beheerd. Sommige tabelkolommen zijn toegevoegd met als enig doel om parkeerreserveringen en -operaties in latere secties efficiënter te maken.

In overeenstemming met de parkeerplaatsstructuur die we in de inleiding hebben besproken, hebben we de volgende tabellen gemaakt om elk detail dat we nodig hebben vast te leggen.

parking_lot – slaat basisinformatie over een parkeerplaats op. De kolommen voor deze tabel zijn:

id – de primaire sleutel voor deze tabel. Het kent een uniek nummer toe aan elke parkeerplaats.
number_of_blocks - houdt het aantal blokken op een parkeerplaats bij.
is_slot_available - geeft aan of de parkeerplaats momenteel beschikbare slots heeft.
address – slaat het volledige adres van een parkeerplaats op.
zip – slaat de postcode van een parkeerplaats op, zodat klanten gemakkelijker naar beschikbare parkeerplaatsen in een bepaald gebied kunnen zoeken door simpelweg hun gewenste postcode op te vragen.
is_reentry_allowed – geeft aan of een klant de parkeerplaats mag verlaten en weer mag binnenkomen met dezelfde parkeerbon. Houd er rekening mee dat veel parkeerplaatsen klanten dit doorgaans niet toestaan. Op dergelijke parkeerplaatsen moet u elke keer dat u op een bepaalde dag opnieuw binnenkomt een nieuw kaartje kopen.
operating_company_name – slaat de naam op van het bedrijf dat de parkeerplaats beheert.
is_valet_parking_available – geeft aan of de parkeerplaats valet parking-diensten aanbiedt.

block – een parkeerplaats is opgedeeld in één of meerdere blokken. Deze tabel bevat informatie over elk blok van een parkeerplaats. De kolommen voor deze tabel zijn:– een parkeerplaats is opgedeeld in een of meer blokken. Deze tabel bevat informatie over elk blok van een parkeerplaats. De kolommen voor deze tabel zijn:

id – de primaire sleutel voor deze tabel.
parking_lot_id – de kolom waarnaar wordt verwezen uit de parking_lot tabel die de parkeerplaats identificeert waartoe het blok behoort.
block_code – slaat de code op die bij dit blok hoort. Blokken krijgen meestal unieke identificatiecodes, zoals "A", "B", "C", "11", "22", "33", enzovoort.
number_of_floors – slaat het aantal verdiepingen in dit blok op. Het cijfer "1" geeft aan dat dit een gelijkvloers blok zonder verdiepingen is.
is_block_full – geeft aan of het blok momenteel vol is.

floor – in parkeergarages met meerdere verdiepingen kunnen blokken meer dan één verdieping hebben. Er kan echter ook naar deze tabel worden verwezen door blokken op grondniveau. De kolommen voor deze tabel zijn:

id – de primaire sleutel voor deze tabel.
block_id – identificeert het blok waartoe een verdieping behoort.
floor_number – staat voor het nummer van een verdieping (waarbij 1 =grondniveau).
max_height_in_inch - op een parkeerplaats met meerdere niveaus heeft elke verdieping een hoogtebeperking. In deze kolom wordt de maximaal toegestane hoogte voor voertuigen op een verdieping opgeslagen.
number_of_wings – een verdieping is verder opgedeeld in vleugels, waardoor klanten onthouden waar ze geparkeerd hebben. In deze kolom wordt het aantal vleugels op een verdieping opgeslagen.
number_of_slots – slaat het aantal slots op dat op een verdieping bestaat.
is_covered – geeft aan of een vloer bedekt is. De bovenste verdieping van een parkeergarage met meerdere niveaus of een parkeerplaats op de begane grond zal nooit worden afgedekt.
is_accessible – geeft aan of de vloer goed toegankelijk is, met name voor gehandicapten. Als een kavel met meerdere verdiepingen een werkende lift heeft, wordt elke verdieping als toegankelijk beschouwd.
is_floor_full – geeft aan of een verdieping volledig bezet is.
is_reserved_reg_cust – geeft aan of een verdieping strikt gereserveerd is voor vaste klanten.

parking_slot – deze tabel bevat alle informatie over de parkeerplaatsen van een parkeerplaats. De kolommen voor deze tabel zijn:

id – primaire sleutel voor deze tabel.
floor_id – identificeert de verdieping waartoe een slot behoort.
slot_number – slaat de unieke identificatie van het slot op een bepaalde verdieping op.
wing_code – identificeert de vleugel waarin zich een gleuf bevindt.

Sectie 2:Klanten

Verderop gaan we nu alle relevante informatie over klanten gedetailleerd weergeven. Houd er rekening mee dat parkeerplaatsen zich niet bezighouden met het vastleggen en opslaan van persoonlijke informatie zoals namen, adressen, enz., aangezien ze op elk moment toegang hebben tot hun lokale DMV-portalen om dergelijke informatie te verkrijgen, indien nodig.

customer – slaat alle relevante gegevens op over allerlei soorten klanten die de parkeerplaats mogen bezoeken (regulier, eenmalig en prepaid). De kolommen voor deze tabel zijn:

id – unieke identificatie voor de klant.
vehicle_number – slaat het kenteken van het voertuig van een klant op.
registration_date – slaat de datum op waarop het voertuig voor het eerst werd geregistreerd op de parkeerplaats.
is_regular_customer – geeft aan of een klant een reguliere pas heeft. Als de kolom de waarde true opslaat, moet er een geldige invoer zijn in de regular_pass tafel. Zodra een pas verloopt en de klant deze nog niet heeft verlengd, wordt de waarde in deze kolom bijgewerkt naar 'false'.
contact_number – slaat het contactnummer van een klant op. Aangezien sommige mensen aarzelen om hun telefoonnummers met parkeerplaatsen te delen, hebben we deze kolom nullable gehouden.

regular_pass - slaat informatie op over reguliere passen die aan klanten worden uitgegeven. De kolommen voor deze tabel zijn:

id – primaire sleutel voor deze tabel.
customer_id – een kolom waarnaar wordt verwezen uit de klantentabel.
purchase_date – slaat de datum op waarop de pas is gekocht.
start_date – slaat de datum op waarop de pas als geldig wordt beschouwd, wat niet noodzakelijk de aankoopdatum hoeft te zijn, aangezien sommige klanten de pas van tevoren kopen.
duration_in_days – slaat het aantal dagen op waarvoor een pas geldig is. Een maandpas blijft meestal 30 dagen geldig.
cost – slaat de kosten op, in lokale valuta, die een klant moet betalen om een pas te kopen.

Sectie 3:Reserveringen

Onze laatste sectie is gewijd aan het detailleren van het reserveringsproces van parkeerplaatsen. Bij het plaatsen van een reservering moet een klant doorgaans bepaalde details verstrekken, zoals de verwachte datum en tijd van aankomst, de hoeveelheid tijd waarvoor ze het slot willen reserveren, enzovoort. We bespreken de twee hoofdtabellen van deze sectie hieronder.

parking_slot_reservation – houdt reserveringsgegevens bij. De kolommen voor deze tabel zijn:

id – kent een uniek referentienummer toe aan een individuele reserveringsaanvraag.
customer_id – verwijzing naar de identificatie van de klant die deze reservering maakt.
start_timestamp – slaat de verwachte datum en tijd van aankomst van de klant op.
duration_in_minutes – slaat de duur op waarvoor de reservering is gemaakt.
booking_date – slaat de datum op waarop de reservering is gemaakt.
parking_slot_id – interne kolom die een parkeerplaats toewijst aan een klant zodra hun verzoek is vastgelegd en de betaling is gedaan.

parking_slip – slaat informatie op over de in- en uitstaptijden van de klant, evenals eventuele relevante vergoedingen. We hebben deze tabel gemaakt voor parkeerplaatsen die meerdere in- en uitgangen onder dezelfde reservering toestaan. De kolommen voor deze tabel zijn:

id – de primaire sleutel voor deze tabel.
parking_slot_reservation_id – kolom waarnaar wordt verwezen die het bijbehorende reserveringsverzoek identificeert.
actual_entry_time – slaat de aankomstdatum en tijdstempel van de klant op.
actual_exit_time – slaat de vertrek- (uitreis)datum en tijdstempel van de klant op.
basic_cost – slaat de basiskosten van de reservering op.
penalty – slaat standaard een waarde van 0 op. Als een klant zijn vertrek uitstelt, wordt een boete in rekening gebracht en wordt de waarde in deze kolom bijgewerkt.
total_cost – deze kolom voegt alleen de waarden toe van de basic_cost en strafkolommen.
is_paid – opnieuw inrijden is meestal alleen toegestaan als een klant zijn parkeergeld heeft betaald. Deze kolom geeft aan of deze betaling is gedaan.

Conclusie

In dit artikel hebben we een overzicht gegeven van een datamodel voor een parkeerbeheersysteem. Er zijn veel apps die gebruikers helpen parkeerplaatsen te vinden door gegevens (zoals beschikbaarheid en kosten) voor parkeerplaatsen in een bepaalde omgeving te extraheren, verwerken en verzamelen. Dit is vooral handig voor mensen die grote steden zoals New York, Los Angeles en andere bezoeken, waar het vinden van een parkeerplaats een nachtmerrie kan zijn als je je bezoek niet zorgvuldig plant. Dergelijke toepassingen zijn afhankelijk van goed ontworpen datamodellen en database-API's om deze informatie op te halen.

In ons volgende artikel zetten we ons huidige datamodel om in een oplossing voor een realtime parkeerbeschikbaarheidssysteem. Voel je vrij om je gedachten, feedback en aanbevelingen te posten in de comments hieronder.