Database
 sql >> Baza danych >  >> RDS >> Database

Tap and Park:model danych aplikacji parkingowej

Różne aplikacje obiecują, że wyszukiwanie miejsca parkingowego będzie bezbolesne. Przyjrzyjmy się tego typu aplikacji za pomocą naszych okularów do modelowania danych. Jak wygląda podstawowy model?

We wcześniejszym artykule wyjaśniliśmy, jak skonstruowany jest parking i jak można zaprojektować model danych do zarządzania nim. W tym artykule przyjrzymy się modelowi danych aplikacji parkingowej. Znasz te aplikacje:wyświetlają one listę dostępnych miejsc parkingowych w pobliżu, podają ceny i pozwalają zarezerwować miejsce lub kupić bilet parkingowy.

Ta aplikacja sprawia, że ​​wyszukiwanie parkingu jest stosunkowo bezbolesne. Powiedziałbym, że najważniejszym czynnikiem przy wyborze miejsca parkingowego jest cena. Pięciominutowy spacer, który pozwala zaoszczędzić kilka dolców, zawsze jest tego wart. Biorąc to pod uwagę, załóżmy nasze okulary do modelowania danych i przyjrzyjmy się bliżej światu aplikacji parkingowych.

Co powinniśmy wiedzieć o parkingach i aplikacjach parkingowych?

Aplikacje parkingowe są dość proste:możemy oczekiwać funkcji śledzenia dostępności i cen miejsc parkingowych w czasie rzeczywistym, rezerwacji tych miejsc i uiszczania opłat.

Oprócz lokalizacji, która jest stosunkowo łatwa w obsłudze dla projektanta danych, kluczowym czynnikiem wpływającym na parking jest cena. Strategia cenowa miejsc parkingowych jest dość prosta, a niektóre metody lub zasady są praktycznie uniwersalne:

  • Parkingi często mają różne ceny w różnych godzinach. Dzień dzieli się zwykle na trzy części – poranek (od 6:00 do 11:00), południe (od 11:00 do 17:00) i wieczór (od 17:00 do 22:00).
  • Wieczory i poranki mają zwykle wyższe ceny, ponieważ więcej samochodów prawdopodobnie będzie potrzebować miejsca w tych godzinach.
  • Ceny mogą się również różnić w zależności od dni tygodnia. Na przykład opłata za parking w pobliżu centrum miasta będzie wyższa w weekendy (sobota i niedziela), ponieważ wtedy odwiedza więcej osób.
  • W większości przypadków partie korzystają ze swoich standardowych cen. Zdarzają się jednak dni, kiedy mogą pobierać więcej – np. parkingi w pobliżu stadionów baseballowych mogą pobierać wyższe opłaty, gdy na stadionie odbywa się mecz lub wydarzenie.
  • Parkingi w pobliżu węzłów komunikacyjnych (lotnisk, dworców kolejowych i przystanków autobusowych) mogą umożliwiać parkowanie przez 24 godziny na dobę lub tydzień. Prawdopodobnie będą mieli specjalną stawkę za parkowanie długoterminowe.
  • Niektóre parkingi wydają miesięczne przepustki po stałej cenie. Posiadacze karnetów miesięcznych płacą stałą kwotę każdego miesiąca zamiast płacić dzienną opłatę.

Model danych




Jak widać, istnieją trzy obszary tematyczne:

  1. „Parking”
  2. „Klient”
  3. „Rezerwacja parkingu”

Weźmy na początek najważniejszy obszar tematyczny – ten, który zajmuje się parkingami i ich cenami.

Parking

Ten obszar tematyczny kręci się wokół parking_lot tabela, w której przechowywane są szczegóły dotyczące każdego parkingu w naszym systemie. Ta tabela została dokładnie wyjaśniona w naszym wcześniejszym artykule na temat modelu danych zarządzania parkingami. Jednak powtórzymy tutaj kilka ważnych kolumn:

  • zip – kod pocztowy; odgrywa to główną rolę w funkcji wyszukiwania.
  • is_slot_available – Zaktualizowany przez operatorów parkingów i wskazuje, czy miejsce jest obecnie dostępne.
  • is_reentry_allowed – Czy klient może ponownie zaparkować na parkingu po jego opuszczeniu. Jeśli ponowne wejście nie jest dozwolone, powracający klient będzie musiał kupić kolejne miejsce.
  • is_valet_parking_available – Parking z obsługą kosztuje dodatkowo, ale ludzie często to wolą – zwłaszcza gdy są na randce.
  • operational_in_night – Czy parking jest otwarty w nocy. Ta informacja staje się bardzo ważna, gdy Twój samochód jest zaparkowany w pobliżu lotniska, a Twój lot przylatuje o północy!
  • minimum_hr_pay – Minimalna opłata za zaparkowanie samochodu na parkingu. Na przykład niektóre parcele mają minimum trzygodzinne, co oznacza, że ​​płacisz za trzy godziny, nawet jeśli parkujesz tylko przez 30 minut.
  • is_monthly_pass_allowed –Czy dużo oferuje karnety miesięczne.

Omówiliśmy już czynniki, które wpływają na ustalanie cen parkingowych. Zobaczmy teraz, jak poradzimy sobie z cenami w naszym modelu. Użyjemy parking_pricing tabelę do rejestrowania regularnych cen i pricing_exception tabeli, aby zapisać wszelkie wyjątki. Obie tabele mają podobną strukturę, a kolumny nie wymagają wyjaśnień. Jedyne różnice to:

  1. parking_pricing tabela ma kolumnę (day_of_week ), który przechowuje dzień tygodnia związany z ceną. pricing_exception tabela ma calendar_date kolumna, która zawiera rzeczywistą datę obowiązywania ceny specjalnej.
  2. Gdy aplikacja wyświetla ceny, pricing_exception tabela ma pierwszeństwo przed parking_pricing stół. Jeśli więc regularna stawka na dzień dzisiejszy wynosi 5 USD za godzinę, ale obowiązuje specjalna stawka za 7 USD, aplikacja pokaże 7 USD za godzinę.

Ostatni stół w tym obszarze tematycznym to offers . Zawiera zapisy kuponów rabatowych i związanych z nimi szczegółów. We wcześniejszym artykule wyjaśniliśmy model danych stojący za ofertami, okazjami i rabatami. Ta tabela opiera się na tej samej teorii, a wszystkie kolumny powinny być oczywiste.

Klient

Kiedy myślimy o aplikacji parkingowej, zwykle myślimy o tych trzech elementach:

  • Klienci – Obejmuje to unikalny identyfikator klienta i podstawowe informacje o użytkownikach aplikacji, takie jak ich imię i nazwisko oraz numer telefonu. Dobrze byłoby też mieć ich adres rozliczeniowy.
  • Pojazdy – Jedna osoba może mieć wiele samochodów, więc powinniśmy mieć możliwość relacji jeden-do-wielu między użytkownikiem aplikacji a jego pojazdami. Oczywiście potrzebowalibyśmy sposobu na identyfikację pojazdów, na przykład na podstawie ich numeru rejestracyjnego.
  • Metody płatności – Ponieważ ta aplikacja pozwala klientom zarezerwować miejsce parkingowe i za nie zapłacić, potrzebujemy sposobu na przechowywanie metod płatności. Po raz kolejny powinien istnieć sposób na posiadanie wielu metod płatności na użytkownika.

Ten model ma jedną tabelę dla każdego z tych podmiotów. customer_id atrybut jest przywoływany w vehicle i payment_method stoły; łączy użytkowników z pojazdami i metodami płatności.

Rezerwacja miejsca parkingowego

Ten obszar tematyczny zawiera tylko dwie tabele. Z tych dwóch, tabela „parking_one_time_reservation” przechowuje szczegóły rezerwacji. Niektóre z jego kolumn są oczywiste; pozostałe to:

  • start_timestamp – Data i godzina rozpoczęcia okresu rezerwacji.
  • pay_for_min_hr – Zatrzymuje „N”, jeśli rezerwacja dotyczy określonej liczby godzin (np. od 9 rano do południa). W przeciwnym razie ten atrybut będzie miał „Y”.
  • booking_for_hr – Liczba godzin rezerwacji. To jest pole dopuszczające wartość null; będzie miał wartość tylko wtedy, gdy pay_for_min_hr jest ustawiony na „N”. W powyższym przykładzie byłoby ustawione na „3” dla trzech godzin, które upływają między 9 rano a południem.
  • basic_parking_cost – Podstawowy koszt parkowania w lokalnej walucie.
  • offer_code – Kod kuponu, jeśli taki istnieje. Ponieważ zastosowanie kodu oferty jest opcjonalne i zależy od dostępności, ta kolumna może mieć wartość null.
  • net_cost – Rzeczywista kwota, jaką klienci płacą przy kasie (kiedy opuszczają partię).
  • is_paid – Czy opłaty parkingowe zostały uiszczone. Staje się to ważną kolumną, gdy ponowny wjazd jest dozwolony na tym samym odcinku parkingowym. W takich przypadkach płatności są zwykle rozliczane przy pierwszej kasie (tj. przy pierwszym opuszczeniu parkingu przez samochód).

parking_monthly_pass tabela rejestruje informacje o wszystkich miesięcznych przepustkach wydanych klientom za pośrednictwem tej aplikacji. Karnety miesięczne można kupić w dowolnym momencie, nawet na przyszłe terminy. Mamy więc dwie oddzielne kolumny, purchase_date i start_date , które umożliwiają użytkownikom aplikacji kupowanie karnetów ważnych w przyszłości. Pozostałe kolumny nie wymagają wyjaśnień.

Co jeszcze możemy dodać do modelu danych aplikacji parkingowej?

Nowoczesne parkingi wyposażone są we wszelkiego rodzaju technologie, takie jak czytniki tablic rejestracyjnych, czujniki, automatyczne systemy kontroli dostępu do parkingów czy inteligentne parkometry. Te zaawansowane systemy ułatwiają prowadzenie parkingów i ułatwiają korzystanie z nich kierowcom.

Jakich dodatkowych zmian potrzebuje ten model danych, aby obsługiwać w pełni wyposażone parkingi? Przekaż nam swoje przemyślenia w sekcji komentarzy.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Monitorowanie kopii zapasowych w różnych instancjach

  2. Co może powiedzieć plan zapytań?

  3. Uważaj na wprowadzające w błąd dane z SET STATISTICS IO

  4. Rozwiązania wyzwań generatora serii liczb – Część 4

  5. Model danych dotyczących opieki nad zwierzętami