| | 6 | |
| | 7 | |
| | 8 | ==Дополнителен опис |
| | 9 | |
| | 10 | Во овој модел, клучните ентитети се структурирани на начин што овозможува прецизно и систематско следење на инфраструктурата и возниот ред. |
| | 11 | |
| | 12 | 1. Специјализација на кориснички улоги |
| | 13 | Ентитетот Person претставува основа на моделот и преку парцијална специјализација се разгранува на Passenger и Employee. |
| | 14 | |
| | 15 | Табелата Employee содржи дополнителни атрибути како position и salary. Особено важно е што надворешниот клуч во сите поврзани табели (како Train Trip или Employee_performs_Maintenance) е композитен и се состои од employee_id и PersonEMBG. На овој начин се обезбедува конзистентност на податоците и јасна поврзаност со конкретното физичко лице. |
| | 16 | |
| | 17 | 2. Хиерархија на инфраструктурата (Route, Segment и Platform) |
| | 18 | Моделот нуди детализиран приказ на физичката патека по која се движат возовите. |
| | 19 | |
| | 20 | Route_Segment е спојна табела која дефинира кои физички делови (Segment) ја сочинуваат една линија (Route). Атрибутот sequence_number има клучна улога, бидејќи го утврдува редоследот на движење по сегментите. |
| | 21 | |
| | 22 | Постои и логичко ограничување поврзано со атрибутот is_station_stop во Route_Segment: доколку овој атрибут е поставен на „true“, задолжително мора да постои валидна вредност за Stationstation_id, што означува дека сегментот завршува на станица каде што возот застанува за прием на патници. Во спротивно, сегментот се третира како транзитен (junction) без патничка функција. |
| | 23 | |
| | 24 | 3. Реализација на возниот ред (Train Trip) |
| | 25 | Табелата Train Trip ја претставува конкретната реализација на едно патување. |
| | 26 | |
| | 27 | Таа е поставена како централна точка во моделот, каде што се поврзуваат линиите (Route), возовите (Train) и вработените (Employee). |
| | 28 | |
| | 29 | Во однос на денормализацијата, атрибутот delay_minutes се ажурира во реално време. Иако доцнењето може да се пресмета преку споредба на departure_time со планираниот возен ред во Schedule, овој атрибут е експлицитно зачуван во Train Trip со цел да се оптимизираат аналитичките пребарувања, особено за корисници кои проверуваат тековни доцнења. |
| | 30 | |
| | 31 | 4. Одржување и безбедност |
| | 32 | Системот опфаќа две клучни many-to-many (M:N) релации поврзани со одржувањето: |
| | 33 | |
| | 34 | Employee_performs_Maintenance — овозможува следење кои вработени (техничари) учествувале во одреден сервисен налог (Maintenance). |
| | 35 | Train_undergoes_Maintenance — го поврзува секој налог за одржување со конкретен воз. |
| | 36 | |
| | 37 | Постои важно логичко правило: иако моделот дозволува еден налог за одржување да биде поврзан со повеќе возови, во пракса точно еден од клучевите (Traintrain_id или Segmentsegment_id) треба да биде non-null. Ова зависи од тоа дали одржувањето се врши врз воз (мобилен ресурс) или врз инфраструктура (сегмент/шина). Ова правило дополнително се гарантира преку CHECK ограничувања во DDL скриптата. |
| | 38 | |
| | 39 | 5. Резервации и плаќања |
| | 40 | Табелата Reservation претставува привремен запис за намерата на патникот да резервира билет. Таа го содржи атрибутот expiry_time — доколку плаќањето не се изврши во зададениот временски рок (на пример, 15 минути), резервацијата автоматски се смета за невалидна. |
| | 41 | |
| | 42 | Само по успешно внесување запис во табелата Payment, се генерира финален Ticket. Овој билет е поврзан со конкретно седиште (seat_number) и вагон (carriage_number) во соодветниот воз за даденото патување. |
| | 43 | |
