Changes between Version 6 and Version 7 of Normalization

Timestamp:

09/23/25 15:25:59 (2 days ago)

Author:

226030

Comment:

--

Normalization

@@ -246 +246 @@
 
 From the normalization steps, we obtain the relations R4 (Payments), R5 (Tables), R6 (Orders), R8 (OrderItems), R9 (Categories), and R10 (Products). These do not exactly match our initial database design. The difference comes from our goal to minimize NULL values and improve data organization. We chose to decompose the Orders table into TabOrders and OnlineOrders to separate dine-in and delivery-specific attributes. We also store inventory data in a separate Inventory table, where the primary key is product_id, because we give the user the option to store inventory information only for products they wish to track. This way, products without inventory data do not require NULL values in the main Products table.
+
+== Conclusion
+From our Normalization process we obtained the relations who all satisfy BCNF:
+
+R7(StaffRole), R8(FrontStaff), R9(Customer), R10(Reservation), R3(Table) R6 (FrontStaff_Managed_reservation) - Reservation Management 
+
+R3(Manager), R4(Shifts), R5(Employees), R6(Assigments) - Shift Managements 
+
+R4 (Payments), R5 (Tables), R6 (Orders), R8 (OrderItems), R9 (Categories), and R10 (Products) - Order Management
+
+The decomposition satisfies lossless join because every decomposition step was carried out on keys, ensuring that the intersection attribute is always a key in at least one of the projections. This guarantees that recombining the smaller relations reconstructs the original relation without producing spurious tuples.
+
+Additionally, the decomposition is dependency preserving since all functional dependencies are still enforceable inside individual relations. No dependency spans across different relations in a way that would require reconstructing joins. Therefore, the final schema preserves both theoretical guarantees.