Changes between Version 10 and Version 11 of Normalization

Timestamp:

09/23/25 03:08:13 (5 weeks ago)

Author:

215010

Comment:

--

Normalization

@@ -193 +193 @@
 3NF статус: секоја FD X -> A во Fc е локален на една од креираните релации (зачувување на зависноста). Бидејќи ги отстранивме атрибутите што предизвикуваа транзитивни ФЗ од нивните релации што содржат (на пр., не го задржавме price_per_night во Reservation), нема преостанати транзитивни зависности во релациите. Значи, сите релации се во 3NF.
 
-==== 
+==== BCNF правило: за секој FD X -> A во релацијата Ri, X мора да биде суперклуч на Ri.
+
+Ја проверуваме секоја релација произведена во 3NF:
+
+Users(user_id, ...) — FD лево од user_id е PK ⇒ BCNF.
+
+Hotel_Building(building_id, ...) — building_id е PK ⇒ BCNF.
+
+Room(room_number, building_id, ...) — (room_number, building_id) е сложен PK ⇒ BCNF.
+
+Staff(user_id, building_id) — user_id е PK ⇒ BCNF.
+
+Reservation(reservation_id, ...) — reservation_id е PK ⇒ BCNF.
+
+Service(service_id, ...) — service_id е PK ⇒ BCNF.
+
+Payment(reservation_id PK, ...) — reservation_id е PK ⇒ BCNF.
+
+Бидејќи секоја детерминанта во секоја релација е примарен клуч на релацијата (или суперклуч), секоја релација е во BCNF под овие избори на клучеви.
+
+Забелешка (компромис): BCNF декомпозицијата понекогаш може да ве принуди да изберете клуч кој не е најзгоден (на пр., ако Payment го воспостави p_id како PK, но reservation_id -> p_id постои, Payment би го прекршил BCNF — решивме со тоа што reservation_id го направивме PK за да го задоволиме BCNF без понатамошно декомпозиција). Ако претпочитате p_id како PK за да дозволите повеќекратни плаќања по резервација (1:N), тогаш p_id би бил детерминанта во Payment, а BCNF исто така важи.
+