Релационен модел

ЕР Дијаграм

Дополнителен опис

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

1. Специјализација на кориснички улоги Ентитетот Person претставува основа на моделот и преку парцијална специјализација се разгранува на Passenger и Employee.

Табелата Employee содржи дополнителни атрибути како position и salary. Особено важно е што надворешниот клуч во сите поврзани табели (како Train Trip или Employee_performs_Maintenance) е композитен и се состои од employee_id и PersonEMBG. На овој начин се обезбедува конзистентност на податоците и јасна поврзаност со конкретното физичко лице.

2. Хиерархија на инфраструктурата (Route, Segment и Platform) Моделот нуди детализиран приказ на физичката патека по која се движат возовите.

Route_Segment е спојна табела која дефинира кои физички делови (Segment) ја сочинуваат една линија (Route). Атрибутот sequence_number има клучна улога, бидејќи го утврдува редоследот на движење по сегментите.

Постои и логичко ограничување поврзано со атрибутот is_station_stop во Route_Segment: доколку овој атрибут е поставен на „true“, задолжително мора да постои валидна вредност за Stationstation_id, што означува дека сегментот завршува на станица каде што возот застанува за прием на патници. Во спротивно, сегментот се третира како транзитен (junction) без патничка функција.

3. Реализација на возниот ред (Train Trip) Табелата Train Trip ја претставува конкретната реализација на едно патување.

Таа е поставена како централна точка во моделот, каде што се поврзуваат линиите (Route), возовите (Train) и вработените (Employee).

Во однос на денормализацијата, атрибутот delay_minutes се ажурира во реално време. Иако доцнењето може да се пресмета преку споредба на departure_time со планираниот возен ред во Schedule, овој атрибут е експлицитно зачуван во Train Trip со цел да се оптимизираат аналитичките пребарувања, особено за корисници кои проверуваат тековни доцнења.

4. Одржување и безбедност Системот опфаќа две клучни many-to-many (M:N) релации поврзани со одржувањето:

Employee_performs_Maintenance — овозможува следење кои вработени (техничари) учествувале во одреден сервисен налог (Maintenance). Train_undergoes_Maintenance — го поврзува секој налог за одржување со конкретен воз.

Постои важно логичко правило: иако моделот дозволува еден налог за одржување да биде поврзан со повеќе возови, во пракса точно еден од клучевите (Traintrain_id или Segmentsegment_id) треба да биде non-null. Ова зависи од тоа дали одржувањето се врши врз воз (мобилен ресурс) или врз инфраструктура (сегмент/шина). Ова правило дополнително се гарантира преку CHECK ограничувања во DDL скриптата.

5. Резервации и плаќања Табелата Reservation претставува привремен запис за намерата на патникот да резервира билет. Таа го содржи атрибутот expiry_time — доколку плаќањето не се изврши во зададениот временски рок (на пример, 15 минути), резервацијата автоматски се смета за невалидна.

Само по успешно внесување запис во табелата Payment, се генерира финален Ticket. Овој билет е поврзан со конкретно седиште (seat_number) и вагон (carriage_number) во соодветниот воз за даденото патување.