= Relational Model

== Relational diagram

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

[[Image(RelationalModel.jpg)]]

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

[[Image(RelationalModel2.jpg)]]


== 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 следење.