sql >> Databáze >  >> RDS >> Database

Databázový model pro taxislužbu

Říkejte jim taxíky nebo taxíky, tyto pohodlné jízdy k pronájmu existují již po staletí. V dnešní době je provozování taxislužby mnohem složitější. V tomto článku se podíváme na databázový model navržený tak, aby vyhovoval potřebám taxislužby.

Historie „volání taxíku“ začala v 17. století v Londýně. Na většině míst jsou kabiny cenově dostupnější než kdy jindy. Také se stávají mnohem dostupnější:taxi si můžeme objednat telefonicky, přes mobilní aplikace nebo na webu. Nebo můžeme použít stejné techniky, které fungují už stovky let – postavit se do řady na stanovišti taxíku nebo na ulici.

Obchodní model taxi v žádném případě nestagnuje. Novější koncepty jako Uber a Lyft získávají na popularitě a jistě budou mít vliv na budoucnost taxislužeb. To vše samozřejmě komplikuje život těm, kdo řídí taxikáře. Pojďme se podívat na příslušné části datového modelu, které by taxikáři mohli použít, aby si udrželi pořádek.

Čeho chceme s tímto modelem databáze kabiny dosáhnout?

Model uvedený v tomto článku bude umět:

  • Vytvořte plány řidičů
  • Sledování dostupnosti ovladače v reálném čase
  • Poskytněte řidičům seznam potenciálních jízd
  • Umožněte řidičům vybrat si jízdu ze seznamu
  • Vypočítejte pracovní dobu a výdělky řidičů
  • Ukládání různých statistik (např. procento zrušených jízd, platby na řidiče za měsíc atd.)

Co potřebujeme vědět o taxislužbách?

Než navrhneme datový model pro taxikářskou společnost, měli bychom být schopni odpovědět na následující otázky:

  1. Kdy ovladače fungují?
    Ve většině taxikářských společností mají řidiči předdefinované jízdní řády. Budeme znát přesné časy, kdy řidič začíná a končí směnu. V některých případech nejsou časy začátku a konce směny definovány předem. Například členové sdružení taxikářů se mohou přihlásit a začít pracovat, kdykoli chtějí. Mohou se také odhlásit a ukončit směnu, když se rozhodnou. Náš model by měl podporovat obě možnosti.

  2. Může řidič pracovat ve více směnách ve stejný den?
    Pokud je řidič členem sdružení taxikářů, může být schopen pracovat ráno, jít domů a pak tentýž večer znovu pracovat. V některých oblastech (jako je New York City) však existují zákonná omezení týkající se délky směn a/nebo toho, kolik hodin mohou řidiči taxíků pracovat každý den.

  3. 3. Kdo iniciuje jízdu?
    Ve většině případů zákazník kontaktuje call centrum taxi a dispečer zadá jeho požadavek do systému. Jiný scénář nastává, když si zákazník objedná taxi přímo (například prostřednictvím mobilní aplikace) a do procesu není zapojen žádný pracovník call centra. Třetí možnost – která také obchází call centrum – nastává, když zákazník dostane taxi na nádraží nebo si ho zavolá na ulici.

Datový model




Náš model má dvě hlavní sekce a tři nekategorizované tabulky. Na každý z nich se podíváme blíže.

Část 1:Kabiny, řidiči a směny

Vše začíná u taxíků a řidičů:potřebujeme auta v taxislužbě a potřebujeme řidiče. (V budoucnu budeme pravděpodobně muset upravit náš model pro samořiditelná auta. Ale zůstaňme zatím v přítomnosti.)

Náš průzkum datového modelu začneme driver stůl. V této tabulce zahrneme obvyklé atributy, jako je jméno, příjmení a datum narození. Budeme mít také některé atributy, které jsou zcela specifické pro tento model:

  • driving_licence_number – Toto je identifikační číslo nebo alfanumerický kód, který se obvykle nachází na vládou vydané licenci. Protože je toto ID jedinečné v reálném světě, bude jedinečné i v naší databázi. (V některých oblastech musí mít taxikáři k práci speciální typ provozní licence; budeme předpokládat, že ji mají.)
  • expiry_date – Toto je datum, kdy řidičský průkaz pozbyl právní moci. Všimněte si, že nebudeme ukládat historii licencí, takže jednoduše přepíšeme driving_licence_number a expiry_date s novými údaji podle potřeby. Pokud chceme ukládat historii licencí, museli bychom do našeho modelu přidat další tabulku.
  • working – Toto je logická hodnota, která se jednoduše zapíná a vypíná, když se řidiči přihlásí do systému. Tento atribut ve výchozím nastavení nastavíme na „Ano“ (hodnota 1) a změníme jej na „Ne“ pouze v případě, že se ovladač již nebude moci přihlásit do systému.

Existuje mnoho dalších podrobností týkajících se řidiče, které bychom mohli uložit do databáze:uživatelská jména a hesla, datum, kdy každý řidič začal pracovat, a aktuální typ zaměstnání každého řidiče. Těmito detaily se nyní nebudeme zabývat, protože se konkrétně netýkají tohoto modelu. Zařadil bych je pod správu uživatelů, která je ve většině systémů stejná.

Nyní přejděme k cab a car_model tabulky. Zde budeme ukládat seznam vozů, které naše společnost provozuje. Uložíme také určité podrobnosti o každém vozidle. Nejdůležitější atributy v těchto dvou tabulkách jsou:

  • model_description – Jedná se o textový atribut, který uchovává firemní popis určitého typu vozu. Taxikáři mohou například chtít uložit počet cestujících, které vůz může převézt, zavazadlový prostor (zavazadlový prostor) a další fakta.
  • license_plate – Číslo na SPZ (SPZ nebo SPZ) jednoznačně definuje auto, a to jak pro společnost, tak pro vládní účely. Při koupi nebo prodeji auta můžeme samozřejmě potřebovat změnit informace o SPZ. V této tabulce uložíme pouze aktuální vozidla společnosti; pokud potřebujeme uchovat historii, můžeme do našeho modelu přidat ještě jednu tabulku.
  • owner_id – Tento atribut je odkazem na driver stůl. Je volitelná, protože ji použijeme pouze v případě, že řidič vlastní svou kabinu. (To je obvykle případ sdružení taxikářů).
  • active – Jedná se o booleovskou hodnotu, která označuje, zda společnost stále používá automobil.

Nakonec se podívejme na nejdůležitější tabulku v této části:shift stůl. Myšlenkou této tabulky je ukládat skutečnou pracovní dobu a rozvrh směn pro auta a řidiče. Každá směna bude mít alespoň jeden taxík (cab_id ) a jeden ovladač (driver_id ). Kromě primárního klíče, což je jedinečné ID směny, jsou to jediné povinné atributy v této tabulce.

shift_start_time a shift_end_time atributy jsou skutečné okamžiky, kdy směna začíná a končí. Často jsou přednastaveny. V případě, že neexistuje žádný rozvrh, jako v případě sdružení taxikářů, budou tyto časy stejné jako login_time a logout_time atributy, resp. login_time a logout_time jsou skutečné časy, kdy se řidiči přihlásí (prostřednictvím mobilního zařízení v autě nebo jakoukoli metodou, kterou taxislužba používá). Když se řidič přihlásí do systému, objeví se seznam dostupných jízd a řidič si jednu vybere. Dispečer bude samozřejmě také upozorněn, že ovladač nyní funguje.

Část 2:Jízdy

Tato část se skládá pouze ze dvou tabulek, ale jsou skutečným srdcem tohoto modelu.

V cab_ride tabulky, uložíme jeden záznam pro každou potenciální jízdu. Tento záznam aktualizujeme podle toho, co se stane. Pojďme si udělat rychlý přehled atributů:

  • shift_id – Toto je odkaz na shift stůl; poskytuje nám podrobnosti o řidiči a kabině pro danou jízdu.
  • ride_start_time a ride_end_time – Tyto jsou aktualizovány, když řidiči signalizují, že jsou aktuálně zaneprázdněni (začátek jízdy) a následně jsou opět k dispozici (konec jízdy).
  • address_starting_point a address_destination – Toto jsou místa, kde jízda začíná a končí. Řidič bude pravděpodobně hledat obě místa, aby získal navigaci na svém tabletu nebo GPS, takže je pravděpodobné, že tyto dva atributy aktualizujeme.
  • GPS_starting_point a GPS_destination – Toto jsou GPS souřadnice výše popsaných výchozích a konečných míst. Tyto hodnoty jsou volitelné, protože je aktualizujeme, pouze když budeme mít data.
  • canceled – Toto je jednoduchá hodnota Ano/Ne, která nám říká, zda byla jízda zrušena. V naší tabulce již máme záznam o této jízdě, takže ji můžeme označit jako zrušenou.
  • payment_type_id a price – Tyto poskytují informace o částce zaplacené za jízdu a způsobu platby, který zákazník používá.

Většina atributů v cab_ride tabulka může obsahovat hodnotu NULL. Jsou pro to dva důvody:

  • Jízdy se ruší, což znamená, že do těchto polí nebudou zadána žádná data;
  • I když nakonec budeme mít všechna data, nebudeme je mít při prvotním vložení záznamu. Každý záznam aktualizujeme několikrát – přinejmenším jej aktualizujeme, když jízda začíná a končí (nebo je zrušena).

Druhá tabulka v této sekci je cab_ride_status stůl. Zde je přidán záznam pro každou změnu související s jedinou jízdou. Když dispečer zadá do systému novou jízdu, přidá záznam do cab_ride tabulka, ale související záznam bude vytvořen také ve cab_ride_status tabulka (spolu s odpovídajícím stavem). Po každé změně související s danou jízdou se do této tabulky přidá ještě jeden záznam. Atributy jsou:

  • cab_ride_id a status_id – Jedná se o cizí klíče, které souvisí s atributem id v ride tabulka a atribut id ve status tabulky (které se budeme věnovat níže). Obojí je povinné.
  • status_time – Zde se uloží aktuální čas, kdy byl záznam vložen. Je to také povinné.
  • cc_agent_id a shift_id – Jedná se o odkazy na zaměstnance, který vložil aktualizaci stavu. Může to být buď dispečer nebo řidič. Pravděpodobně dispečer vloží počáteční stav a řidič vloží všechny následující stavy.
  • status_details – Toto je textový atribut, který lze použít k uložení dalších informací. Dispečer může například tento atribut použít k zaznamenání speciálních pokynů o jízdě.

Nekategorizované tabulky

Nakonec si rychle projdeme naše nezařazené tabulky.

cc_agent tabulka obsahuje seznam agentů call centra nebo dispečerů, kteří mohou přidávat nové záznamy do cab_ride a cab_ride_status tabulky.

Ve status slovníku, uložíme seznam všech možných stavů, které bychom mohli přiřadit jízdě. Některé hodnoty zahrnují „nová jízda“ , „jízda přidělena řidiči“ , „jízda zahájena“ , „jízda skončila“ nebo „jízda zrušena“ .

Payment_type je další slovníková tabulka. Jeho obsah se používá k aktualizaci payment_type_id atribut v cab_ride stůl. Běžné hodnoty jsou „hotovost“ a „kreditní karta“ .

Jak byste zlepšili datový model taxi?

Databázový model kabiny/taxi uvedený v tomto článku je zaměřen pouze na nejdůležitější funkce. Existuje mnoho vylepšení, která bychom mohli provést. Trasy jsou jen ty, které mě napadají.

V budoucnu pravděpodobně budeme mít kabiny bez řidiče. V takovém případě bychom vypustili ovladač z modelu a nahradili věci, jako jsou doby dobíjení a oprav.

Neváhejte komentovat a přidávat své nápady.


  1. Jak FIELD() funguje v MariaDB

  2. Systémové databáze SQL Server – základní pojmy

  3. Proč v TSQL používat nenulový primární klíč?

  4. Proč postgres v mém dotazu nepoužívá index