Bài 14 — Normalization — 3NF Transitive Dependencies

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa hoàn tất chuẩn hóa một bảng dữ liệu khách hàng cho hệ thống bán hàng. Bảng đã sạch sẽ: mỗi ô chỉ chứa một giá trị (1NF), mọi cột đều phụ thuộc vào toàn bộ khóa chính (2NF). Bạn thở phào, nghĩ rằng thiết kế đã chắc chắn. Nhưng rồi một ngày, phòng kế toán báo rằng cùng một mã bưu chính "70000" lại được ghi thuộc về "Quận 1" ở dòng này, "Quận 3" ở dòng khác. Dữ liệu mâu thuẫn, báo cáo sai, và không ai biết con số nào đúng.

Đây chính xác là vấn đề mà Third Normal Form (3NF — chuẩn hóa cấp ba) sinh ra để giải quyết. Nếu 1NF và 2NF lo về cách dữ liệu liên hệ với khóa chính, thì 3NF lo về một mối nguy tinh vi hơn nhiều: các cột không khóa lại "ngầm" phụ thuộc vào nhau, tạo ra một chuỗi phụ thuộc gián tiếp gọi là transitive dependency (phụ thuộc bắc cầu).

Với một Business Analyst, hiểu 3NF không phải để "khoe" thuật ngữ học thuật. Nó là kỹ năng sống còn để bạn phát hiện ra những thiết kế bảng tưởng chừng ổn nhưng sẽ gây ra dữ liệu mâu thuẫn, cập nhật khó khăn, và bug khó truy vết khi hệ thống lớn lên. Phần lớn các lỗi "dữ liệu không nhất quán" trong doanh nghiệp đều bắt nguồn từ việc bỏ qua 3NF. Bài này sẽ giúp bạn nhìn ra chúng từ trước khi chúng trở thành thảm họa.

Khái niệm cốt lõi

Định nghĩa 3NF

Một bảng được xem là đạt Third Normal Form (3NF) khi thỏa mãn đồng thời hai điều kiện:

• Đã ở 2NF — tức đã qua 1NF (giá trị nguyên tử, không có nhóm lặp) và không còn partial dependency (phụ thuộc một phần vào khóa).
• Không còn transitive dependency — mọi cột không khóa (non-key attribute) phải phụ thuộc TRỰC TIẾP vào khóa chính, chứ không thông qua một cột không khóa khác.

Câu thần chú kinh điển mà các chuyên gia dữ liệu hay nhắc để nhớ ba chuẩn đầu tiên là: "Mỗi non-key attribute phải phụ thuộc vào khóa (1NF), vào toàn bộ khóa (2NF), và chỉ vào khóa mà thôi (3NF)." Vế cuối — "chỉ vào khóa mà thôi" — chính là linh hồn của 3NF.

Transitive dependency là gì?

Transitive dependency (phụ thuộc bắc cầu) xảy ra khi một cột không khóa phụ thuộc vào một cột không khóa khác, thay vì phụ thuộc trực tiếp vào khóa chính.

Diễn đạt bằng ký hiệu phụ thuộc hàm: nếu ta có

• A → B (B phụ thuộc vào A — khóa chính)
• B → C (C phụ thuộc vào B — một cột không khóa)

thì suy ra A → C một cách gián tiếp, bắc cầu qua B. Cột C lúc này không thực sự "thuộc về" thực thể mà A mô tả; nó thuộc về thực thể mà B mô tả. Đó là dấu hiệu C đang nằm sai chỗ.

Ví dụ ngắn gọn để bạn hình dung: trong bảng NhanVien, ta có MaNV → MaPhongBan (mỗi nhân viên thuộc một phòng ban) và MaPhongBan → TenPhongBan (mỗi mã phòng ban có một tên). Vậy TenPhongBan phụ thuộc bắc cầu vào MaNV. TenPhongBan không mô tả nhân viên — nó mô tả phòng ban. Nó đang đứng nhầm bảng.

Vì sao transitive dependency gây hại?

Khi một cột nằm sai bảng, bạn gặp ba loại "dị thường" (anomalies) kinh điển:

• Update anomaly (dị thường cập nhật): Phòng "Kế toán" đổi tên thành "Tài chính – Kế toán". Nếu phòng này có 40 nhân viên, bạn phải sửa 40 dòng. Sửa thiếu một dòng là dữ liệu mâu thuẫn ngay.
• Insertion anomaly (dị thường chèn): Công ty vừa lập phòng "Pháp chế" nhưng chưa tuyển ai. Bạn không thể lưu thông tin phòng này vì không có dòng nhân viên nào để gắn vào.
• Deletion anomaly (dị thường xóa): Nhân viên cuối cùng của phòng "R&D" nghỉ việc. Khi xóa dòng của họ, bạn vô tình xóa luôn toàn bộ thông tin về sự tồn tại của phòng R&D.

3NF triệt tiêu cả ba loại dị thường này bằng cách tách cột "lạc loài" ra một bảng riêng, nơi nó phụ thuộc trực tiếp vào khóa chính của chính nó.

Một lưu ý về BCNF (để bạn không nhầm)

Bạn có thể nghe đến Boyce-Codd Normal Form (BCNF) — một phiên bản "chặt hơn" của 3NF. BCNF xử lý các trường hợp hiếm gặp khi một determinant (vế trái của phụ thuộc) không phải là khóa dự tuyển. Trong bài này ta tập trung vào 3NF, vì với 95% các bảng nghiệp vụ thực tế, đạt 3NF là đủ tốt và đúng. Ta chỉ cần biết BCNF tồn tại như một bậc cao hơn để tham chiếu khi gặp ca đặc biệt.

Tình huống thực tế

Tình huống 1 — Sàn TMĐT "ChợViệt" và bảng đơn hàng

Công ty khởi nghiệp ChợViệt vận hành một sàn thương mại điện tử nhỏ ở TP.HCM. Trong giai đoạn đầu, đội kỹ thuật thiết kế bảng ChiTietDonHang như sau:

Thoạt nhìn bảng có vẻ ổn. Nhưng hãy soi kỹ chuỗi phụ thuộc:

• MaChiTiet → MaSanPham (mỗi dòng chi tiết ứng với một sản phẩm)
• MaSanPham → TenSanPham, MaSanPham → MaDanhMuc
• MaDanhMuc → TenDanhMuc, MaDanhMuc → ThueSuat

Vậy TenSanPham, MaDanhMuc, TenDanhMuc, ThueSuat đều phụ thuộc bắc cầu vào MaChiTiet. Hậu quả ập đến khi nhà nước điều chỉnh thuế suất ngành thời trang từ 8% lên 10%: đội kỹ thuật phải UPDATE hàng trăm nghìn dòng chi tiết đơn hàng. Một câu lệnh chạy 12 phút, và do bị timeout giữa chừng, một phần dữ liệu cập nhật thiếu — báo cáo thuế quý đó sai lệch khoảng 47 triệu đồng.

Diễn giải: Lỗi gốc là ThueSuat thuộc về danh mục, không thuộc về dòng chi tiết đơn hàng. Khi đưa về 3NF, ChợViệt tách thành ba bảng: ChiTietDonHang(MaChiTiet, MaSanPham, SoLuong, DonGia), SanPham(MaSanPham, TenSanPham, MaDanhMuc), và DanhMuc(MaDanhMuc, TenDanhMuc, ThueSuat). Sau khi tách, đổi thuế suất chỉ là một dòng UPDATE duy nhất trong bảng DanhMuc.

Bài học: Bất cứ khi nào bạn thấy một thuộc tính có thể thay đổi đồng loạt theo nhóm (thuế theo danh mục, tên theo mã), hãy nghi ngờ ngay đó là transitive dependency.

Tình huống 2 — Ngân hàng "VietPhuongBank" và bảng tài khoản chi nhánh

Một ngân hàng cỡ vừa tại Việt Nam lưu thông tin tài khoản khách hàng trong bảng TaiKhoan:

Phụ thuộc bắc cầu ở đây rất rõ: SoTaiKhoan → MaChiNhanh, rồi MaChiNhanh → TenChiNhanh, DiaChiChiNhanh, MaTinhThanh. Khi chi nhánh Hoàn Kiếm chuyển trụ sở sang địa chỉ mới, bộ phận vận hành phải cập nhật trường DiaChiChiNhanh cho hàng chục nghìn tài khoản gắn với chi nhánh đó. Tệ hơn, do thao tác thủ công ở nhiều thời điểm, một số tài khoản ghi địa chỉ cũ, một số ghi địa chỉ mới — và bộ phận thanh tra nội bộ phát hiện sự bất nhất này khi đối chiếu hồ sơ.

Diễn giải: Thông tin chi nhánh mô tả chi nhánh, không mô tả tài khoản. Giải pháp 3NF: tách ChiNhanh(MaChiNhanh, TenChiNhanh, DiaChiChiNhanh, MaTinhThanh) thành bảng riêng, bảng TaiKhoan chỉ giữ MaChiNhanh như một khóa ngoại (foreign key).

Bài học: Trong môi trường ngân hàng nơi tính toàn vẹn dữ liệu là pháp lý bắt buộc, một transitive dependency không được xử lý có thể dẫn đến rủi ro tuân thủ thật sự, không chỉ là phiền toái kỹ thuật.

Tình huống 3 — Trường hợp "tưởng vi phạm nhưng không"

Một học viên cũ của tôi làm ở công ty logistics "GiaoNhanh" từng tách quá tay. Cô có bảng DonHang(MaDon, NgayDat, ThanhTien, ChietKhau, SoTienThucThu). Cô lo lắng vì SoTienThucThu = ThanhTien - ChietKhau, nên nghĩ SoTienThucThu phụ thuộc bắc cầu và đòi tách ra bảng khác.

Diễn giải: Đây không phải transitive dependency theo nghĩa cần tách bảng. SoTienThucThu là một giá trị tính toán (derived/computed attribute) từ các cột cùng bảng, cùng phụ thuộc trực tiếp vào MaDon. Vấn đề ở đây không phải 3NF mà là redundancy do lưu giá trị dẫn xuất. Cách xử lý đúng là hoặc dùng computed column, hoặc đơn giản là không lưu mà tính khi cần — chứ không phải tách bảng.

Bài học: 3NF nói về việc cột phụ thuộc vào cột không khóa khác qua một thực thể khác. Đừng nhầm nó với cột tính toán nội bộ. Tách nhầm sẽ làm mô hình rườm rà vô ích.

Hướng dẫn từng bước

Đây là quy trình thực hành để đưa một bảng về 3NF mà bạn có thể áp dụng ngay:

Bước 1 — Xác nhận bảng đã ở 2NF. Đừng nhảy cóc. Nếu bảng còn partial dependency (cột chỉ phụ thuộc một phần khóa kép), xử lý 2NF trước (đã học ở Bài 13). 3NF chỉ có ý nghĩa khi 2NF đã đạt.

Bước 2 — Liệt kê toàn bộ functional dependency. Viết ra mọi quan hệ "cột nào quyết định cột nào". Ví dụ: MaNV → TenNV, MaPhong; MaPhong → TenPhong, TruongPhong. Bước này là bước quan trọng nhất — chuẩn hóa thực chất là kỹ năng đọc ra các phụ thuộc hàm.

Bước 3 — Săn tìm phụ thuộc giữa các cột không khóa. Quét danh sách ở Bước 2, tìm bất kỳ phụ thuộc nào có vế trái KHÔNG phải khóa chính. Mỗi phụ thuộc kiểu (cột không khóa) → (cột không khóa) chính là một transitive dependency cần xử lý.

Bước 4 — Tách thành bảng mới. Với mỗi cột-quyết-định không khóa tìm được (ví dụ MaPhong), tạo một bảng mới lấy nó làm khóa chính, gom mọi cột phụ thuộc vào nó: PhongBan(MaPhong, TenPhong, TruongPhong).

Bước 5 — Giữ lại khóa ngoại ở bảng gốc. Bảng gốc chỉ giữ lại cột quyết định (MaPhong) như một foreign key trỏ tới bảng mới. Các cột mô tả phòng ban bị xóa khỏi bảng gốc.

Bước 6 — Kiểm tra lại và lặp. Sau khi tách, kiểm tra cả bảng cũ lẫn bảng mới xem còn transitive dependency nào không. Đôi khi một bảng mới tách ra vẫn còn chuỗi bắc cầu sâu hơn, cần tách tiếp.

Bước 7 — Đối chiếu với nghiệp vụ. Cuối cùng, kiểm tra bằng mắt nghiệp vụ: mỗi bảng giờ có mô tả đúng một thực thể không? NhanVien chỉ chứa thuộc tính nhân viên, PhongBan chỉ chứa thuộc tính phòng ban. Nếu đúng, bạn đã ở 3NF.

Lỗi thường gặp & mẹo

Lỗi 1 — Bỏ qua 2NF, nhảy thẳng vào 3NF. Nhiều người háo hức "soi" transitive dependency mà quên bảng còn vi phạm 2NF. Kết quả là tách bảng nửa vời. Luôn đi tuần tự 1NF → 2NF → 3NF.

Lỗi 2 — Nhầm cột tính toán với transitive dependency. Như tình huống GiaoNhanh ở trên, ThanhTien = SoLuong × DonGia không phải lý do để tách bảng. Phân biệt: transitive dependency là phụ thuộc qua một thực thể khác; cột tính toán là phép tính trên các cột cùng thực thể.

Lỗi 3 — Quên foreign key sau khi tách. Tách bảng nhưng không để lại khóa ngoại ở bảng gốc thì bạn mất luôn mối liên kết, không join lại được. Luôn giữ cột quyết định làm FK.

Lỗi 4 — Chuẩn hóa quá đà cho dữ liệu ít thay đổi. Với một số bảng tra cứu cực kỳ ổn định (ví dụ danh sách 63 tỉnh thành Việt Nam, gần như không đổi), việc denormalize có chủ đích đôi khi hợp lý vì lý do hiệu năng. Nhưng đây là quyết định có chủ đích, không phải sự lười biếng — và chủ đề denormalization sẽ được bàn kỹ ở Bài 15.

Mẹo nhận diện nhanh: Khi nhìn một bảng, hãy tự hỏi: "Nếu tôi sửa giá trị ô này, liệu tôi có buộc phải sửa nhiều dòng cùng lúc để giữ dữ liệu nhất quán không?" Nếu câu trả lời là có, gần như chắc chắn bạn đang nhìn vào một transitive dependency.

Mẹo đặt câu hỏi nghiệp vụ: Với mỗi cột, hỏi "Cột này mô tả về cái gì?" Nếu câu trả lời không phải là thực thể của khóa chính bảng đó, cột đang nằm sai chỗ.

Bài tập thực hành

Cho bảng DangKyHoc của một trung tâm tiếng Anh tại Hà Nội (mỗi dòng là một lượt học viên đăng ký một lớp):

Yêu cầu:

• Liệt kê tất cả các functional dependency bạn nhận ra trong bảng.
• Chỉ ra các transitive dependency cụ thể (cột nào phụ thuộc bắc cầu qua cột nào).
• Tách bảng về 3NF: viết ra cấu trúc các bảng kết quả, chỉ rõ khóa chính và khóa ngoại của từng bảng.
• Câu hỏi nâng cao: Giả sử trung tâm muốn lưu thêm PhongHoc cho mỗi lớp, và mỗi phòng học có SucChua. Thuộc tính SucChua nên nằm ở bảng nào để đảm bảo 3NF? Vì sao?

Gợi ý định hướng: Bạn sẽ tìm thấy ít nhất hai chuỗi bắc cầu — một liên quan đến thông tin lớp học và một liên quan đến thông tin giáo viên. Đáp án mong đợi gồm bốn bảng: DangKyHoc, HocVien, Lop, và GiaoVien. Với câu 4, hãy nhớ rằng SucChua mô tả phòng học, không mô tả lớp — nên cần một bảng PhongHoc riêng.

Tóm tắt

• 3NF = 2NF + không còn transitive dependency. Mọi cột không khóa phải phụ thuộc trực tiếp vào khóa chính, không qua trung gian.
• Transitive dependency xảy ra khi một cột không khóa phụ thuộc vào một cột không khóa khác (A → B → C). Cột C đang nằm sai bảng — nó mô tả thực thể của B, không phải của A.
• Hậu quả của việc bỏ qua 3NF là ba loại dị thường: update, insertion, deletion anomalies, dẫn đến dữ liệu mâu thuẫn và bảo trì khó khăn — như các tình huống thuế suất ở ChợViệt và địa chỉ chi nhánh ở VietPhuongBank đã minh họa.
• Quy trình xử lý: liệt kê functional dependency → săn phụ thuộc giữa các cột không khóa → tách bảng mới với cột quyết định làm khóa chính → giữ lại khóa ngoại ở bảng gốc → kiểm tra lặp.
• Cẩn trọng phân biệt transitive dependency với cột tính toán; và nhớ rằng chuẩn hóa quá đà cũng là một sai lầm cần cân nhắc (sẽ bàn ở Bài 15 về denormalization).

Nắm vững 3NF, bạn đã có trong tay bộ ba chuẩn hóa nền tảng (1NF–2NF–3NF) — đủ để thiết kế hầu hết các mô hình dữ liệu nghiệp vụ sạch sẽ và bền vững. Đây là ranh giới phân biệt một người "vẽ bảng cho có" với một người thiết kế dữ liệu thực thụ.