Модел на база данни за таксиметрова услуга

Наречете ги таксита или таксита, тези удобни превозни средства под наем съществуват от векове. В днешно време е много по-сложно да управлявате таксиметрова услуга. В тази статия ще разгледаме модел на база данни, предназначен да отговори на нуждите на таксиметрова компания.

Историята на „извикването на такси“ започва през 17 век в Лондон. На повечето места такситата са по-достъпни от всякога. Те също така стават много по-достъпни:можем да поръчаме такси по телефона, чрез мобилни приложения или в мрежата. Или можем да използваме същите техники, които работят от стотици години – да се наредим на таксиметрова станция или да маркираме едно на улицата.

Бизнес моделът на таксиметровите услуги по никакъв начин не е в застой. По-новите концепции като Uber и Lyft набират популярност и със сигурност ще окажат влияние върху бъдещето на таксиметровите услуги. Разбира се, всичко това усложнява живота на тези, които управляват таксиметровите компании. Нека да разгледаме съответните части на модела на данни, който таксиметровата компания може да използва, за да остане организирана.

Какво искаме да постигнем с този модел на база данни на кабината?

Моделът, представен в тази статия, ще може да:

Създаване на графици за драйвери
Проследявайте наличността на драйвери в реално време
Предоставете на шофьорите списък с потенциални пътувания
Позволете на шофьорите да изберат пътуване от списъка
Изчислете работното време и приходите на шофьорите
Съхранявайте различни статистически данни (напр. процент на анулираните пътувания, плащания на шофьор на месец и т.н.)

Какво трябва да знаем за таксиметровите компании?

Преди да проектираме модел на данни за таксиметрова компания, трябва да можем да отговорим на следните въпроси:

Кога работят драйверите?
В повечето таксиметрови компании шофьорите имат предварително дефинирани графици. Ще знаем точното време, когато водачът започва и завършва смяна. В някои случаи началното и крайното време на смяната не са дефинирани предварително. Например, членовете на таксиметрова асоциация могат да влязат и да започнат работа, когато пожелаят. Те също могат да излязат и да прекратят смяната си, когато решат. Нашият модел трябва да може да поддържа и двете опции.
Може ли шофьор да работи на няколко смени в един и същи ден?
Ако шофьорът е член на таксиметрова асоциация, той може да е в състояние да работи сутрин, да се прибере вкъщи и след това да работи отново същата вечер. Въпреки това, в някои области (като Ню Йорк) има законови ограничения относно продължителността на смяната и/или колко часа могат да работят таксиметровите шофьори всеки ден.
3. Кой инициира езда?
В повечето случаи клиентът ще се свърже с центъра за повикване на такси и диспечерът ще въведе заявката му в системата. Друг сценарий възниква, когато клиентът поръча директно такси (например чрез мобилно приложение) и няма служител на кол центъра, участващ в процеса. Трети вариант – който също заобикаля кол центъра – се случва, когато клиентът вземе такси на гарата или се обади на улицата.

Моделът на данните

Нашият модел има два основни раздела и три некатегоризирани таблици. Ще разгледаме по-отблизо всеки един от тях.

Раздел 1:Кабини, шофьори и смени

Всичко започва с такси и шофьори:имаме нужда от автомобили в таксиметрова компания и имаме нужда от шофьори. (В бъдеще вероятно ще трябва да коригираме модела си за самоуправляващи се автомобили. Но нека останем в настоящето засега.)

Ще започнем нашето изследване на модела на данни с driver маса. В тази таблица ще включим обичайните атрибути като име, фамилия и дата на раждане. Ще имаме и някои атрибути, които са доста специфични за този модел:

driving_licence_number – Това е идентификационен номер или буквено-цифров код, който обикновено се намира в лиценз, издаден от правителството. Тъй като този идентификатор е уникален в реалния свят, той ще бъде уникален и в нашата база данни. (В някои райони таксиметровите шофьори трябва да имат специален вид лиценз за работа; ние ще приемем, че го имат.)
expiry_date – Това е датата, на която шофьорската книжка вече не е законно валидна. Забележете, че няма да съхраняваме историята на лиценза, така че просто ще презапишем driving_licence_number и expiry_date с нови данни според нуждите. Ако искаме да съхраняваме истории на лицензи, ще трябва да добавим още една таблица към нашия модел.
working – Това е булева стойност, която просто се включва и изключва, когато драйверите влизат в системата. Ще зададем този атрибут по подразбиране на „Да“ (стойност 1) и ще го променим на „Не“ само когато на водача вече не е разрешено да влиза в системата.

Има много други подробности, свързани с водача, които бихме могли да съхраняваме в базата данни:потребителски имена и пароли, датата, на която всеки шофьор е започнал работа, и текущия вид на работа на всеки шофьор. Сега няма да навлизаме в тези подробности, защото те не са конкретно свързани с този модел. Бих ги класирал под потребителско администриране, което е същото в повечето системи.

Сега да преминем към cab и car_model маси. Тук ще съхраняваме списък с колите, които нашата компания оперира. Ние също така ще съхраняваме определени подробности за всяко превозно средство. Най-важните атрибути в тези две таблици са:

model_description – Това е текстов атрибут, който съхранява посочено от компанията описание на определен тип автомобил. Например таксиметровите компании може да искат да съхранят броя на пътниците, които колата може да превози, пространството в багажника (багажника) и други факти.
license_plate – Номерът на регистрационния номер (регистрационна табела на превозното средство или номер) уникално определя автомобил, както за фирмени, така и за държавни цели. Разбира се, може да се наложи да променим информацията за регистрационния номер, ако колата бъде закупена или продадена. В тази таблица ще съхраняваме само текущите превозни средства на компанията; ако трябва да запазим история, можем да добавим още една таблица към нашия модел.
owner_id – Този атрибут е препратка към driver маса. Не е задължително, защото ще го използваме само когато шофьорът притежава кабината си. (Това обикновено е така в таксиметровите асоциации).
active – Това е булева стойност, която показва дали компанията все още използва автомобил.

И накрая, нека да разгледаме най-важната таблица в този раздел:shift маса. Идеята зад тази таблица е да съхранява действителното работно време и смените на графика за автомобили и шофьори. Всяка смяна ще има поне една кабина (cab_id ) и един драйвер (driver_id). ). Освен първичния ключ, който е уникален идентификационен номер на смяна, това са единствените задължителни атрибути в тази таблица.

shift_start_time и shift_end_time атрибутите са действителните моменти, когато смяната започва и завършва. Често те са предварително зададени. В случай, че няма график, както при асоциация на такси, тези времена ще бъдат същите като login_time и logout_time атрибути, респ. login_time и logout_time са действителните времена, в които шофьорите влизат (чрез мобилно устройство в колата си или какъвто и да е метод, използван от таксиметровата компания). Когато водачът влезе в системата, ще се появи списък с наличните пътувания и водачът ще избере едно. Разбира се, диспечерът също ще бъде уведомен, че шофьорът вече работи.

Раздел 2:Разходки

Този раздел се състои само от две таблици, но те са истинското сърце на този модел.

В cab_ride таблица, ще съхраняваме един запис за всяко потенциално пътуване. Ще актуализираме този запис според случващото се. Нека направим бърз преглед на атрибутите:

shift_id – Това е препратка към shift маса; той ни предоставя подробности за шофьора и кабината за дадено пътуване.
ride_start_time и ride_end_time – Те се актуализират, когато водачите сигнализират, че в момента са заети (начало на пътуването) и впоследствие отново достъпни (край на пътуването).
address_starting_point и address_destination – Това са местата, където започва и завършва едно пътуване. Шофьорът вероятно ще търси и двете местоположения, за да получи навигацията на своя таблет или GPS, така че това е вероятно, когато ще актуализираме тези два атрибута.
GPS_starting_point и GPS_destination – Това са GPS координатите на началното и крайното местоположение, описани по-горе. Тези стойности не са задължителни, защото ще ги актуализираме само когато имаме данни.
canceled – Това е проста стойност да/не, която ни казва дали пътуването е било отменено. Вече ще имаме запис за това пътуване в нашата таблица, така че можем просто да отбележим пътуването като отменено.
payment_type_id и price – Те предоставят информация за сумата, платена за пътуване, и за начина на плащане, използван от клиента.

Повечето от атрибутите в cab_ride таблицата може да съдържа стойност NULL. Има две причини за това:

Пътуванията се анулират, което означава, че няма да се въвеждат данни в тези полета;
Дори ако в крайна сметка ще имаме всички данни, няма да имаме всички, когато записът е първоначално вмъкнат. Ще актуализираме всеки запис няколко пъти – най-малкото ще го актуализираме, когато пътуването започне и приключи (или бъде отменено).

Втората таблица в този раздел е cab_ride_status маса. Тук се добавя запис за всяка промяна, свързана с едно пътуване. Когато диспечерът въведе ново пътуване в системата, той ще добави запис към cab_ride таблица, но свързан запис също ще бъде създаден в cab_ride_status таблица (заедно със съответния статус). След всяка промяна, свързана с това пътуване, към тази таблица ще бъде добавен още един запис. Атрибутите са:

cab_ride_id и status_id – Това са външни ключове, които са свързани с атрибута id в ride таблица и атрибута id в status таблица (която ще разгледаме по-долу). И двете са задължителни.
status_time – Това съхранява действителното време, когато записът е бил поставен. Също така е задължително.
cc_agent_id и shift_id – Това са препратки към служителя, който е вмъкнал актуализация на състоянието. Може да бъде или диспечер, или шофьор. Вероятно диспечерът ще въведе първоначалното състояние, а водачът ще въведе всички следните статуси.
status_details – Това е текстов атрибут, който може да се използва за съхраняване на допълнителна информация. Например, диспечерът може да използва този атрибут, за да записва специални инструкции за пътуване.

Некатегоризирани таблици

И накрая, нека бързо да разгледаме нашите некатегоризирани таблици.

cc_agent таблицата съдържа списък с агенти или диспечери на кол центъра, които могат да добавят нови записи в cab_ride и cab_ride_status таблици.

В status речник, ще съхраняваме списък с всички възможни състояния, които можем да присвоим на едно пътуване. Някои стойности включват „ново пътуване“ , „пътуването е възложено на водача“ , „карането започна“ , „пътуването приключи“ или „пътуването е отменено“ .

Payment_type е друга речникова таблица. Съдържанието му се използва за актуализиране на payment_type_id атрибут в cab_ride маса. Обичайните стойности са „кеш“ и „кредитна карта“ .

Как бихте подобрили модела на данни за такситата?

Моделът на база данни за таксита/таксита, представен в тази статия, е фокусиран само върху най-важните функционалности. Има много подобрения, които можем да направим. Маршрутите са само един, за който се сещам.

В бъдеще вероятно ще имаме кабини без шофьор. В този случай ще изхвърлим драйвера от модела и ще заменим неща като времена за презареждане и ремонт.

Чувствайте се свободни да коментирате и да добавяте вашите идеи.