CHUẨN HÓA CƠ SỞ DỮ LIỆU

Phụ thuộc hàm, các dạng chuẩn 1NF, 2NF, 3NF, BCNF qua một sổ bán hàng và lúc nào nên phi chuẩn hóa

---

Một cửa hàng của chuỗi siêu thị mini giả định Sen Vàng Mart ghi mọi lần bán vào một sổ Excel duy nhất. Mỗi dòng là một sản phẩm trên một hóa đơn, kèm đủ thông tin: ngày giờ, cửa hàng, thu ngân, mã và tên khách, hạng thành viên, mã và tên sản phẩm, mã và tên nhóm hàng, số lượng, đơn giá. Quý I có 8.554 dòng như vậy, 17 cột mỗi dòng. Sổ chạy tốt cho tới ngày ban giám đốc đổi tên nhóm "Nước giải khát" thành "Đồ uống".

Tên nhóm được chép trên mọi dòng bán một sản phẩm của nhóm đó: 767 dòng, chỉ trong một cửa hàng và một quý. Sót một dòng là sổ có hai tên cho cùng một nhóm và mọi báo cáo theo nhóm hàng chia nhóm đó làm hai. Không ai cẩu thả cả: chính cấu trúc của sổ buộc một sự thật duy nhất, "nhóm 01 tên là gì", phải được ghi lại 767 lần.

Chuẩn hóa (normalization) là phương pháp có hệ thống để nhận ra những cấu trúc như vậy và tách bảng sao cho mỗi sự thật chỉ được ghi một lần (Codd, 1970; Jukić, 2025). Bài viết gồm năm mục. Mục 1 đo ba loại dị thường của sổ bán hàng. Mục 2 giới thiệu phụ thuộc hàm, công cụ để tách bảng bằng quy tắc thay vì cảm tính. Mục 3 đi qua ba dạng chuẩn 1NF, 2NF, 3NF và đo kết quả bằng số. Mục 4 bàn BCNF và cái giá của việc chuẩn hóa cao hơn. Mục 5 bàn phi chuẩn hóa, tức lúc nào nên cố ý đi ngược lại.

1. Ba loại dị thường cập nhật

Một cơ sở dữ liệu tác nghiệp thay đổi liên tục qua ba thao tác: chèn dòng mới, xóa dòng cũ và sửa giá trị. Khi bảng được thiết kế kém, các thao tác này sinh ra dị thường cập nhật (update anomaly), tức hậu quả ngoài ý muốn mà người thao tác không hề định gây ra (Jukić, 2025). Bảng 1 đo ba loại dị thường trên sổ bán hàng quý I của cửa hàng Cầu Giấy.

Bảng 1. Ba loại dị thường trên sổ bán hàng và tình trạng sau khi tách bảng (tình huống giả định)

Dị thường sửa xảy ra khi một sự thật nằm ở nhiều dòng nên sửa nó phải sửa tất cả. Dị thường xóa xảy ra khi xóa một dòng làm mất luôn thông tin về một đối tượng khác: 209 khách chỉ mua đúng một hóa đơn trong quý, hủy hóa đơn đó là tên, số điện thoại và hạng của khách biến mất theo. Dị thường chèn xảy ra khi không ghi được một thông tin vì thiếu một thông tin khác không liên quan: danh mục có 1.200 sản phẩm nhưng 53 sản phẩm chưa bán lần nào ở Cầu Giấy và sổ không có chỗ ghi chúng vì mỗi dòng bắt buộc phải là một lần bán.

Cả ba dị thường trong Bảng 1 có chung một gốc: một dòng trộn bốn chủ đề là hóa đơn, khách hàng, sản phẩm và nhóm hàng. Đây chính là "dư thừa sinh mâu thuẫn" mà bài Quy trình phát triển hệ thống cơ sở dữ liệu mô tả qua các tệp Excel rời rạc, giờ được gọi tên chính xác và đếm được bằng số.

2. Phụ thuộc hàm

Muốn tách bảng một cách có hệ thống, cần một công cụ mô tả chính xác "thông tin nào quyết định thông tin nào". Công cụ đó là phụ thuộc hàm, khái niệm trụ cột của chuẩn hóa. Mục này trình bày định nghĩa, ba loại phụ thuộc và cạm bẫy khi đi tìm chúng.

2.1. Định nghĩa và cách đọc

Trong một bảng, cột Y phụ thuộc hàm (functional dependency) vào cột X nếu mỗi giá trị của X luôn đi kèm đúng một giá trị của Y. Ký hiệu là X → Y, đọc là "X quyết định Y"; X được gọi là yếu tố quyết định (determinant) (Jukić, 2025). Ví dụ MaSP → TenSP: biết mã sản phẩm là biết tên, vì quy tắc của chuỗi là mỗi mã ứng với đúng một sản phẩm. Chiều ngược lại không đúng, vì hai sản phẩm ở hai nhóm có thể trùng tên.

Phụ thuộc hàm trả lời đúng câu hỏi mà dị thường đặt ra: một sự thật nên được lưu ở đâu. Nếu MaNhom → TenNhom thì tên nhóm là sự thật về nhóm hàng và chỉ nên ghi ở nơi mỗi nhóm xuất hiện đúng một lần. Trong sổ bán hàng, MaNhom xuất hiện trên cả 8.554 dòng, nên TenNhom cũng bị chép 8.554 lần. Đó là cơ chế sinh ra 767 dòng phải sửa.

Cạm bẫy ở đây là suy phụ thuộc hàm từ dữ liệu đang có. Nhìn sổ quý I, mỗi tên sản phẩm đi với đúng một mã, nên dễ kết luận TenSP → MaSP. Nhưng đó chỉ là tình cờ đúng trong 8.554 dòng; tháng sau chuỗi hoàn toàn có thể nhập một sản phẩm cùng tên ở nhóm khác. Giống cạm bẫy bản số trong bài Mô hình thực thể liên kết ER và cách đọc bản số, dữ liệu chỉ bác bỏ được một phụ thuộc, không chứng minh được nó. Phụ thuộc hàm là quy tắc nghiệp vụ và phải lấy từ người hiểu nghiệp vụ.

2.2. Ba loại phụ thuộc theo khóa

Khóa của sổ bán hàng là cặp (SoHD, MaSP), vì mỗi dòng là một sản phẩm trên một hóa đơn. So với khóa này, mỗi phụ thuộc rơi vào một trong ba loại và mỗi loại được một dạng chuẩn xử lý. Hình 1 vẽ các phụ thuộc của sổ, rút gọn còn chín cột.

Hình 1. Sơ đồ phụ thuộc hàm của sổ bán hàng, rút gọn còn chín cột (tình huống giả định). Nguồn: dựa trên Jukić (2025).

Phụ thuộc đầy đủ theo khóa (full key functional dependency) có vế trái là toàn bộ khóa: (SoHD, MaSP) → SoLuong. Số lượng là sự thật về đúng một cặp hóa đơn và sản phẩm, nên nó thuộc về bảng này; đơn giá bán thực tế cũng vậy. Phụ thuộc bộ phận (partial functional dependency) có vế trái là một phần của khóa phức hợp: SoHD → NgayGio, MaKH và MaSP → TenSP, MaNhom. Phụ thuộc bắc cầu (transitive functional dependency) có vế trái là một cột không thuộc khóa: MaKH → TenKH và MaNhom → TenNhom. Như Hình 1 cho thấy, chỉ một trong chín cột thật sự thuộc về bảng này.

Một nhầm lẫn thường gặp là xếp MaKH → TenKH vào loại bộ phận, vì "MaKH là mã, trông giống khóa". Phép thử đúng là xem MaKH có nằm trong khóa (SoHD, MaSP) hay không. Không nằm, nên đây là phụ thuộc bắc cầu: SoHD quyết định MaKH, MaKH lại quyết định TenKH, nên SoHD quyết định TenKH "qua cầu" MaKH.

Tập phụ thuộc cũng giúp tìm khóa mà không cần đoán. Bắt đầu từ các cột không đứng ở vế phải của phụ thuộc nào, vì chúng bắt buộc phải nằm trong khóa; với sổ bán hàng đó là SoHD và MaSP. Sau đó lần theo các mũi tên trong Hình 1: từ hai cột này có đi tới được mọi cột còn lại không? Có, nên (SoHD, MaSP) là khóa.

3. Ba dạng chuẩn 1NF, 2NF, 3NF

Chuẩn hóa đưa bảng qua một chuỗi dạng chuẩn (normal form), mỗi dạng loại bỏ một loại phụ thuộc gây dị thường bằng cách tách bảng (Jukić, 2025). Các dạng chuẩn lồng nhau: bảng ở 3NF thì đã ở 2NF, bảng ở 2NF thì đã ở 1NF. Hình 2 tóm tắt ba bước trên sổ bán hàng; các tiểu mục sau giải thích từng bước.

Hình 2. Ba bước chuẩn hóa sổ bán hàng. Nguồn: dựa trên Jukić (2025).

3.1. Dạng chuẩn thứ nhất

Bảng ở dạng chuẩn thứ nhất (1NF) khi mọi ô chứa đúng một giá trị và không có nhóm lặp (Jukić, 2025). Sổ 8.554 dòng đã đạt 1NF. Nhưng nhiều sổ tự phát được ghi theo kiểu "một dòng một hóa đơn", với một ô liệt kê mọi mặt hàng như "SV0807 x2; SV0815 x1". Ô như vậy không lọc, không cộng và không kiểm tra được từng mặt hàng.

Đưa về 1NF là tách mỗi mặt hàng thành một dòng và chép thông tin chung của hóa đơn xuống từng dòng. Điều trớ trêu là bước này tăng dư thừa. Mục tiêu của 1NF không phải giảm dư thừa mà làm cho từng giá trị truy cập được riêng lẻ; giảm dư thừa là việc của hai bước tiếp theo.

3.2. Dạng chuẩn thứ hai

Bảng ở dạng chuẩn thứ hai (2NF) khi đã ở 1NF và không có phụ thuộc bộ phận. Cách sửa: với mỗi phần khóa đứng ở vế trái của phụ thuộc bộ phận, tách ra một bảng mới gồm phần khóa đó và các cột nó quyết định; bảng gốc chỉ giữ khóa và các cột phụ thuộc đầy đủ. Sổ bán hàng tách thành ba bảng: chi tiết hóa đơn (SoHD, MaSP, SoLuong, DonGiaBan), hóa đơn (SoHD và những gì SoHD quyết định) và sản phẩm (MaSP và những gì MaSP quyết định).

Một chi tiết giúp tiết kiệm thời gian: bảng có khóa chính một cột thì không thể có phụ thuộc bộ phận, vì một cột không có "một phần". Bảng như thế, nếu đã ở 1NF, tự động ở 2NF. Kiểm tra 2NF chỉ đáng làm với bảng có khóa phức hợp. Sau bước này, dị thường đổi tên nhóm vẫn còn nguyên, vì TenNhom vẫn nằm trong bảng sản phẩm.

3.3. Dạng chuẩn thứ ba

Bảng ở dạng chuẩn thứ ba (3NF) khi đã ở 2NF và không có phụ thuộc bắc cầu. Cách sửa tương tự: mỗi cột ngoài khóa đứng ở vế trái của phụ thuộc bắc cầu trở thành khóa của một bảng mới, còn ở bảng cũ nó ở lại làm khóa ngoại. Bảng hóa đơn tách ra khách hàng, cửa hàng và nhân viên; bảng sản phẩm tách ra nhóm hàng. Kết quả là bảy bảng, trong đó mỗi cột phụ thuộc vào khóa, vào toàn bộ khóa và không vào gì khác ngoài khóa.

Kết quả này trùng với bảy bảng mà ta có được khi đi từ sơ đồ ER xuống. Sự trùng khớp không phải ngẫu nhiên: hai con đường, một đi từ yêu cầu của người dùng, một đi từ cuốn sổ có sẵn, cùng diễn đạt những quy tắc nghiệp vụ như nhau, một bên bằng bản số, một bên bằng phụ thuộc hàm. Bảng 2 đo kích thước dữ liệu trước và sau khi tách.

Bảng 2. Số ô dữ liệu trước và sau khi chuẩn hóa sổ bán hàng (tình huống giả định)

Sau khi tách, số ô chỉ còn 41,0% so với ban đầu, dù bảng sản phẩm lưu đủ 1.200 sản phẩm của danh mục, nhiều hơn 1.147 sản phẩm thực sự có trong sổ. Cần đọc Bảng 2 cho đúng: tiết kiệm dung lượng chỉ là hệ quả phụ, vì vài chục nghìn ô chẳng đáng kể với ổ đĩa ngày nay. Điều quan trọng nằm ở cột cuối của Bảng 1: đổi tên nhóm giờ chỉ chạm một ô và không thao tác nào có thể để lại hai tên cho cùng một nhóm. Cái giá là muốn in lại sổ như cũ phải kết nối bảy bảng, một câu truy vấn được trình bày trong bài SQL từ cơ bản đến nâng cao.

4. BCNF và cái giá của chuẩn hóa cao hơn

3NF loại bỏ phụ thuộc có vế trái ngoài khóa và vế phải cũng ngoài khóa. Còn một trường hợp lọt qua: vế trái ngoài khóa nhưng vế phải nằm trong khóa. Dạng chuẩn Boyce–Codd (BCNF) đóng nốt khe hở này bằng một điều kiện gọn hơn: mọi yếu tố quyết định đều phải là khóa ứng viên (Elmasri & Navathe, 2016).

Xét một chương trình tư vấn giả định: mỗi khách hạng Vàng có một nhân viên tư vấn riêng cho từng nhóm hàng và mỗi nhân viên tư vấn chỉ phụ trách một nhóm. Bảng TUVAN(MaKH, NhomHang, MaNVTuVan) có khóa (MaKH, NhomHang) và thêm phụ thuộc MaNVTuVan → NhomHang. Phụ thuộc này không vi phạm 3NF vì NhomHang thuộc khóa, nhưng vi phạm BCNF vì MaNVTuVan không phải khóa. Dị thường vẫn có thật: nhân viên đổi nhóm phụ trách thì phải sửa mọi dòng của họ và nhân viên mới chưa có khách thì không có chỗ ghi nhóm phụ trách.

Tách TUVAN để đạt BCNF lại có một cái giá ít được nhắc tới. Sau khi tách, quy tắc "mỗi khách có một nhân viên tư vấn cho mỗi nhóm hàng" không còn là khóa của bảng nào, nên hệ quản trị cơ sở dữ liệu không tự cưỡng chế được nữa. Người thiết kế phải chọn giữa giữ dị thường (ở lại 3NF) và mất khả năng cưỡng chế một quy tắc (lên BCNF rồi cài thêm ràng buộc). Trong thực tế, bảng đạt 3NF mà vi phạm BCNF khá hiếm và phần lớn thiết kế dừng ở 3NF là đủ. Bảng 3 tóm tắt bốn dạng chuẩn.

Bảng 3. Bốn dạng chuẩn và loại phụ thuộc mà mỗi dạng loại bỏ

Nguồn: dựa trên Jukić (2025) và Elmasri & Navathe (2016).

5. Phi chuẩn hóa có chủ đích

Phi chuẩn hóa (denormalization) là cố ý đưa một bảng về dạng chuẩn thấp hơn, thường bằng cách gộp lại hai bảng đã tách hoặc lưu một giá trị dẫn xuất, để đổi lấy tốc độ đọc (Jukić, 2025). Ví dụ điển hình là lưu cột TongTien trong bảng hóa đơn để báo cáo doanh thu không phải cộng hàng trăm nghìn dòng chi tiết mỗi lần chạy. Cái giá là TongTien phải luôn khớp với các dòng chi tiết: mỗi lần thêm, sửa, xóa một dòng hàng, tổng phải tính lại, tốt nhất giao cho chính hệ quản trị qua trigger thay vì trông vào mã ứng dụng.

Hai cạm bẫy đối xứng nằm ở hai đầu. "Chuẩn hóa càng cao càng tốt" bỏ qua cái giá của việc tách: nhiều bảng hơn, truy vấn kết nối nhiều hơn và như ví dụ TUVAN cho thấy, đôi khi mất khả năng cưỡng chế một quy tắc. Ngược lại, "phi chuẩn hóa cho nhanh" đánh đổi một vấn đề đo được (truy vấn chậm vài phần mười giây) lấy một vấn đề không thấy được (dữ liệu âm thầm mâu thuẫn). Quy tắc thực hành an toàn là cơ sở dữ liệu tác nghiệp mặc định ở 3NF và chỉ phi chuẩn hóa khi đã đo được vấn đề hiệu năng và đã có cơ chế giữ dữ liệu đồng bộ.

Có một nơi mà phi chuẩn hóa là thiết kế chủ đạo chứ không phải ngoại lệ: kho dữ liệu dùng cho phân tích. Ở đó dữ liệu chỉ được đọc, được nạp định kỳ, nên dị thường cập nhật gần như không xảy ra, còn tốc độ đọc là ưu tiên số một. Bài Lược đồ hình sao, bảng sự kiện và bảng chiều cho thấy các bảng chiều được cố ý giữ ở dạng chưa chuẩn hóa vì lý do này.

AI giúp được việc chuẩn hóa ở hai chỗ: liệt kê các phụ thuộc hàm ứng viên từ danh sách cột và kiểm tra một lược đồ đã tách có còn phụ thuộc bộ phận hay bắc cầu không. Nhưng AI mắc đúng cạm bẫy ở Mục 2.1: nó suy phụ thuộc từ tên cột và từ dữ liệu mẫu, nên mỗi phụ thuộc nó đề xuất phải được người hiểu nghiệp vụ xác nhận. Bài Trí tuệ nhân tạo cho dữ liệu văn phòng có thêm ví dụ.

Kết luận

Chuẩn hóa không phải nghi thức học thuật mà là câu trả lời cho một câu hỏi rất thực tế: một sự thật nên được lưu ở đâu. Sổ bán hàng của Sen Vàng Mart cho thấy câu trả lời sai tốn bao nhiêu: 767 dòng phải sửa khi đổi một tên nhóm, 209 khách có nguy cơ mất thông tin, 53 sản phẩm không có chỗ ghi. Phụ thuộc hàm là công cụ để trả lời đúng và ba dạng chuẩn 1NF, 2NF, 3NF là ba bước tách bảng theo từng loại phụ thuộc.

Chuẩn hóa cũng có giới hạn. BCNF đôi khi đổi dị thường lấy việc mất một quy tắc, còn phi chuẩn hóa có chủ đích là lựa chọn hợp lý khi đã đo được vấn đề tốc độ. Điểm chung của cả hai cạm bẫy là áp dụng một nguyên tắc mà không hỏi nguyên tắc đó phục vụ quyết định nào. Cơ sở dữ liệu tác nghiệp đứng ở 3NF; kho dữ liệu phân tích thì đi theo hướng khác.

Đọc thêm

• Mô hình thực thể liên kết ER và cách đọc bản số
• Quy trình phát triển hệ thống cơ sở dữ liệu
• SQL từ cơ bản đến nâng cao
• Kho dữ liệu là gì và khi nào doanh nghiệp cần nó
• Lược đồ hình sao, bảng sự kiện và bảng chiều

Tài liệu tham khảo

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685

Elmasri, R., & Navathe, S. B. (2016). Fundamentals of database systems (7th ed.). Pearson. https://www.pearson.com/en-us/subject-catalog/p/fundamentals-of-database-systems/P200000003546/9780137502523

Jukić, N. (2025). Database systems: Introduction to databases and data warehouses (3rd ed.). Prospect Press. https://www.prospectpressvt.com/textbooks/jukic-database-systems-introduction-to-databases-and-data-warehouses-3-0