← Về danh sách
Cơ sở dữ liệu
#정규화#이상현상#함수종속#반정규화#무결성#129회#125회
Cập nhật lần cuối · 2026-09-22

Chuẩn hóa cơ sở dữ liệu (Normalization)

1. Tổng quan

A. Định nghĩa

Chuẩn hóa là quá trình thiết kế có hệ thống trong cơ sở dữ liệu quan hệ, nhằm loại bỏ dư thừa dữ liệu và ngăn ngừa các dị thường (Anomaly) bằng cách phân rã không mất mát (Lossless Decomposition) một quan hệ (bảng) thành nhiều quan hệ nhỏ hơn dựa trên phụ thuộc hàm (Functional Dependency).

Lý do căn bản cần chuẩn hóa nằm ở chỗ 'nếu dồn thông tin thuộc các chủ đề khác nhau vào một bảng thì sẽ phát sinh dư thừa, và chính sự dư thừa đó gây ra dị thường'. Ví dụ, nếu đưa thông tin khoa·giáo viên hướng dẫn của sinh viên vào cùng bảng đăng ký học phần, mỗi khi cùng một sinh viên đăng ký nhiều môn, giá trị khoa·giáo viên hướng dẫn sẽ bị lưu lặp lại trên từng dòng. Ban đầu nó trông như một sự lãng phí không gian lưu trữ nhỏ nhặt, nhưng sự dư thừa này tạo ra lỗi tiềm ẩn ở mọi thời điểm chèn·xóa·sửa dữ liệu. Việc E. F. Codd, người sáng lập mô hình quan hệ, đưa ra khái niệm dạng chuẩn (Normal Form) vào thập niên 1970 cũng là để giải quyết bằng toán học vấn đề toàn vẹn "phải bố trí dữ liệu như thế nào để không phát sinh mâu thuẫn khi cập nhật".

Tư tưởng cốt lõi của chuẩn hóa được tóm tắt thành "một sự thật chỉ được lưu ở đúng một nơi (One Fact, One Place)". Khi tách dữ liệu của các chủ đề (thực thể) khác nhau thành các bảng riêng và liên kết bằng khóa ngoại (FK), mọi sự thật chỉ được ghi đúng một lần trong toàn bộ cơ sở dữ liệu. Khi thay đổi giá trị chỉ cần sửa một nơi, nên mâu thuẫn về căn bản không thể xảy ra. Tức là chuẩn hóa không đơn thuần là kỹ thuật chia nhỏ bảng mà là nguyên tắc thiết kế đặt dữ liệu vào đúng vị trí về mặt logic, và là thước đo cơ bản nhất quyết định chất lượng của schema.

Ngoài ra, chuẩn hóa còn là quá trình làm rõ ý nghĩa của thực thể. Nếu một bảng trộn lẫn hai khái niệm sinh viên và đăng ký học phần thì bảng đó "biểu diễn cái gì" trở nên mơ hồ. Khi phân rã bảng thông qua chuẩn hóa, mỗi bảng chỉ chứa một chủ đề rõ ràng, nên bản thân schema phản ánh nguyên vẹn cấu trúc khái niệm của miền nghiệp vụ. Ở điểm này, chuẩn hóa cũng có thể được xem là bước tinh chỉnh cuối cùng của mô hình hóa dữ liệu (thiết kế khái niệm→logic).

B. Sự cần thiết

Nếu để mặc dư thừa, vấn đề không chỉ dừng ở lãng phí không gian lưu trữ mà khi cập nhật, chỉ một phần trong nhiều dòng được thay đổi, dẫn đến vấn đề toàn vẹn nghiêm trọng khi dữ liệu mâu thuẫn với nhau. Đặc biệt với các dữ liệu mà độ chính xác gắn trực tiếp với niềm tin vào dịch vụ như số dư tài khoản·số lượng tồn kho·hạng khách hàng, dư thừa là chết người. Chuẩn hóa là điểm khởi đầu của thiết kế cơ sở dữ liệu đáng tin cậy, bảo đảm tính toàn vẹn logic (Consistency) ở cấp cấu trúc schema. Ngược lại, trong hệ thống phân tích nơi hiệu năng truy vấn là ưu tiên hàng đầu, người ta đôi khi nới lỏng chuẩn hóa (phi chuẩn hóa), và để đánh giá điểm cân bằng này, trước hết phải hiểu chính xác nguyên lý của chuẩn hóa.

2. Nguyên lý phát sinh dị thường (Anomaly)

Cách nhanh nhất để hiểu chuẩn hóa là xem "nếu không chuẩn hóa thì điều gì sẽ xảy ra". <Bảng đăng ký học phần> dưới đây (khóa chính: {Mã SV, Mã học phần}) là thiết kế chưa chuẩn hóa, trộn lẫn thông tin sinh viên và thông tin đăng ký học phần vào một bảng.

Mã SV Khoa Giáo viên hướng dẫn Mã học phần
221571 Khoa Máy tính K1 C412
221571 Khoa Máy tính K1 C511
221572 Khoa Máy tính M1 C412
211561 Khoa Toán P2 C324

Nhìn bảng này, sinh viên mã 221571 đăng ký hai môn (C412, C511), nên khoa (Khoa Máy tính) và giáo viên hướng dẫn (K1) bị lưu giống hệt nhau hai lần. Nguyên nhân căn bản của dị thường nằm chính ở đây. Các thuộc tính không phải khóa chính là khoa·giáo viên hướng dẫn chỉ phụ thuộc vào một phần của khóa chính là mã SV (phụ thuộc hàm bộ phận, Partial Dependency) chứ không phụ thuộc vào toàn bộ khóa chính {Mã SV, Mã học phần}, vậy mà vẫn bị lưu lặp lại không cần thiết theo số dòng do phần còn lại của khóa chính (mã học phần) tạo ra. Khiếm khuyết cấu trúc này biểu hiện thành ba loại dị thường: chèn, xóa và cập nhật.

Thứ nhất, dị thường chèn (Insertion Anomaly) là vấn đề phải miễn cưỡng đưa vào cả dữ liệu không mong muốn. Ngay cả khi muốn lưu thông tin khoa của một tân sinh viên chưa đăng ký môn nào, nếu mã học phần — một phần của khóa chính — là NULL thì không thể tạo dòng, nên không thể đưa chính thông tin sinh viên vào. Tức là ràng buộc phi thực tế "phải đăng ký học phần thì mới được ghi nhận là sinh viên" bị áp đặt do cấu trúc dữ liệu.

Thứ hai, dị thường xóa (Deletion Anomaly) là vấn đề khi muốn xóa một thứ lại mất luôn cả thông tin không liên quan. Nếu sinh viên 211561 hủy đăng ký C324 — học phần duy nhất đang học — và dòng đó bị xóa, thì thông tin khoa (Khoa Toán)·giáo viên hướng dẫn (P2) được lưu cùng cũng biến mất, khiến chính sự tồn tại của sinh viên bị xóa khỏi cơ sở dữ liệu. Nguyên nhân là hai sự thật riêng biệt — lịch sử đăng ký học phần và thông tin cá nhân của sinh viên — bị gắn vào một dòng.

Thứ ba, dị thường cập nhật (Update Anomaly) là loại nguy hiểm nhất, khi chỉ một phần trong các giá trị trùng lặp được sửa khiến dữ liệu mâu thuẫn. Nếu khoa của sinh viên 221571 đổi từ Khoa Máy tính sang Khoa Phần mềm, phải sửa không sót mọi dòng liên quan đến sinh viên đó (C412, C511). Nếu chỉ sửa một dòng và bỏ sót dòng khác, khoa của cùng một sinh viên sẽ đồng thời được ghi thành hai giá trị, rơi vào trạng thái không biết "cái nào là thật".

Dị thường Triệu chứng Nguyên nhân căn bản
Dị thường chèn Không thể chèn thông tin sinh viên nếu chưa đăng ký học phần Một phần của khóa chính (mã học phần) là NULL thì không tạo được dòng
Dị thường xóa Xóa học phần cuối cùng thì thông tin sinh viên cũng mất Hai sự thật sinh viên·đăng ký học phần trộn lẫn trong một dòng
Dị thường cập nhật Đổi khoa nhưng chỉ sửa một số dòng→mâu thuẫn Thông tin khoa bị lưu trùng lặp ở nhiều dòng

3. Giải pháp — phân rã không mất mát dựa trên phụ thuộc hàm

Giải pháp cho dị thường rất rõ ràng: tách bảng để loại bỏ phụ thuộc hàm bộ phận. Tách khoa·giáo viên hướng dẫn — vốn chỉ phụ thuộc vào mã SV — thành một bảng sinh viên riêng, còn bảng quan hệ đăng ký học phần chỉ giữ lại khóa chính {Mã SV, Mã học phần}. Dưới đây là sơ đồ cấu trúc cho thấy bảng gốc được phân rã thành hai bảng có chủ đề rõ ràng.

flowchart LR
  O["Bảng đăng ký học phần (chưa chuẩn hóa)<br/>Mã SV·Khoa·GVHD·Mã học phần"] --> S["Bảng sinh viên<br/>Mã SV(PK) → Khoa·GVHD"]
  O --> E["Bảng đăng ký học phần<br/>Mã SV·Mã học phần(PK)"]
  E -. "Mã SV(FK)" .-> S
  style O fill:#fdecea,stroke:#d64b3a,stroke-width:2px
  style S fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style E fill:#e6f4ea,stroke:#137333,stroke-width:2px

Kết quả phân rã như sau. Trong bảng sinh viên, khoa·giáo viên hướng dẫn chỉ được lưu một lần cho mỗi sinh viên, còn bảng đăng ký học phần chỉ thuần túy biểu diễn quan hệ "ai học môn gì".

Bảng sinh viên (khóa chính: Mã SV)

Mã SV Khoa Giáo viên hướng dẫn
221571 Khoa Máy tính K1
221572 Khoa Máy tính M1
211561 Khoa Toán P2

Bảng đăng ký học phần (khóa chính: {Mã SV, Mã học phần})

Mã SV Mã học phần
221571 C412
221571 C511
211561 C324

Tách như vậy thì cả ba dị thường được giải quyết đồng thời. Tân sinh viên được đăng ký vào bảng sinh viên chỉ với thông tin khoa nên dị thường chèn biến mất; dù hủy mọi học phần thì thông tin cá nhân trong bảng sinh viên vẫn còn nên dị thường xóa không còn; việc đổi khoa chỉ cần sửa đúng một dòng trong bảng sinh viên nên dị thường cập nhật bị loại bỏ tận gốc. Điểm quan trọng là phân rã này là không mất mát (Lossless). Khi kết nối (JOIN) lại hai bảng theo mã SV, có thể khôi phục chính xác thông tin ban đầu, tức là chia nhỏ dữ liệu mà không mất một chút ý nghĩa nào. Đây là lý do chuẩn hóa không phải là xóa bỏ đơn thuần mà là "phân rã an toàn".

4. Các dạng chuẩn (Normal Forms) và quy trình thực hiện

Chuẩn hóa không diễn ra trong một lần mà được tiến hành dần qua các bậc 1NF→2NF→3NF→BCNF→4NF→5NF tùy theo loại phụ thuộc cần loại bỏ. Trong thực tiễn, phần lớn dị thường được giải quyết ở 3NF hoặc BCNF, nên thông thường lấy 3NF/BCNF làm mục tiêu. Mỗi bậc có cấu trúc tích lũy, đòi hỏi thêm điều kiện mới trên cơ sở đã thỏa mãn bậc trước.

flowchart TB
  A["Quan hệ chưa chuẩn hóa"] --> B["1NF: Giá trị nguyên tử<br/>Loại bỏ nhóm lặp·đa trị"]
  B --> C["2NF: Loại bỏ phụ thuộc hàm bộ phận<br/>Phụ thuộc đầy đủ vào toàn bộ khóa chính"]
  C --> D["3NF: Loại bỏ phụ thuộc hàm bắc cầu<br/>Không phụ thuộc bắc cầu"]
  D --> E["BCNF: Mọi định thuộc đều là khóa ứng viên"]
  E --> F["4NF/5NF: Loại bỏ phụ thuộc đa trị·phụ thuộc kết nối"]
  style A fill:#fdecea,stroke:#d64b3a
  style D fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style E fill:#e6f4ea,stroke:#137333,stroke-width:2px

Dạng chuẩn thứ nhất (1NF) yêu cầu mọi thuộc tính có giá trị nguyên tử (Atomic Value) không thể chia nhỏ hơn. Nếu một ô chứa nhiều giá trị ngăn cách bằng dấu phẩy như "C412, C511" hoặc có các cột lặp (Môn1, Môn2) thì vi phạm 1NF. Khi đó, tách mỗi giá trị thành một dòng riêng để loại bỏ nhóm lặp. 1NF tương ứng với điều kiện tư cách tối thiểu của một bảng quan hệ.

Dạng chuẩn thứ hai (2NF) là trạng thái thỏa mãn 1NF và loại bỏ phụ thuộc hàm bộ phận. Như ví dụ ở mục trước, khi khóa chính là khóa phức hợp ({Mã SV, Mã học phần}), tách các thuộc tính (khoa·giáo viên hướng dẫn) chỉ phụ thuộc vào một phần của khóa chính (mã SV) thì đạt 2NF. Nếu khóa chính là một thuộc tính đơn thì bản thân phụ thuộc bộ phận không tồn tại, nên đạt 1NF là tự động đạt 2NF.

Dạng chuẩn thứ ba (3NF) là trạng thái thỏa mãn 2NF và loại bỏ phụ thuộc hàm bắc cầu (Transitive Dependency). Ví dụ, nếu có (Mã SV→Khoa) và (Khoa→Trường thành viên) thì tồn tại phụ thuộc bắc cầu Mã SV→Trường thành viên. Khi đó, nếu khoa thay đổi thì trường thành viên cũng phải được quản lý theo, phát sinh dư thừa, nên tách Khoa-Trường thành viên thành bảng riêng. Phần lớn đường mục tiêu của schema thực tiễn nằm ở đây.

BCNF (Boyce-Codd Normal Form) tăng cường 3NF, đòi hỏi điều kiện mọi định thuộc (Determinant) phải là khóa ứng viên (Candidate Key). Đây là bậc nhằm loại bỏ dị thường còn sót lại dù đã thỏa mãn 3NF trong tình huống đặc biệt có nhiều khóa ứng viên chồng lấn nhau, thường xuất hiện trong hệ thống đặt chỗ (phân công đan xen sinh viên·môn học·giảng viên, v.v.). Tuy nhiên, phân rã BCNF có thể phá vỡ việc bảo toàn phụ thuộc hàm (Dependency Preservation), nên trong thực tiễn cần xem xét sự đánh đổi giữa 3NF và BCNF rồi mới quyết định mức áp dụng.

Quy trình thực hiện chuẩn hóa trên thực tế được tóm tắt như sau. Thứ nhất, xác định đầy đủ mọi thuộc tính của quan hệ đối tượng và các phụ thuộc hàm giữa chúng. Thứ hai, xác lập khóa ứng viên và khóa chính. Thứ ba, bắt đầu từ 1NF, lần lượt tìm các phụ thuộc vi phạm của từng bậc (nhóm lặp→phụ thuộc bộ phận→phụ thuộc bắc cầu→định thuộc không phải khóa ứng viên) và tách các thuộc tính tương ứng thành quan hệ mới. Thứ tư, kiểm chứng xem khi kết nối lại các quan hệ đã tách thì bản gốc có được khôi phục không (kết nối không mất mát) và các phụ thuộc ban đầu có được bảo toàn không. Thay vì tuân theo quy trình này một cách máy móc, cốt lõi để có schema đúng đắn là đồng thời xác nhận mỗi phép phân rã có khớp với quy tắc nghiệp vụ (ý nghĩa miền) hay không.

Bậc Điều kiện thỏa mãn Đối tượng loại bỏ
1NF Mọi thuộc tính là giá trị nguyên tử Nhóm lặp·đa trị
2NF Phụ thuộc hàm đầy đủ vào toàn bộ khóa chính Phụ thuộc hàm bộ phận
3NF Không có phụ thuộc bắc cầu Phụ thuộc hàm bắc cầu
BCNF Mọi định thuộc đều là khóa ứng viên Dị thường còn lại do khóa ứng viên chồng lấn
4NF Không có phụ thuộc đa trị Phụ thuộc đa trị (MVD)
5NF Không có phụ thuộc kết nối Phụ thuộc kết nối (PJNF)

5. Chuyên sâu — đánh đổi thực tiễn giữa chuẩn hóa và phi chuẩn hóa (De-normalization)

Về lý thuyết, bậc chuẩn hóa càng cao thì tính toàn vẹn càng tốt, nhưng trong thực tiễn dạng chuẩn cao hơn không phải lúc nào cũng là đáp án. Chuẩn hóa chia nhỏ bảng, nên số trường hợp phải kết nối (JOIN) nhiều bảng để tạo ra một màn hình·báo cáo tăng lên. Phép kết nối tiêu tốn CPU·bộ nhớ và trở thành thủ phạm chính gây trễ phản hồi trong môi trường truy vấn dung lượng lớn·tần suất cao. Vì vậy xuất hiện phi chuẩn hóa, kỹ thuật thiết kế theo chiều ngược lại, cố ý cho phép dư thừa hoặc gộp bảng vì hiệu năng.

Ví dụ tiêu biểu là lược đồ hình sao (Star Schema) của kho dữ liệu (DW). Hệ thống phân tích chủ yếu là truy vấn tổng hợp lượng lớn như "tổng doanh thu theo khu vực·sản phẩm của quý trước", và nếu mỗi lần đều kết nối hàng chục bảng đã chuẩn hóa thì không đạt được hiệu năng. Vì vậy, bố trí các bảng chiều (Dimension) xung quanh bảng sự kiện (Fact), và trong bảng chiều cố ý lưu trùng lặp (phi chuẩn hóa) các giá trị như tên khu vực·phân loại sản phẩm để giảm thiểu số lần kết nối. Trong thương mại điện tử, việc tính trước và lưu "số lượng đánh giá" hay "điểm đánh giá trung bình" vào bảng sản phẩm cho màn hình danh sách sản phẩm cũng là phi chuẩn hóa theo cùng nguyên lý. Thay vì tổng hợp bảng đánh giá ở mỗi lần truy vấn, chỉ cập nhật bộ đếm khi có đánh giá mới được thêm vào, qua đó cải thiện đáng kể hiệu năng đọc.

Cốt lõi là phi chuẩn hóa không phải là thất bại của chuẩn hóa mà là lựa chọn có ý thức dựa trên tiền đề đã chuẩn hóa. Trước hết phải có được cấu trúc logic đúng đắn bằng chuẩn hóa, sau đó chỉ áp dụng phi chuẩn hóa cho những phần đã xác nhận có nút thắt hiệu năng qua đo đạc thực tế. Việc để mặc dư thừa ngay từ đầu mà không chuẩn hóa hoàn toàn khác với việc đưa vào dư thừa có kiểm soát sau khi đã chuẩn hóa. Vì trong trường hợp sau, trách nhiệm duy trì tính nhất quán của giá trị trùng lặp (trigger·batch·logic ứng dụng) được quản lý rõ ràng. Hiệu năng và tính toàn vẹn là hai mục tiêu xung đột, vì vậy Kỹ sư chuyên nghiệp (Professional Engineer) phải có khả năng đánh giá điểm cân bằng này tùy theo tính chất của hệ thống (OLTP lấy giao dịch làm trung tâm hay OLAP lấy truy vấn làm trung tâm).

6. Lưu ý và hàm ý

  1. Đánh giá đánh đổi giữa chuẩn hóa và hiệu năng là cốt lõi của năng lực thiết kế. Chuẩn hóa nâng cao tính toàn vẹn nhưng có thể làm giảm hiệu năng truy vấn do số phép kết nối tăng. Cách tiếp cận hai hướng là phù hợp: hệ thống tài khoản·sổ cái ưu tiên tính toàn vẹn thì chuẩn hóa đến 3NF/BCNF, còn hệ thống phân tích·thống kê ưu tiên hiệu năng truy vấn thì áp dụng phi chuẩn hóa một cách chiến lược (lược đồ hình sao, cột tổng hợp).

  2. Phân tích chính xác phụ thuộc hàm là tiền đề của phân rã đúng đắn. Nếu không xác định chính xác ở cấp quy tắc nghiệp vụ "thuộc tính nào được quyết định bởi cái gì", việc chia bảng theo khóa sai có thể ngược lại làm phá vỡ phân rã không mất mát hoặc tạo ra các phép kết nối không cần thiết. Cần đưa việc lập sơ đồ phụ thuộc (FD Diagram) và kiểm chứng của chuyên gia miền vào quy trình thiết kế.

  3. Tách kiến trúc theo tiêu chí OLTP chuẩn hóa, OLAP phi chuẩn hóa. Hệ thống vận hành coi trọng toàn vẹn giao dịch tích lũy dữ liệu an toàn bằng schema đã chuẩn hóa, còn truy vấn·phân tích được nạp qua ETL vào kho phân tích riêng đã phi chuẩn hóa (DW/data mart) để xử lý. Tách workload như vậy có thể đạt đồng thời tính toàn vẹn và hiệu năng.

  4. Khi phi chuẩn hóa, bắt buộc thiết kế kèm cơ chế duy trì tính nhất quán của dữ liệu trùng lặp. Nếu đã đưa vào cột tổng hợp·cột trùng lặp, phải chuẩn bị tường minh trigger·CDC·batch hoặc logic ứng dụng để đồng bộ khi dữ liệu nguồn thay đổi. Phi chuẩn hóa mà trách nhiệm đồng bộ không rõ ràng sẽ dẫn đến kết quả làm sống lại dị thường cập nhật một cách nhân tạo.

  5. Ngay cả trong thời đại NoSQL·DB tài liệu, nguyên lý chuẩn hóa vẫn còn hiệu lực. Các DB tài liệu như MongoDB khuyến nghị nhúng (Embedding, phi chuẩn hóa) dữ liệu vì hiệu năng truy vấn, nhưng điều đó không có nghĩa là không cần biết nguyên lý chuẩn hóa, mà là lựa chọn có chủ đích theo mẫu truy cập trên nền hiểu rõ sự đánh đổi giữa chuẩn hóa và phi chuẩn hóa. Phải biết nguyên lý thì mới đánh giá được nên chọn tham chiếu (Reference) hay nhúng (Embedding).

Tài liệu tham khảo


Tóm tắt một câu: Chuẩn hóa là nguyên tắc thiết kế (1NF→2NF→3NF→BCNF) phân rã không mất mát các bảng theo phụ thuộc hàm nhằm loại bỏ dư thừa và ngăn ngừa dị thường (chèn·xóa·cập nhật), loại bỏ phụ thuộc bộ phận·bắc cầu để bảo đảm tính toàn vẹn, đồng thời cân bằng một cách chiến lược với phi chuẩn hóa trong hệ thống phân tích cần hiệu năng truy vấn.