Changes between Version 8 and Version 9 of Normalization
- Timestamp:
- 09/23/25 02:55:02 (2 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Normalization
v8 v9 79 79 ==== 1 НФ 80 80 81 За да постигнеме 1NF, мора да се осигураме дека сите атрибути во секоја торка се атомски, што значи дека не постојат повеќевредносни атрибути или композитни атрибути.81 Услов за 1NF: вредности на атомски атрибути (без низи / вгнездени релации). 82 82 83 ===== Проблем во тековната шема: 83 Нема повторувачки групи или низи, значи R е во 1NF. 84 84 85 Композитни атрибути како address (кои може да имаат повеќе компоненти како што се улица, град итн.). 85 2NF (отстранување на делумни зависности) 86 86 87 ===== Решение: 87 2NF тест: ако релацијата има композитен кандидатски клуч, секој не-примарен атрибут мора да зависи од целиот клуч, а не од дел. 88 88 89 Разделување на повеќевредносните атрибути во посебни колони.89 Бидејќи започнавме од голем композитен суперклуч K, многу FD како user_id -> first_name се делумни зависности во однос на тој суперклуч. Стандардниот пристап е да се извлечат детерминантите и нивните зависни во нивните сопствени релации. Овој чекор обично ги дава табелите со природни ентитети. 90 90 91 ===== Применето 1NF:91 Декомпозиции (за отстранување на делумни зависности): 92 92 93 Адресата во Hotel_Building треба да се подели на атомски компоненти: улица, град и поштенски код. 93 Ги извлекуваме детерминантите и нивните зависни во посебни релации: 94 94 95 Табела Hotel_Building: 95 ==== Users 96 96 97 building_id, street, city, zip_code, floors, num_rooms 97 R1: Users(user_id, first_name, last_name, phone, email, password) 98 98 99 Сите атрибути во секоја табела ќе бидат атомски, што значи дека нема да постојат дополнителни сложени или повеќевредносни атрибути. 99 FDs во R1: user_id -> first_name, last_name, phone, email, password 100 100 101 ==== 2 НФ 101 PK: user_id 102 102 103 За да постигнеме 2NF, треба да отстраниме делумни зависности. Атрибутот што не е примарен мора да биде целосно функционално зависен од целиот примарен клуч, а не само од негов дел.103 R1 е во BCNF. 104 104 105 ==== = Проблем во тековната шема:105 ==== Hotel_Building 106 106 107 Во Reservation, атрибутите како user_id, manager_id и room_number се делумно зависни само од дел од примарниот клуч (т.е. reservation_id), а не од целиот примарен клуч. 107 R2: Hotel_Building(building_id, address, city, floors, num_rooms, manager_id) 108 108 109 ===== Решение: 109 FDs во R2: building_id -> address, city, floors, num_rooms, manager_id 110 110 111 Преместување на атрибутите што зависат од дел од примарниот клуч во посебни табели за да ги елиминирате делумните зависности. 111 PK: building_id 112 112 113 ===== Применето 2NF: 113 R2 е во BCNF. 114 114 115 Креирање табела Customer со user_id како примарен клуч и атрибути поврзани со клиентот. 115 ==== Room 116 116 117 Креирање табела Manager со user_id како примарен клуч и атрибути поврзани со менаџерот. 117 R3: Room(room_number, building_id, room_type, number_of_beds, price_per_night, available) 118 118 119 Изменување на Reservation за да ги чува само атрибутите што зависат од reservation_id и преместување на user_id (клиент) и manager_id во нивните соодветни табели. 119 PK: (room_number, building_id) 120 120 121 По 2NF: 121 FDs: (room_number, building_id) -> room_type, number_of_beds, price_per_night, available 122 122 123 Customer: user_id, first_name, last_name, phone, email, password 123 R3 е во BCNF. 124 124 125 Manager: user_id, first_name, last_name, phone, email, password 125 ==== Staff 126 126 127 R eservation: reservation_id, start_date, end_date, reserv_date, status, room_number, building_id, customer_id, manager_id127 R4: Staff(user_id /*staff_id*/, building_id) 128 128 129 ==== 3 НФ 129 FDs: staff_id -> building_id 130 130 131 За да постигнеме 3NF, мора да ги отстраниме транзитивните зависности. Непримарниот атрибут не смее да зависи од друг непримарен атрибут. 131 PK: user_id (staff_id) 132 132 133 ===== Проблеми во тековната шема: 133 R4 е во BCNF. 134 134 135 Во Payment, user_id индиректно одредува атрибути како first_name и last_name, создавајќи транзитивна зависност. 135 ==== Reservation 136 136 137 ===== Решение: 137 R5: Reservation(reservation_id, start_date, end_date, reserv_date, status, room_number, building_id, customer_id, manager_id) 138 138 139 Отстранување на транзитивните зависности со креирање посебни табели за User (веќе направено во 2NF) и осигурувајќи се дека секоја табела ги складира само атрибутите што директно зависат од примарниот клуч. 139 FDs: reservation_id -> start_date, end_date, reserv_date, status, room_number, building_id, customer_id, manager_id 140 140 141 ===== Применето 3NF: 141 PK: reservation_id 142 142 143 Во табелата Payment, складираме само p_id, p_method, amount, p_date и reservation_id. До user_id може да се пристапи преку reservation_id, па затоа не треба да се чува во табелата Payment.143 R5 е во BCNF. 144 144 145 ==== = По 3NF:145 ==== Service 146 146 147 Payment: p_id, p_method, amount, p_date, reservation_id 147 R6: Service(service_id, service_type, service_date, service_status, room_number, building_id, staff_id) 148 148 149 ==== BCNF 149 FDs: service_id -> service_type, service_date, service_status, room_number, building_id, staff_id 150 150 151 За да се постигне BCNF, мора да се осигураме дека секоја детерминанта во релацијата е клуч-кандидат, односно За секоја функционална зависност: A→B, A мора да биде клуч-кандидат. 151 PK: service_id 152 152 153 ===== Проблем во тековната шема: 153 R6 е во BCNF. 154 154 155 Во табелата Service, функционалната зависност: 155 ===== Payment 156 156 157 service_id → service_type, service_date, service_status, staff_id, room_number, building_id 157 R7: Payment(reservation_id PK, p_id UNIQUE, p_method, amount, p_date, customer_id) 158 158 159 Оваа функционална зависност покажува дека service_id ги одредува service_type, service_date и service_status, но room_number и building_id не се дел од клучот-кандидат. Така, room_number и building_id се не-примарни атрибути кои зависат од service_id, создавајќи потенцијално прекршување на BCNF. 159 FD: reservation_id -> p_id, p_method, amount, p_date, customer_id (1:1 means reservation determines payment) 160 160 161 ===== Решение за BCNF: 161 PK: reservation_id 162 162 163 164 За да го решиме ова прекршување, треба да се осигураме дека секоја детерминанта е клуч-кандидат. 165 166 room_number и building_id се одредени од композитниот клуч (room_number, building_id) во табелата Room, што е клуч-кандидат. 167 168 Треба да ја отстраниме зависноста од room_number и building_id од табелата Service бидејќи овие атрибути се веќе одредени од табелата Room. 169 170 ===== По примена на BCNF: 171 172 Табелата Service ќе ги чува само: 173 174 service_id, service_type, service_date, service_status и staff_id. 175 176 Табелата Room ќе продолжи да ги чува деталите поврзани со собата, вклучувајќи го room_number и building_id. 177 178 Со ова, сите не-примарни атрибути во табелата Service зависат единствено од клучот-кандидат service_id. 179 180 ===== Конечни табели во BCNF: 181 182 По примената на BCNF и решавањето на сите проблеми, конечната шема за засегнатите табели изгледа вака: 183 184 Hotel_Bidling: building_id, street, city, zip_code, floors, num_rooms 185 186 Room: room_number, building_id, room_type, number_of_beds, price_per_night, available 187 188 Customer: user_id, first_name, last_name, phone, e-mail, password 189 190 Manager: user_id, first_name, last_name, phone, e-mail, password 191 192 Reservation: reservation_id, start_date, end_date, reserv_date, status, customer_id, manager_id, room_number, building_id 193 194 Payment: p_id, p_method, amount, p_date, reservation_id 195 196 Service: service_id, service_type, service_date, service_status, staff_id 163 R7 е во BCNF.
