Database
 sql >> база данни >  >> RDS >> Database

Изграждане на модел на данни за система за управление на паркинг

Изследванията показват, че автомобилите остават паркирани през 95% от живота си, което предполага, че системите за управление на паркинга трябва да бъдат интелигентни, ефективни и здрави. В тази статия ще изградим модел на данни за такава система.

Въведение

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

  1. Как са структурирани паркингите?

    Типичният паркинг се състои от един или повече блокове, които са допълнително разделени на етажи. Всеки етаж съдържа множество крила, които помагат на шофьорите да се ориентират и да запомнят своите места за паркиране. Те обикновено са обозначени с букви, като "A", "B", "C" и така нататък. Подът обикновено има ограничение за височина, което ограничава достъпа на определени превозни средства на паркинга. Освен това един етаж съдържа няколко уникално номерирани места за паркиране. Някои от тези слотове са запазени за хора с увреждания; други могат да бъдат резервирани от редовни посетители на определена цена.

  2. Как работят паркингите?

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

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

    На редовните клиенти обикновено се дават карти/стикери, които да поставят някъде видимо на таблото или предното стъкло, така че ръководството на паркинга лесно да определи, че клиентите не нарушават никакви правила за паркиране. За разлика от случайните посетители, на редовните клиенти никога не се издават ежедневно фишове за паркиране. Паркингът обикновено запазва цял блок или етаж за своите редовни посетители, за да гарантира, че винаги имат места за паркиране. Редовните клиенти могат също да резервират слотове за себе си, за да могат да паркират автомобилите си в едни и същи определени места всеки ден, но това обикновено струва допълнително.

    Тези, които правят резервации за дистанционно паркиране, обикновено могат да използват само определените си слотове за ограничен времеви прозорец от няколко часа, след което слотове се освобождават. Когато тези посетители влязат на паркинга, те трябва да паркират в запазените си места. Неустойка се начислява на клиенти, които не напуснат паркинга след изтичане на времето им, но клиентите със сигурност могат да напуснат преди изтичането на резервациите им. Някои паркинги имат фиксиран минимален времеви прозорец (например клиентът може да се наложи да резервира място за три часа, дори ако ще го няма само за един час).

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

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




Имайки предвид тези изисквания, нека да продължим и да създадем нашия модел на данни. Този път ще работим с три основни раздела:

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

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

Раздел 1:Паркинг

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

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

parking_lot – съхранява основна информация за паркинг. Колоните за тази таблица са:

  • id – първичният ключ за тази таблица. Той присвоява уникален номер на всеки паркинг.
  • number_of_blocks – проследява броя на блоковете на паркинг.
  • is_slot_available – означава дали паркингът в момента има свободни места.
  • address – съхранява пълния адрес на паркинг.
  • zip – съхранява пощенския код на паркинг, което позволява на клиентите по-лесно да търсят налични паркинги в определен район, като просто потърсят желания от тях пощенски код.
  • is_reentry_allowed – означава дали клиентът може да излезе от паркинга и да влезе отново със същия паркинг фиш. Имайте предвид, че много паркинги обикновено не позволяват на клиентите да правят това. На такива паркинги трябва да купувате нов фиш всеки път, когато влезете отново в даден ден.
  • operating_company_name – съхранява името на фирмата, която оперира паркинга.
  • is_valet_parking_available – означава дали паркингът предлага услуги за паркиране с камериер.

block – паркингът е разделен на един или повече блокове. Тази таблица съхранява информация за всеки блок от паркинг. Колоните за тази таблица са:– паркингът е разделен на един или повече блока. Тази таблица съхранява информация за всеки блок от паркинг. Колоните за тази таблица са:

  • id – първичният ключ за тази таблица.
  • parking_lot_id – посочената колона от parking_lot таблица, която идентифицира паркинга, към който принадлежи блокът.
  • block_code – съхранява кода, свързан с този блок. На блоковете обикновено се дават уникални идентифициращи кодове, като „A“, „B“, „C“, „11“, „22“, „33“ и т.н.
  • number_of_floors – съхранява броя на етажите в този блок. Числото „1“ показва, че това е приземен блок без етажи.
  • is_block_full – означава дали блокът в момента е пълен.

floor – при многоетажни паркинги блоковете могат да имат повече от един етаж. Тази таблица обаче може да бъде препращана и от блокове на земно ниво. Колоните за тази таблица са:

  • id – първичният ключ за тази таблица.
  • block_id – идентифицира блока, към който принадлежи етаж.
  • floor_number – представлява номера на етаж (където 1 =нивото на земята).
  • max_height_in_inch – в многоетажен паркинг всеки етаж има ограничение по височина. Тази колона съхранява максимално допустимата височина за превозни средства на пода.
  • number_of_wings – етажът е допълнително разделен на крила, които помагат на клиентите да запомнят къде са паркирали. Тази колона съхранява броя на крилата, които съществуват на пода.
  • number_of_slots – съхранява броя на слотовете, които съществуват на етаж.
  • is_covered – идентифицира дали пода е покрит. Последният етаж на многоетажен паркинг или приземен паркинг никога няма да бъде покрит.
  • is_accessible – показва дали подът е лесно достъпен, особено за хора с увреждания. Ако многоетажен парцел има работещ асансьор, всеки от етажите му се счита за достъпен.
  • is_floor_full – показва дали един етаж е напълно зает.
  • is_reserved_reg_cust – показва дали етажът е строго запазен за редовни клиенти.

parking_slot – тази таблица съхранява цялата информация за местата за паркиране на паркинг. Колоните за тази таблица са:

  • id – първичен ключ за тази таблица.
  • floor_id – идентифицира етажа, към който принадлежи слотът.
  • slot_number – съхранява уникалния идентификатор на слота на определен етаж.
  • wing_code – идентифицира крилото, в което се намира слот.

Раздел 2:Клиенти

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

customer – съхранява всички подходящи подробности за всички видове клиенти, които могат да посетят паркинга (редовни, еднократни и предплатени). Колоните за тази таблица са:

  • id – уникален идентификатор за клиента.
  • vehicle_number – съхранява регистрационния номер на автомобила на клиента.
  • registration_date – съхранява датата, когато автомобилът е регистриран за първи път на паркинга.
  • is_regular_customer – показва дали клиентът има редовен пропуск. Ако колоната съхранява стойност true, тогава трябва да съществува валиден запис в regular_pass маса. След като пропускът изтече и клиентът все още не го е подновен, стойността в тази колона се актуализира на false.
  • contact_number – съхранява контактния номер на клиента. Тъй като някои хора не са склонни да споделят номерата си за връзка с паркингите, ние запазихме тази колона за нула.

regular_pass – съхранява информация за редовни пропуски, които се издават на клиенти. Колоните за тази таблица са:

  • id – първичен ключ за тази таблица.
  • customer_id – реферирана колона от таблицата на клиентите.
  • purchase_date – съхранява датата, на която е закупен пропускът.
  • start_date – съхранява датата, на която пропускът ще се счита за валиден, което може да не е непременно датата на покупката, тъй като някои клиенти купуват пропуски предварително.
  • duration_in_days – съхранява броя на дните, за които е валиден пропускът. Месечната карта обикновено остава валидна 30 дни.
  • cost – съхранява цената в местна валута, която клиентът трябва да заплати, за да закупи пропуск.

Раздел 3:Резервации

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

parking_slot_reservation – поддържа подробности за резервацията. Колоните за тази таблица са:

  • id – присвоява уникален референтен номер на индивидуална заявка за резервация.
  • customer_id – препратка към идентификатора на клиента, който прави тази резервация.
  • start_timestamp – съхранява очакваната дата и час на пристигането на клиента.
  • duration_in_minutes – съхранява продължителността, за която е направена резервацията.
  • booking_date – съхранява датата, на която е направена резервацията.
  • parking_slot_id – вътрешна колона, която определя място за паркиране на клиент, след като заявката му бъде уловена и плащането е извършено.

parking_slip – съхранява информация за времето на влизане и излизане на клиента, както и всички съответни такси. Създадохме тази таблица за паркинги, които позволяват множество влизания и излизания под една и съща резервация. Колоните за тази таблица са:

  • id – първичният ключ за тази таблица.
  • parking_slot_reservation_id – реферирана колона, която идентифицира свързаната заявка за резервация.
  • actual_entry_time – съхранява дата на пристигане и времеви печат на клиента.
  • actual_exit_time – съхранява датата на заминаване (излизане) на клиента и час.
  • basic_cost – съхранява основната цена на резервацията.
  • penalty – съхранява стойност 0 по подразбиране. Ако клиент забави излизането си, ще бъде наложена наказателна такса и стойността в тази колона ще бъде актуализирана.
  • total_cost – тази колона просто добавя стойностите на basic_cost и наказателни колони.
  • is_paid – повторното влизане обикновено е разрешено само когато клиентът е платил таксата си за паркиране. Тази колона показва дали това плащане е извършено.

Заключение

В тази статия представихме преглед на модел на данни за система за управление на паркинг. Има много приложения, които помагат на потребителите да намират места за паркиране чрез извличане, обработка и компилиране на данни (като наличност и разходи) за паркинги в определена близост. Това е особено полезно за хора, посещаващи големи градове като Ню Йорк, Лос Анджелис и други, където намирането на паркинг може да бъде кошмар, ако не планирате внимателно посещението си. Такива приложения разчитат на добре проектирани модели на данни и API на бази данни за извличане на тази информация.

В следващата ни статия ще трансформираме нашия текущ модел на данни в решение за система за паркиране в реално време. Чувствайте се свободни да публикувате вашите мисли, отзиви и препоръки в секцията за коментари по-долу.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Цели на редове, част 2:Полусъединяване

  2. Формат на датата на SQL:Как да се справяте с него по интелигентен начин

  3. Какво е пролетна интеграция?

  4. Анатомия на ролята в разработката на софтуер:специалист по данни

  5. Обосновка на ВМЕСТО тригери – част 1