Relational database là gì?

Mục lục

1. Relational database là gì?
2. Mô hình quan hệ ra đời để giải quyết vấn đề gì?
3. Cơ sở dữ liệu quan hệ hoạt động thế nào?
4. Chuẩn hoá dữ liệu để tránh lỗi gì?
5. ACID là gì và vì sao cơ sở dữ liệu quan hệ được tin cậy cho tiền bạc?
6. Có những hệ quản trị cơ sở dữ liệu quan hệ nào?
7. Doanh nghiệp Việt Nam dùng cơ sở dữ liệu quan hệ ở đâu?
8. Ưu điểm và hạn chế của cơ sở dữ liệu quan hệ
9. Cơ sở dữ liệu quan hệ khác gì NoSQL và data warehouse?
10. Khi nào nên và không nên chọn cơ sở dữ liệu quan hệ?
11. Những lỗi thiết kế thường gặp là gì?
12. Câu hỏi thường gặp

Relational database là gì?

Relational database, tiếng Việt là cơ sở dữ liệu quan hệ, là kiểu cơ sở dữ liệu mà mọi thông tin được trình bày dưới dạng các bảng. Mỗi bảng mô tả một loại đối tượng: khách hàng, đơn hàng, sản phẩm. Mỗi hàng là một bản ghi, mỗi cột là một thuộc tính. Điểm làm nên chữ “quan hệ” là các bảng không đứng riêng lẻ mà tham chiếu nhau qua giá trị của khoá.

Ba thuật ngữ hay bị dùng lẫn nhau, bạn nên tách bạch:

• Mô hình quan hệ (relational model): lý thuyết toán học về cách biểu diễn dữ liệu bằng các “quan hệ” (relation), tương ứng với bảng.
• Cơ sở dữ liệu quan hệ (relational database): tập dữ liệu thực tế được tổ chức theo mô hình đó.
• RDBMS (Relational Database Management System): phần mềm tạo, lưu, truy vấn và bảo vệ cơ sở dữ liệu quan hệ, như MySQL, PostgreSQL, SQL Server, Oracle hay SQLite.

Nếu bạn chưa quen khái niệm nền, bài cơ sở dữ liệu là gì giải thích DBMS và các nhóm cơ sở dữ liệu nói chung. Bài này chỉ đi sâu vào nhóm quan hệ.

Mô hình quan hệ ra đời để giải quyết vấn đề gì?

Tháng 6/1970, Edgar F. Codd của IBM công bố bài báo “A Relational Model of Data for Large Shared Data Banks” trên Communications of the ACM, tập 13, số 6. Trước đó, các hệ thống dùng cấu trúc phân cấp hoặc mạng lưới: muốn lấy dữ liệu, lập trình viên phải viết chương trình đi theo từng con trỏ vật lý. Khi cấu trúc cơ sở dữ liệu đổi, các chương trình đó hỏng ngay.

Ý tưởng cốt lõi của Codd là tính độc lập dữ liệu (data independence): người dùng hoặc ứng dụng không cần biết cấu trúc lưu trữ vẫn truy vấn được dữ liệu. Bạn chỉ nói mình muốn gì, hệ thống tự quyết định lấy bằng cách nào. Chính tư tưởng khai báo này dẫn tới SQL, ngôn ngữ mà các nhà nghiên cứu IBM là Chamberlin và Boyce phát triển từ đầu thập niên 1970 với tên SEQUEL. Bạn có thể đọc thêm về ngôn ngữ này ở bài SQL là gì.

Một chi tiết thú vị: khi mô hình quan hệ trở nên thời thượng đầu thập niên 1980, Codd đã đưa ra bộ 12 quy tắc để ngăn các hãng gắn nhãn “quan hệ” lên công nghệ cũ. Tuy vậy, không sản phẩm thương mại nào tuân thủ đủ 12 quy tắc, nên thuật ngữ này dần chỉ một nhóm hệ thống rộng hơn. Vì vậy, khi một sản phẩm tự nhận là “relational”, hãy hiểu theo nghĩa thực dụng: dữ liệu dạng bảng, có khoá, có SQL, có giao dịch.

Cơ sở dữ liệu quan hệ hoạt động thế nào?

Bảng, khoá chính và khoá ngoại

Mỗi bảng có một khoá chính (primary key): cột hoặc nhóm cột có giá trị duy nhất cho từng hàng và không được để trống. Khoá ngoại (foreign key) là cột trong bảng này chứa giá trị khoá chính của bảng khác. RDBMS dùng khoá ngoại để từ chối những dữ liệu vô nghĩa, chẳng hạn một đơn hàng trỏ tới khách hàng không tồn tại.

Ví dụ minh hoạ: một cửa hàng online nhỏ có bốn bảng. Bảng khách hàng giữ thông tin người mua; bảng đơn hàng ghi mỗi lần đặt; bảng chi tiết đơn ghi từng dòng hàng trong đơn; bảng sản phẩm giữ tên và giá. Bảng chi tiết đơn là chỗ biểu diễn quan hệ nhiều–nhiều: một đơn có nhiều sản phẩm, một sản phẩm nằm trong nhiều đơn.

Join: ghép bảng khi truy vấn

Dữ liệu được tách ra nhiều bảng, nên khi cần báo cáo bạn ghép chúng lại bằng phép nối (JOIN) dựa trên khoá. Truy vấn dưới đây trả lời “tháng này khách nào mua sản phẩm nào, bao nhiêu”:

SELECT kh.ten, sp.ten_sp, ct.so_luong
FROM don_hang d
JOIN khach_hang kh ON kh.ma_kh = d.ma_kh
JOIN chi_tiet_don ct ON ct.ma_don = d.ma_don
JOIN san_pham sp ON sp.ma_sp = ct.ma_sp
WHERE d.ngay_dat >= '2026-10-01';

Bạn không chỉ ra cách duyệt bảng nào trước. Bộ tối ưu truy vấn (query optimizer) của RDBMS tự chọn kế hoạch thực thi dựa trên chỉ mục (index) và thống kê dữ liệu. Chỉ mục giống mục lục sách: nó làm truy vấn đọc nhanh hơn nhưng làm thao tác ghi tốn thêm công cập nhật.

Chuẩn hoá dữ liệu để tránh lỗi gì?

Hãy tưởng tượng thay vì bốn bảng, nhân viên kinh doanh ghi mọi thứ vào một bảng phẳng: mỗi dòng gồm tên khách, địa chỉ khách, sản phẩm, giá. Khách mua mười lần thì địa chỉ bị chép mười lần. Khi khách đổi địa chỉ, bạn phải sửa mười dòng; sửa sót một dòng là dữ liệu mâu thuẫn. Đây là các dị thường khi cập nhật, thêm và xoá mà chuẩn hoá (normalization) sinh ra để loại bỏ.

Chuẩn hoá nghĩa là tách bảng sao cho mỗi sự thật chỉ lưu đúng một nơi. Codd giới thiệu ba dạng chuẩn đầu tiên trong một bài báo năm 1971. Trong thực tế bạn thường chỉ cần tới dạng chuẩn 3:

• 1NF: mỗi ô chỉ chứa một giá trị, không nhét danh sách “SP01, SP02, SP03” vào một ô.
• 2NF: mọi cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần của nó (quan trọng với khoá gồm nhiều cột như bảng chi tiết đơn).
• 3NF: cột không khoá không phụ thuộc vào cột không khoá khác. Ví dụ, nếu bảng đơn hàng lưu cả mã tỉnh và tên tỉnh, tên tỉnh phải chuyển sang bảng riêng.

ACID là gì và vì sao cơ sở dữ liệu quan hệ được tin cậy cho tiền bạc?

Giao dịch (transaction) là một nhóm thao tác được coi như một khối: hoặc thực hiện hết, hoặc không thực hiện gì. RDBMS nổi tiếng nhờ bảo đảm bốn tính chất ACID:

• Atomicity (nguyên tử): giao dịch thành công trọn vẹn hoặc bị huỷ hoàn toàn.
• Consistency (nhất quán): sau giao dịch, mọi ràng buộc như khoá ngoại, kiểu dữ liệu, điều kiện CHECK vẫn đúng.
• Isolation (cô lập): các giao dịch chạy đồng thời không làm hỏng kết quả của nhau.
• Durability (bền vững): đã xác nhận (commit) thì không mất, kể cả khi máy chủ sập ngay sau đó. Cơ chế thường dùng là ghi nhật ký giao dịch trước khi ghi vào bảng.

Tính cô lập là phần dễ gây rắc rối nhất. Chuẩn SQL định nghĩa các mức cô lập (isolation level) như READ COMMITTED, REPEATABLE READ và SERIALIZABLE; mức càng chặt thì càng ít hiện tượng đọc sai nhưng càng dễ xảy ra chờ khoá hoặc bế tắc (deadlock). Mỗi RDBMS cài đặt các mức này hơi khác nhau, nên một logic chạy đúng trên hệ này chưa chắc đúng y nguyên trên hệ khác. Bạn cần đọc tài liệu của chính sản phẩm đang dùng.

Có những hệ quản trị cơ sở dữ liệu quan hệ nào?

Phần lớn RDBMS dùng chung nền tảng SQL nhưng khác nhau về giấy phép, tính năng mở rộng và hệ sinh thái. Bảng dưới đây chỉ mô tả đặc điểm chung, không xếp hạng.

Hệ quản trị	Giấy phép	Đặc điểm thường được nhắc	Hay gặp ở
MySQL	Mã nguồn mở (có bản thương mại)	Nhẹ, quen thuộc với hosting và website	Web, thương mại điện tử, WordPress
PostgreSQL	Mã nguồn mở	Nhiều kiểu dữ liệu, hỗ trợ JSON, hệ thống tiện ích mở rộng	Ứng dụng nghiệp vụ phức tạp, dữ liệu địa lý
Microsoft SQL Server	Thương mại	Tích hợp với hệ sinh thái Microsoft	Doanh nghiệp dùng Windows Server, .NET
Oracle Database	Thương mại	Tính năng cao cấp cho hệ thống lớn	Ngân hàng, viễn thông, tập đoàn
SQLite	Phạm vi công cộng	Nằm trong một tệp, không cần máy chủ riêng	Ứng dụng di động, phần mềm đóng gói

Hai lựa chọn mã nguồn mở được tìm hiểu nhiều nhất có bài riêng: MySQL là gì và PostgreSQL là gì. Cách chọn giữa chúng phụ thuộc vào đội ngũ đang có, phần mềm đã gắn với hệ nào và yêu cầu tính năng, chứ không có đáp án chung.

Doanh nghiệp Việt Nam dùng cơ sở dữ liệu quan hệ ở đâu?

Hầu hết phần mềm nghiệp vụ bạn đang dùng có một RDBMS ở phía sau, dù giao diện không cho thấy. Một số tình huống điển hình:

• Bán hàng và kho: đơn hàng, tồn kho, phiếu nhập xuất. Điểm quan trọng là hai nhân viên cùng bán món hàng cuối cùng thì chỉ một người thành công; giao dịch và khoá hàng giúp việc này.
• Kế toán và hoá đơn: sổ cái, công nợ. Tổng ghi nợ phải khớp tổng ghi có; ràng buộc và giao dịch là lớp bảo vệ cuối cùng khi ứng dụng có lỗi.
• Nhân sự và chấm công: một nhân viên thuộc một phòng ban, có nhiều kỳ lương. Quan hệ một–nhiều rất tự nhiên.
• CRM và chăm sóc khách hàng: khách, liên hệ, cơ hội, lịch sử tương tác.

Ví dụ minh hoạ về một lỗi thực tế: một cửa hàng chạy khuyến mại cuối tháng, hai máy POS cùng trừ tồn kho sản phẩm có 1 chiếc còn lại. Nếu ứng dụng đọc tồn kho rồi mới ghi số mới mà không khoá dòng, cả hai lần bán đều “thành công” và tồn kho thành số âm. Cách xử lý đúng nằm ở thiết kế giao dịch (khoá dòng hoặc cập nhật có điều kiện), không nằm ở việc mua máy chủ mạnh hơn.

Nếu dữ liệu của bạn có trường định danh khách hàng như số điện thoại hay căn cước, hãy tách chúng thành cột riêng với quyền truy cập riêng thay vì để chung trong cột ghi chú tự do. Việc này giúp che dữ liệu (xem data masking) hoặc xoá theo yêu cầu dễ hơn nhiều.

Ưu điểm và hạn chế của cơ sở dữ liệu quan hệ

Ưu điểm

• Toàn vẹn dữ liệu được khai báo ngay trong cơ sở dữ liệu (khoá, kiểu dữ liệu, ràng buộc), không phụ thuộc mọi lập trình viên đều viết đúng.
• SQL là ngôn ngữ chuẩn, kỹ năng chuyển được giữa nhiều hệ quản trị, nguồn nhân lực dồi dào.
• Truy vấn ad hoc linh hoạt: bạn hỏi câu hỏi chưa từng dự tính mà không phải đổi cấu trúc lưu trữ.
• Giao dịch ACID cho những nghiệp vụ không chấp nhận sai số như tiền, tồn kho, vé.

Hạn chế

• Lược đồ (schema) cố định: thêm thuộc tính mới cho hàng chục triệu bản ghi cần kế hoạch di chuyển cẩn thận.
• Join nhiều bảng trên dữ liệu rất lớn có thể chậm nếu thiếu chỉ mục hoặc truy vấn viết kém.
• Mở rộng theo chiều ngang (chia dữ liệu ra nhiều máy) khó hơn so với nhiều hệ NoSQL; thường phải qua phân vùng (sharding) hoặc bản sao đọc (read replica).
• Khó lưu trực tiếp dữ liệu phi cấu trúc như video, tài liệu dài, dù nhiều hệ đã hỗ trợ kiểu JSON.

Cơ sở dữ liệu quan hệ khác gì NoSQL và data warehouse?

Với NoSQL, dữ liệu được lưu dạng tài liệu, cặp khoá–giá trị, cột rộng hoặc đồ thị, thường ưu tiên linh hoạt cấu trúc và mở rộng ngang. Bài SQL và NoSQL khác nhau so sánh chi tiết; điểm cần nhớ ở đây là nhiều hệ quan hệ hiện đại đã có cột JSON, còn nhiều hệ NoSQL đã hỗ trợ giao dịch, nên ranh giới mờ hơn trước.

Với kho dữ liệu (data warehouse), bản thân kho cũng thường dùng SQL và bảng, nhưng được tối ưu cho đọc và tổng hợp lượng lớn. Cặp khái niệm cần phân biệt là xử lý giao dịch trực tuyến và phân tích, được giải thích trong bài OLAP và OLTP. Một cơ sở dữ liệu quan hệ chạy ứng dụng bán hàng là hệ OLTP; nếu bạn chạy báo cáo nặng trực tiếp trên đó vào giờ cao điểm, người bán hàng sẽ thấy hệ thống chậm.

Tiêu chí	Cơ sở dữ liệu quan hệ	NoSQL (nhìn chung)	Data warehouse
Cấu trúc	Bảng, lược đồ định trước	Tài liệu, khoá–giá trị, đồ thị… linh hoạt	Bảng, thường theo mô hình phân tích
Việc chính	Ghi và đọc nghiệp vụ hằng ngày	Khối lượng lớn, cấu trúc đa dạng	Tổng hợp, báo cáo, phân tích
Giao dịch	ACID là điểm mạnh	Tuỳ sản phẩm	Không phải trọng tâm
Đổi cấu trúc	Cần di chuyển lược đồ	Dễ hơn	Có kiểm soát theo quy trình nạp

Khi nào nên và không nên chọn cơ sở dữ liệu quan hệ?

Hai câu hỏi giúp bạn quyết định nhanh: dữ liệu có cấu trúc tương đối ổn định không, và sai lệch một bản ghi có gây hậu quả tiền bạc hay pháp lý không? Hình dưới đặt hai câu hỏi đó lên một ma trận.

Nên chọn khi nghiệp vụ xoay quanh các thực thể rõ ràng có quan hệ với nhau (khách, đơn, hoá đơn), cần truy vấn linh hoạt và cần chặn dữ liệu sai ngay từ cơ sở dữ liệu. Đây là lựa chọn mặc định hợp lý cho phần lớn phần mềm quản lý doanh nghiệp.

Nên cân nhắc cách khác khi bạn lưu luồng sự kiện hoặc nhật ký với tốc độ ghi rất cao (xem streaming data), khi mỗi bản ghi có cấu trúc khác hẳn nhau, hoặc khi mục tiêu chính là phân tích tổng hợp trên khối lượng lớn thay vì xử lý từng giao dịch.

Những lỗi thiết kế thường gặp là gì?

• Không đặt khoá ngoại “cho nhanh”. Hậu quả là xuất hiện đơn hàng mồ côi, chi tiết đơn không còn đơn cha. Hãy khai báo khoá ngoại và quy định rõ khi xoá cha thì cấm xoá hay xoá theo.
• Nhét nhiều giá trị vào một ô. Chuỗi như “0901…, 0902…” trong cột điện thoại khiến bạn không tìm hay thống kê được. Tách ra bảng liên hệ riêng.
• Dùng số điện thoại hoặc email làm khoá chính. Giá trị này có thể đổi. Khoá chính nên là mã nội bộ ổn định, còn số điện thoại là cột có ràng buộc duy nhất nếu cần.
• Lưu tiền bằng kiểu số thực dấu phẩy động. Sai số làm tổng lệch vài đồng. Dùng kiểu số thập phân cố định (DECIMAL/NUMERIC) hoặc lưu theo đơn vị nhỏ nhất.
• Thiếu chỉ mục trên cột dùng để join và lọc. Truy vấn chạy ổn khi dữ liệu nhỏ, rồi chậm hẳn khi bảng lên hàng triệu dòng. Dùng lệnh xem kế hoạch thực thi (EXPLAIN) để kiểm tra trước khi thêm chỉ mục bừa bãi.
• Chạy báo cáo nặng trực tiếp trên cơ sở dữ liệu giao dịch. Hãy dùng bản sao đọc hoặc đẩy dữ liệu sang kho phân tích.

Dữ liệu sai thường bắt nguồn từ thiết kế lỏng lẻo hơn là từ lỗi người nhập; phần này liên quan trực tiếp tới chất lượng dữ liệu.

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

Relational database và RDBMS có phải một không?

Không. Relational database là tập dữ liệu được tổ chức theo mô hình quan hệ. RDBMS là phần mềm quản lý tập dữ liệu đó. Trong giao tiếp hằng ngày hai từ hay bị dùng thay nhau, nhưng khi trao đổi kỹ thuật, bạn nên gọi “cơ sở dữ liệu” khi nói về dữ liệu và “hệ quản trị” khi nói về phần mềm.

Excel có phải cơ sở dữ liệu quan hệ không?

Excel cũng có bảng, hàng, cột và hàm tra cứu như VLOOKUP, nhưng không có khoá ngoại bắt buộc, không có giao dịch ACID và không kiểm soát nhiều người cùng ghi một lúc. Với danh sách nhỏ một người dùng, Excel đủ dùng. Khi nhiều người cùng cập nhật và dữ liệu có quan hệ chéo, hệ quản trị quan hệ an toàn hơn.

Cơ sở dữ liệu quan hệ có xử lý được dữ liệu lớn không?

Có, trong giới hạn nhất định. Với chỉ mục tốt, phân vùng bảng và bản sao đọc, nhiều hệ thống vận hành bảng hàng trăm triệu dòng. Khi khối lượng và tốc độ vượt khả năng một cụm máy, bạn mới cần các kiến trúc khác; xem tổng quan ở bài big data là gì.

Học cơ sở dữ liệu quan hệ nên bắt đầu từ đâu?

Bắt đầu với SQL cơ bản (SELECT, JOIN, GROUP BY), sau đó học thiết kế bảng, khoá, chuẩn hoá và đọc kế hoạch thực thi truy vấn. Bạn có thể cài MySQL hoặc PostgreSQL trên máy cá nhân và tự dựng thử bốn bảng cửa hàng online như ví dụ trong bài.

Mô hình quan hệ có lỗi thời trước NoSQL không?

Không. Mô hình ra đời từ năm 1970 nhưng vẫn là nền tảng của phần lớn hệ thống nghiệp vụ. Các hệ NoSQL giải quyết bài toán khác về cấu trúc và quy mô, còn nhiều hệ quan hệ đã tiếp thu ý tưởng như JSON. Lựa chọn nên dựa trên đặc điểm dữ liệu và yêu cầu về tính nhất quán.

Khi cột dữ liệu đổi, phải làm gì với cơ sở dữ liệu đang chạy?

Bạn thực hiện di chuyển lược đồ (schema migration): viết tập lệnh ALTER có phiên bản, thử trên bản sao dữ liệu thật, rồi áp dụng vào lúc ít tải. Với bảng rất lớn, một số hệ cho phép thêm cột mà không khoá bảng lâu, nhưng hành vi này phụ thuộc từng sản phẩm và phiên bản nên cần đọc tài liệu trước khi làm.