Chuẩn hoá cơ sở dữ liệu là gì?

Mục lục

1. Chuẩn hoá cơ sở dữ liệu là gì?
2. Vì sao bảng “phẳng” gây lỗi? Ba dị thường cần nhớ
3. Các dạng chuẩn hoạt động thế nào qua một ví dụ đơn hàng
4. Viết ra bằng SQL trông thế nào?
5. Chuẩn hoá khác gì với các khái niệm gần nó?
6. Ưu điểm và nhược điểm
7. Khi nào nên chuẩn hoá, khi nào nên phi chuẩn hoá?
8. Dấu hiệu bảng của bạn cần chuẩn hoá
9. Lỗi thường gặp khi chuẩn hoá
10. Câu hỏi thường gặp

Chuẩn hoá cơ sở dữ liệu là gì?

Chuẩn hoá cơ sở dữ liệu là quá trình tổ chức lại các bảng theo một chuỗi quy tắc gọi là dạng chuẩn (normal forms). Kết quả là các bảng nhỏ hơn, mỗi bảng nói về một đối tượng, nối với nhau bằng khoá chính (primary key) và khoá ngoại (foreign key). Theo cách diễn đạt phổ biến, đích đến là mỗi sự kiện dữ liệu chỉ nằm ở đúng một nơi.

Kỹ thuật này gắn với mô hình quan hệ của Edgar F. Codd. Các hệ quản trị quan hệ ngày nay vẫn theo những nguyên tắc ông đề xuất. Nếu bạn chưa nắm nền tảng, hãy đọc trước bài cơ sở dữ liệu là gì và bài về cơ sở dữ liệu quan hệ.

Phân biệt hai nghĩa của “chuẩn hoá dữ liệu”

Từ khoá này hay bị lẫn nghĩa. Bảng dưới tách ba cách hiểu thường gặp.

Cách hiểu	Đối tượng tác động	Ví dụ
Chuẩn hoá lược đồ (bài này)	Cấu trúc bảng và quan hệ giữa bảng	Tách thông tin khách hàng khỏi bảng đơn hàng
Chuẩn hoá giá trị (data standardization)	Định dạng nội dung trong ô	Số điện thoại về dạng 10 số, tên tỉnh theo một danh mục
Chuẩn hoá thang đo (scaling)	Cột số trước khi huấn luyện mô hình	Đưa tuổi và thu nhập về cùng khoảng giá trị

Nghĩa thứ hai là phần việc của làm sạch dữ liệu. Nghĩa thứ ba thuộc quy trình chuẩn bị dữ liệu cho học máy. Hai nghĩa này không đổi cấu trúc bảng, nên bài này không đi sâu.

Vì sao bảng “phẳng” gây lỗi? Ba dị thường cần nhớ

Nhiều doanh nghiệp bắt đầu bằng một bảng tính lớn rồi nhập thẳng vào phần mềm. Bảng đó có dữ liệu lặp, và sự lặp sinh ra ba kiểu lỗi mà giáo trình gọi là dị thường (anomaly).

• Dị thường khi cập nhật: email của một khách hàng nằm ở 40 dòng đơn hàng. Bạn sửa 39 dòng, còn một dòng giữ email cũ. Hệ thống giờ có hai sự thật.
• Dị thường khi chèn: bạn muốn thêm sản phẩm mới vào danh mục nhưng chưa có đơn nào. Bảng đơn hàng buộc phải có mã đơn, nên sản phẩm không có chỗ để lưu.
• Dị thường khi xoá: xoá đơn hàng cuối cùng của một khách thì mất luôn thông tin liên hệ của khách đó.

Chuẩn hoá nhằm chặn cả ba. Nó đảm bảo mỗi phần dữ liệu chỉ được lưu trữ ở một vị trí, giúp duy trì tính nhất quán dễ dàng hơn.

Các dạng chuẩn hoạt động thế nào qua một ví dụ đơn hàng

Ví dụ minh hoạ: một cửa hàng phân phối đồ gia dụng ghi mọi thứ vào một bảng DonHang_phang. Mỗi dòng gồm: ma_don, ngay, ma_kh, ten_kh, email_kh, danh sách sản phẩm trong một ô (ví dụ “SP01, SP02”), ten_sp, don_gia, so_luong. Các bước dưới đây biến bảng đó thành lược đồ chuẩn.

Bước 1 – Dạng chuẩn 1 (1NF)

Quy tắc: mỗi ô chỉ chứa một giá trị và không có nhóm cột lặp. Theo mô tả quen thuộc, mỗi số điện thoại phải nằm ở một dòng riêng để không cột nào chứa nhiều giá trị. Với bảng ví dụ, ô “SP01, SP02” phải tách thành hai dòng: một dòng cho SP01, một dòng cho SP02. Khoá của bảng giờ là cặp (ma_don, ma_sp).

Sau 1NF, dữ liệu đã nguyên tử nhưng sự lặp càng lộ rõ: ten_kh, email_kh và ngay xuất hiện lại trên mọi dòng của cùng một đơn.

Bước 2 – Dạng chuẩn 2 (2NF)

Bảng phải đạt 1NF và mọi cột không thuộc khoá phải phụ thuộc vào toàn bộ khoá. Quy tắc này chỉ có ý nghĩa với khoá ghép, vì phụ thuộc một phần (partial dependency) chỉ xảy ra khi khoá gồm nhiều cột. Trong ví dụ:

• ten_sp và don_gia chỉ phụ thuộc ma_sp, không cần biết ma_don.
• ngay, ma_kh, ten_kh, email_kh chỉ phụ thuộc ma_don, không cần biết ma_sp.
• so_luong phụ thuộc cả hai, nên ở lại bảng chi tiết đơn hàng.

Tách ra ta có ba bảng: SanPham, DonHang và ChiTietDonHang.

Bước 3 – Dạng chuẩn 3 (3NF)

Bảng phải đạt 2NF và không có phụ thuộc bắc cầu (transitive dependency). Trong DonHang, ten_kh và email_kh không phụ thuộc trực tiếp vào ma_don. Chúng phụ thuộc ma_kh, còn ma_kh mới phụ thuộc ma_don. Đường đi ma_don → ma_kh → email_kh là phụ thuộc bắc cầu. Giải pháp là tách bảng KhachHang riêng, DonHang chỉ giữ ma_kh làm khoá ngoại.

Một chi tiết nhiều người bỏ sót: bảng chi tiết có cột gia_ban, còn SanPham có gia_niem_yet. Hai cột này không trùng lặp. Giá niêm yết đổi theo thời gian, còn giá bán ghi trong đơn phải giữ nguyên để báo cáo doanh thu quý trước không bị đổi khi bạn tăng giá. Chuẩn hoá không có nghĩa là xoá mọi cột trông giống nhau. Câu hỏi đúng là hai cột có cùng một sự thật hay không.

Bước 4 – BCNF và các dạng cao hơn

BCNF (Boyce-Codd Normal Form) chặt hơn 3NF một chút. Theo định nghĩa, bảng đạt BCNF khi ở 3NF và với mọi phụ thuộc hàm X → Y thì X phải là siêu khoá của bảng. Nó chỉ khác 3NF trong các bảng có nhiều khoá ứng viên chồng lấn, là tình huống hiếm ở dữ liệu nghiệp vụ thông thường. 4NF xử lý phụ thuộc đa trị, 5NF xử lý phụ thuộc nối. Hai dạng này ít khi cần trong hệ thống quản lý doanh nghiệp.

Viết ra bằng SQL trông thế nào?

Lược đồ trên chuyển thành câu lệnh SQL như sau. Cú pháp này chạy được trên các hệ quản trị quan hệ phổ biến, chỉ khác nhau chút ít về kiểu dữ liệu.

CREATE TABLE KhachHang (
  ma_kh INT PRIMARY KEY,
  ten_kh VARCHAR(100) NOT NULL,
  email_kh VARCHAR(150)
);
CREATE TABLE SanPham (
  ma_sp INT PRIMARY KEY,
  ten_sp VARCHAR(150) NOT NULL,
  gia_niem_yet DECIMAL(12,0)
);
CREATE TABLE DonHang (
  ma_don INT PRIMARY KEY,
  ngay DATE NOT NULL,
  ma_kh INT NOT NULL REFERENCES KhachHang(ma_kh)
);
CREATE TABLE ChiTietDonHang (
  ma_don INT REFERENCES DonHang(ma_don),
  ma_sp INT REFERENCES SanPham(ma_sp),
  so_luong INT NOT NULL,
  gia_ban DECIMAL(12,0) NOT NULL,
  PRIMARY KEY (ma_don, ma_sp)
);

Phần REFERENCES là ràng buộc khoá ngoại. Nó là cơ chế khiến chuẩn hoá có tác dụng thật: cơ sở dữ liệu từ chối một dòng chi tiết trỏ tới mã đơn không tồn tại. Nếu chỉ tách bảng mà không khai báo khoá ngoại, bạn mất tính toàn vẹn tham chiếu và lược đồ chỉ còn đẹp trên giấy.

Để xem báo cáo, bạn nối các bảng lại:

SELECT d.ma_don, k.ten_kh, s.ten_sp, c.so_luong, c.gia_ban
FROM ChiTietDonHang c
JOIN DonHang d ON d.ma_don = c.ma_don
JOIN KhachHang k ON k.ma_kh = d.ma_kh
JOIN SanPham s ON s.ma_sp = c.ma_sp;

Một báo cáo đơn giản giờ cần ba phép nối. Đây là cái giá của việc chuẩn hoá, sẽ nói rõ hơn ở phần sau.

Chuẩn hoá khác gì với các khái niệm gần nó?

Ba khái niệm dễ bị trộn với chuẩn hoá lược đồ:

• Mô hình hoá dữ liệu: chuẩn hoá là một công cụ kiểm tra bên trong bước thiết kế. Bức tranh rộng hơn, từ mô hình khái niệm đến vật lý, nằm trong bài data modeling là gì.
• Làm sạch dữ liệu: sửa giá trị sai, thiếu, trùng trong bảng đang có. Chuẩn hoá thay đổi cấu trúc chứa giá trị.
• Phi chuẩn hoá (denormalization): cố ý gộp hoặc nhân bản dữ liệu để đọc nhanh. Đây là bước ngược lại, có chủ đích.

Một điểm hay gây hiểu lầm: chuẩn hoá cũng không thay thế việc loại trùng bản ghi. Hai dòng khách “Nguyen Van A” và “Nguyễn Văn A” cùng email vẫn là hai khách trong bảng KhachHang đã đạt 3NF. Bài toán đó thuộc về quản trị dữ liệu chủ, xem bài về quản lý dữ liệu chủ.

Ưu điểm và nhược điểm

Tiêu chí	Khi chuẩn hoá	Khi phi chuẩn hoá
Dư thừa dữ liệu	Thấp, mỗi sự thật một chỗ	Cao, cố ý lặp
Sửa một giá trị	Một dòng	Nhiều dòng hoặc nhiều bảng
Truy vấn tổng hợp	Nhiều JOIN, chậm hơn khi dữ liệu lớn	Ít JOIN, nhanh hơn
Ghi dữ liệu (INSERT, UPDATE)	Gọn, ít khoá xung đột	Nặng hơn vì phải cập nhật nhiều nơi
Rủi ro sai lệch	Thấp	Cao nếu thiếu cơ chế đồng bộ
Độ dễ đọc với người làm báo cáo	Cần hiểu quan hệ giữa bảng	Một bảng rộng, dễ dùng

Nhược điểm cốt lõi được nêu khá nhất quán: mức chuẩn hoá càng cao thì bảng càng phân mảnh và cần nhiều phép nối hơn để lấy dữ liệu liên quan. Vì vậy câu trả lời đúng cho “chuẩn hoá đến mức nào” phụ thuộc vào cách dữ liệu được dùng.

Khi nào nên chuẩn hoá, khi nào nên phi chuẩn hoá?

Hãy nhìn hai đặc điểm của hệ thống: mức độ ghi và sửa dữ liệu, và mức độ truy vấn tổng hợp.

• Nên chuẩn hoá đến 3NF hoặc BCNF với hệ thống ghi liên tục như bán hàng, kho, kế toán, nhân sự. Đó là loại hệ thống xử lý giao dịch, đã phân tích trong bài OLAP và OLTP. Sai lệch ở đây gây hậu quả trực tiếp, ví dụ hai số tồn kho cho cùng một mặt hàng.
• Nên phi chuẩn hoá có kiểm soát với dữ liệu đọc nhiều, ít sửa, đặc biệt là kho dữ liệu. Ở đó, bảng sự kiện và bảng chiều (mô hình sao) cố ý lặp thuộc tính để báo cáo chạy ít phép nối. Dữ liệu nguồn vẫn là bản chuẩn hoá.
• Chưa cần chuẩn hoá sâu với bảng tạm, bảng nhập một lần để phân tích, hoặc dữ liệu dạng tài liệu lưu trong kho NoSQL, nơi lược đồ được thiết kế theo cách truy cập.

Lời khuyên thực tế được nhiều tài liệu kỹ thuật đồng thuận: nhắm tới 3NF hoặc BCNF cho phần lớn cơ sở dữ liệu sản xuất, và chỉ phi chuẩn hoá khi hiệu năng đọc đã đo được là chưa đạt. Nghĩa là bạn cần có truy vấn chậm thật, kèm kế hoạch thực thi (execution plan), trước khi gộp bảng.

Dấu hiệu bảng của bạn cần chuẩn hoá

Bạn không cần là kỹ sư mới nhận ra. Đây là các dấu hiệu quan sát được ngay trên dữ liệu đang chạy:

• Một ô chứa nhiều giá trị ngăn cách bằng dấu phẩy, ví dụ nhiều số điện thoại hoặc nhiều mã sản phẩm.
• Các cột đặt tên theo số thứ tự như dien_thoai_1, dien_thoai_2, dien_thoai_3.
• Cùng một khách hàng có nhiều cách viết tên hoặc nhiều địa chỉ khác nhau trong các dòng đơn hàng.
• Truy vấn SELECT DISTINCT trên một cột chỉ để “lấy danh sách” khách hàng hoặc sản phẩm. Điều này cho thấy danh mục đó chưa có bảng riêng.
• Bạn không thể thêm một đối tượng mới (nhà cung cấp, sản phẩm) nếu chưa có giao dịch liên quan.

Để biết mức độ lặp thực tế, hãy chạy phân tích hồ sơ dữ liệu. Đếm số giá trị khác biệt của email_kh so với số dòng sẽ cho thấy một khách đang bị lưu bao nhiêu lần.

Lỗi thường gặp khi chuẩn hoá

• Tách quá tay: biến danh mục chỉ có ba giá trị cố định thành bảng riêng cho từng cột khiến truy vấn đơn giản cũng cần năm phép nối. Hãy cân nhắc kiểu liệt kê (enum) hoặc ràng buộc CHECK.
• Dùng khoá tự nhiên không ổn định: lấy số điện thoại hay email làm khoá chính. Khi khách đổi số, mọi khoá ngoại trỏ tới nó phải đổi theo. Khoá đại diện (surrogate key) như ma_kh số nguyên giúp tránh việc này.
• Quên khoá ngoại và chỉ mục: lược đồ đã tách nhưng không khai báo ràng buộc, hoặc không đánh chỉ mục (index) trên cột khoá ngoại nên JOIN chậm.
• Xoá cột lịch sử: như ví dụ gia_ban ở trên. Các giá trị cần đóng băng theo thời điểm, như giá, tỷ giá, địa chỉ giao hàng của đơn, phải được sao chép có chủ đích vào bảng giao dịch.
• Chuẩn hoá trên dữ liệu chưa hiểu: bạn cần biết cột nào xác định cột nào (phụ thuộc hàm). Chọn sai phụ thuộc sẽ tách bảng sai. Hãy hỏi người vận hành nghiệp vụ trước khi vẽ.

Câu hỏi thường gặp

Chuẩn hoá cơ sở dữ liệu có bắt buộc không?

Không có quy định nào bắt buộc. Đây là thực hành thiết kế. Hệ thống không chuẩn hoá vẫn chạy được nhưng dễ phát sinh dữ liệu mâu thuẫn khi có nhiều người cùng sửa. Với hệ thống giao dịch, bạn nên coi 3NF là mặc định và chỉ lệch khỏi nó khi có lý do đo được.

1NF, 2NF, 3NF khác nhau ở điểm nào?

1NF yêu cầu mỗi ô một giá trị. 2NF yêu cầu mọi cột không khoá phụ thuộc toàn bộ khoá, nên chỉ có ý nghĩa với khoá ghép. 3NF yêu cầu cột không khoá không phụ thuộc vào cột không khoá khác, tức là không có phụ thuộc bắc cầu.

Chuẩn hoá có làm cơ sở dữ liệu chậm đi không?

Có thể với truy vấn tổng hợp, vì cần nhiều phép nối. Ngược lại, thao tác ghi thường nhẹ hơn vì mỗi giá trị chỉ sửa một chỗ. Với dữ liệu cỡ vừa và có chỉ mục đúng, chênh lệch thường không đáng kể. Hãy đo bằng kế hoạch thực thi trên dữ liệu thật trước khi kết luận.

Chuẩn hoá có áp dụng cho NoSQL không?

Dạng chuẩn là lý thuyết của mô hình quan hệ. Kho NoSQL như document store thường lồng dữ liệu vào cùng một tài liệu để đọc một lần, tức là cố ý phi chuẩn hoá. Bạn vẫn nên tự hỏi dữ liệu nào bị lặp và ai chịu trách nhiệm đồng bộ. Xem thêm bài so sánh SQL và NoSQL.

Chuẩn hoá dữ liệu trong học máy có giống không?

Không. Trong học máy, chuẩn hoá thường là đưa các cột số về cùng thang đo (ví dụ min-max hoặc z-score) để mô hình không bị chi phối bởi cột có giá trị lớn. Nó không thay đổi cấu trúc bảng hay quan hệ giữa các bảng.