Data modeling là gì?

Mục lục

1. Data modeling là gì và nó giải quyết vấn đề nào?
2. Ba cấp mô hình: conceptual, logical, physical khác nhau ở đâu?
3. Một data model gồm những thành phần nào?
4. Cách mô hình hoá hoạt động: ví dụ một chuỗi trà sữa
5. Chuẩn hoá, ERD và star schema: dùng mô hình nào cho việc gì?
6. Có phải chỉ dùng cho cơ sở dữ liệu quan hệ không?
7. Ứng dụng cho doanh nghiệp Việt Nam
8. Ưu điểm và hạn chế
9. Data modeling khác gì với các khái niệm gần?
10. Khi nào nên và không nên đầu tư mô hình hoá bài bản?
11. Checklist kiểm tra một data model trước khi cài đặt
12. Công cụ vẽ và quản lý data model
13. Câu hỏi thường gặp

Data modeling là gì và nó giải quyết vấn đề nào?

Data modeling là quá trình xác định và vẽ lại cách dữ liệu của doanh nghiệp được tổ chức: có những đối tượng nào (khách hàng, đơn hàng, sản phẩm), mỗi đối tượng có thông tin gì, và chúng gắn với nhau theo quan hệ nào. Các bài tiếng Việt đang xếp hạng đều mô tả nó là việc tạo ra mô hình dữ liệu để lưu trong cơ sở dữ liệu và thể hiện quan hệ giữa các đối tượng dữ liệu. Cách hiểu đó đúng, nhưng thiếu một điểm: mô hình hoá trước hết là cuộc trao đổi giữa người làm nghiệp vụ và người làm kỹ thuật. Bảng chỉ là hệ quả.

Ví dụ minh hoạ: một chuỗi bán lẻ có 12 cửa hàng. Phòng kế toán gọi “khách hàng” là người xuất hoá đơn có mã số thuế. Phòng marketing gọi “khách hàng” là mọi người từng quét mã tích điểm. Phần mềm bán hàng lưu một kiểu, CRM lưu một kiểu khác. Nếu không ai ngồi lại thống nhất “khách hàng” là gì, báo cáo “số khách hàng tháng này” sẽ ra hai con số và cả hai đều đúng theo cách đếm riêng. Data modeling buộc các bên viết định nghĩa đó ra thành một thực thể có khoá, thuộc tính và quy tắc rõ ràng.

Nếu bạn chưa quen khái niệm nền, hãy đọc trước bài về cơ sở dữ liệu và DBMS. Tóm gọn: cơ sở dữ liệu là nơi chứa dữ liệu, còn data model là bản thiết kế quyết định nơi chứa đó được chia ngăn thế nào.

Ba cấp mô hình: conceptual, logical, physical khác nhau ở đâu?

Hầu hết tài liệu chuyên môn chia mô hình hoá thành ba cấp, đi từ ngôn ngữ nghiệp vụ đến cấu trúc cài đặt trong một hệ quản trị cơ sở dữ liệu cụ thể.

Tiêu chí	Khái niệm	Logic	Vật lý
Trả lời câu hỏi	Hệ thống chứa những gì?	Dữ liệu được tổ chức thế nào, độc lập với DBMS?	Cài đặt cụ thể trong DBMS ra sao?
Người dùng chính	Người làm nghiệp vụ, kiến trúc sư dữ liệu	Kiến trúc sư dữ liệu, business analyst	DBA, lập trình viên
Chi tiết	Thực thể, quan hệ ở mức cao	Thuộc tính, khoá chính, khoá ngoại, kiểu dữ liệu chung, chuẩn hoá	Bảng, cột có kiểu riêng của DBMS, chỉ mục, phân vùng
Chuẩn hoá	Chưa áp dụng	Thường đến 3NF	Có thể phi chuẩn hoá có chủ đích để tăng tốc truy vấn

Cách phân vai trên khớp với mô tả trong tài liệu của Guru99 và các hướng dẫn kỹ thuật tương tự: người làm nghiệp vụ sở hữu cấp khái niệm, kiến trúc sư định hình cấp logic, DBA và lập trình viên giao cấp vật lý. Trong dự án nhỏ, ba cấp có thể gộp trên một tờ giấy, nhưng ranh giới tư duy vẫn nên giữ: đừng quyết định kiểu dữ liệu hay chỉ mục khi nghiệp vụ chưa thống nhất thực thể.

Một data model gồm những thành phần nào?

• Thực thể (entity): thứ doanh nghiệp cần theo dõi, như Khách hàng, Đơn hàng, Sản phẩm.
• Thuộc tính (attribute): thông tin mô tả thực thể, như tên, email, ngày đăng ký.
• Khoá chính (primary key): thuộc tính hoặc nhóm thuộc tính định danh duy nhất một dòng. Mỗi bảng cần một khoá, và mỗi đối tượng thật chỉ có một dòng.
• Khoá ngoại (foreign key): cột tham chiếu tới khoá chính của bảng khác, ví dụ cột mã khách hàng trong bảng đơn hàng.
• Quan hệ và số lượng quan hệ (cardinality): một-một, một-nhiều hoặc nhiều-nhiều, kèm việc quan hệ đó bắt buộc hay tuỳ chọn.
• Quy tắc toàn vẹn: ràng buộc như “đơn hàng phải thuộc một khách hàng đã tồn tại”, “giá không âm”.

Quan hệ nhiều-nhiều là chỗ người mới hay vấp. Một đơn hàng có nhiều sản phẩm, một sản phẩm nằm trong nhiều đơn. Bạn không thể nhét cả hai vào một cột. Cách xử lý chuẩn là tạo bảng trung gian (thường gọi là chi tiết đơn hàng) với khoá ngoại trỏ về cả hai phía, và bảng đó còn chứa số lượng, đơn giá tại thời điểm bán.

Cách mô hình hoá hoạt động: ví dụ một chuỗi trà sữa

Ví dụ minh hoạ (giả định): chuỗi trà sữa muốn biết món nào bán chạy theo cửa hàng và theo khung giờ. Quy trình mô hình hoá có thể đi như sau.

1. Liệt kê danh từ nghiệp vụ. Phỏng vấn quản lý cửa hàng, thu ngân, kế toán. Kết quả: Cửa hàng, Món, Topping, Đơn hàng, Khách thành viên, Khuyến mãi.
2. Vẽ quan hệ ở cấp khái niệm. Một cửa hàng có nhiều đơn; một đơn gồm nhiều dòng món; một khách thành viên có nhiều đơn nhưng đơn của khách vãng lai không có khách.
3. Chốt thuộc tính và khoá ở cấp logic. Đơn hàng có mã đơn, thời điểm tạo, mã cửa hàng, mã khách (cho phép rỗng). Dòng món lưu đơn giá tại thời điểm bán, vì giá menu sẽ đổi.
4. Chuẩn hoá. Địa chỉ cửa hàng không chép vào từng đơn, chỉ lưu một lần ở bảng Cửa hàng và tham chiếu bằng khoá.
5. Cài đặt vật lý. Chọn kiểu dữ liệu, đặt chỉ mục trên cột thời điểm tạo và mã cửa hàng vì các báo cáo luôn lọc theo hai cột đó.

Chi tiết nhỏ ở bước 3, lưu đơn giá tại thời điểm bán, là kiểu quyết định chỉ xuất hiện khi mô hình hoá nghiêm túc. Nếu chỉ tham chiếu giá hiện tại trong bảng Món, doanh thu quá khứ sẽ tự thay đổi mỗi lần đổi menu.

Với ngôn ngữ truy vấn để làm việc trên các bảng này, bạn có thể xem hướng dẫn SQL cơ bản.

Chuẩn hoá, ERD và star schema: dùng mô hình nào cho việc gì?

Ba kỹ thuật này hay bị nhầm là “đối thủ” của nhau. Thực tế chúng phục vụ hai loại việc khác nhau.

ERD và chuẩn hoá đến 3NF

Sơ đồ thực thể-quan hệ (entity relationship diagram, ERD) vẽ thực thể, thuộc tính và quan hệ ở dạng đồ hoạ. Chuẩn hoá (normalization) tách bảng rộng thành các bảng nhỏ có liên kết để loại bỏ dư thừa và tránh lỗi cập nhật. Dạng chuẩn thứ ba (3NF) loại các phụ thuộc bắc cầu: thuộc tính không khoá chỉ được phụ thuộc vào khoá, không phụ thuộc vào thuộc tính không khoá khác. Cách này hợp với hệ thống ghi nhận giao dịch, nơi mỗi thông tin chỉ nên nằm đúng một chỗ.

Mô hình chiều (dimensional) và star schema

Ralph Kimball đề xuất star schema cho phân tích: một bảng sự kiện (fact) ở giữa chứa các số đo như số lượng, doanh thu, nối bằng khoá ngoại tới các bảng chiều (dimension) xung quanh. Theo phân tích đăng trên MSSQLTips về các sách của Kimball, ông cho rằng độ dễ dùng và tốc độ truy vấn của star schema đáng giá hơn phần dung lượng tiết kiệm được của snowflake schema. Bảng chiều thường được làm phẳng (phi chuẩn hoá) có chủ đích.

Kimball mô tả bốn bước thiết kế: chọn quy trình nghiệp vụ, xác định grain, xác định các chiều, xác định các sự kiện (số đo). Grain là bước quan trọng nhất. Trong ví dụ trên, bạn phải chọn một dòng sự kiện đại diện cho “một dòng món trong một đơn” hay “một đơn” hay “tổng theo cửa hàng theo ngày”. Chọn grain thô rồi sau này muốn xem theo món thì không thể tách ngược ra, vì dữ liệu chi tiết đã mất.

Chọn theo mục đích

Sự phân biệt này gắn chặt với khác biệt giữa hệ thống ghi nhận giao dịch và hệ thống phân tích, được giải thích trong bài OLAP và OLTP. Khi dựng kho dữ liệu, việc chọn Kimball, Inmon hay Data Vault là một chủ đề lớn của kiến trúc data warehouse. Theo mô tả của Agile Data Engine, Inmon đi từ trên xuống, dựng kho ở dạng 3NF toàn doanh nghiệp trước; Kimball đi từ dưới lên, gom nhiều data mart dạng chiều thành kho.

Có phải chỉ dùng cho cơ sở dữ liệu quan hệ không?

Không. Mô hình quan hệ chỉ là một dạng. Các tài liệu tiếng Việt còn liệt kê mô hình phân cấp, mạng, hướng đối tượng. Với dữ liệu phi quan hệ, mô hình hoá vẫn cần nhưng chuyển trọng tâm: thay vì hỏi “bảng nào nối với bảng nào”, bạn hỏi “ứng dụng đọc dữ liệu theo cách nào”. Ở cơ sở dữ liệu tài liệu, quyết định chính là nhúng dữ liệu con vào cùng tài liệu hay tham chiếu sang tài liệu khác. Cơ sở dữ liệu cột rộng thường thiết kế bảng theo từng truy vấn dự kiến. Phần này có chỗ khác biệt riêng, xem NoSQL là gì để nắm các nhóm kiểu dữ liệu.

Việc bỏ qua mô hình hoá vì “NoSQL không cần schema” là hiểu nhầm phổ biến. Cơ sở dữ liệu có thể không ép schema, nhưng ứng dụng đọc dữ liệu vẫn giả định một cấu trúc. Cấu trúc đó chỉ chuyển từ cơ sở dữ liệu sang mã nguồn.

Ứng dụng cho doanh nghiệp Việt Nam

• Phần mềm nội bộ: trước khi thuê làm hệ thống quản lý đơn hàng hay kho, yêu cầu nhà thầu giao kèm ERD. Bản vẽ này là tài liệu bàn giao có thể kiểm tra, và giúp bạn đổi nhà cung cấp sau này mà không phải đoán cấu trúc bảng.
• Báo cáo và BI: khi dashboard chạy chậm hoặc mỗi phòng một con số, nguyên nhân thường nằm ở việc báo cáo đọc thẳng từ bảng giao dịch. Dựng một lớp mô hình chiều giúp công cụ business intelligence chỉ cần kéo-thả.
• Hợp nhất nhiều hệ thống: khi sáp nhập hoặc có ERP, CRM, POS riêng, mô hình khái niệm chung (khách hàng, sản phẩm) là nền để đối chiếu mã. Việc giữ một bản ghi gốc cho các đối tượng này thuộc phạm vi quản lý dữ liệu chủ.
• Dữ liệu cá nhân: Ở bước mô hình, bạn nên gắn nhãn các cột là dữ liệu cá nhân (họ tên, số điện thoại, ảnh khuôn mặt…) trong từ điển dữ liệu, để sau này biết cột nào cần che, xoá hoặc giới hạn quyền truy cập.

Ưu điểm và hạn chế

Ưu điểm	Hạn chế
Sửa sai trên bản vẽ rẻ hơn nhiều so với sửa khi bảng đã có hàng triệu dòng và báo cáo đã phụ thuộc vào chúng.	Mất thời gian họp để thống nhất định nghĩa; nghiệp vụ hay đổi thì mô hình phải cập nhật theo.
Tạo ngôn ngữ chung giữa nghiệp vụ và kỹ thuật, giảm tranh cãi số liệu.	Mô hình quá chi tiết ngay từ đầu dễ thành tài liệu không ai đọc.
Chuẩn hoá giảm trùng lặp và lỗi cập nhật; star schema giúp truy vấn phân tích đơn giản.	Star schema nhân bản dữ liệu và cần quy trình nạp định kỳ. Cube.dev ước tính dựng một star cho một quy trình nghiệp vụ có thể mất vài tuần.
Là điểm xuất phát cho từ điển dữ liệu, phân quyền và kiểm soát chất lượng.	Mô hình đẹp không bảo đảm dữ liệu nhập đúng; vẫn cần kiểm soát chất lượng ở nguồn.

Data modeling khác gì với các khái niệm gần?

• Thiết kế cơ sở dữ liệu: thường chỉ phần logic và vật lý cho một ứng dụng. Data modeling rộng hơn, bắt đầu từ cấp khái niệm và có thể phủ nhiều hệ thống.
• Siêu dữ liệu (metadata): là dữ liệu mô tả dữ liệu, như tên cột, kiểu, nguồn. Data model là nơi sinh ra phần lớn metadata đó; xem thêm metadata là gì.
• ETL/ELT: là cách di chuyển và biến đổi dữ liệu vào mô hình đích. Mô hình đích phải có trước, sau đó mới viết luồng nạp. Bài ETL là gì trình bày phần luồng.
• Data lineage: truy vết dữ liệu đi từ đâu đến đâu. Nó cần mô hình để biết các thực thể nối nhau thế nào; xem data lineage.

Khi nào nên và không nên đầu tư mô hình hoá bài bản?

Nên làm bài bản khi: hệ thống sẽ sống nhiều năm; nhiều phòng ban cùng dùng một dữ liệu; có kế hoạch dựng kho dữ liệu hoặc BI; hoặc dữ liệu có yêu cầu pháp lý cao như dữ liệu cá nhân hoặc tài chính.

Có thể làm nhẹ khi: chỉ phân tích một lần trên một tệp, hoặc làm bản mẫu thử ý tưởng sẽ bỏ đi. Lúc đó một phác thảo thực thể và quan hệ trên giấy thường đủ.

Checklist kiểm tra một data model trước khi cài đặt

1. Mỗi thực thể có định nghĩa bằng một câu mà người nghiệp vụ ký xác nhận.
2. Mỗi bảng có khoá chính ổn định. Tránh dùng số điện thoại hay email làm khoá vì chúng có thể đổi.
3. Mỗi quan hệ nhiều-nhiều đã được tách qua bảng trung gian.
4. Với bảng sự kiện, câu “một dòng đại diện cho…” đã được viết ra và không mâu thuẫn.
5. Các giá trị có thể thay đổi theo thời gian (giá, địa chỉ, hạng thành viên) đã có quyết định: ghi đè, lưu lịch sử, hay chụp lại tại thời điểm giao dịch.
6. Cột chứa dữ liệu cá nhân đã được đánh dấu.
7. Tên bảng, tên cột theo một quy ước thống nhất, có từ điển dữ liệu đi kèm.

Điểm 5 là chỗ nhiều mô hình thiếu. Trong kho dữ liệu, kỹ thuật chiều thay đổi chậm (slowly changing dimension) tồn tại chính vì địa chỉ khách hay hạng thành viên đổi theo thời gian mà báo cáo lịch sử vẫn phải đúng.

Công cụ vẽ và quản lý data model

Công cụ chỉ là phương tiện: có thể là bảng trắng, các công cụ vẽ ERD chuyên dụng, hoặc chức năng thiết kế sơ đồ đi kèm DBMS và công cụ BI. Khi chọn, hãy xem ba tiêu chí: có xuất ra được script tạo bảng (forward engineering) và đọc ngược từ cơ sở dữ liệu có sẵn (reverse engineering) không; có lưu phiên bản và so sánh thay đổi không; có gắn được mô tả nghiệp vụ cho từng cột không. Với đội nhỏ, bản vẽ lưu cùng mã nguồn và duyệt như mã vẫn tốt hơn một tệp riêng không ai cập nhật. Khi số bảng lên hàng trăm, nên nối mô hình với danh mục dữ liệu để người dùng tìm và hiểu bảng mà không phải hỏi từng người.

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

Data modeling và data model khác nhau thế nào?

Data model là sản phẩm: sơ đồ và tài liệu mô tả cấu trúc dữ liệu. Data modeling là hoạt động tạo ra và duy trì sản phẩm đó. Trong tiếng Việt, “mô hình hoá dữ liệu” chỉ hoạt động, “mô hình dữ liệu” chỉ sản phẩm.

Người không biết lập trình có làm được data modeling không?

Phần khái niệm thì có, và nên có. Người nghiệp vụ là người biết khách hàng, hợp đồng hay đơn hàng thực sự vận hành ra sao. Phần logic và vật lý cần người quen với khoá, kiểu dữ liệu và DBMS.

Chuẩn hoá đến mức nào là đủ?

Với hệ thống ghi giao dịch, 3NF là điểm dừng phổ biến theo các tài liệu chuyên ngành. Với kho dữ liệu phục vụ báo cáo, bạn có thể phi chuẩn hoá có chủ đích ở bảng chiều để truy vấn đơn giản hơn. Hãy ghi rõ lý do mỗi lần phi chuẩn hoá.

Star schema và snowflake schema khác nhau ở đâu?

Star schema giữ mỗi chiều trong một bảng phẳng. Snowflake schema tách chiều thành nhiều bảng chuẩn hoá. Snowflake tiết kiệm dung lượng hơn nhưng cần nhiều phép nối hơn; Kimball nghiêng về star vì dễ dùng và truy vấn nhanh hơn.

Có cần mô hình hoá khi dùng data lake không?

Có, chỉ là thời điểm khác. Dữ liệu thô có thể vào trước, nhưng đến lớp dùng cho báo cáo hoặc học máy vẫn cần mô hình rõ ràng. Hãy xem thêm về data lake để hiểu các lớp dữ liệu.

Mô hình dữ liệu có phải là tài liệu một lần rồi cất không?

Không. Nghiệp vụ đổi thì mô hình đổi. Hãy lưu phiên bản, ghi lý do thay đổi và cập nhật từ điển dữ liệu cùng lúc để bản vẽ luôn khớp với hệ thống thật.