| | 1 | === Third Normal Form (3NF) – Detailed Explanation === |
| | 2 | |
| | 3 | Third Normal Form builds on Second Normal Form by eliminating transitive dependencies. |
| | 4 | |
| | 5 | |
| | 6 | Even though 2NF removes partial dependencies, data anomalies can still exist if non-key attributes depend on other non-key attributes. |
| | 7 | |
| | 8 | === Formal Definition of 3NF === |
| | 9 | |
| | 10 | A relation R is in Third Normal Form (3NF) if and only if: |
| | 11 | |
| | 12 | **R is already in Second Normal Form (2NF)** |
| | 13 | |
| | 14 | **For every functional dependency X → A, at least one of the following holds: |
| | 15 | |
| | 16 | 1.X is a superkey, OR |
| | 17 | |
| | 18 | 2.A is a prime attribute (part of some candidate key) |
| | 19 | |
| | 20 | This definition ensures that non-key attributes depend only on the primary key and nothing else.** |
| | 21 | |
| | 22 | === Why 3NF Is Necessary in Wedding Planner === |
| | 23 | |
| | 24 | In the Wedding Planner system, many entities are logically independent, but still connected: |
| | 25 | |
| | 26 | 1.Weddings are created by users |
| | 27 | |
| | 28 | 2.Venues have descriptive properties |
| | 29 | |
| | 30 | 3.Bookings connect weddings and venues |
| | 31 | |
| | 32 | If descriptive attributes are stored indirectly via other non-key attributes, transitive dependencies arise, which violate 3NF. |
| | 33 | |
| | 34 | === Relations After 2NF (Starting Point for 3NF) === |
| | 35 | |
| | 36 | || Table || Primary Key || Attributes || |
| | 37 | || user || user_id || user_first_name, user_last_name, user_email |
| | 38 | || wedding || wedding_id || wedding_date, wedding_budget, user_id |
| | 39 | || venue || venue_id || venue_name, venue_type, venue_capacity |
| | 40 | || venue_booking || booking_id || venue_id, wedding_id, booking_date, start_time, end_time || |
| | 41 | |
| | 42 | All relations are in 2NF, but this does not guarantee 3NF. |
| | 43 | |
| | 44 | === Identification of Transitive Dependencies === |
| | 45 | |
| | 46 | A transitive dependency exists when: |
| | 47 | |
| | 48 | **Primary Key → Non-Key Attribute → Another Non-Key Attribute** |
| | 49 | |
| | 50 | === Transitive Dependency Analysis === |
| | 51 | |
| | 52 | || Dependency Chain || Explanation || |
| | 53 | || wedding_id → user_id → user_email || wedding_id indirectly determines user data |
| | 54 | || booking_id → venue_id → venue_name || booking_id indirectly determines venue attributes || |
| | 55 | |
| | 56 | In both cases: |
| | 57 | |
| | 58 | **1.The middle attribute (user_id, venue_id) is not a key |
| | 59 | |
| | 60 | 2.The final attribute is non-key |
| | 61 | |
| | 62 | 3This violates 3NF** |
| | 63 | |
| | 64 | === Why This Violates 3NF (Formal Proof) === |
| | 65 | |
| | 66 | Consider: |
| | 67 | |
| | 68 | wedding_id → user_id |
| | 69 | user_id → user_email |
| | 70 | |
| | 71 | By transitivity: |
| | 72 | |
| | 73 | wedding_id → user_email |
| | 74 | |
| | 75 | Since: |
| | 76 | |
| | 77 | wedding_id is not a superkey of the user relation |
| | 78 | |
| | 79 | user_email is not a prime attribute |
| | 80 | |
| | 81 | ➡ 3NF is violated |
| | 82 | |
| | 83 | === Decomposition Strategy for 3NF === |
| | 84 | |
| | 85 | To eliminate transitive dependencies: |
| | 86 | |
| | 87 | *Each non-key attribute must depend directly on the primary key |
| | 88 | |
| | 89 | *Intermediate determining attributes must be separated into their own relations |
| | 90 | |
| | 91 | *This process does not lose data and does not break dependencies. |
| | 92 | |
| | 93 | === 3NF Decomposition (Final Relations) === |
| | 94 | |
| | 95 | === USER === |
| | 96 | |
| | 97 | || user_id || user_first_name || user_last_name || user_email || |
| | 98 | || 1 || Ana || Trajkovska || ana.trajkovska@gmail.com|| |
| | 99 | |
| | 100 | FD: |
| | 101 | user_id → user_first_name, user_last_name, user_email |
| | 102 | |
| | 103 | === WEDDING === |
| | 104 | |
| | 105 | || wedding_id || wedding_date || wedding_budget || user_id || |
| | 106 | || W01 || 2026-06-20 || 8500 || 1 || |
| | 107 | |
| | 108 | FD: |
| | 109 | wedding_id → wedding_date, wedding_budget, user_id |
| | 110 | |
| | 111 | === VENUE === |
| | 112 | |
| | 113 | || venue_id || venue_name || venue_type || venue_capacity || |
| | 114 | || W011 || Lakeside Garden Venue || Outdoor Garden || 200 || |
| | 115 | |
| | 116 | FD: |
| | 117 | venue_id → venue_name, venue_type, venue_capacity |
| | 118 | |
| | 119 | === VENUE_BOOKING === |
| | 120 | |
| | 121 | || booking_id || venue_id || wedding_id || booking_date || start_time || end_time || |
| | 122 | || B01 || V01 || W01 || 2026-06-20 || 12:00 || 13:00 || |
| | 123 | |
| | 124 | FD: |
| | 125 | booking_id → venue_id, wedding_id, booking_date, start_time, end_time |
| | 126 | |
| | 127 | === Proof That 3NF Conditions Are Satisfied === |
| | 128 | |
| | 129 | For every functional dependency: |
| | 130 | |
| | 131 | || Dependency || Determinant Type || |
| | 132 | || user_id → user_email || user_id is PK |
| | 133 | || wedding_id → wedding_budget || wedding_id is PK |
| | 134 | || venue_id → venue_type || venue_id is PK |
| | 135 | || booking_id → start_time || booking_id is PK || |
| | 136 | |
| | 137 | **✔ All determinants are superkeys** |
| | 138 | |
| | 139 | **✔ No non-key attribute determines another non-key attribute** |