Интегриран модел на транспортни данни

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

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

Идея

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

Нека обясним това с два примера.

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

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

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

Имайки предвид това, нека преминем към нашия модел.

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

Моделът се състои от две предметни области:

• Cities & companies
• Tickets

Ще ги опишем в реда, в който са изброени.

Градове и компании

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

country таблицата съдържа списък с УНИКАЛНИ country_name стойности. Тази таблица се използва само като справка в city маса. Въпреки че можем да очакваме, че нашият модел ще обхване транспорта само в една страна, ние искаме да имаме опцията да включваме няколко държави. За всеки град ще съхраняваме УНИКАЛНАТА комбинация city_name – country_id .

По-малките градове вероятно ще имат само една зона, докато по-големите градове ще имат няколко зони. Списък с всички възможни зони се съхранява в zone маса. За всяка зона ще съхраняваме нейното zone_name и препратка към съответния град. Тази двойка формира алтернативния ключ на тази таблица.

Можем да очакваме, че нашата система ще съхранява информация за множество транспортни компании. Фирмите ще издават собствени билети, но също така ще могат да издават билети съвместно с други компании. За всяка company , ще съхраняваме УНИКАЛНАТА комбинация от company_name и city_id където се намира. Всяка необходима допълнителна информация може да бъде съхранена в текстовите details поле.

Последното нещо, което трябва да определим, е формата на транспорт, която всяка компания предоставя. Някои очаквани стойности са „автобус“, „трамвай“, „подземно“ и „железопътна линия“. За всяка стойност в transport_form таблица, ще съхраняваме УНИКАЛНО име на формуляр.

• zone_id – Препраща към zone таблица и обозначава района, където тази форма на транспорт се предоставя от тази компания.
• company_id – Препраща към company предоставяне на тази услуга в тази зона.
• transport_form_id – Препраща към transport_form таблица и обозначава вида на предоставяната услуга.
• date_from и date_to – Периодът, през който тази услуга е била предоставена от тази компания. Обърнете внимание, че date_to може да съдържа стойност NULL, ако тази услуга все още е налична и/или няма очакван срок на валидност.
• details – Всички други подробности, в неструктуриран текстов формат.
• is_active – Ако тази услуга е активна (текуща) или не. Това е прост превключвател за включване/изключване, който можем да използваме в някои случаи вместо date_from – date_to интервал на сервизна дейност. Най-доброто използване на този атрибут би било да се опростят заявките, т.е. да се тества тази стойност, вместо да се тества интервалът от дати и да се „играе“ с NULL стойности.

Билети

Предишната предметна област беше само подготовка за основното нещо:билети. И това ще обхване тази тема.

Ние сме дефинирали компании, зони и транспортни форми, но нямаме никакви разпоредби за пътници и билети – ядрото на този модел. Ще приемем, че един билет може да се използва за една или повече зони, обхванати от една или повече компании.

Следователно, първо трябва да дефинираме всеки ticket_type . В тази таблица ще изброим всички възможни видове билети, продавани от компаниите в нашата база данни. За всеки тип ще съхраняваме следните стойности:

• type_name – Име, УНИКАЛНО обозначаващо този тип.
• valid_from и valid_to – Периодът, през който този тип билет е (или е бил) валиден. И двете полета са нулеви; стойност NULL означава, че няма начална (или крайна) дата, когато това е било валидно.
• details – Всички необходими подробности, в неструктуриран текстов формат.
• recurring – Флаг, обозначаващ дали този тип билет се повтаря (напр. годишен, месечен) или не.
• interval_month – Ако типът на билета се повтаря, този атрибут ще съдържа интервала в месеци, когато се повтаря (напр. „1“ за месечен билет, „12“ за годишен билет).

Сега сме готови да дефинираме зоните, обхванати от всеки тип билет. В service_included таблица, ще съхраняваме само УНИКАЛНАТА двойка ticket_type_id – service_available_id . Последният също така ще посочи компанията и зоната, където може да се използва този билет. Тази таблица ни позволява да дефинираме множество зони на билет; зони могат да принадлежат на различни компании. Тъй като това са предварително дефинирани типове билети, всеки тип билет ще има зоните, дефинирани тук (не за всеки отделен пътник).

Няма да съхраняваме твърде много данни за пътниците в този модел. За всеки passenger , ще съхраняваме само тяхното first_name , last_name , address , и препратка към града, в който живеят. Всички тези данни ще бъдат показани на билета.

Последната маса в нашия модел е ticket маса. Тук няма да се фокусираме върху билетите за еднократна употреба; по-скоро ще се справим с абонаментните и предплатените билети. Тези билети ще имат баланс, дата на валидност или и двете. Това може да се различава значително в зависимост от компанията и нейните правила. Ако няколко компании решат да издадат билет, можем да подкрепим това в тази таблица – ще знаем всички важни подробности. За всеки билет ще съхраняваме:

• serial_number – УНИКАЛНО обозначение за всеки билет. Това може да е комбинация от цифри и букви.
• ticket_type_id – Посочва типа на този билет.
• passenger_id – Позовава се на пътника, ако има такъв, който притежава този билет. В случай на предплатен билет може да няма собственик.
• valid_from и valid_to – Означава периода, през който този билет е валиден. NULL стойностите означават, че няма долна или горна граница.
• credits – Кредитите (като числова стойност), налични в момента на този билет. Ако това е предплатен билет, можем да предположим, че пътниците ще закупят допълнителни кредити за билета. Ако билетът е валиден през целия месец (или друг период от време) без никакви ограничения за използване, тази стойност може да е NULL.

Подобрения на интегрирания модел на транспортни данни

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

• Зоните са твърде опростени; трябва да можем да ги дефинираме по-динамично.
• Не покриваме линии (напр. автобусни линии). Ами ако минат от една зона в друга и т.н.?
• Не съхраняваме история на използване на билети.
• Няма регистрация за компании и пътници.

Всичко това би довело до факта, че ще ни липсват важни данни и не можем да направим по-задълбочен анализ. И така, какво мислите? От какво се нуждае този модел? Какво бихте добавили или премахнали? Споделете вашите идеи в коментарите.