JSON vs Cơ sở dữ liệu quan hệ: Cuộc đối đầu giữa Linh hoạt và Ổn định

🌐 Nếu bạn quan tâm đến NoSQL và muốn tìm hiểu thêm, bạn có thể khám phá nhiều bài viết chi tiết tại blog của mình: Quan Notes

Trong lĩnh vực quản lý và lưu trữ dữ liệu, hai mô hình được sử dụng rộng rãi nhất là mô hình dữ liệu quan hệ và mô hình dữ liệu tài liệu (JSON).

Mô hình quan hệ đã tồn tại hàng thập kỷ, nổi bật với tính ổn định và ràng buộc chặt chẽ, trong khi JSON cùng với các cơ sở dữ liệu tài liệu mang đến sự linh hoạt và khả năng biểu diễn dữ liệu phức tạp.

Việc nghiên cứu và so sánh hai mô hình này giúp chúng ta hiểu rõ đặc điểm, ưu nhược điểm và bối cảnh ứng dụng phù hợp.

I/ Tổng quan về Mô hình Tài liệu (Document) và Dữ Liệu Quan Hệ (Relational Data)

Mô hình dữ liệu quan hệ tổ chức các bộ dữ liệu cố định thành bảng với thuộc tính có tên và kiểu dữ liệu.

Các định dạng dữ liệu này thực chất chỉ là cách biểu diễn dữ liệu. Chúng cho phép tuần tự hóa (serialize) cấu trúc dữ liệu trong ứng dụng thành dạng có thể truyền qua mạng và được client sử dụng để xử lý logic.

• XML và Java từng phát triển song song từ những ngày đầu Internet công cộng, khi XML là định dạng phổ biến để trao đổi dữ liệu, còn Java là ngôn ngữ lập trình chính.
• JSON trở nên phổ biến cùng với sự phát triển của JavaScript trong hai thập kỷ qua, và hiện là định dạng dữ liệu chủ đạo trên web.
• Protocol Buffers (Protobuf) do Google phát triển, nhằm tạo ra định dạng nhỏ gọn và hiệu quả hơn XML.

Ban đầu, các định dạng này chủ yếu dùng để trao đổi dữ liệu, nhưng ngày nay còn được dùng làm mô hình dữ liệu cho các cơ sở dữ liệu dạng tài liệu.

Ví dụ:

• SQL Server hỗ trợ kiểu dữ liệu XML.
• PostgreSQL hỗ trợ XML và JSON.
• CouchBase, MongoDB, Snowflake… đều hỗ trợ JSON.

II/ Tổng quan về JSON

JSON là một định dạng văn bản phổ biến được thiết kế để con người dễ đọc và máy tính dễ xử lý, dùng để trao đổi dữ liệu bán cấu trúc.

Ban đầu, JSON được phát triển nhằm hỗ trợ việc trao đổi dữ liệu giữa web server và JavaScript chạy trên trình duyệt của client.

Ngày nay, JSON còn được sử dụng như dạng biểu diễn dữ liệu gốc trong nhiều cơ sở dữ liệu NoSQL.

JSON hỗ trợ ba loại dữ liệu chính:

• Object: tập hợp các cặp key–value, key luôn là chuỗi, value có thể là bất kỳ kiểu JSON (atomic, object, array), không được trùng key, dùng { }.
• Array: danh sách có thứ tự các giá trị, mỗi phần tử có thể là bất kỳ kiểu JSON, dùng [ ].
• Atomic: gồm số (64-bit float), chuỗi, boolean hoặc null.

Tài liệu JSON gồm các kiểu dữ liệu cơ bản, có thể lồng nhau, ví dụ: một đối tượng với khóa "books" chứa mảng các đối tượng.

Đặc điểm quan trọng của JSON là tính tự mô tả, cho phép mỗi tài liệu có lược đồ riêng ngay cả trong cùng cơ sở dữ liệu.

Tài liệu JSON có thể được diễn giải như một cây do cấu trúc lồng nhau của nó.

III/ So sánh JSON và Mô hình Quan hệ

Bây giờ chúng ta có thể so sánh JSON với mô hình dữ liệu quan hệ:

1/ Tính linh hoạt:

• JSON rất linh hoạt, dễ biểu diễn cấu trúc phức tạp và dữ liệu lồng nhau.
• Mô hình quan hệ kém linh hoạt hơn, cần dùng khóa và phép nối (join) để mô tả cấu trúc phức tạp.

2/ Ràng buộc lược đồ (schema):

• JSON mang tính tự mô tả, mỗi tài liệu có thể có cấu trúc riêng.
• Dữ liệu quan hệ áp dụng lược đồ cố định: tất cả các bản ghi trong bảng phải tuân theo cùng một cấu trúc định sẵn.

3/ Biểu diễn dữ liệu:

• JSON là định dạng văn bản, thuận tiện để truyền tải trên web và dễ dàng được xử lý bởi nhiều ngôn ngữ lập trình.
• Dữ liệu quan hệ dùng biểu diễn nhị phân, tối ưu cho lưu trữ và truy xuất trong hệ quản trị CSDL, nhưng không tiện chia sẻ (ví dụ MySQL và Postgres có định dạng nhị phân riêng, không tương thích nhau).

IV/ Chuyển đổi giữa JSON và Dữ liệu quan hệ

1/ Dữ liệu quan hệ sang JSON:

Một bảng quan hệ được biểu diễn trong JSON như một đối tượng với khóa là tên bảng và giá trị là mảng các đối tượng, mỗi đối tượng tương ứng một hàng (thuộc tính là khóa, giá trị là dữ liệu).

Với mối quan hệ một - nhiều được lồng ghép bằng cách nhúng các hàng liên quan từ bảng thứ hai vào bảng đầu tiên.

Với mối quan hệ nhiều - nhiều có ba cách biểu diễn:

• Mảng phẳng: Mỗi bảng là một mảng JSON, không dư thừa dữ liệu nhưng cần ứng dụng nối bảng.
• Lồng theo bảng thứ nhất: Nhúng bảng quan hệ và bảng thứ ba, gây trùng lặp dữ liệu bảng thứ ba.
• Lồng theo bảng thứ ba: Nhúng ngược lại, gây trùng lặp dữ liệu bảng thứ nhất. Hai cách này không cần nối bảng nhưng phải đồng bộ dữ liệu khi cập nhật.

2/ JSON sang Dữ liệu quan hệ:

Chuyển dữ liệu JSON thành bảng quan hệ gặp khó khăn do cấu trúc không đồng nhất.

Ví dụ, bảng person(name, phone, address, email) có thể gặp vấn đề:

• Nhiều giá trị: Số điện thoại đa dạng cần bảng riêng hoặc chấp nhận trùng lặp.
• Thiếu thuộc tính: Email có thể vắng mặt, dùng NULL, nhưng thuộc tính mới đòi hỏi sửa lược đồ.
• Cấu trúc khác nhau: Địa chỉ có thể là chuỗi hoặc đối tượng lồng ghép, khó thống nhất.

V/ Kết luận

Nói ngắn gọn, cơ sở dữ liệu quan hệ giống như một ngôi nhà chắc chắn với nền móng ổn định, trong khi JSON lại như căn hộ linh hoạt có thể thay đổi theo nhu cầu.

Ngày nay, nhiều hệ thống đang chọn cách kết hợp cả hai để vừa có sự vững chắc vừa có sự linh hoạt – một lựa chọn phù hợp với thế giới dữ liệu ngày càng phức tạp và thay đổi nhanh chóng.

Vậy là mình đã cùng nhìn lại hai thế giới dữ liệu – ổn định của quan hệ và linh hoạt của JSON – để thấy rằng khi kết hợp, chúng ta có thể xây dựng những hệ thống cực kì mạnh mẽ.

Đọc thêm: NoSQL – Bước Ngoặt Trong Dữ Liệu Lớn và Ứng Dụng Thực Tiễn

📚 Nguồn tham khảo

Berkeley: NoSQL - Database System

📝 Kết nối với mình

✍️ Blog: Quan Notes

💼 Linkedin: Võ Minh Quân