Model bazy danych dla usługi taksówkowej

Nazwij je taksówkami lub taksówkami, te wygodne przejażdżki do wynajęcia istnieją od wieków. W dzisiejszych czasach prowadzenie taksówki jest o wiele bardziej skomplikowane. W tym artykule przyjrzymy się modelowi bazy danych zaprojektowanemu w celu zaspokojenia potrzeb firmy taksówkowej.

Historia „wezwania taksówki” rozpoczęła się w XVII-wiecznym Londynie. W większości miejsc taksówki są tańsze niż kiedykolwiek. Stają się też o wiele bardziej dostępne:taksówkę możemy zamówić telefonicznie, przez aplikacje mobilne lub przez Internet. Albo możemy użyć tych samych technik, które sprawdzają się od setek lat – ustawić się w kolejce na dworcu taksówki lub zgłosić go na ulicy.

Model biznesowy taksówki w żadnym wypadku nie jest w stagnacji. Nowsze koncepcje, takie jak Uber i Lyft, zyskują na popularności i z pewnością będą miały wpływ na przyszłość usług taksówkarskich. Oczywiście wszystko to komplikuje życie tym, którzy prowadzą firmy taksówkowe. Rzućmy okiem na odpowiednie części modelu danych, które firma taksówkarska mogłaby wykorzystać do utrzymania porządku.

Co chcemy osiągnąć dzięki temu modelowi bazy danych taksówki?

Model przedstawiony w tym artykule będzie w stanie:

Utwórz harmonogramy kierowców
Dostępność sterownika śledzenia w czasie rzeczywistym
Dostarcz kierowcom listę potencjalnych przejazdów
Pozwól kierowcom wybrać przejazd z listy
Oblicz godziny pracy i zarobki kierowców
Przechowuj różne statystyki (np. procent odwołanych przejazdów, płatności na kierowcę miesięcznie itp.)

Co musimy wiedzieć o firmach taksówkarskich?

Zanim zaprojektujemy model danych dla firmy taksówkarskiej, powinniśmy być w stanie odpowiedzieć na następujące pytania:

Kiedy działają sterowniki?
W większości firm taksówkowych kierowcy mają ustalone harmonogramy. Poznamy dokładne godziny rozpoczęcia i zakończenia zmiany przez kierowcę. W niektórych przypadkach godziny rozpoczęcia i zakończenia zmiany nie są z góry określone. Na przykład członkowie stowarzyszenia taksówek mogą się zalogować i rozpocząć pracę, kiedy tylko chcą. Mogą również się wylogować i zakończyć swoją zmianę, kiedy zechcą. Nasz model powinien być w stanie obsługiwać obie opcje.
Czy kierowca może pracować na wiele zmian tego samego dnia?
Jeśli kierowca jest członkiem stowarzyszenia taksówkarzy, może być w stanie pracować rano, wracać do domu i jeszcze tego samego wieczoru pracować. Jednak w niektórych obszarach (takich jak Nowy Jork) istnieją prawne ograniczenia dotyczące długości zmiany i/lub liczby godzin pracy taksówkarzy każdego dnia.
3. Kto inicjuje przejazd?
W większości przypadków klient skontaktuje się z taksówką, a dyspozytor wprowadzi jego żądanie do systemu. Inny scenariusz ma miejsce, gdy klient zamawia taksówkę bezpośrednio (np. za pomocą aplikacji mobilnej), a w proces nie jest zaangażowany pracownik call center. Trzecia opcja – która również omija call center – ma miejsce, gdy klient wsiada do taksówki na dworcu lub zatrzymuje ją na ulicy.

Model danych

Nasz model ma dwie główne sekcje i trzy nieskategoryzowane tabele. Każdemu z nich przyjrzymy się bliżej.

Sekcja 1:Kabiny, kierowcy i zmiany biegów

Wszystko zaczyna się od taksówek i kierowców:potrzebujemy samochodów w firmie taksówkowej i potrzebujemy kierowców. (W przyszłości prawdopodobnie będziemy musieli dostosować nasz model do samochodów autonomicznych. Ale na razie pozostańmy w teraźniejszości).

Eksplorację modelu danych rozpoczniemy od driver stół. W tej tabeli uwzględnimy zwykłe atrybuty, takie jak imię, nazwisko i data urodzenia. Będziemy też mieć kilka atrybutów, które są dość specyficzne dla tego modelu:

driving_licence_number – Jest to numer identyfikacyjny lub kod alfanumeryczny, który zwykle znajduje się na licencji wydanej przez rząd. Ponieważ ten identyfikator jest unikalny w świecie rzeczywistym, będzie również unikalny w naszej bazie danych. (W niektórych obszarach kierowcy taksówek muszą mieć specjalny rodzaj licencji operacyjnej, aby pracować; zakładamy, że ją mają).
expiry_date – Jest to data, w której prawo jazdy utraciło ważność. Zauważ, że nie będziemy przechowywać historii licencji, więc po prostu nadpiszemy driving_licence_number i expiry_date z nowymi danymi w razie potrzeby. Jeśli chcemy przechowywać historię licencji, musielibyśmy dodać kolejną tabelę do naszego modelu.
working – Jest to wartość logiczna, która po prostu włącza się i wyłącza, gdy kierowcy logują się do systemu. Ustawimy ten atrybut domyślnie na „Tak” (wartość 1) i zmienimy go na „Nie” tylko wtedy, gdy kierowca nie będzie już mógł logować się do systemu.

Istnieje wiele innych szczegółów związanych z kierowcami, które moglibyśmy przechowywać w bazie danych:nazwy użytkownika i hasła, data rozpoczęcia pracy każdego kierowcy oraz aktualny rodzaj zatrudnienia każdego kierowcy. Nie będziemy teraz wchodzić w te szczegóły, ponieważ nie są one specjalnie związane z tym modelem. Zaklasyfikowałbym je do administracji użytkownikami, co jest takie samo w większości systemów.

Przejdźmy teraz do cab i car_model tabele. Tutaj przechowujemy listę samochodów, którymi operuje nasza firma. Przechowujemy również pewne szczegóły dotyczące każdego pojazdu. Najważniejsze atrybuty w tych dwóch tabelach to:

model_description – Jest to atrybut tekstowy, który przechowuje firmowy opis określonego typu samochodu. Na przykład firmy taksówkowe mogą chcieć przechowywać liczbę pasażerów, jaką może przewozić samochód, miejsce w bagażniku (bagażnik) i inne fakty.
license_plate – Numer na tablicy rejestracyjnej (tablica rejestracyjna pojazdu lub tablica rejestracyjna) jednoznacznie definiuje samochód, zarówno dla celów firmowych, jak i rządowych. Oczywiście może być konieczna zmiana informacji o tablicach rejestracyjnych, jeśli samochód jest kupowany lub sprzedawany. W tej tabeli będziemy przechowywać tylko aktualne pojazdy firmy; jeśli musimy zachować historię, możemy dodać jeszcze jedną tabelę do naszego modelu.
owner_id – Ten atrybut jest odniesieniem do driver stół. Jest to opcjonalne, ponieważ użyjemy go tylko wtedy, gdy kierowca ma swoją kabinę. (Zwykle ma to miejsce w przypadku stowarzyszeń taksówek).
active – Jest to wartość logiczna, która oznacza, czy firma nadal korzysta z samochodu.

Na koniec spójrzmy na najważniejszą tabelę w tej sekcji:shift stół. Ideą tej tabeli jest przechowywanie rzeczywistych godzin pracy i zmian harmonogramu dla samochodów i kierowców. Każda zmiana będzie miała co najmniej jedną taksówkę (cab_id ) i jeden sterownik (driver_id ). Oprócz klucza podstawowego, który jest unikalnym numerem identyfikacyjnym zmiany, są to jedyne obowiązkowe atrybuty w tej tabeli.

shift_start_time i shift_end_time atrybuty to rzeczywiste momenty rozpoczęcia i zakończenia zmiany. Często są one ustawione fabrycznie. W przypadku braku harmonogramu, jak w przypadku powiązania taksówki, te czasy będą takie same jak login_time i logout_time odpowiednio atrybuty. login_time i logout_time to rzeczywiste godziny, w których kierowcy się logują (za pomocą urządzenia mobilnego w samochodzie lub innej metody stosowanej przez firmę taksówkarską). Gdy kierowca zaloguje się do systemu, pojawi się lista dostępnych przejazdów, z których kierowca wybierze jeden. Oczywiście dyspozytor zostanie również powiadomiony, że kierowca pracuje.

Sekcja 2:Przejażdżki

Ta sekcja składa się tylko z dwóch tabel, ale to one są prawdziwym sercem tego modelu.

W cab_ride tabeli, zapiszemy jeden rekord na każdą potencjalną jazdę. Zaktualizujemy ten rekord zgodnie z tym, co się stanie. Zróbmy krótki przegląd atrybutów:

shift_id – To jest odniesienie do shift stół; dostarcza nam dane kierowcy i kabiny dla danej jazdy.
ride_start_time i ride_end_time – Są one aktualizowane, gdy kierowcy sygnalizują, że są aktualnie zajęci (rozpoczęcie jazdy), a następnie ponownie są dostępne (koniec jazdy).
address_starting_point i address_destination – To miejsca, w których zaczyna się i kończy przejażdżka. Kierowca prawdopodobnie wyszuka obie lokalizacje, aby uzyskać nawigację na swoim tablecie lub GPS, więc jest to prawdopodobne, gdy zaktualizujemy te dwa atrybuty.
GPS_starting_point i GPS_destination – Są to współrzędne GPS lokalizacji początkowej i końcowej opisanej powyżej. Te wartości są opcjonalne, ponieważ zaktualizujemy je tylko wtedy, gdy będziemy mieć dane.
canceled – To prosta wartość Tak/Nie, która informuje nas, czy przejazd został odwołany. Mamy już zapis tej jazdy w naszym stole, więc możemy po prostu oznaczyć przejazd jako anulowany.
payment_type_id i price – Dostarczają one informacji o kwocie zapłaconej za przejazd i metodzie płatności używanej przez klienta.

Większość atrybutów w cab_ride tabela może zawierać wartość NULL. Są ku temu dwa powody:

Przejazdy są anulowane, co oznacza, że w tych polach nie zostaną wprowadzone żadne dane;
Nawet jeśli w końcu będziemy mieć wszystkie dane, nie będziemy mieć ich wszystkich przy pierwszym wstawieniu rekordu. Zaktualizujemy każdy rekord kilka razy – przynajmniej zaktualizujemy go, gdy przejazd się rozpocznie i zakończy (lub zostanie anulowany).

Druga tabela w tej sekcji to cab_ride_status stół. Tutaj dodawany jest rekord dla każdej zmiany związanej z pojedynczą jazdą. Gdy dyspozytor wprowadzi do systemu nową jazdę, doda rekord do cab_ride tabeli, ale powiązany rekord zostanie również utworzony w cab_ride_status tabela (wraz z odpowiednim statusem). Po każdej zmianie związanej z tą jazdą do tej tabeli zostanie dodany jeszcze jeden rekord. Atrybuty to:

cab_ride_id i status_id – Są to klucze obce, które są powiązane z atrybutem id w ride tabela i atrybut id w status tabela (którą omówimy poniżej). Oba są obowiązkowe.
status_time – Przechowuje rzeczywisty czas wstawienia rekordu. Jest to również obowiązkowe.
cc_agent_id i shift_id – Są to odniesienia do pracownika, który wstawił aktualizację statusu. Może to być dyspozytor lub kierowca. Prawdopodobnie dyspozytor wstawi stan początkowy, a kierowca wstawi wszystkie następujące stany.
status_details – Jest to atrybut tekstowy, którego można użyć do przechowywania dodatkowych informacji. Na przykład dyspozytor może użyć tego atrybutu do zapisania specjalnych instrukcji dotyczących jazdy.

Tabele bez kategorii

Na koniec szybko przejrzyjmy nasze nieskategoryzowane tabele.

cc_agent tabela zawiera listę agentów call center lub dyspozytorów, którzy mogą dodawać nowe rekordy w cab_ride i cab_ride_status tabele.

W status słownika, przechowamy listę wszystkich możliwych statusów, które możemy przypisać do przejazdu. Niektóre wartości to „nowa jazda” , „jazda przypisana kierowcy” , „jazda rozpoczęta” , „jazda zakończona” lub „przejazd odwołany” .

Payment_type to kolejna tabela słownika. Jego zawartość służy do aktualizacji payment_type_id atrybut w cab_ride stół. Typowe wartości to „gotówka” i „karta kredytowa” .

Jak ulepszyłbyś model danych taksówki?

Przedstawiony w tym artykule model bazy danych taksówki/taxi skupia się tylko na najważniejszych funkcjonalnościach. Możemy wprowadzić wiele ulepszeń. Trasy to tylko te, o których mogę pomyśleć.

W przyszłości prawdopodobnie będziemy mieli kabiny bez kierowcy. W takim przypadku usunęlibyśmy sterownik z modelu i zastąpilibyśmy takie rzeczy jak czasy ładowania i naprawy.

Zapraszam do komentowania i dodawania swoich pomysłów.