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

Wynajem samochodów jest tak prosty jak prowadzenie pojazdu:model danych dla wypożyczalni samochodów

Mogłeś wynająć samochód na ostatnie wakacje. Zarezerwowałeś samochód online, a następnie odebrałeś go z wyznaczonego miejsca po zapłaceniu wszystkich uzgodnionych wcześniej opłat. Kiedy skończyłeś, zwróciłeś go agencji i być może zapłaciłeś dodatkowe opłaty. Czy kiedykolwiek myślałeś o systemie, który sprawia, że ​​wszystkie te rzeczy się zdarzają? W tym artykule przyjrzymy się modelowi danych dla systemu wynajmu samochodów.

Po co budować inny model danych wynajmu samochodów?

Chcę zaprojektować model danych w pełni funkcjonalnego systemu dla międzynarodowej wypożyczalni samochodów. Firma posiada samochody do wynajęcia w różnych segmentach (mini, ekonomiczne, pośrednie, SUV, cargo oraz limuzyny). Prowadzi działalność z różnych miast w wielu krajach. Firma umożliwia swoim klientom wypożyczenie samochodu w jednym miejscu (miejsce odbioru) i oddanie go w innym miejscu (miejsce odbioru).

W tym miejscu odwołajmy się do wcześniejszego artykułu, który wyjaśnia prosty model wypożyczalni samochodów. Ten model obsługuje wszystkie podstawowe usługi oferowane przez wypożyczalnię samochodów.




Zanim dodamy nowe funkcje, chciałbym wprowadzić do tego modelu kilka drobnych zmian, a mianowicie:

  • Dodawanie city jako kolumna w location i całkowite usunięcie tabeli miast.
  • Dodanie jednej dodatkowej kolumny, zip (jak w kodzie pocztowym lub kodzie pocztowym), w location stół. Ten system zidentyfikuje miejsce odbioru/nadania za pomocą kodu pocztowego. W wielu krajach kod pocztowy jest liczbą alfanumeryczną, więc zachowam tę kolumnę jako kolumnę varchar.

  • Dodanie driving license issue date do customer stół. W niektórych krajach maksymalne ograniczenie prędkości zależy od daty wydania prawa jazdy kierowcy.

  • Zmiana nazwy category tabela do car_category , który dokładniej opisuje jego zawartość.
  • Przechowywanie informacji o lotach klientów, jeśli miejsce odbioru znajduje się w pobliżu lotniska. Dzięki temu system może wprowadzić odpowiednie zmiany w żądaniu rezerwacji klienta w przypadku opóźnienia lub odwołania lotu. Aby to zrobić, dodaję kolejną tabelę o nazwie flight_detail i podłącz go do reservation stół.

Dodawanie informacji o fakturze klienta

W przypadku fakturowania musimy przechowywać wartość najmu dla każdej pozycji w ekwipunku, w tym samochodów i sprzętu. Koszt wynajmu jest przypisany do każdej kategorii, ponieważ proces rezerwacji dotyczy kategorii, a nie poszczególnych samochodów.

Pozwól, że dodam rental_value w car_category i equipment_category tabele.

Podobnie musi być jakiś koszt związany z ubezpieczeniem. Koszt ten ustala firma ubezpieczeniowa. Na razie dodam jeszcze jedną kolumnę, koszt, w insurance tabela.

Do fakturowania tworzę osobną tabelę do przechowywania wszystkich szczegółów faktury. W ten sposób te same dane można łatwo odzyskać w razie potrzeby. Ponieważ obliczenie tych wartości jest nieco skomplikowane, nie będę ich powtarzał dla faktury. Dodam jedną tabelę, a mianowicie rental_invoice , co jest związane przede wszystkim z rental stół.

rental_invoice tabela zawiera następujące kolumny:

  • id – klucz podstawowy tej tabeli.
  • rental_id – klucz podstawowy rental stół. Dodam jedno unikalne ograniczenie do tej kolumny:dla każdego wypożyczenia może być tylko jeden rekord.
  • car_rent – Ta kolumna oznacza koszty wynajmu wynajętego pojazdu.
  • Koszt ten można określić za pomocą następującego kodu SQL:

    select a.rental_value from car_category a, car b, rental c
    where  c.car_id = b.car_id and b.category_id = a.id
    and c.id = ;
    

  • equipment_rent_total – Ta kolumna pokazuje kwotę do pobrania za każdy sprzęt wypożyczony klientowi
  • Całkowity koszt można określić za pomocą następującego kodu SQL:

    select sum(a.rental_value) from equipment_category a, equipment b, car_equipment c, car d, rental e
    where  a.id = b.equipment_category_id and b.id = c.equipment_id
    and c.car_id = d.id and d.id = e.car_id 
    and e.id = ;
    

  • insurance_cost_total – Ta kolumna dotyczy całkowitego kosztu ubezpieczenia klienta. Można to określić za pomocą następującego SQL

    select sum(a.cost) from insurance a, rental_insurance b, rental c
    where a.id = b.insurance_id and b.rental_id = c.id 
    and c.id = ;
    

  • service_tax i VAT – Jak sugerują ich nazwy, kolumny te przechowują wartości obowiązującego podatku od usług i VAT.
  • total_amount_payable – Ta kolumna będzie zawierała wartość całkowitej kwoty faktury. Byłaby to suma następujących kolumn:

    total_amount_payable =car_rent + equipment_rent_total + insurance_cost_total

  • waiver_amount i net_amount_payable – W tych kolumnach przechowywane są wartości kwot zwolnień (jeśli istnieją) oraz należna kwota netto do zapłaty. waiver_amount to kwota, która zostanie uchylona od całkowitej faktury. Jest powszechnie stosowany, gdy wypożyczalnia oferuje klientom zniżkę. Wzór do określenia net_amount_payable wygląda tak:

    net_amount_payable =total_amount_payable – waiver_amount

Asortyment mobilny – W przypadku wypożyczalni samochodów jej ekwipunek jest zawsze mobilny, ponieważ przemieszcza się z jednej lokalizacji do drugiej. Jeśli zauważyłeś pole wyboru z napisem „powrót do innej lokalizacji?”, gdy rezerwujesz samochód online, widzisz je w akcji. System traktuje twoją prośbę nieco inaczej, jeśli miejsce zwrotu NIE jest takie samo jak miejsce odbioru. System zawsze śledzi stan magazynowy w momencie wypożyczenia i zwrotu.

Na przykład jeden klient wynajmuje samochód w Chicago, potwierdza, że ​​miejsce odbioru będzie inne i jedzie do miejsca docelowego w Saint Louis. Oczywiście podrzuci samochód w siedzibie firmy w Saint Louis. W tym przypadku, gdy tylko jedzie samochodem z lokalizacji w Chicago, ta część ekwipunku nie jest już powiązana z tym biurem. Samochód zostanie ponownie zarejestrowany, tym razem w biurze Saint Louis, jak tylko z tym skończy.

Aby włączyć ten mechanizm, dodam jedną kolumnę, a mianowicie current_location_id , w car tabeli oraz equipment stół. Ta kolumna zawiera tylko prawidłowe identyfikatory lokalizacji z location tabela.

Tak więc w powyższym przykładzie początkowa lokalizacja samochodu to Chicago; zostanie zaktualizowany, gdy klient zwróci samochód do biura docelowego.

Konfigurowanie opcji tankowania

Większość wypożyczalni samochodów oferuje następujące opcje tankowania:
  1. Zaliczka na paliwo – klient z góry płaci za pełny bak i zwraca auto z pustym bakiem.
  2. Opłata za paliwo – klient dostaje samochód z pełnym bakiem, ale płaci za niego na podstawie zużycia paliwa.
  3. Samoobsługa paliwowa – klient odbiera auto z pełnym bakiem i zwraca auto z pełnym bakiem. To najbardziej akceptowana opcja z tych trzech.

Tutaj nie obchodzi nas, którą opcję wybierze klient. Chcemy zarejestrować ich wybór podczas przetwarzania wniosku o wypożyczenie.

Aby zaspokoić tę potrzebę, dodam jedną tabelę, fuel_option , który przechowuje wszystkie możliwe opcje tankowania samochodu. Musi istnieć mapowanie jeden do jednego między żądaniem wypożyczenia a fuel_option , ponieważ klient jest proszony o wybranie jednego w momencie rezerwacji wynajmu.

Ostateczny model danych wynajmu samochodu




W wielu obszarach firmy zajmujące się wynajmem samochodów przestawiają się na korzystanie z bezkluczykowego, samoobsługowego wynajmu dla swoich klientów. Nie chcą, aby ich klienci czekali przy ladzie tylko po to, aby wypełnić papierkową robotę i odebrać kluczyki do samochodu. Czy nasz obecny model danych może sprostać takim wymaganiom? Jakie zmiany są potrzebne w naszym modelu danych, aby tak się stało?

Czy masz jakieś przemyślenia na temat naszego modelu danych dotyczących wynajmu samochodów? Zacznijmy dyskusję! Podziel się swoimi uwagami 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. Maskowanie danych w aplikacjach DB

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

  3. Jak zainstalować Cassandra v3 na CentOS 6?

  4. Połączenie krzyżowe SQL

  5. Podejścia do bezpieczeństwa w modelowaniu danych. Część 4