Relational Model

Relational diagram

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

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

---

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 би ја усложнило табелата и би ја намалило јасноста на моделот.

---