Vì sao cần thiết kế mô hình dữ liệu trước khi lưu trữ?

Thiết kế trước vì lưu trữ không đơn thuần là “đặt dữ liệu vào đâu đó”. Mỗi cấu trúc lưu trữ đều ngầm chứa giả định về ý nghĩa, quan hệ và quy tắc của dữ liệu. Nếu các giả định ấy sai hoặc không thống nhất, vấn đề thường chỉ lộ rõ sau khi dữ liệu đã phát sinh: cùng một thông tin xuất hiện ở nhiều nơi, quan hệ không thể kiểm soát, bản ghi mâu thuẫn hoặc thay đổi nghiệp vụ kéo theo quá trình chuyển đổi dữ liệu phức tạp.

Mô hình dữ liệu là gì?

Mô hình dữ liệu là sự biểu diễn có cấu trúc về những thông tin mà một hệ thống cần quản lý. Nó xác định các thực thể cần theo dõi, thuộc tính mô tả từng thực thể, quan hệ giữa chúng và các ràng buộc chi phối dữ liệu. Chẳng hạn, trong một hệ thống bán hàng, Khách hàng, Đơn hàng và Sản phẩm có thể là các thực thể; mã khách hàng, ngày đặt hàng hay đơn giá là các thuộc tính; còn việc một khách hàng có thể tạo nhiều đơn hàng là một quan hệ.

Tài liệu của IBM mô tả data modeling như quá trình biểu diễn các cấu trúc dữ liệu và mối liên hệ giữa chúng, đồng thời nhấn mạnh rằng yêu cầu và quy tắc nghiệp vụ cần được chuyển thành cấu trúc dữ liệu trước khi triển khai cơ sở dữ liệu.

Mô hình dữ liệu cũng không đồng nghĩa hoàn toàn với database schema. Mô hình có thể tồn tại ở mức nghiệp vụ hoặc logic, chưa phụ thuộc một hệ quản trị cơ sở dữ liệu cụ thể. Schema thường gần với cách dữ liệu thực sự được triển khai hơn, chẳng hạn bảng, cột, kiểu dữ liệu, khóa và chỉ mục. Vì vậy, một sơ đồ ERD có thể là phương tiện thể hiện mô hình, nhưng bản thân sơ đồ không nhất thiết chứa toàn bộ quy tắc và ý nghĩa của dữ liệu.

Điểm quan trọng nằm ở chỗ mô hình mô tả ý nghĩa của thông tin trước khi mô tả nơi chứa thông tin. Chính sự tách biệt này giúp đội ngũ tránh biến những quyết định kỹ thuật tạm thời thành cấu trúc dữ liệu khó thay đổi về sau.

Vì sao phải thiết kế mô hình dữ liệu trước khi lưu trữ?

Lý do đầu tiên là để thống nhất một khái niệm nghiệp vụ tương ứng với dữ liệu nào. Nếu không có mô hình, hai phần của cùng hệ thống có thể hiểu “khách hàng” theo hai cách khác nhau: nơi này coi email là định danh duy nhất, nơi khác dùng số điện thoại, còn một hệ thống khác lại tạo mã riêng. Dữ liệu vẫn có thể được lưu, nhưng khi kết nối các nguồn với nhau, việc xác định bản ghi nào thực sự đại diện cho cùng một người trở nên khó khăn.

Mô hình còn xác định quan hệ trước khi dữ liệu phát sinh. Trong cơ sở dữ liệu quan hệ, quan hệ một-một, một-nhiều hoặc nhiều-nhiều thường được thể hiện thông qua khóa và các cấu trúc liên kết phù hợp. Foreign key, chẳng hạn, cho phép bản ghi ở phía phụ thuộc tham chiếu tới khóa của thực thể chính, nhờ đó quan hệ không chỉ tồn tại trong suy nghĩ của lập trình viên mà trở thành một phần có thể kiểm soát của hệ thống.

Một lợi ích khác là kiểm soát dư thừa và tính nhất quán. Nếu tên, địa chỉ và số điện thoại của khách hàng được sao chép vào mọi đơn hàng, một thay đổi địa chỉ có thể buộc hệ thống cập nhật nhiều bản ghi. Nếu chỉ một phần được cập nhật, cơ sở dữ liệu sẽ tồn tại nhiều phiên bản khác nhau của cùng một thông tin. Nguyên tắc chuẩn hóa trong thiết kế cơ sở dữ liệu được sử dụng chính để hạn chế dạng dư thừa này và giảm các bất thường khi thêm, sửa hoặc xóa dữ liệu.

Thiết kế trước cũng cho phép xác định những ràng buộc về tính hợp lệ. Một mã đơn hàng có cần duy nhất hay không? Đơn hàng có được phép tồn tại khi chưa có khách hàng? Số lượng sản phẩm có thể bằng 0 không? Trạng thái nào được phép chuyển sang trạng thái nào? Không phải tất cả quy tắc đều được triển khai trực tiếp bằng constraint của cơ sở dữ liệu, nhưng mô hình phải làm rõ chúng để tầng lưu trữ và logic ứng dụng không đưa ra các quyết định mâu thuẫn.

Cấu trúc dữ liệu còn ảnh hưởng trực tiếp đến cách dữ liệu được truy vấn. Một mô hình logic tốt không tự động bảo đảm truy vấn nhanh, vì hiệu năng còn phụ thuộc vào chỉ mục, dung lượng, phân vùng, loại cơ sở dữ liệu và access pattern. Tuy vậy, nếu quan hệ và ranh giới giữa các thực thể đã sai từ đầu, việc thêm chỉ mục chỉ tối ưu một cấu trúc sai chứ không sửa được ý nghĩa của dữ liệu.

Cuối cùng là chi phí thay đổi. Khi mô hình thay đổi trước lúc có dữ liệu thật, phần lớn công việc nằm ở thiết kế. Khi thay đổi sau khi hệ thống đã vận hành, có thể phải chuyển đổi bản ghi cũ, duy trì tương thích với ứng dụng đang sử dụng schema trước đó và kiểm tra lại các báo cáo, API hoặc quy trình phụ thuộc vào cấu trúc cũ. Thiết kế trước không loại bỏ mọi thay đổi, nhưng giúp những quyết định nền tảng được kiểm tra khi chi phí sửa còn thấp hơn.

Ba mức mô hình chuyển yêu cầu nghiệp vụ thành cấu trúc lưu trữ

Trong thực hành data modeling, mô hình thường được nhìn qua ba mức trừu tượng: conceptual, logical và physical. Chúng không phải ba cơ sở dữ liệu khác nhau mà là ba góc nhìn ngày càng cụ thể của cùng một miền dữ liệu. IBM cũng phân biệt ba mức này, trong đó mô hình logic không phụ thuộc DBMS còn mô hình vật lý mô tả cấu trúc có thể triển khai như bảng, cột, khóa và các thành phần vật lý khác.

Mô hình khái niệm

Mô hình khái niệm trả lời câu hỏi hệ thống cần quản lý những loại thông tin nào và chúng liên quan đến nhau ra sao. Ở mức này, trọng tâm là ngôn ngữ nghiệp vụ.

Ví dụ, doanh nghiệp xác định có Khách hàng, Đơn hàng, Sản phẩm và Thanh toán. Một Khách hàng có thể tạo nhiều Đơn hàng; mỗi Đơn hàng chứa sản phẩm và có thể gắn với giao dịch thanh toán. Chưa cần quyết định tên bảng hay kiểu dữ liệu cụ thể.

Mô hình logic

Mô hình logic đi sâu hơn vào thuộc tính, định danh, cardinality và các ràng buộc. “Khách hàng” lúc này có thể được xác định bởi CustomerID và có các thuộc tính như tên, email, số điện thoại. Quan hệ giữa Khách hàng và Đơn hàng được mô tả rõ là một-nhiều.

Mức logic đặc biệt hữu ích vì nó buộc đội ngũ giải quyết các câu hỏi về ý nghĩa dữ liệu trước khi bị chi phối bởi một công nghệ lưu trữ cụ thể.

Mô hình vật lý

Mô hình vật lý biến thiết kế logic thành cấu trúc phù hợp với nền tảng triển khai. Với cơ sở dữ liệu quan hệ, đây có thể là bảng, cột, kiểu dữ liệu, primary key, foreign key, index và các cấu hình liên quan.

Chính ở mức này, yêu cầu về truy vấn, dung lượng, hiệu năng và đặc điểm của DBMS tác động mạnh hơn. Một quan hệ đúng về mặt logic có thể được triển khai theo nhiều cách vật lý khác nhau tùy workload, nhưng cách triển khai vẫn phải bảo toàn ý nghĩa nghiệp vụ mà mô hình logic đã xác định.

Không phải mọi dự án đều cần ba bộ tài liệu đồ sộ. Một ứng dụng nhỏ có thể gộp một số bước vào cùng sơ đồ. Giá trị nằm ở việc các quyết định tương ứng vẫn được suy nghĩ rõ ràng, chứ không nằm ở số lượng tài liệu được tạo ra.

Ví dụ: mô hình hóa khách hàng và đơn hàng trước khi tạo bảng

Giả sử một cửa hàng cần lưu khách hàng, đơn hàng và sản phẩm. Cách nhanh nhất có thể là tạo một bảng lớn chứa mã đơn, ngày đặt hàng, tên khách, số điện thoại, địa chỉ, tên sản phẩm, số lượng và giá. Cách này lưu được dữ liệu ngay, nhưng nhanh chóng phát sinh câu hỏi: một đơn có nhiều sản phẩm thì thông tin khách hàng phải lặp bao nhiêu lần? Nếu khách đổi số điện thoại, các đơn cũ có phải sửa theo không? Giá trên đơn hàng là giá hiện tại hay giá tại thời điểm mua?

Khi mô hình được xác định trước, các đối tượng có thể được tách theo ý nghĩa:

·         Customer lưu thông tin nhận diện và liên hệ hiện tại của khách hàng

·         Order lưu giao dịch đặt hàng và tham chiếu Customer thông qua CustomerID

·         Product lưu thông tin sản phẩm

·         OrderItem liên kết Order với Product, đồng thời lưu số lượng và mức giá áp dụng cho dòng hàng đó

Cấu trúc này cho thấy một khách hàng có thể có nhiều đơn hàng, còn quan hệ nhiều-nhiều giữa đơn hàng và sản phẩm được xử lý thông qua OrderItem. Dữ liệu khách hàng không cần được sao chép toàn bộ vào từng dòng sản phẩm.

Tuy nhiên, đây cũng là nơi thấy rõ rằng “không lặp dữ liệu” không phải nguyên tắc tuyệt đối. Nếu doanh nghiệp cần chứng minh địa chỉ đã dùng để giao một đơn hàng tại thời điểm giao dịch, việc lưu một shipping-address snapshot trong đơn hàng có thể là quyết định đúng. Tương tự, giá bán trong OrderItem nên phản ánh mức giá thực tế khi giao dịch xảy ra thay vì luôn đọc giá hiện tại từ Product.

Những trường hợp này không phải dư thừa do thiết kế cẩu thả. Chúng là dữ liệu lịch sử có ý nghĩa riêng. Mô hình tốt giúp phân biệt giữa sao chép không cần thiết và lưu có chủ đích để bảo toàn một sự kiện trong quá khứ.

Thiết kế trước không có nghĩa là đóng băng mô hình

Một mô hình dữ liệu tốt không phải cấu trúc được thiết kế một lần rồi không bao giờ thay đổi. Nghiệp vụ thay đổi, nguồn dữ liệu mới xuất hiện và cách hệ thống được sử dụng cũng có thể khác so với dự kiến ban đầu. Vì vậy, thiết kế trước nhằm tạo một điểm xuất phát có logic và có thể kiểm chứng, không nhằm loại bỏ khả năng tiến hóa.

Mức độ mô hình hóa cũng phải phù hợp với quy mô và rủi ro. Một prototype có thể chỉ cần xác định vài thực thể, quan hệ và quy tắc cốt lõi. Một hệ thống dùng chung dữ liệu giữa nhiều ứng dụng cần kiểm soát chặt hơn vì một thay đổi schema có thể ảnh hưởng nhiều thành phần phụ thuộc.

Tương tự, chuẩn hóa không nên được áp dụng như mục tiêu tuyệt đối. Một số workload đọc nhiều có thể cần denormalization, materialized view hoặc cấu trúc được tối ưu theo access pattern. Điều quan trọng là những quyết định đó phải được đưa ra có chủ đích: biết thông tin nào đang được lặp, vì sao cần lặp và cơ chế nào bảo đảm các bản sao không tạo ra mâu thuẫn ngoài ý muốn.

Ngay cả khi sử dụng hệ thống NoSQL không có schema cứng theo kiểu cơ sở dữ liệu quan hệ, nhu cầu mô hình hóa vẫn tồn tại. Ứng dụng vẫn phải quyết định cấu trúc document, khóa định danh, cách biểu diễn quan hệ, dữ liệu nào được nhúng hay tham chiếu và access pattern nào cần ưu tiên. “Schema linh hoạt” vì thế không đồng nghĩa với “không cần thiết kế dữ liệu”.

Mô hình dữ liệu cần được thiết kế trước khi lưu trữ vì nó xác định dữ liệu có nghĩa gì, thuộc về đối tượng nào, liên hệ với nhau thế nào và phải tuân theo quy tắc gì trước khi các quyết định đó trở thành cấu trúc kỹ thuật.

Khi phần nền này rõ ràng, cơ sở dữ liệu có khả năng giữ dữ liệu nhất quán hơn, hạn chế dư thừa không cần thiết và thích ứng với thay đổi có kiểm soát. Thiết kế trước không bảo đảm một hệ thống sẽ không bao giờ phải sửa mô hình; nó giúp những lần sửa sau diễn ra trên một cấu trúc có chủ đích thay vì phải tháo gỡ các giả định đã vô tình bị đóng cứng vào dữ liệu.