Changes between Version 3 and Version 4 of RelationalModel

Timestamp:

04/21/26 17:44:24 (13 days ago)

Author:

231186

Comment:

--

RelationalModel

@@ -2 +2 @@
 == Relational diagram ==
 [[Image("STS Delivery.svg")]]
+
+I Сегмент на моделот: Корисничка хиерархија и Лојалност
+Вклучени ентитети: User, Customer, Driver, LoyalCustomer.
+
+Како е моделиран: Моделот користи централизирана табела User за основните информации (име, е-маил, контакт), која потоа се специјализира преку релации 1-на-1 во Customer и Driver. Дополнително, за најредовните купувачи е изведен ентитетот LoyalCustomer.
+
+Зошто е моделиран на овој начин:
+
+Специјализација на улоги: Наместо сите колони да се во една табела, овој пристап овозможува јасно разграничување. Доставувачите имаат специфични податоци (како број на лиценца), додека купувачите имаат историја на лојалност.
+
+Систем за наградување: Ентитетот LoyalCustomer овозможува следење на поени и родендени независно од основниот кориснички профил, што го олеснува креирањето на маркетинг автоматизации за попусти.
+
+II Сегмент на моделот: Логистика и Географска структура
+Вклучени ентитети: City, DeliveryZone, Address, Vehicle, VehicleType.
+
+Како е моделиран: Географијата е нормализирана во три нивоа: Град -> Зона -> Адреса. Логистиката за транспорт е одвоена преку Vehicle кој е дефиниран според VehicleType.
+
+Зошто е моделиран на овој начин:
+
+Оптимизација на достава: Со поделбата на градот на зони (DeliveryZone), системот може прецизно да пресметува цена за достава и да доделува доставувачи кои се активни само во таа специфична област.
+
+Управување со флота: Одвојувањето на возилата овозможува апликацијата да знае дали одредена нарачка (на пр. кабаста нарачка од маркет) бара автомобил или може да се достави со велосипед.
+
+III Сегмент на моделот: Бизнис објекти и Каталог на производи
+Вклучени ентитети: Store, StoreType, StoreInstance, Product, Promotion.
+
+Како е моделиран: Продавниците се дефинирани како генерален концепт (Store), но функционираат преку конкретни физички локации (StoreInstance). Секоја продавница поседува свој каталог на производи и активни промоции.
+
+Зошто е моделиран на овој начин:
+
+Поддршка за франшизи: Овој модел овозможува еден бренд (на пр. специфичен ланец маркети) да има една заедничка листа на производи, но да ги продава преку десет различни локации низ градот, секоја со сопствен телефон и адреса.
+
+Динамично ценообразување: Промоциите се врзани директно за продавниците, овозможувајќи автоматско пресметување на попусти во кошничката пред да се финализира нарачката.
+
+IV Сегмент на моделот: Нарачки, Трансакции и Оценување
+Вклучени ентитети: Order, OrderItem, Payment, Review, Products_review, Delivery_review.
+
+Како е моделиран: Нарачката функционира како централен ентитет кој ги поврзува купувачот, доставувачот, продавницата и зоната. По наплатата преку Payment, системот овозможува разгрането оценување преку Review кое се дели на специфични рецензии за продуктот и за доставата.
+
+Зошто е моделиран на овој начин:
+
+Детална евиденција: OrderItem овозможува следење на повеќе производи со различна количина во рамките на една иста нарачка.
+
+Изолација на фидбек (Feedback): Професорот ни сугерираше да ги разделиме рецензиите (Products_review и Delivery_review). На овој начин, ако доставата била бавна, тоа нема да го расипе рејтингот на квалитетот на храната во продавницата, и обратно – секој ентитет добива реална оцена за својот дел од услугата.
+
+V Сегмент на моделот: Интегритет и Финансиски текови
+Вклучени ентитети: Payment_method, Payment.
+
+Како е моделиран: Начините на плаќање се издвоени во посебна шифрарник табела, а секое плаќање е врзано со конкретна нарачка и временски печат.
+
+Зошто е моделиран на овој начин:
+
+Ревизија и безбедност: Одвојувањето на плаќањата овозможува лесно генерирање на дневни извештаи за промет и следење на статусот на трансакциите (на пр. дали е платено или е во процес), независно од тоа дали нарачката е веќе доставена или е сè уште во подготовка.