Normalization là gì? 1NF, 2NF, 3NF, BCNF và Denormalization trong Database

Ở phần 1, CloudX đã giải thích Primary Key, Foreign Key, Index, Clustered Index, Non-Clustered Index và cách thiết kế quan hệ dữ liệu trong Database.

Trong phần 2 này, chúng ta sẽ tiếp tục tìm hiểu một chủ đề rất quan trọng khi thiết kế cơ sở dữ liệu quan hệ: Normalization, hay còn gọi là chuẩn hóa dữ liệu.

Nếu Primary Key và Foreign Key giúp các bảng liên kết với nhau đúng cách, thì Normalization giúp dữ liệu được tổ chức gọn gàng, tránh trùng lặp, dễ bảo trì và ít sai lệch hơn khi hệ thống phát triển.

1. Normalization là gì?

Normalization, hay chuẩn hóa dữ liệu, là quá trình thiết kế Database theo các nguyên tắc nhằm giảm trùng lặp dữ liệu, tránh sai lệch dữ liệu và giúp cơ sở dữ liệu dễ bảo trì hơn.

Hiểu đơn giản, Normalization giúp bạn chia dữ liệu thành các bảng hợp lý thay vì nhét tất cả thông tin vào một bảng lớn.

Ví dụ, thay vì lưu thông tin khách hàng lặp lại trong từng đơn hàng:

orders
- order_id
- customer_name
- customer_phone
- customer_email
- product_name
- product_price
- quantity

Ta nên tách thành nhiều bảng:

customers
- customer_id
- full_name
- phone
- email

orders
- order_id
- customer_id
- order_date

products
- product_id
- product_name
- price

order_items
- order_item_id
- order_id
- product_id
- quantity

Cách thiết kế này giúp dữ liệu rõ ràng hơn, tránh lặp lại thông tin khách hàng và dễ mở rộng khi hệ thống phát triển.

2. Vì sao cần Normalization?

Normalization rất quan trọng vì giúp giải quyết các vấn đề thường gặp trong Database:

• Giảm dữ liệu trùng lặp.
• Tránh sai lệch dữ liệu.
• Dễ cập nhật thông tin.
• Dễ mở rộng hệ thống.
• Dễ bảo trì khi phần mềm phát triển.
• Giúp quan hệ dữ liệu rõ ràng hơn.
• Hạn chế lỗi khi insert, update, delete.

Nếu không chuẩn hóa Database, hệ thống dễ gặp các lỗi:

• Cùng một khách hàng nhưng lưu nhiều bản ghi khác nhau.
• Sửa số điện thoại khách hàng ở một nơi nhưng nơi khác vẫn giữ số cũ.
• Xóa một đơn hàng làm mất luôn thông tin khách hàng.
• Dữ liệu báo cáo bị sai vì thông tin bị trùng lặp.

3. 1NF - First Normal Form

1NF, hay First Normal Form, là dạng chuẩn đầu tiên trong Normalization.

Một bảng đạt 1NF khi:

• Mỗi ô dữ liệu chỉ chứa một giá trị duy nhất.
• Không có danh sách nhiều giá trị trong một cột.
• Mỗi dòng dữ liệu có thể được xác định rõ ràng.
• Không có nhóm dữ liệu lặp trong cùng một bảng.

Ví dụ chưa đạt 1NF

Cột phones chứa nhiều số điện thoại trong cùng một ô. Đây là thiết kế không đạt 1NF.

Thiết kế đạt 1NF

Tốt hơn nữa, có thể tách số điện thoại sang bảng riêng:

CREATE TABLE customers (
    customer_id BIGINT PRIMARY KEY,
    full_name VARCHAR(255)
);

CREATE TABLE customer_phones (
    phone_id BIGINT PRIMARY KEY,
    customer_id BIGINT,
    phone VARCHAR(50),
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

4. 2NF - Second Normal Form

2NF, hay Second Normal Form, yêu cầu bảng phải đạt 1NF và các cột không khóa phải phụ thuộc hoàn toàn vào khóa chính.

2NF thường quan trọng khi bảng có khóa chính gồm nhiều cột.

Ví dụ chưa đạt 2NF

Giả sử bảng order_items có khóa chính gồm order_id và product_id:

Ở đây, product_name chỉ phụ thuộc vào product_id, không phụ thuộc toàn bộ khóa chính order_id + product_id. Vì vậy bảng này chưa đạt 2NF.

Thiết kế đạt 2NF

Tách thông tin sản phẩm ra bảng products:

CREATE TABLE products (
    product_id BIGINT PRIMARY KEY,
    product_name VARCHAR(255),
    price DECIMAL(12,2)
);

CREATE TABLE order_items (
    order_id BIGINT,
    product_id BIGINT,
    quantity INT,
    PRIMARY KEY (order_id, product_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);

Như vậy:

• product_name nằm trong bảng products.
• order_items chỉ lưu dữ liệu liên quan trực tiếp đến đơn hàng và sản phẩm.
• Dữ liệu sản phẩm không bị lặp lại trong từng đơn hàng.

5. 3NF - Third Normal Form

3NF, hay Third Normal Form, yêu cầu bảng phải đạt 2NF và các cột không khóa không được phụ thuộc vào nhau.

Nói đơn giản, dữ liệu trong bảng chỉ nên phụ thuộc vào khóa chính, không nên phụ thuộc vòng qua một cột khác.

Ví dụ chưa đạt 3NF

department_name phụ thuộc vào department_id, không phụ thuộc trực tiếp vào employee_id. Vì vậy bảng này chưa đạt 3NF.

Thiết kế đạt 3NF

CREATE TABLE departments (
    department_id BIGINT PRIMARY KEY,
    department_name VARCHAR(255)
);

CREATE TABLE employees (
    employee_id BIGINT PRIMARY KEY,
    employee_name VARCHAR(255),
    department_id BIGINT,
    FOREIGN KEY (department_id) REFERENCES departments(department_id)
);

Cách thiết kế này giúp:

• Tên phòng ban chỉ lưu một lần.
• Khi đổi tên phòng ban, chỉ cần sửa ở bảng departments.
• Dữ liệu nhân viên gọn hơn.
• Báo cáo phòng ban chính xác hơn.

6. BCNF - Boyce-Codd Normal Form

BCNF, hay Boyce-Codd Normal Form, là dạng chuẩn mạnh hơn 3NF. Một bảng đạt BCNF khi mọi phụ thuộc hàm đều xuất phát từ một candidate key.

BCNF thường được nhắc đến trong các hệ thống dữ liệu phức tạp hơn, nơi có nhiều khóa ứng viên và nhiều mối quan hệ phụ thuộc dữ liệu đặc biệt.

Nói dễ hiểu:

• 3NF giải quyết phần lớn lỗi phụ thuộc dữ liệu thông thường.
• BCNF xử lý kỹ hơn các trường hợp phụ thuộc phức tạp.
• Không phải hệ thống nào cũng cần thiết kế tới BCNF tuyệt đối.

Ví dụ ý tưởng BCNF

Giả sử một bảng lưu thông tin lớp học:

Nếu có quy tắc đặc biệt rằng mỗi teacher_id chỉ được dạy ở một room_id cố định, thì room_id phụ thuộc vào teacher_id. Khi đó cần xem xét tách bảng để tránh phụ thuộc không đúng khóa.

7. So sánh 1NF, 2NF, 3NF và BCNF

8. Denormalization là gì?

Denormalization, hay phi chuẩn hóa, là quá trình cố ý thêm dữ liệu trùng lặp hoặc gộp dữ liệu từ nhiều bảng để tăng tốc truy vấn.

Nếu Normalization giúp dữ liệu gọn và chính xác hơn, thì Denormalization thường được dùng khi hệ thống cần hiệu năng đọc nhanh hơn.

Ví dụ, bảng orders có thể lưu thêm customer_name tại thời điểm đặt hàng:

orders
- order_id
- customer_id
- customer_name_snapshot
- order_date
- total_amount

Dữ liệu customer_name_snapshot có thể trùng với bảng customers, nhưng nó giúp lưu lại tên khách hàng tại thời điểm phát sinh đơn hàng.

9. Khi nào nên Denormalization?

Bạn nên cân nhắc Denormalization khi:

• Truy vấn báo cáo quá chậm do join nhiều bảng.
• Hệ thống đọc nhiều hơn ghi.
• Cần lưu dữ liệu lịch sử tại thời điểm giao dịch.
• Cần tối ưu dashboard realtime.
• Cần giảm tải cho Database chính.
• Dữ liệu đã được xử lý cho mục đích phân tích.

Ví dụ phù hợp Denormalization:

• Bảng báo cáo doanh thu theo ngày.
• Bảng thống kê số lượng học viên theo khóa học.
• Bảng tổng hợp tồn kho.
• Bảng snapshot hóa đơn.
• Data warehouse.
• Search index.

10. Thiết kế Database cho doanh nghiệp

Khi thiết kế Database cho doanh nghiệp, không nên chỉ nhìn vào hiện tại mà cần tính tới khả năng mở rộng trong tương lai.

Một thiết kế Database tốt nên đảm bảo:

• Có Primary Key rõ ràng.
• Có Foreign Key cho các quan hệ quan trọng.
• Có Index cho truy vấn thường dùng.
• Chuẩn hóa dữ liệu đến mức hợp lý.
• Không chuẩn hóa quá mức gây khó truy vấn.
• Có chiến lược Denormalization khi cần báo cáo nhanh.
• Có backup và restore định kỳ.
• Có monitoring CPU/RAM/Disk I/O.
• Có phân quyền user Database.
• Không public Database trực tiếp ra Internet.

Gợi ý thiết kế theo từng hệ thống

11. Sai lầm thường gặp khi thiết kế Database

• Không có Primary Key cho bảng.
• Không dùng Foreign Key dù dữ liệu có quan hệ rõ ràng.
• Không chuẩn hóa dữ liệu ở giai đoạn đầu.
• Lưu nhiều giá trị trong một cột.
• Lạm dụng JSON để thay thế quan hệ dữ liệu.
• Tạo quá nhiều Index không cần thiết.
• Không tạo Index cho cột hay join/filter.
• Chuẩn hóa quá mức khiến query quá phức tạp.
• Denormalization nhưng không có cơ chế đồng bộ.
• Không có backup và monitoring.
• Thiết kế chỉ đủ cho hiện tại, không tính đến mở rộng.

12. Yêu cầu CPU/RAM/NVMe

Database được thiết kế tốt vẫn cần hạ tầng đủ mạnh để vận hành ổn định. CPU xử lý query, RAM dùng cho cache/buffer, còn NVMe ảnh hưởng trực tiếp đến tốc độ đọc ghi dữ liệu, index, log và backup.

13. FAQ SEO

Normalization là gì?

Normalization là quá trình chuẩn hóa dữ liệu trong Database nhằm giảm trùng lặp, tránh sai lệch dữ liệu và giúp hệ thống dễ bảo trì hơn.

1NF là gì?

1NF là dạng chuẩn đầu tiên, yêu cầu mỗi ô dữ liệu chỉ chứa một giá trị duy nhất và không lưu danh sách nhiều giá trị trong cùng một cột.

2NF là gì?

2NF yêu cầu bảng phải đạt 1NF và các cột không khóa phải phụ thuộc hoàn toàn vào khóa chính.

3NF là gì?

3NF yêu cầu bảng phải đạt 2NF và các cột không khóa không được phụ thuộc vào nhau thông qua phụ thuộc bắc cầu.

BCNF là gì?

BCNF là dạng chuẩn mạnh hơn 3NF, yêu cầu mọi phụ thuộc hàm phải xuất phát từ candidate key.

Denormalization là gì?

Denormalization là quá trình cố ý thêm dữ liệu trùng lặp hoặc gộp dữ liệu để tăng tốc truy vấn, thường dùng cho báo cáo, dashboard hoặc hệ thống đọc nhiều.

Có nên chuẩn hóa Database 100% không?

Không phải lúc nào cũng nên chuẩn hóa 100%. Trong thực tế, cần cân bằng giữa tính đúng đắn dữ liệu và hiệu năng truy vấn.

Database chuẩn hóa có nhanh hơn không?

Database chuẩn hóa giúp dữ liệu gọn và ít sai lệch hơn, nhưng truy vấn có thể cần nhiều JOIN hơn. Với hệ thống lớn, cần kết hợp Index và Denormalization hợp lý.

MySQL, PostgreSQL, MariaDB có cần Normalization không?

Có. Dù dùng MySQL, PostgreSQL hay MariaDB, thiết kế Database quan hệ vẫn nên áp dụng Normalization ở mức phù hợp.

Thiết kế Database sai có ảnh hưởng hiệu năng không?

Có. Thiết kế sai có thể gây trùng dữ liệu, query chậm, khó mở rộng, khó backup và dễ phát sinh lỗi khi hệ thống phát triển.

14. CloudX hỗ trợ triển khai Database

15. Kết luận

Normalization là nền tảng quan trọng trong thiết kế Database quan hệ. 1NF, 2NF, 3NF và BCNF giúp dữ liệu được tổ chức rõ ràng, hạn chế trùng lặp, giảm sai lệch và giúp hệ thống dễ bảo trì hơn.

Tuy nhiên trong thực tế, doanh nghiệp không nên áp dụng chuẩn hóa một cách máy móc. Với các hệ thống cần báo cáo nhanh, dashboard realtime hoặc truy vấn đọc rất nhiều, Denormalization có thể là lựa chọn cần thiết nếu được thiết kế và kiểm soát tốt.

Một Database tốt cần kết hợp giữa thiết kế quan hệ đúng, chuẩn hóa hợp lý, Index tối ưu, hạ tầng Cloud VPS NVMe đủ mạnh, backup đầy đủ và giám sát thường xuyên.