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

ЕР Дијаграм

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

Резервација наспроти договор (RentalBooking, RentalAgreement)

Како е моделирано: Процесот на изнајмување е поделен во две посебни табели. RentalBooking ја следи резервацијата, поврзувајќи се со моделот на возилото (VehicleModel - не конкретен автомобил) и предложени датуми. RentalAgreement дејствува како финализиран договор, користејќи го booking_id како свој примарен клуч (agreement_id) за да спроведе строга врска 1:0-или-1, и се поврзува со конкретното возило (Vehicle - точниот број на шасија/VIN).

Зошто е моделирано на тој начин: Кога корисникот прави резервација онлајн, тој резервира категорија или модел (на пр. „VW Golf“), а не специфично физичко возило. Вистинското возило не се доделува додека корисникот физички не пристигне во филијалата. Раздвојувањето на овие ентитети му овозможува на системот лесно да се справи со корисници кои не се појавиле или откажани резервации (кои остануваат како записи во RentalBooking).

Финансиски податоци (Invoice, Transaction, Payment)

Како е моделирано: Финансиските податоци нормализирани низ три табели. Фактурата (Invoice) го дефинира вкупниот износ што се должи за одреден договор. Трансакцијата (Transaction) дејствува како главна книга, бележејќи ги парите што влегуваат или излегуваат (ENUM типови type_transaction како Депозит, Рефундирање, Казна) за таа фактура. Плаќањето (Payment) е наставка 1:1 на Transaction која ги чува податоците за начинот на плаќање (card_four_last, gateway_token).

Зошто е моделирано на тој начин: Едно изнајмување ретко вклучува само едно плаќање. Корисникот може да плати депозит, потоа конечната сметка и потенцијално казна по завршување на изнајмувањето за сообраќаен прекршок (TrafficViolation) или оштета (DamageReport). Со раздвојување на фактурата и трансакцијата, системот може да се прилагоди на делумни плаќања и рефундирања без да мора да се пресметува повторно или да се препишува оригиналниот запис на фактурата.

Одговорност за средства и сервисирање (InsurancePolicy, DamageReport, MaintenanceRecord)

Како е моделирано: Извештајот за штета (DamageReport) и полисата за осигурување (InsurancePolicy) се директно поврзани со договорот за изнајмување (RentalAgreement). Записот за сервисирање (MaintenanceRecord) е поврзан со возилото (Vehicle) и е авторизиран од менаџер, со евидентирани трошоци. И осигурувањето и сервисирањето се структурно поврзани со надворешна компанија (Company).

Зошто е моделирано на тој начин: Кога автомобилот е оштетен, трошок за поправка во DamageReport може вкрстено да се провери преку SQL со износот на покритие и типот на полиса во InsurancePolicy поврзани со истиот договор. Ова ѝ овозможува на апликацијата динамично да пресметува дали клиентот или осигурителната компанија плаќа за штетата.