Tikken en parkeren:een datamodel voor een parkeerapp

Verschillende apps beloven je zoektocht naar parkeren pijnloos te maken. Laten we dit type app eens onderzoeken met onze bril voor gegevensmodellering. Hoe ziet het onderliggende model eruit?

In een eerder artikel hebben we uitgelegd hoe een parkeerplaats is gestructureerd en hoe een datamodel kan worden ontworpen om een parkeerplaats te beheren. In dit artikel onderzoeken we het datamodel voor een parkeer-app. Je kent deze apps wel:ze geven een overzicht van parkeermogelijkheden in de buurt, vertellen je de prijzen, en laten je een plaats reserveren of reserveren of een parkeerkaart kopen.

Deze applicatie maakt uw zoektocht naar parkeren relatief pijnloos. Ik zou zeggen dat de prijs de belangrijkste factor bij het kiezen van een parkeerplaats is. Een wandeling van vijf minuten die een paar dollar bespaart, is altijd de moeite waard. Dat gezegd hebbende, laten we onze bril voor datamodellering opzetten en de wereld van parkeerplaats-apps eens van dichtbij bekijken.

Wat moeten we weten over parkeerplaatsen en parkeerapps?

Parkeer-apps zijn vrij eenvoudig:we kunnen functies verwachten voor het in realtime volgen van de beschikbaarheid en prijs van parkeerplaatsen, het boeken van deze parkeerplaatsen en het betalen van de kosten.

Afgezien van de locatie, die relatief eenvoudig is voor een datamodelleur, is de belangrijkste factor voor parkeerplaatsen de prijs. De prijsstrategie voor parkeerplaatsen is vrij eenvoudig en bepaalde methoden of regels zijn praktisch universeel:

Parkeerplaatsen hebben vaak verschillende prijzen voor verschillende tijden. Een dag wordt gewoonlijk in drie delen verdeeld:'s ochtends (6:00 tot 11:00 uur), 's middags (11:00 tot 17:00 uur) en 's avonds (17:00 tot 22:00 uur).
's Avonds en 's ochtends hebben meestal hogere prijzen, omdat er waarschijnlijk meer auto's een plaats nodig hebben tijdens deze uren.
Prijzen kunnen ook verschillen op basis van de dagen van een week. Een parkeerplaats in de buurt van een stadscentrum zal in het weekend (zaterdag en zondag) bijvoorbeeld meer kosten, omdat er dan meer mensen komen.
Meestal gebruiken kavels hun standaardprijzen. Er zijn echter dagen waarop ze meer kunnen rekenen - b.v. parkeerplaatsen in de buurt van honkbalstadions kunnen meer kosten wanneer er een wedstrijd of evenement in het stadion is.
Parkeerplaatsen in de buurt van vervoersknooppunten (luchthavens, treinstations en bushaltes) kunnen 24 uur per dag of een week parkeren. Ze hebben waarschijnlijk een speciaal tarief voor lang parkeren.
Sommige parkeerplaatsen geven maandelijkse passen uit tegen een vast bedrag. Houders van een maandpas betalen elke maand het vaste bedrag in plaats van een dagtarief.

Het gegevensmodel

Zoals u kunt zien, zijn er drie vakgebieden:

“Parkeerplaats”
“Klant”
"Parkeerplaatsreservering"

Laten we eerst het belangrijkste onderwerp nemen - het gebied dat parkeerplaatsen en hun prijsstelling afhandelt.

Parkeerplaats

Dit onderwerp draait om de parking_lot tabel, waarin details over elke parkeerplaats in ons systeem worden opgeslagen. Deze tabel is uitgebreid uitgelegd in ons eerdere artikel over een datamodel voor parkeerbeheer. We zullen hier echter een paar belangrijke kolommen herhalen:

zip – Een postcode; dit speelt een grote rol in de zoekfunctie.
is_slot_available - Bijgewerkt door parkeerexploitanten en geeft aan of er momenteel ruimte beschikbaar is.
is_reentry_allowed – Of een klant na het verlaten van de parkeerplaats weer op de parkeerplaats kan parkeren. Als re-entry niet is toegestaan, moet de terugkerende klant een andere ruimte kopen.
is_valet_parking_available – Valetparkeren kost extra, maar mensen geven er vaak de voorkeur aan – vooral als ze een date hebben.
operational_in_night – Of de parkeerplaats 's nachts open is. Deze informatie wordt erg belangrijk wanneer uw auto geparkeerd staat in de buurt van een luchthaven en uw vlucht om middernacht aankomt!
minimum_hr_pay – Het minimumtarief om uw auto op een kavel te parkeren. Sommige kavels hebben bijvoorbeeld een minimum van drie uur, wat betekent dat u voor drie uur betaalt, zelfs als u maar 30 minuten geparkeerd staat.
is_monthly_pass_allowed –Of veel maandelijkse passen bieden.

We hebben het al gehad over de factoren die een rol spelen bij het vaststellen van parkeerprijzen. Laten we nu eens kijken hoe we met de prijzen in ons model omgaan. We gebruiken de parking_pricing tabel om de normale prijzen en de pricing_exception tabel om eventuele uitzonderingen vast te leggen. Beide tabellen hebben een vergelijkbare structuur en de kolommen spreken voor zich. De enige verschillen zijn:

De parking_pricing tabel heeft een kolom (day_of_week ) die de dag van de week opslaat die relevant is voor een prijs. De pricing_exception tabel heeft een calendar_date kolom met de actuele datum waarop de speciale prijs van toepassing was.
Als de app prijzen toont, geldt de pricing_exception tabel heeft voorrang op de parking_pricing tafel. Dus als het normale tarief voor vandaag $ 5 per uur is, maar er een speciaal tarief van kracht is voor $ 7, geeft de app $ 7 per uur weer.

De finaletafel in dit onderwerpgebied is offers . Het bevat records van kortingsbonnen en de bijbehorende details. Het datamodel achter aanbiedingen, deals en kortingen hebben we in een eerder artikel uitgelegd. Deze tabel is gebaseerd op dezelfde theorie en alle kolommen zouden voor zichzelf moeten spreken.

Klant

Als we aan een parkeerapp denken, denken we meestal aan deze drie elementen:

Klanten – Dit omvat een unieke klant-ID en basisgegevens over app-gebruikers, zoals hun naam en telefoonnummer. Het zou ook goed zijn om hun factuuradres te hebben.
Voertuigen - Eén persoon kan meerdere auto's hebben, dus we moeten de mogelijkheid hebben voor een een-op-veel-relatie tussen een app-gebruiker en zijn voertuigen. Het is duidelijk dat we een manier nodig hebben om voertuigen te identificeren, bijvoorbeeld op basis van hun kenteken.
Betaalmethoden - Aangezien deze applicatie klanten in staat stelt een parkeerplaats te reserveren en ervoor te betalen, hebben we een manier nodig om betalingsmethoden op te slaan. Nogmaals, er zou een manier moeten zijn om meerdere betaalmethoden per gebruiker te hebben.

Dit model heeft één tabel voor elk van deze entiteiten. De customer_id kenmerk waarnaar wordt verwezen in het vehicle en payment_method tafels; het koppelt gebruikers aan voertuigen en betaalmethoden.

Parkeerplaatsreservering

Dit onderwerpgebied bevat slechts twee tabellen. Van de twee slaat de tabel "parking_one_time_reservation" reserveringsdetails op. Sommige van zijn kolommen spreken voor zich; de andere zijn:

start_timestamp – De datum en tijd waarop de reserveringsperiode begint.
pay_for_min_hr – Heeft een 'N' als de reservering voor een bepaald aantal uren is (bijvoorbeeld van 9.00 uur tot 12.00 uur). Anders heeft dit kenmerk een 'Y'.
booking_for_hr – Het aantal uren van een reservering. Dit is een veld met nulwaarden; het heeft alleen een waarde als pay_for_min_hr is ingesteld op 'N'. In het bovenstaande voorbeeld zou het worden ingesteld op "3" voor de drie uur die verstrijken tussen 9.00 uur en 12.00 uur.
basic_parking_cost – De basis parkeerkosten, in lokale valuta.
offer_code – Een couponcode, indien van toepassing. Aangezien het toepassen van een aanbiedingscode optioneel is en afhankelijk is van beschikbaarheid, is deze kolom nullable.
net_cost – Het werkelijke bedrag dat klanten betalen bij het afrekenen (wanneer ze de kavel verlaten).
is_paid – Of er parkeergeld is betaald. Dit wordt een belangrijke kolom wanneer inrijden op dezelfde parkeerstrook is toegestaan. In dergelijke gevallen worden betalingen meestal afgerekend bij de eerste kassa (d.w.z. de eerste keer dat de auto de parkeerplaats verlaat).

De parking_monthly_pass tabel registreert informatie over alle maandelijkse passen die via deze applicatie aan klanten zijn uitgegeven. Maandkaarten kunnen op elk moment worden gekocht, zelfs voor toekomstige data. We hebben dus twee aparte kolommen, purchase_date en start_date , waarmee app-gebruikers passen kunnen kopen die in de toekomst geldig zijn. De andere kolommen spreken voor zich.

Wat kunnen we nog meer toevoegen aan het datamodel van de parkeerapp?

Moderne parkeerplaatsen zijn uitgerust met allerlei technologieën, zoals kentekenlezers, sensoren, geautomatiseerde parkeertoegangscontrolesystemen en slimme parkeermeters. Deze geavanceerde systemen maken parkeerplaatsen gemakkelijker te besturen en gemakkelijker te gebruiken voor automobilisten.

Welke aanvullende wijzigingen heeft dit datamodel nodig om volledig uitgeruste parkeerplaatsen te ondersteunen? Vertel ons uw mening in het opmerkingengedeelte.