Changes between Version 33 and Version 34 of Transactions

Timestamp:

02/10/26 18:02:35 (3 weeks ago)

Author:

222039

Comment:

--

Transactions

@@ -14 +14 @@
 Овие операции во пракса често се случуваат истовремено од различни корисници и без трансакции и locking  можат да доведат до неконзистентни резултати, „изгубени” промени или некоректен број на резервации.
 
+=== Core  transactional domain во airportdb
+
+'''booking''' – централната табела за резервации. Токму тука најчесто се појавуваат concurrency проблеми , бидејќи повеќе корисници можат истовремено да направат booking (или менуваат) на седишта за ист лет.
+
+[[Image(booking table image)]]
+
+'''flight''' - табела што го дефинира летот (од каде до каде, време на поаѓање и пристигнување, авиокомпанија и кој авион го извршува летот). Оваа табела е важна затоа што секоја резервација се врзува за конкретен лет, а промени во летот (на пример reschedule или промена на авион) имаат директно влијание врз валидноста на постоечките резервации.
+
+[[Image(flight table image)]]
+
+'''airplane''' - табела која го носи најважниот капацитетен параметар: capacity. Ова е основата за контролирање на overbooking. Дури и кога различни седишта се резервираат паралелно, системот мора да осигури дека вкупниот број резервации за летот не го надминува капацитетот на авионот кој го извршува летот.
+
+[[Image(airplane table image)]]
+
+Дополнително, постојат и '''поддржувачки табли''' кои се важни за реалистичност и traceability:
+
+* '''passenger''' и '''passengerdetails''' – иако не се директниот извор на concurrency проблемите, тие често учествуваат во транзакции (на пример при креирање нов патник + резервација во една атомска операција).
+* '''flight_log''' – корисна за audit (логирање на историја кој и кога направил промена). Во реални системи audit логиката е критична, особено при debugging на проблеми со конкурентност и при следење на промени во распоредите или атрибутите на летовите.
+
+