Changes between Version 4 and Version 5 of Normalization
- Timestamp:
- 01/28/26 02:50:49 (12 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Normalization
v4 v5 75 75 build_id → user_id, build_name, build_created_at, build_description, build_total_price, build_is_approved 76 76 77 build_component_id → build_id, user_id 78 77 79 (build_id, user_id) → rating_value 78 80 … … 103 105 cooler_cpu_sockets(cooler_id, socket) 104 106 105 build_component(build_id, component_id)106 107 107 108 108 We separate obvious entities in individual relations: … … 144 144 build(build_id, user_id, build_name, build_created_at, build_description, build_total_price, build_is_approved) 145 145 146 build_component(build_component_id, build_id, component_id) 147 146 148 review(review_id, build_id, user_id, review_content, review_created_at) 147 149 … … 165 167 build → build_id 166 168 169 build_component → build_component_id 170 167 171 review → review_id 168 172 … … 175 179 == Second Normal Form (2NF) 176 180 177 2NF focuses on partial dependencies, which can only occur when a relation has a composite primary key and a non-key attribute depends on only part of that key. Relations with a single-attribute primary key were considered to be automatically in 2NF. Most of the relations obtained after 1NF like users, components, build, review and suggestions, have single-attribute primary keys so partial dependencies cannot exist in these relations. The remaining relations that have composite primary keys build_component, favorite_build, rating_build were analyzed separately. 178 179 build_component(build_id, component_id) - doesn't have non-key attributes so it is already 2NF 181 2NF focuses on partial dependencies, which can only occur when a relation has a composite primary key and a non-key attribute depends on only part of that key. Relations with a single-attribute primary key were considered to be automatically in 2NF. Most of the relations obtained after 1NF like users, components, build, review and suggestions, have single-attribute primary keys so partial dependencies cannot exist in these relations. The remaining relations that have composite primary keys favorite_build and rating_build were analyzed separately. 180 182 181 183 favorite_build(build_id, user_id) - doesn't have non-key attributes so it is already 2NF … … 211 213 cooler_cpu_sockets(cooler_id, socket) - no transitive dependencies, 3NF is satisfied 212 214 213 build_component(build_ id, component_id) - no transitive dependencies because there are no non-key attributes, therefore 3NF is satisfied.215 build_component(build_component_id, build_id, component_id) - no transitive dependencies because all attributes depend on build_component_id, therefore 3NF is satisfied. 214 216 215 217 == BCNF decomposition … … 252 254 253 255 254 build_component(build_ id, component_id):255 256 FD: composite key (build_id, component_id) → /257 258 No non-key attributes so its by default BCNF256 build_component(build_component_id, build_id, component_id): 257 258 FD: build_component_id → build_id, component_id 259 260 Determinant build_component_id is primary key(superkey), BCNF 259 261 260 262
