sql >> Database teknologi >  >> RDS >> Database

Konstruktion af en datamodel for et parkeringspladsstyringssystem

Forskning viser, at biler forbliver parkeret i 95 % af deres levetid, hvilket tyder på, at parkeringspladsstyringssystemer bør være smarte, effektive og robuste. I denne artikel konstruerer vi en datamodel for et sådant system.

Introduktion

Før vi begynder at konstruere vores datamodel, bør vi først forstå, hvordan parkeringspladser er opbygget, og hvordan de fungerer. Lad os tage et kort kig på disse to nøgleområder.

  1. Hvordan er parkeringspladser opbygget?

    En typisk parkeringsplads består af en eller flere blokke, der er yderligere opdelt i etager. Hver etage indeholder flere vinger, der hjælper chaufførerne med at orientere sig og huske deres parkeringspladser. Disse er normalt mærket med bogstaver, såsom "A", "B", "C" og så videre. En etage har normalt en højdegrænse, der begrænser visse køretøjer i at komme ind på parkeringspladsen. Derudover indeholder en etage flere unikt nummererede parkeringspladser. Nogle af disse slots er forbeholdt handicappede; andre kan reserveres af almindelige besøgende til en vis pris.

  2. Hvordan fungerer parkeringspladser?

    For at forstå, hvordan parkeringspladser fungerer, skal vi vide mere om de typer mennesker, der besøger parkeringspladser. Kunder, der kommer ind på parkeringspladser, tilhører en af ​​følgende grupper:

    • En almindelig kunde, der har købt et 2-uge-, måneds- eller årskort.
    • En forudbetalt kunde, der har reserveret et slot eksternt (på telefonen eller online).
    • En walk-in-kunde, som hverken har et pas eller har reserveret en plads eksternt. En slot vil blive tildelt en sådan kunde baseret på tilgængelighed.

    Faste kunder får normalt kort/mærkater, som de kan placere et synligt sted på deres instrumentbræt eller forrude, så parkeringspladsens ledelse nemt kan fastslå, at kunderne ikke overtræder nogen parkeringsregler. I modsætning til lejlighedsvis besøgende, får faste kunder aldrig udstedt parkeringssedler på daglig basis. En parkeringsplads reserverer typisk en hel blok eller etage til sine regelmæssige besøgende for at sikre, at de altid har steder at parkere. Faste kunder kan også reservere pladser til sig selv, så de kan parkere deres køretøjer i de samme udpegede pladser hver dag, men det koster typisk ekstra.

    De, der reserverer fjernparkering, kan typisk kun bruge deres udpegede pladser i et begrænset tidsrum på et par timer, hvorefter pladserne frigives. Når disse besøgende kommer ind på parkeringspladsen, skal de parkere i deres reserverede pladser. En bøde pålægges kunder, der ikke forlader parkeringspladsen, efter deres tidsvinduer er udløbet, men kunder kan bestemt tage af sted, før deres reservationer udløber. Nogle parkeringspladser har et fast minimumstidsvindue (f.eks. kan kunden blive nødt til at reservere en plads i tre timer, selvom de kun skal være væk i en time).

    Walk-in kunder får parkeringssedler, når de kommer ind på en parkeringsplads. En parkeringsplads tildeles derefter kunden, efterhånden som sedlen genereres, baseret på præferencer, de har angivet. Reservationsprocessen her er stort set den samme som for forudbetalte kunder. Dog afhænger en walk-in reservation helt af tilgængelighed. Et slot kan koste dig mere, end hvis du skulle reservere en plads i forvejen, især hvis der er begrænset tilgængelighed og stor efterspørgsel.

Datamodel




Med disse krav i tankerne, lad os gå videre og skabe vores datamodel. Denne gang arbejder vi med tre hovedafsnit:

  • Parkeringsplads
  • Kunde
  • Parkeringsreservation

Lad os se nærmere på hvert af disse områder af vores datamodel.

Sektion 1:Parkeringsplads

Parkeringsplads-sektionen fanger ikke kun alle vigtige oplysninger om selve parkeringspladsen, men forenkler også måden, hvorpå den mindste enhed på parkeringspladsen (en slot) kan administreres af virksomheden. Nogle tabelkolonner er tilføjet udelukkende med det formål at effektivisere parkeringsreservationer og drift i senere afsnit.

I overensstemmelse med parkeringspladsstrukturen, vi diskuterede i introduktionen, har vi oprettet følgende tabeller for at fange hver eneste detalje, vi har brug for.

parking_lot – gemmer grundlæggende oplysninger om en parkeringsplads. Kolonnerne for denne tabel er:

  • id – den primære nøgle til denne tabel. Den tildeler et unikt nummer til hver parkeringsplads.
  • number_of_blocks – sporer antallet af blokke på en parkeringsplads.
  • is_slot_available – angiver, om parkeringspladsen i øjeblikket har ledige pladser.
  • address – gemmer den komplette adresse på en parkeringsplads.
  • zip – gemmer postnummeret på en parkeringsplads, så kunderne nemmere kan søge efter tilgængelige parkeringspladser inden for et bestemt område ved blot at forespørge på deres ønskede postnummer.
  • is_reentry_allowed – angiver, om en kunde må forlade parkeringspladsen og komme ind igen med samme parkeringsseddel. Bemærk, at mange parkeringspladser typisk ikke tillader kunder at gøre dette. På sådanne parkeringspladser skal du købe en ny seddel hver gang du kommer ind igen på en given dag.
  • operating_company_name – gemmer navnet på den virksomhed, der driver parkeringspladsen.
  • is_valet_parking_available – angiver, om parkeringspladsen tilbyder parkeringsservice.

block – en parkeringsplads er opdelt i en eller flere blokke. Denne tabel gemmer oplysninger om hver blok på en parkeringsplads. Kolonnerne for denne tabel er:– en parkeringsplads er opdelt i en eller flere blokke. Denne tabel gemmer oplysninger om hver blok på en parkeringsplads. Kolonnerne for denne tabel er:

  • id – den primære nøgle til denne tabel.
  • parking_lot_id – den refererede kolonne fra parking_lot tabel, der identificerer den parkeringsplads, som blokken hører til.
  • block_code – gemmer den kode, der er knyttet til denne blok. Blokke får normalt entydigt identificerende koder, såsom "A", "B", "C", "11", "22", "33" og så videre.
  • number_of_floors – gemmer antallet af etager i denne blok. Tallet "1" angiver, at dette er en blok i stueetagen uden etager.
  • is_block_full – angiver, om blokken i øjeblikket er fuld.

floor – på parkeringspladser med flere niveauer kan blokke have mere end én etage. Denne tabel kan dog også refereres til ved jordniveaublokke. Kolonnerne for denne tabel er:

  • id – den primære nøgle til denne tabel.
  • block_id – identificerer den blok, som en etage hører til.
  • floor_number – repræsenterer tallet på en etage (hvor 1 =jordniveau).
  • max_height_in_inch – på en parkeringsplads med flere niveauer har hver etage en højdebegrænsning. Denne kolonne gemmer den maksimalt tilladte højde for køretøjer på et gulv.
  • number_of_wings – en etage er yderligere opdelt i fløje, som hjælper kunderne med at huske, hvor de har parkeret. Denne kolonne gemmer antallet af vinger, der findes på en etage.
  • number_of_slots – gemmer antallet af pladser, der findes på en etage.
  • is_covered – identificerer om et gulv er dækket. Den øverste etage på en parkeringsplads i flere niveauer eller en parkeringsplads i stueplan vil aldrig være dækket.
  • is_accessible – angiver, om gulvet er let tilgængeligt, især for handicappede. Hvis en grund med flere niveauer har en operationel elevator, anses hver af dens etager for at være tilgængelige.
  • is_floor_full – angiver, om en etage er fuldt optaget.
  • is_reserved_reg_cust – angiver, om en etage er strengt forbeholdt faste kunder.

parking_lot – denne tabel gemmer al information om parkeringspladserne på en parkeringsplads. Kolonnerne for denne tabel er:

  • id – primær nøgle til denne tabel.
  • floor_id – identificerer den etage, som en spalte tilhører.
  • slot_number – gemmer den unikke identifikator for åbningen på en bestemt etage.
  • wing_code – identificerer den fløj, hvori en spalte er placeret.

Afsnit 2:Kunder

Vi går videre og begynder nu at detaljere alle relevante oplysninger om kunder. Bemærk, at parkeringspladser ikke beskæftiger sig med at indfange og opbevare personlige oplysninger som navne, adresser osv., da de til enhver tid kan få adgang til deres lokale DMV-portaler for at få sådanne oplysninger, hvis det er nødvendigt.

customer – gemmer alle relevante detaljer om alle slags kunder, der kan besøge parkeringspladsen (almindelig, engangs og forudbetalt). Kolonnerne for denne tabel er:

  • id – unik identifikator for kunden.
  • vehicle_number – gemmer nummerpladenummeret på en kundes køretøj.
  • registration_date – gemmer datoen, hvor køretøjet første gang blev registreret på parkeringspladsen.
  • is_regular_customer – angiver, om en kunde har almindeligt pas. Hvis kolonnen gemmer værdien sand, skal der eksistere en gyldig post i regular_pass bord. Når et pas udløber, og kunden endnu ikke har fornyet det, opdateres værdien i denne kolonne til falsk.
  • contact_number – gemmer en kundes kontaktnummer. Da nogle mennesker er tilbageholdende med at dele deres kontaktnumre med parkeringspladser, har vi holdt denne kolonne ugyldig.

regular_pass – gemmer oplysninger om almindelige pas, der udstedes til kunder. Kolonnerne for denne tabel er:

  • id – primær nøgle til denne tabel.
  • customer_id – en refereret kolonne fra kundetabellen.
  • purchase_date – gemmer den dato, hvor passet blev købt.
  • start_date – gemmer den dato, hvor passet vil blive betragtet som gyldigt, hvilket ikke nødvendigvis er købsdatoen, da nogle kunder køber adgangskort på forhånd.
  • duration_in_days – gemmer antallet af dage, som et pas er gyldigt. Et månedskort er normalt gyldigt i 30 dage.
  • cost – gemmer omkostningerne i lokal valuta, som en kunde skal betale for at købe et pas.

Afsnit 3:Reservationer

Vores sidste afsnit er dedikeret til at detaljere reservationsprocessen for parkeringspladser. Når en kunde foretager en reservation, skal en kunde typisk angive visse detaljer, såsom deres forventede ankomstdato og -tidspunkt, hvor lang tid de ønsker at reservere pladsen til og så videre. Vi diskuterer de to hovedtabeller i dette afsnit nedenfor.

parking_slot_reservation – vedligeholder reservationsdetaljer. Kolonnerne for denne tabel er:

  • id – tildeler et unikt referencenummer til en individuel reservationsanmodning.
  • customer_id – henvisning til identifikatoren for den kunde, der foretager denne reservation.
  • start_timestamp – gemmer den forventede dato og tidspunkt for kundens ankomst.
  • duration_in_minutes – gemmer varigheden af ​​reservationen.
  • booking_date – gemmer datoen, hvor reservationen blev foretaget.
  • parking_lot_id – intern kolonne, der tildeler en parkeringsplads til en kunde, når deres anmodning er fanget, og betalingen er foretaget.

parking_slip – gemmer oplysninger om kundens ind- og udgangstider, samt eventuelle relevante gebyrer. Vi har lavet denne tabel til parkeringspladser, der tillader flere ind- og udgange under samme reservation. Kolonnerne for denne tabel er:

  • id – den primære nøgle til denne tabel.
  • parking_slot_reservation_id – refereret kolonne, der identificerer den tilknyttede reservationsanmodning.
  • actual_entry_time – gemmer kundens ankomstdato og tidsstempel.
  • actual_exit_time – gemmer kundens afgangs- (udgangs-) dato og tidsstempel.
  • basic_cost – gemmer basisomkostningerne for reservationen.
  • penalty – gemmer en værdi på 0 som standard. Hvis en kunde forsinker sin udgang, vil der blive pålagt et bødegebyr, og værdien i denne kolonne vil blive opdateret.
  • total_cost – denne kolonne tilføjer blot værdierne for basic_cost og strafkolonner.
  • is_paid – genadgang er normalt kun tilladt, når en kunde har betalt sin parkeringsafgift. Denne kolonne angiver, om denne betaling er foretaget.

Konklusion

I denne artikel præsenterede vi en oversigt over en datamodel for et parkeringspladsstyringssystem. Der er mange apps, der hjælper brugere med at finde parkeringspladser ved at udtrække, behandle og kompilere data (såsom tilgængelighed og omkostninger) for parkeringspladser i en specificeret nærhed. Dette er især nyttigt for folk, der besøger storbyer som New York, Los Angeles og andre, hvor det kan være et mareridt at finde en parkeringsplads, hvis du ikke planlægger dit besøg omhyggeligt. Sådanne applikationer er afhængige af veldesignede datamodeller og database-API'er til at hente disse oplysninger.

I vores næste artikel vil vi omdanne vores nuværende datamodel til en løsning til et tilgængeligt parkeringssystem i realtid. Du er velkommen til at skrive dine tanker, feedback og anbefalinger i kommentarfeltet nedenfor.


  1. ListView-kontrol med Ms-Access TreeView

  2. Vil du slette en enkelt post fra Entity Framework?

  3. jQuery UI Sorterbar, og skriv derefter rækkefølge i en database

  4. Sådan starter parallelle planer – del 5