Các nguyên tắc thiết kế database là nền tảng quan trọng giúp xây dựng một hệ thống database có cấu trúc rõ ràng, dễ quản lý và hoạt động hiệu quả. Trước khi triển khai trên các hệ quản trị như PostgreSQL, MySQL hay SQL Server, việc thiết kế dữ liệu hợp lý là bước cần thiết để đảm bảo hệ thống vận hành ổn định và hỗ trợ truy vấn tốt.
Một thiết kế database tốt giúp giảm trùng lặp dữ liệu và đảm bảo tính toàn vẹn thông tin. Ngược lại, thiết kế kém có thể dẫn đến dữ liệu dư thừa và khó cập nhật.
Trong bài này, chúng ta sẽ tìm hiểu:
- Các nguyên tắc nền tảng khi thiết kế database
- ERD – công cụ mô hình hóa dữ liệu trước khi triển khai
- Chuẩn hóa dữ liệu (Normalization)
Qua đó, bạn sẽ hiểu cách tổ chức và thiết kế database một cách khoa học trước khi triển khai trên hệ quản trị cơ sở dữ liệu.
1. Các nguyên tắc cơ bản khi thiết kế database
1.1 Tính nhất quán (Consistency)
Cùng một loại thông tin phải được lưu trữ theo cùng một quy ước. Ví dụ:
- Số điện thoại không lúc lưu “+84…”, lúc “084…”, lúc “84…”
- Ngày tháng không được lúc dd/mm/yyyy, lúc khác mm/dd/yyyy
Nếu không có quy ước rõ ràng, dữ liệu sẽ khó xử lý và dễ gây sai sót khi phân tích.
1.2 Tính toàn vẹn (Integrity)
Tính toàn vẹn đảm bảo dữ liệu đúng và hợp lệ. Gồm 3 loại:
🔹Thực thể (Entity Integrity): Toàn vẹn thực thể tức là mỗi bảng phải có khóa chính để định danh duy nhất mỗi dòng.
🔹 Tham chiếu (Referential Integrity) : Toàn vẹn về tham chiếu đó là khóa ngoại phải trỏ đến bản ghi hợp lệ , không được tồn tại dữ liệu “mồ côi”
🔹 Toàn vẹn miền (Domain Integrity): Đó là dữ liệu phải đúng kiểu, đúng phạm vi giá trị và tuân theo các ràng buộc (NOT NULL, DEFAULT…)
1.3 Tránh dư thừa (Reduce redundancy)
Dư thừa dữ liệu dễ dẫn đến mâu thuẫn. Ví dụ: Nếu bạn lưu tên khách hàng trực tiếp trong bảng don_hang dẫn tới dư thừa. Vì một khách có thể mua nhiều đơn hàng. Rồi khi khách đổi tên hay địa chỉ, bạn phải cập nhật mọi nơi. Nếu cập nhật sót một nơi thì dữ liệu bị sai. Giải pháp:
- Tách bảng hợp lý
- Sử dụng khóa ngoại thay vì lặp dữ liệu
1.4 Tính độc lập (Independence)
Tính độc lập là nguyên tắc cho phép thay đổi ở tầng thấp hơn của hệ thống database mà không làm ảnh hưởng đến tầng cao hơn (ứng dụng).
Thay đổi cách lưu trữ vật lý không nên làm ứng dụng bị ảnh hưởng. Ví dụ: Thay đổi cách tổ chức file trên đĩa, Tối ưu hóa storage thì ứng dụng phía trên vẫn hoạt động bình thường. Nguyên tắc này giúp hệ thống: Dễ nâng cấp, Dễ tối ưu, Dễ bảo trì lâu dài
2. ERD (Entity–Relationship Diagram)
ERD (Entity–Relationship Diagram) là công cụ mô hình hóa dùng để mô tả cấu trúc của database. Một ERD thường gồm ba thành phần chính:
- Các thực thể (Entity)
- Thuộc tính (Attribute) của các thực thể.
- Mối quan hệ (Relationship) giữa các thực thể
2.1. Thực thể (Entity)
Mỗi thực thể là một đối tượng trong thế giới thực mà ta muốn lưu trữ thông tin. Ví dụ: Khách hàng, Đơn hàng, Sản phẩm, Sinh viên, Nhân viên
Trong ERD, thực thể thường được biểu diễn bằng hình chữ nhật và có 2 loại thực thể:
Thực thể mạnh: là những thực thể tồn tại độc lập, có khóa chính riêng, không phụ thuộc vào thực thể khác. Ví dụ: Khách hàng, Sản phẩm, Sinh viên.
Thực thể yếu: Là những thực thể không tồn tại độc lập, về ý nghĩa nóphụ thuộc vào thực thể khác. Nó thường cần khóa của thực thể mạnh để định danh. Ví dụ: Chi tiết đơn hàng (order_details), Điểm thi của sinh viên
2.2 Thuộc tính (Attribute)
Thuộc tính là các thông tin mô tả thực thể. Ví dụ: Thực thể Khách hàng có các thuộc tính: id, ho_ten, email, ngay_sinh, so_dien_thoai.
Trong ERD, thuộc tính được liệt kê bên trong thực thể (cách phổ biến hiện nay) Một số lưu ý khi thiết kế thuộc tính:
- Thuộc tính khóa: Là thuộc tính dùng để xác định duy nhất mỗi thực thể (ví dụ: id). Đây sẽ trở thành Primary Key của bảng sau này.
- Thuộc tính đa giá trị : Nếu có nhiều giá trị cho cùng một thông tin (ví dụ nhiều số phone), thông tin này thường cần tách thành bảng riêng để đảm bảo chuẩn hóa.
- Thuộc tính dẫn xuất : Một số thông tin có thể tính toán từ dữ liệu khác (ví dụ: tuoi tính từ ngay_sinh). Trong thiết kế tốt, ta thường lưu dữ liệu gốc (ngày_sinh) thay vì lưu giá trị dẫn xuất (tuoi).
2.3. Mối quan hệ (Relationship)
Mối quan hệ thể hiện sự liên kết có ý nghĩa giữa các thực thể trong hệ thống. Ví dụ:
- Khách hàng đặt Đơn hàng
- Sinh viên học Môn học
- Nhân viên quản lý Nhân viên
Trong ERD, mối quan hệ thường được biểu diễn bằng đường nối giữa các thực thể.
Phân loại theo mức độ quan hệ :
- 1–1 (One-to-One) Một dòng dữ liệu của thực thể A liên kết với đúng một dòng dữ liệu của thực thể B và ngược lại. Ví dụ: Nhân viên – Thẻ nhân viên.
- 1–n (One-to-Many) Một dòng dữ liệu của thực thể A có thể liên kết với nhiều dòng dữ liệu của thực thể B, nhưng mỗi dòng của B chỉ thuộc về một A. Ví dụ: Một khách hàng có nhiều đơn hàng.
- n–n (Many-to-Many) Một dòng của thực thể A có thể liên kết với nhiều dòng của thực thể B và ngược lại. Ví dụ: Sinh viên – Môn học.
Lưu ý: Trong database quan hệ, quan hệ n–n không được triển khai trực tiếp mà cần tạo bảng trung gian để chuyển thành hai quan hệ 1–n.
Phân loại theo số lượng thực thể tham gia
🔹 Đơn ngôi (Unary Relationship) Quan hệ xảy ra trong cùng một thực thể. Ví dụ: Nhân viên quản lý nhân viên.
🔹 Nhị ngôi (Binary Relationship) Quan hệ giữa hai thực thể khác nhau. Đây là loại quan hệ phổ biến nhất trong thiết kế database.
🔹 Tam ngôi (Ternary Relationship) Quan hệ có sự tham gia đồng thời của ba thực thể. Ví dụ: Sinh viên thi Môn học tại Phòng thi.
Kí hiệu mối quan hệ
2.4. Ba cấp độ ERD:
Trong quá trình thiết kế database, ERD không chỉ có một phiên bản duy nhất. Thông thường, thiết kế sẽ đi qua ba cấp độ: khái niệm → logic → vật lý.
Ba cấp độ này phản ánh quá trình chuyển đổi từ việc hiểu nghiệp vụ đến khi triển khai thực tế trên một hệ quản trị cụ thể.
1. ERD mức khái niệm (Conceptual ERD)
ERD dùng để hiểu tổng quan vấn đề và các thành phần chính của hệ thống. Đây là bản vẽ ở mức ý tưởng chưa liên quan đến kỹ thuật. Thường dùng để trao đổi với khách hàng hoặc bộ phận nghiệp vụ.
Đặc điểm:
- Chỉ thể hiện các thực thể chính và mối quan hệ giữa chúng
- Không liệt kê thuộc tính chi tiết
- Không xác định khóa chính hay khóa ngoại
- Hoàn toàn độc lập với hệ quản trị database
Diễn giải ERD:
- Các thực thể:có 3 thực thểcustomers, orders, products
- Mỗi order thuộc về đúng một customer.
- Mỗi customer có thể có 0 hoặc nhiều order → Đây là quan hệ 1–n (một khách hàng – nhiều đơn hàng).
- Mỗi order phải chứa ít nhất một product.
- Mỗi product có thể không thuộc đơn hàng nào hoặc thuộc nhiều order→ Đây là quan hệ n–n (nhiều đơn hàng – nhiều sản phẩm).
Ở mức này, ta chỉ quan tâm: “Hệ thống có những đối tượng nào và chúng liên kết với nhau ra sao?”
2. ERD mức logic (Logical ERD)
Mục đích của ERD logic là làm chi tiết các thực thể, để chuẩn bị cho việc triển khai. Đây là bước chuyển từ “ý tưởng nghiệp vụ” sang “cấu trúc dữ liệu”.
Đặc điểm:
- Có đầy đủ các thuộc tính của từng thực thể
- Xác định rõ khóa chính (Primary Key)
- Xác định khóa ngoại (Foreign Key)
- Chuẩn hóa các quan hệ n–n thành bảng trung gian
- Có thể định nghĩa kiểu dữ liệu ở mức khái quát (INT, VARCHAR…)
- Vẫn chưa phụ thuộc vào một RDBMS cụ thể
Ở mức này, ta trả lời câu hỏi: “Dữ liệu sẽ được tổ chức như thế nào?”
Diễn giải ERD:
- Cácthực thể: customers, orders, order_details, products được thêm các thuộc tính
- Quan hệ orders – products là n–n, được triển khai bằng thực thể trung gian order_details:
- Mỗi order có 1 hoặc nhiều OrderDetail.
- Mỗi order_details thuộc về đúng 1 order và tham chiếu đúng 1 product.
- Mỗi product có thể xuất hiện trong 0 hoặc nhiều order_details.
3. ERD mức vật lý (Physical ERD)
Mục đích của ERD vật lý là triển khai thiết kế trên một hệ quản trị database cụ thể như PostgreSQL, MySQL, SQL Server… Đây là bước từ “thiết kế” sang “xây dựng hệ thống”.
Đặc điểm:
- Kiểu dữ liệu cụ thể theo RDBMS (VARCHAR(255), NUMERIC(10,2)…)
- Định nghĩa chi tiết các ràng buộc (NOT NULL, CHECK, DEFAULT…)
- Thiết lập index
- Partition (nếu cần)
- Các yếu tố tối ưu hiệu năng
Ở mức này, ta trả lời câu hỏi: “Hệ thống sẽ được triển khai cụ thể ra sao trên nền tảng kỹ thuật?”
Tóm lại : Ba cấp độ ERD thể hiện ba giai đoạn:
- Khái niệm → Hiểu nghiệp vụ
- Logic → Thiết kế cấu trúc dữ liệu
- Vật lý → Triển khai kỹ thuật
3. CHUẨN HÓA DỮ LIỆU (NORMALIZATION)
Chuẩn hóa dữ liệu (Normalization) trong database là quá trình tổ chức dữ liệu nhằm:
- Giảm dư thừa dữ liệu: Tránh lưu trữ thông tin trùng lặp
- Tăng tính nhất quán: Cập nhật một lần, có hiệu lực toàn bộ
- Tiết kiệm không gian: Giảm dung lượng lưu trữ
- Tăng tính toàn vẹn: Giảm nguy cơ dữ liệu mâu thuẫn
Các chuẩn hóa phổ biến gồm: 1NF, 2NF, 3NF
1. 1NF (First Normal Form) – mỗi ô là một giá trị nguyên tử
Một bảng đạt chuẩn 1NF khi: Mỗi ô trong bảng chỉ chứa một giá trị duy nhất (còn gọi là giá trị nguyên tử).
Ví dụ 1: cột SoDienThoai chứa: 090849242, 091248553. Ở đây, một ô chứa nhiều giá trị → vi phạm 1NF.
Cách khắc phục: Tách thành:
- Nhiều dòng (mỗi dòng một số điện thoại), hoặc
- Một bảng riêng lưu số điện thoại và liên kết bằng khóa ngoại.
Ví dụ 2: Cột MonHoc chứa nhiều giá trị è Vi phạm chuẩn 1NF
2. 2NF (Second Normal Form) – phụ thuộc đầy đủ vào khóa chính
Một bảng đạt chuẩn 2NF khi:
- Đã đạt 1NF.
- Mọi thuộc tính không khóa phải phụ thuộc hoàn toàn vào toàn bộ khóa chính.
Lưu ý: 2NF chỉ có ý nghĩa khi bảng có khóa chính ghép. Nếu khóa chính chỉ gồm một cột, bảng tự động sẽ đạt 2NF.
Ví dụ vi phạm 2NF : Khóa chính (MaSV, MaMH)
| ma_sv | ma_mh | ten_sv | ten_mh | diem |
| SV01 | MH01 | Nam | Toán | 8 |
| SV01 | MH02 | Nam | Lý | 7 |
Vấn đề:ten_sv chỉ phụ thuộc vào ma_sv và ten_mh chỉ phụ thuộc vào ma_mh
Sau khi chuẩn hóa 2NF
| Bảng sinh_vien ma_sv ten_sv SV01 Nam | Bảng mon_hoc ma_mh ten_mh MH01 Toán MH02 Lý | Bảng ket_qua ma_sv ma_mh diem SV01 MH01 8 SV01 MH02 7 |
3. 3NF (Third Normal Form)
Một bảng đạt 3NF khi: Đã đạt 2NF và không tồn tại phụ thuộc bắc cầu giữa các thuộc tính không khóa
Nói cách khác: Không có thuộc tính không khóa nào phụ thuộc vào một thuộc tính không khóa khác.
Ví dụ vi phạm 3NF
| ma_sv (PK) | ten_sv | ma_lop | ten_lop |
| SV01 | Nam | L01 | CNTT1 |
| SV02 | Thảo | L01 | CNTT1 |
Vấn đề:ten_lop phụ thuộc vào ma_lop, ma_lop phụ thuộc vào ma_sv => ten_lop đang phụ thuộc bắc cầu vào ma_sv
Sau khi chuẩn hóa 3NF
| Bảng lop ma_lop ten_lop L01 CNTT1 | Bảng sinh_vien ma_sv ten_sv ma_lop SV01 Nam L01 SV02 Thảo L01 |
Nhược điểm của chuẩn hóa : Tuy có nhiều lợi ích, nhưng việc chuẩn hóa cũng dẫn đến tăng số lượng bảng, có thể làm tăng số phép JOIN, ảnh hưởng đến hiệu năng trong một số truy vấn lớn.
Thiết kế dữ liệu kém thường dẫn đến các bất thường dữ liệu (data anomalies):
- Insert anomaly – không thể thêm dữ liệu nếu thiếu thông tin liên quan
- Update anomaly – phải cập nhật cùng một dữ liệu ở nhiều nơi
- Delete anomaly – xóa dữ liệu làm mất thông tin ngoài ý muốn
KẾT LUẬN
Các nguyên tắc thiết kế database giúp tổ chức dữ liệu một cách khoa học, giảm dư thừa và đảm bảo tính toàn vẹn trong hệ thống database. Trong bài này, chúng ta đã tìm hiểu các nguyên tắc quan trọng như tính nhất quán, toàn vẹn dữ liệu, giảm dư thừa và tính độc lập dữ liệu, cùng với công cụ mô hình hóa ERD và các bước chuẩn hóa dữ liệu từ 1NF đến 3NF.
Việc áp dụng đúng các nguyên tắc thiết kế không chỉ giúp database dễ bảo trì, dễ mở rộng, mà còn hỗ trợ hệ thống hoạt động ổn định và hiệu quả trong dài hạn. Trong thực tế, mức độ chuẩn hóa và thiết kế cần được cân nhắc phù hợp với mục tiêu và quy mô của hệ thống.
Hiểu rõ các nguyên tắc thiết kế database là bước quan trọng để xây dựng nền tảng dữ liệu vững chắc trước khi triển khai và tối ưu database trong các ứng dụng thực tế.
