= Relational Model =

=== Relational diagram ===

Ова е деталниот релационен модел за системот GEOCAB (Taxi Services Application). Моделот е изработен во Visual Paradigm (desktop верзија) и содржи 18 табели кои ја опфаќаат комплетната логика на бизнис процесот.

Дијаграмот е експортиран како SVG фајл '''RelationalModel-ProjectCode.svg''' и е прикачен на оваа страница. Исто така, прикачен е и оригиналниот Visual Paradigm модел (RelationalModel-ProjectCode.vpp).

[[Image(RelationalModel-ProjectCode.svg, width=800)]]

----

=== Descriptive documentation and argumentation ===

Клучни сегменти од моделот кои не се целосно очигледни, заедно со аргументи за донесените дизајнерски одлуки:

 * '''Сегмент: Rides и Locations'''
Табелата `Rides` користи два Foreing Keys (`pickup_location_id` и `dropoff_location_id`) кои реферираат кон `Locations`. Овој пристап овозможува повторна употреба на истите локации во повеќе возења и избегнува дуплирање на адресни податоци. Дополнително, `Locations` содржи и географски координати што овозможува идни проширувања како GPS следење и оптимизација на рути. Чувањето на адресните податоци директно во `Rides` би довело до редундантност и потешко одржување.

 * '''Сегмент: Status (централизација на статуси)'''
Табелата `Status` е поврзана со повеќе ентитети (`Users`, `Drivers`, `Admins`, `Rides`, `Payments`, `Notifications`). Наместо статусите да се чуваат како текст во секоја табела, тие се централизирани. Ова обезбедува конзистентност и олеснува идни промени или додавање нови статуси. Алтернативен пристап со текстуални вредности во секоја табела би довел до неконзистентни податоци и дуплирање.

 * '''Сегмент: Vehicles и ownership модел'''
Возилата се моделирани преку повеќе поврзани табели (`Vehicles_model`, `Vehicle_types`, `Vehicle_ownership`) со цел да се постигне нормализација и флексибилност. Табелата `Drivers_Vehicle_ownership` имплементира many-to-many релација, овозможувајќи еден возач да користи повеќе возила и обратно. Доколку оваа врска беше имплементирана директно во `Drivers` или `Vehicle_ownership`, би се изгубила флексибилноста и би се ограничиле можните сценарија.

 * '''Сегмент: Pricing_rules'''
Цените се дефинирани во табелата `Pricing_rules` и се поврзани со `Vehicle_types`, наместо да се чуваат директно во `Rides`. Ова овозможува централизирано управување со цените и нивно лесно ажурирање. Доколку цените беа зачувани во `Rides`, секоја промена на ценовна политика би барала сложени ажурирања и би постоел ризик од неконзистентност.

 * '''Сегмент: Active_drivers (динамички податоци)'''
Табелата `Active_drivers` ги содржи само динамичките податоци како моментална локација, достапност и работно време. Оваа поделба е направена со цел да се подобрат перформансите и да се избегне често ажурирање на табелата `Drivers`. Чувањето на овие податоци во `Drivers` би довело до непотребно оптоварување и намалена ефикасност.

 * '''Сегмент: Payments и Payment_methods'''
Табелата `Payments` е поврзана со `Rides` и `Payment_methods`, што овозможува поддршка за различни начини на плаќање. Оваа поделба овозможува флексибилност и проширување без промена на основната логика. Доколку типот на плаќање беше директно запишан во `Payments` како текст, би се намалила конзистентноста и би се отежнало додавањето нови методи.

 * '''Сегмент: Notifications и Messages'''
Системот за нотификации е моделиран преку табелите `Notifications` и `Messages`. `Messages` ги содржи текстовите, додека `Notifications` ги поврзува со конкретни корисници и возења. Ова овозможува повторна употреба на истите пораки и избегнува дуплирање. Доколку текстот се чуваше директно во `Notifications`, би се намалила флексибилноста.

 * '''Сегмент: Cancellations'''
Табелата `Cancellations` е издвоена од `Rides` за да се овозможи детално следење на откажувањата (кој откажал, причина, пенали). Овој пристап овозможува подобра анализа и извештаи. Вградувањето на овие податоци во `Rides` би ја усложнило табелата и би ја намалило јасноста на моделот.

----