Relational Model

Relational diagram

• Дијаграмот е прикажан во поголема резолуција со цел јасно да се прикажат сите ентитети и нивните релации.

• Тука е иститиот дијаграм, но е прикажан во помала големина.

Descriptive documentation and argumentation

Моделот претставува систем за управување со јавен транспорт кој опфаќа повеќе функционални целини како што се управување со патници, билети, линии, возила, персонал, доцнења и плаќања. Поради комплексноста на системот, одредени сегменти од моделот се моделирани со дополнителни посредни табели или со одвојување на ентитети со цел да се обезбеди подобра нормализација, флексибилност и можност за идно проширување. Во продолжение се објаснети сегментите кои се најмалку очигледни и бараат дополнителнo објаснување.

• Route – Stops – Route_Stop: Сегментот за линии и постојки е моделиран преку табелите Route, Stops и Route_Stop. Наместо постојките директно да се чуваат во Route, воведена е посредната табела Route_Stop бидејќи една линија има повеќе постојки, а една постојка може да припаѓа на повеќе линии. Route_Stop дополнително овозможува чување на: редослед на постојките изминато растојание и timepoint. Овој пристап овозможува флексибилно дефинирање на линии и избегнување дуплирање на податоци, што е важно за транспортен систем каде постојките често се користат во повеќе рути.

• Trip – Stop_Time – Transfer: Trip сегментот е моделиран преку Trip, Stop_Time и Transfer табели. Trip ја претставува конкретната реализација на линија, додека Stop_Time ги дефинира временските интервали за секоја постојка во рамки на едно возење. Ова решение е избрано бидејќи: една линија има повеќе возења дневно, секое возење има различни времиња и потребно е следење на распоред. Transfer табелата е додадена за да се моделираат трансфери помеѓу линии, што овозможува: преседнување меѓу линии, минимално време за трансфер и подобра организација на транспортниот систем.

• Vehicle – Vehicle_Type – Logs: Возилата се моделирани преку Vehicle и Vehicle_Type, додека дополнително се користат лог табели: Vehicle_log, Fuel_log, Capacity_log и Delay_log. Vehicle_Type е одвоена табела за да се избегне повторување на типови на возила. Log табелите се одвоени бидејќи овие податоци се менуваат често и претставуваат историја. Овој сегмент овозможува: следење на статус на возило, следење на гориво, следење на капацитет, следење на доцнења.

• Passenger – Ticket – Payment – Subscription: Сегментот за патници е моделиран преку: Passenger, Ticket, Payment, Subscription_pass, Ticket_type, Fare_rule. Овој сегмент е комплексен бидејќи системот поддржува различни типови билети и плаќања. Passenger е одвоен од Ticket бидејќи еден патник може да има повеќе билети, а Payment е одвоен за да се овозможи повеќе плаќања. Subscription_pass е воведен за: месечни карти, годишни карти и претплатнички систем. Ова моделирање овозможува поголема флексибилност при управување со билети.

• Employee – Driver – Conductor – Schedule: Персоналот е моделиран преку: Employee, Driver, Conductor, Shift, Driver_schedule, Conductor_schedule. Schedule табелите се користат за управување со смени. Овој сегмент овозможува: управување со работни смени, повеќе улоги за вработени и подобра организација на персонал.

• Fare – Zone – Ticket_Type: Сегментот за цени е моделиран преку табелите Fare, Zone и Ticket_Type. Наместо цената да се чува директно во Ticket, воведена е табелата Fare бидејќи цената зависи од повеќе фактори како зона, тип на билет и валидност. Овој пристап овозможува една иста цена да се користи за повеќе билети и полесно ажурирање на тарифите. Овој сегмент овозможува: различни тарифи по зона, различни типови билети (еднократни, дневни, месечни), временска валидност на цените, флексибилно менување на тарифниот систем.

• Agency – Route: Сегментот Agency – Route е моделиран така што една агенција може да управува со повеќе линии. Route содржи foreign клуч кон Agency, со што се овозможува повеќе транспортни оператори во системот. Овој пристап овозможува: повеќе транспортни компании, поделба на линии по оператор, полесно проширување на системот. Ова е корисно во случаи кога јавниот транспорт го управуваат повеќе компании.

• Delay – Notification – Trip: Сегментот за доцнења е моделиран преку табелите Delay, Notification и Trip. Delay е поврзан со Trip бидејќи доцнењето се однесува на конкретно возење, а не на линијата генерално. Notification табелата овозможува испраќање известувања до патници кога ќе се појави доцнење. Овој сегмент е одвоен бидејќи: едно возење може да има повеќе доцнења, едно доцнење може да генерира повеќе известувања, потребно е следење на статусот. Овој сегмент овозможува: известување за доцнења, следење на проблеми и подобрување на корисничко искуство.

• Shape – Shape_Point – Route: Сегментот Shape е воведен за да се моделира географската патека на линијата. Наместо координатите да се чуваат директно во Route, тие се чуваат во Shape и Shape_Point табели. Овој пристап овозможува: GPS координати за линијата, мапирање на рутите, визуелизација на карта и повторно користење на ист shape за повеќе линии. Ова е важно за системи кои користат мапи и GPS следење.