Докоснете и паркирайте:Модел на данни за приложение за паркиране

Различни приложения обещават да направят вашето търсене на паркинг безболезнено. Нека разгледаме този тип приложение, използвайки нашите очила за моделиране на данни. Как изглежда основният модел?

В по-ранна статия обяснихме как е структуриран паркинг и как може да бъде проектиран модел на данни, за да го управлява. В тази статия разглеждаме модела на данни за приложение за паркиране. Знаете тези приложения:те изброяват опциите за паркиране наблизо, казват ви цените и ви позволяват да резервирате или резервирате място или да закупите карта за паркиране.

Това приложение прави търсенето ви за паркиране сравнително безболезнено. Бих казал, че най-важният фактор при избора на място за паркиране е цената. Петминутна разходка, която спестява няколко долара, винаги си заслужава. Като се има предвид това, нека сложим нашите очила за моделиране на данни и да разгледаме отблизо света на приложенията за паркинг.

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

Приложенията за паркиране са доста прости:можем да очакваме функции за проследяване на наличността и цената на паркоместа в реално време, резервиране на посочените места и плащане на таксите.

Освен местоположението, което е сравнително лесно за моделиране на данни, основният двигател за паркингите е цената. Стратегията за ценообразуване на местата за паркиране е доста проста и определени методи или правила са практически универсални:

Паркингите често имат различни цени за различно време. Денят обикновено се разделя на три части – сутрин (6:00 до 11:00 ч.), обед (11:00 до 17:00 ч.) и вечер (5:00 до 22:00 ч.).
Вечерите и сутрините обикновено имат по-високи цени, тъй като е вероятно повече автомобили да се нуждаят от място през тези часове.
Цените също могат да се различават в зависимост от дните от седмицата. Например, паркинг близо до центъра на града ще таксува повече през уикенда (събота и неделя), защото тогава повече хора посещават.
През повечето време партидите използват стандартните си цени. Има обаче дни, в които може да таксуват повече – напр. паркингите в близост до бейзболни стадиони може да таксуват повече, когато има мач или събитие на стадиона.
Паркинги в близост до транспортни центрове (летища, железопътни гари и автобусни стоянки) може да позволяват паркиране за 24-часов ден или седмично. Те вероятно ще имат специална тарифа за по-дългосрочно паркиране.
Някои паркинги издават месечни карти на фиксирана цена. Притежателите на месечна карта плащат фиксираната сума всеки месец, вместо да плащат дневна такса.

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

Както можете да видите, има три тематични области:

„Паркинг“
„Клиент“
„Резервация за паркинг“

Нека първо вземем най-важната тематична област – тази, която се занимава с паркинги и тяхното ценообразуване.

Паркинг

Тази тематична област се върти около parking_lot таблица, която съхранява подробности за всеки паркинг в нашата система. Тази таблица е подробно обяснена в предишната ни статия за модел на данни за управление на паркинг. Тук обаче ще повторим няколко важни колони:

zip – Пощенски код; това играе основна роля във функцията за търсене.
is_slot_available – Актуализира се от операторите на паркинги и показва дали има място в момента.
is_reentry_allowed – Дали клиентът може да паркира отново на парцела, след като го е напуснал. Ако повторното влизане не е разрешено, връщащият се клиент ще трябва да закупи друго място.
is_valet_parking_available – Паркирането от служител струва допълнително, но хората често го предпочитат – особено когато са на среща. 😉
operational_in_night – Дали паркингът е отворен през нощта. Тази информация става много важна, когато колата ви е паркирана близо до летище и полетът ви пристига в полунощ!
minimum_hr_pay – Минималната такса за паркиране на колата ви на място. Например, някои парцели имат тричасов минимум, което означава, че плащате за три часа, дори ако сте паркирани само за 30 минути.
is_monthly_pass_allowed –Дали много предлага месечни карти.

Вече обсъдихме факторите, които влизат в определянето на цените за паркиране. Сега нека видим как ще се справим с ценообразуването в нашия модел. Ще използваме parking_pricing таблица, за да поддържате запис на редовните цени и pricing_exception таблица за записване на всички изключения. И двете таблици имат сходна структура, а колоните се разбират сами. Единствените разлики са:

parking_pricing таблицата има колона (day_of_week ), който съхранява деня от седмицата, свързан с дадена цена. pricing_exception таблицата има calendar_date колона, която съдържа действителната дата, когато е била приложима специалната цена.
Когато приложението показва цени, pricing_exception таблицата има предимство пред parking_pricing маса. Така че, ако обичайната тарифа за днес е 5 долара на час, но има специална ставка за 7 долара, приложението ще показва 7 долара на час.

Финалната таблица в тази тематична област е offers . Той съхранява записи на купони за отстъпка и свързаните с тях подробности. Обяснихме модела на данни зад оферти, сделки и отстъпки в по-ранна статия. Тази таблица се основава на същата теория и всички колони трябва да се обясняват сами.

Клиент

Когато мислим за приложение за паркиране, обикновено мислим за тези три елемента:

Клиенти – Това включва уникален идентификационен номер на клиента и основни подробности за потребителите на приложението, като тяхното име и телефонен номер. Също така би било добре да имате техния адрес за фактуриране.
Превозни средства – Един човек може да има няколко коли, така че трябва да имаме възможност за връзка един към много между потребител на приложението и неговите превозни средства. Очевидно ще ни е необходим начин да идентифицираме превозните средства, като например по техния регистрационен номер.
Начини на плащане – Тъй като това приложение позволява на клиентите да резервират място за паркиране и да плащат за него, имаме нужда от начин за съхраняване на начините на плащане. Още веднъж трябва да има начин да имате няколко начина на плащане на потребител.

Този модел има по една таблица за всеки от тези обекти. customer_id атрибутът е посочен в vehicle и payment_method маси; той свързва потребителите с превозни средства и методи на плащане.

Резервация за паркинг

Тази тематична област съдържа само две таблици. От двете, таблицата „parking_one_time_reservation“ съхранява подробности за резервацията. Някои от колоните му се разбират сами; другите са:

start_timestamp – Датата и часът, когато започва периодът на резервация.
pay_for_min_hr – Задържа „N“, ако резервацията е за определен брой часове (например от 9:00 до обяд). В противен случай този атрибут ще има „Y“.
booking_for_hr – Броят на часовете на една резервация. Това е поле с нула; ще има стойност само когато pay_for_min_hr е настроен на „N“. В примера по-горе той ще бъде зададен на „3“ за трите часа, които изтичат между 9:00 и обяд.
basic_parking_cost – Основната цена за паркиране, в местна валута.
offer_code – Код на талон, ако има такъв. Тъй като прилагането на код на офертата не е задължително и зависи от наличността, тази колона може да бъде нула.
net_cost – Действителната сума, която клиентите плащат при плащане (когато напуснат обекта).
is_paid – Платени ли са такси за паркиране. Това става важна колона, когато е разрешено повторното влизане на същия паркинг. В такива случаи плащанията обикновено се извършват при първото плащане (т.е. първия път, когато колата напусне партидата).

parking_monthly_pass таблицата записва информация за всички месечни карти, издадени на клиенти чрез това приложение. Месечните карти могат да бъдат закупени по всяко време, дори за бъдещи дати. Така че имаме две отделни колони, purchase_date и start_date , които позволяват на потребителите на приложението да купуват пропуски, които са валидни в бъдеще. Останалите колони се обясняват сами.

Какво друго можем да добавим към модела на данните на приложението за паркиране?

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

Какви допълнителни промени са необходими на този модел на данни, за да поддържа напълно оборудвани паркинги? Моля, кажете ни вашите мисли в секцията за коментари.