Normalization trong database là gì? Tại sao quan trọng?

Chuẩn hóa (normalization) là tách dữ liệu sao cho mỗi sự thật chỉ lưu một chỗ — để tránh trùng lặp và "lỗi cập nhật". Ba mức thường gặp:

• 1NF — mỗi ô một giá trị nguyên tử, không nhồi danh sách. Sai: tags: 'nodejs,react' → tách bảng user_tags(user_id, tag).
• 2NF — (với khóa chính ghép) mọi cột phụ thuộc vào TOÀN BỘ khóa. Sai: order_items(order_id, product_id, product_name) — product_name chỉ phụ thuộc product_id → tách bảng products.
• 3NF — không phụ thuộc bắc cầu. Sai: employees(id, dept_id, dept_name) — dept_name phụ thuộc dept_id chứ không phải id → tách bảng departments.

Vì sao cần: nếu để trùng, đổi tên một phòng ban phải sửa N dòng (dễ lệch nhau), không thêm được phòng ban khi chưa có nhân viên, xóa nhân viên cuối là mất luôn thông tin phòng.

Thực tế: chuẩn tới 3NF là đủ cho phần lớn trường hợp; chỉ phá chuẩn (denormalize) có chủ đích khi đo đạc cho thấy cần.

Normalization means splitting data so each fact is stored in exactly one place — to avoid duplication and "update anomalies". Three common levels:

• 1NF — each cell holds one atomic value, no stuffed lists. Wrong: tags: 'nodejs,react' → split into user_tags(user_id, tag).
• 2NF — (with a composite key) every non-key column depends on the WHOLE key. Wrong: order_items(order_id, product_id, product_name) — product_name depends only on product_id → split into products.
• 3NF — no transitive dependencies. Wrong: employees(id, dept_id, dept_name) — dept_name depends on dept_id, not id → split into departments.

Why it matters: with duplication, renaming a department means updating N rows (easy to get inconsistent), you can't add a department before it has employees, and deleting the last employee wipes the department info.

In practice: normalizing to 3NF is enough for most cases; only denormalize deliberately when measurements show you need to.