Changes between Version 2 and Version 3 of Proof of 1N form
- Timestamp:
- 01/27/26 23:38:59 (13 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Proof of 1N form
v2 v3 1 === Step 0:Initial Unnormalized Relation (UNF) ===1 === Initial Unnormalized Relation (UNF) === 2 2 3 3 The system initially stores all information in a single relation: 4 4 5 5 USER_WEDDING_VENUE(user_id, user_first_name, user_last_name, user_email, wedding_id, wedding_date, wedding_budget, venue_id, venue_name, venue_type, venue_capacity, booking_id, booking_date, start_time, end_time) 6 7 === Example of UNF Data === 8 9 || user_id || user_first_name || user_last_name || user_email || wedding_id || wedding_date || wedding_budget || venue_id || venue_name || venue_type || venue_capacity || booking_id || booking_date || start_time || end_time || 10 || U01 || Ana || Petrova || ana@mail.com 11 || W01 || 2026-06-12 || 15000 || V01 || Grand Hall || Ballroom || 300 || B01 || 2026-06-12 || 18:00 || 23:00 | 12 || U01 || Ana || Petrova || ana@mail.com 13 || W01 || 2026-06-12 || 15000 || V02 || Garden Venue || Outdoor || 200 || B02 || 2026-06-12 || 12:00 || 16:00 | 14 || U02 || Marko || Iliev || marko@mail.com 15 || W02 || 2026-09-20 || 20000 || V01 || Grand Hall || Ballroom || 300 || B03 || 2026-09-20 || 19:00 || 01:00 | 16 17 === Why This Relation Is UNF === 18 19 -Repeating groups exist: 20 21 22 --User and wedding data are repeated for each venue booking 23 24 -Redundancy: 25 26 27 --Venue details (name, type, capacity) are duplicated across multiple rows 28 --User information appears multiple times 29 30 -Update anomalies: 31 32 33 --Changing a venue name requires updating multiple rows 34 --Changing a user email risks inconsistent data 35 36 -Insertion anomalies: 37 38 39 --A venue cannot be stored unless it is booked 40 --A user cannot exist without a wedding 41 42 -Deletion anomalies: 43 44 45 --Deleting a booking may remove venue or wedding information 6 46 7 47 This relation contains attributes describing multiple entities (User, Wedding, Venue, Booking). … … 42 82 -user_id → user_first_name, user_last_name, user_email 43 83 44 Justification: 84 **Justification:** 85 86 45 87 -All attributes are atomic 46 88 … … 54 96 -No repeating groups exist 55 97 56 Conclusion:57 -R1 satisfies 1NF 98 **Conclusion: 99 -R1 satisfies 1NF** 58 100 59 101 === R2: WEDDING === … … 71 113 -wedding_id → wedding_date, wedding_budget, user_id 72 114 73 Justification: 115 **Justification:** 116 117 74 118 -Each wedding is uniquely identified by wedding_id 75 119 … … 80 124 -All non-key attributes depend solely on wedding_id 81 125 82 Conclusion:126 **Conclusion: 83 127 -R2 satisfies 1NF 84 128 ** 85 129 === R3: VENUE === 86 130 … … 94 138 -venue_id → venue_name, venue_type, venue_capacity 95 139 96 Justification: 140 **Justification:** 141 142 97 143 -Venue attributes describe a single independent entity 98 144 … … 103 149 -venue_id uniquely identifies a venue 104 150 105 Conclusion: 106 -R3 satisfies 1NF 151 152 **Conclusion: 153 -R3 satisfies 1NF** 107 154 108 155 === R4: VENUE_BOOKING === … … 121 168 -booking_id → venue_id, wedding_id, booking_date, start_time, end_time 122 169 123 Justification: 170 171 **Justification:** 172 173 124 174 -A booking represents a reservation of a venue for a specific wedding 125 175 … … 132 182 133 183 134 Conclusion:135 -R4 satisfies 1NF 184 **Conclusion: 185 -R4 satisfies 1NF** 136 186
