Normalization & Denormalization

🎯 Mục tiêu bài học

Thiết kế DB: Khi nào nên chia bảng? Khi nào nên gộp bảng?

1. Các dạng chuẩn (Normal Forms) - Ôn tập sâu

1NF (Atomic)

Lỗi: Cột Skills: "Java, Python, SQL".

Sửa: Tách bảng riêng User_Skills (UserID, SkillID). Mỗi dòng 1 skill.

2NF (Partial Dependency)

Chỉ xảy ra khi khóa chính là khóa phức hợp (A, B). Nếu Cột C chỉ phụ thuộc vào A mà không phụ thuộc B -> Vi phạm.

3NF (Transitive Dependency)

A -> B -> C. (MãSV -> MãLớp -> TênLớp). Tách bảng Lớp riêng.

BCNF (Boyce-Codd) - 3.5NF

Phiên bản chặt chẽ hơn của 3NF. Mọi định thức (Determinant) đều phải là Candidate Key.

2. Denormalization (Phi chuẩn hóa) - Thực tế

Chuẩn hóa giúp dữ liệu Gọn và Nhất quán (Consistency), nhưng làm Query chậm vì phải JOIN quá nhiều bảng.

Rủi ro: Khi User đổi tên, phải update cả 2 bảng. Không thì dữ liệu bị lệch (Inconsistency).

3. SQL Anti-Patterns

• Index Shotgun: Đánh index cho TẤT CẢ các cột. (Hại: Tốn chỗ, Insert siêu chậm).
• Select *: Lấy thừa cột làm tốn băng thông mạng và RAM. Không tận dụng được Covering Index.
• ID as String: Dùng UUID (String 36 chars) làm Primary Key. (Hại: Làm Index B-Tree bị phân mảnh, to cồng kềnh. Nên dùng BIGINT tự tăng hoặc Snowflake ID).

📝 Lab 15: Database Design Challenge

Thiết kế DB cho E-commerce (Shopee).

• Bảng Products, Categories (Quan hệ N-N? Hay Tree?).
• Bảng Orders, OrderItems.
• Tại sao giá tiền trong OrderItems phải lưu cứng (Denormalize) mà không được tham chiếu sang bảng Products? (Vì giá sản phẩm thay đổi theo thời gian, giá lúc mua phải giữ nguyên).