Mô hình dữ liệu chiều (dimensional modeling) tổ chức dữ liệu phân tích thành hai loại bảng: bảng fact chứa các sự kiện đo được (một dòng bán hàng, một lần nhập kho) cùng các con số cộng được như số lượng, tiền; và các bảng dimension mô tả ngữ cảnh của sự kiện: ai, cái gì, ở đâu, khi nào. Khi bảng fact nằm giữa và các dimension toả quanh, sơ đồ trông như ngôi sao, nên gọi là star schema.
Cách tổ chức này được Ralph Kimball phổ biến qua The Data Warehouse Toolkit (1996) và vẫn là nền tảng của phần lớn công cụ BI hiện đại. Lý do không nằm ở thẩm mỹ mà ở hai điều: người dùng nghiệp vụ hiểu được ("doanh thu theo sản phẩm, theo cửa hàng, theo tháng" đúng là cách họ hỏi), và bộ máy truy vấn chạy nhanh vì chỉ cần nối một bảng lớn với vài bảng nhỏ.
Fact và dimension: phân biệt bằng một câu hỏi
Cách nhanh nhất để phân biệt: trong câu hỏi quản trị, phần đứng sau chữ "tổng", "trung bình", "bao nhiêu" thường là fact; phần đứng sau chữ "theo" là dimension. "Tổng doanh thu và số đơn theo chi nhánh, theo nhóm hàng, theo quý" cho ta fact là doanh thu, số đơn; dimension là chi nhánh, nhóm hàng, thời gian.
Bảng fact thường dài và hẹp: hàng triệu dòng, mỗi dòng gồm các khoá trỏ tới dimension và vài cột số. Bảng dimension ngắn và rộng: vài nghìn sản phẩm, mỗi sản phẩm có hàng chục thuộc tính mô tả như nhóm hàng, ngành hàng, thương hiệu, quy cách, trạng thái kinh doanh. Thuộc tính dimension là thứ người dùng kéo vào bộ lọc và nhãn hàng, nên càng đầy đủ, đặt tên càng rõ thì báo cáo càng dễ dùng.
Một sai lầm phổ biến là đưa con số mô tả vào dimension rồi cộng chúng. Ví dụ đặt "giá niêm yết" trong dimension sản phẩm là đúng (đó là thuộc tính), nhưng tính doanh thu bằng cách nhân giá niêm yết với số lượng là sai, vì giá bán thực tế sau chiết khấu là một sự kiện và thuộc về bảng fact.
Quy trình bốn bước thiết kế của Kimball
Kimball đề xuất bốn quyết định theo đúng thứ tự. Đảo thứ tự, đặc biệt là bỏ qua bước hai, là nguyên nhân của phần lớn mô hình phải làm lại.
- Chọn quy trình nghiệp vụ. Không phải "phòng kinh doanh" mà là một quy trình sinh ra sự kiện đo được: bán hàng tại quầy, nhận đơn trực tuyến, nhập kho, xuất hoá đơn, thu tiền. Mỗi quy trình thường thành một bảng fact.
- Khai báo độ hạt (grain). Một dòng trong bảng fact đại diện cho cái gì, nói bằng một câu chính xác: "một dòng sản phẩm trên một hoá đơn bán lẻ". Mọi cột về sau phải nhất quán với câu này.
- Xác định các dimension. Với độ hạt đã chốt, những ngữ cảnh nào luôn có giá trị duy nhất cho mỗi dòng: ngày, giờ, cửa hàng, sản phẩm, nhân viên thu ngân, chương trình khuyến mãi, khách hàng thành viên nếu có.
- Xác định các fact. Những con số đo được ở đúng độ hạt đó: số lượng, đơn giá thực, tiền chiết khấu, doanh thu thuần, giá vốn. Con số ở độ hạt khác, như phí giao hàng tính trên cả đơn, cần phân bổ xuống hoặc để ở bảng fact khác.
Nguyên tắc vàng là chọn độ hạt nhỏ nhất có thể. Dữ liệu chi tiết luôn cộng lên được thành tổng, nhưng tổng không bao giờ tách ngược về chi tiết. Nếu chỉ lưu doanh thu theo ngày theo cửa hàng, bạn sẽ không bao giờ trả lời được câu hỏi về giỏ hàng hay khung giờ.
Ba loại bảng fact và khi nào dùng
Không phải mọi sự kiện đều ghi giống nhau. Ba loại dưới đây bao phủ hầu hết tình huống trong doanh nghiệp:
| Loại | Một dòng là | Ví dụ | Lưu ý |
|---|---|---|---|
| Fact giao dịch | Một sự kiện tại một thời điểm | Dòng hoá đơn, lượt thanh toán | Phổ biến nhất, cộng theo mọi chiều |
| Fact ảnh chụp định kỳ | Trạng thái tại cuối mỗi kỳ | Tồn kho cuối ngày theo kho, số dư công nợ cuối tháng | Số dư không cộng theo thời gian; tồn kho 30 ngày cộng lại là vô nghĩa |
| Fact ảnh chụp tích luỹ | Một quy trình có nhiều mốc | Đơn hàng từ đặt, duyệt, xuất kho, giao, thu tiền | Dòng được cập nhật khi qua mỗi mốc; đo được thời gian giữa các bước |
Loại thứ hai sinh ra khái niệm fact bán cộng (semi-additive): cộng được theo kho, theo sản phẩm, nhưng theo thời gian thì phải lấy giá trị cuối kỳ hoặc trung bình. Nhiều dashboard tồn kho sai chính vì công cụ BI mặc định cộng mọi cột số.
Dimension thay đổi chậm: giữ lịch sử thế nào
Vấn đề. Cửa hàng A thuộc vùng Bắc Trung Bộ năm ngoái, năm nay được tái cơ cấu sang vùng khác; một tỉnh sáp nhập vào tỉnh khác; nhân viên chuyển chi nhánh. Báo cáo doanh thu vùng năm ngoái nên tính cửa hàng A vào vùng cũ hay vùng mới? Câu trả lời là quyết định nghiệp vụ, và mô hình phải hỗ trợ được nó.
Kiểu 1: ghi đè. Cập nhật thuộc tính, không giữ lịch sử. Hợp với sửa lỗi chính tả hoặc thuộc tính mà quá khứ không quan trọng. Hệ quả: mọi báo cáo lịch sử sẽ hiển thị theo giá trị mới.
Kiểu 2: thêm dòng mới. Tạo một dòng mới cho cửa hàng A với khoá thay thế mới, cột hiệu lực từ ngày, đến ngày và cờ đang hiệu lực. Giao dịch cũ trỏ vào dòng cũ, giao dịch mới trỏ vào dòng mới. Đây là kiểu phổ biến nhất khi cần báo cáo đúng theo cơ cấu tại thời điểm phát sinh.
Kiểu 3: thêm cột. Giữ "vùng hiện tại" và "vùng trước đó" trên cùng một dòng. Chỉ lưu được một bước thay đổi, hợp với tái cơ cấu một lần cần so sánh hai cách chia.
Khoá thay thế. Kiểu 2 chỉ khả thi khi dimension dùng khoá thay thế (một số nguyên do kho sinh ra) thay vì mã gốc của hệ thống nguồn. Đây là lý do Kimball khuyên luôn dùng khoá thay thế, kể cả khi lúc đầu chưa thấy cần.
Star schema, snowflake hay bảng phẳng
Ngoài star schema còn hai lựa chọn hay được bàn. Không có đáp án tuyệt đối; bảng dưới giúp bạn hiểu đánh đổi.
| Cách tổ chức | Mô tả | Ưu điểm | Nhược điểm |
|---|---|---|---|
| Star schema | Dimension phi chuẩn hoá, mỗi dimension một bảng | Dễ hiểu, ít phép nối, công cụ BI hỗ trợ tốt | Lặp dữ liệu mô tả, dimension rộng |
| Snowflake schema | Dimension tách nhiều tầng: sản phẩm, nhóm hàng, ngành hàng | Ít lặp, sửa một chỗ | Nhiều phép nối, người dùng khó đọc, truy vấn chậm hơn |
| Bảng phẳng rộng | Gộp fact và mọi thuộc tính vào một bảng | Đơn giản cho một báo cáo, nhanh trên kho lưu theo cột | Khó giữ nhất quán giữa các bảng, phình nhanh, khó quản lý lịch sử |
Thực hành phổ biến hiện nay: xây star schema làm lớp lõi để giữ nhất quán, rồi sinh bảng phẳng từ đó cho những báo cáo cần tốc độ. Snowflake chỉ nên dùng có chủ đích, ví dụ khi một dimension con được nhiều dimension khác dùng chung.
Conformed dimension và ma trận bus: chìa khoá để các mảng ghép được
Khi doanh nghiệp có nhiều bảng fact (bán hàng, nhập kho, công nợ), giá trị lớn nhất đến từ việc so sánh chéo: tồn kho bao nhiêu ngày bán, công nợ quá hạn của nhóm khách đang mua nhiều nhất. Điều đó chỉ làm được nếu các fact dùng chung một dimension sản phẩm, một dimension khách hàng, một dimension thời gian, gọi là conformed dimension. Nếu mart bán hàng định nghĩa "nhóm hàng" một kiểu và mart kho định nghĩa kiểu khác, mọi phép so sánh chéo đều sai lặng lẽ.
Công cụ lập kế hoạch Kimball đề xuất là ma trận bus: hàng là các quy trình nghiệp vụ, cột là các dimension, ô được đánh dấu khi quy trình dùng dimension đó. Một trang giấy như vậy đủ để ban điều hành thấy lộ trình xây kho, và để đội dữ liệu thấy dimension nào phải làm cẩn thận nhất vì được dùng nhiều nhất. Với doanh nghiệp bán lẻ hay phân phối Việt Nam, hai dimension đáng đầu tư sớm nhất thường là sản phẩm (vì mã hàng lộn xộn giữa kho, sàn và kế toán) và khách hàng (vì cùng một người có nhiều số điện thoại, nhiều tài khoản).
Sáu lỗi thiết kế làm mô hình chiều ra số sai
Các lỗi dưới đây hiếm khi gây báo lỗi; chúng sinh ra con số trông hợp lý nhưng sai, và thường chỉ bị phát hiện khi ai đó đối chiếu với sổ kế toán:
- Trộn độ hạt trong một bảng fact: vừa có dòng chi tiết sản phẩm vừa có dòng tổng đơn, khiến phép cộng tính hai lần.
- Đặt phí cấp đơn vào dòng sản phẩm mà không phân bổ: phí giao hàng của cả đơn lặp lại trên mỗi dòng, cộng lên thành gấp nhiều lần thực tế.
- Cộng fact bán cộng theo thời gian: tồn kho, số dư công nợ, số nhân viên đang làm việc được cộng qua các ngày.
- Dùng mã gốc của nguồn làm khoá dimension: khi hệ thống nguồn tái sử dụng mã cũ cho sản phẩm mới, lịch sử bị trộn lẫn.
- Để khoá dimension rỗng trong fact: giao dịch không có khách thành viên bị loại khỏi báo cáo khi nối bảng. Cách đúng là tạo dòng "không xác định" trong dimension và trỏ tới nó.
- Đếm khách qua bảng cầu nối mà không khử trùng: một khách thuộc hai phân khúc bị đếm hai lần trong tổng số khách.
Một bộ kiểm thử tối thiểu cho mô hình chiều gồm: tổng doanh thu trong fact khớp sổ sách theo tháng, mỗi khoá trong fact đều tìm được dòng trong dimension, và mỗi dimension có đúng một dòng đang hiệu lực cho mỗi mã gốc. Ba kiểm tra này bắt được phần lớn sáu lỗi trên.
Mô hình chiều và công cụ BI: ai nên giữ logic
Phần lớn công cụ BI hiện nay có mô hình dữ liệu riêng bên trong: bạn nạp bảng, khai báo quan hệ, viết công thức đo lường. Điều này tạo cám dỗ dựng mô hình chiều ngay trong công cụ BI, bỏ qua kho. Với một phòng ban, một bộ báo cáo, cách này nhanh và chấp nhận được. Vấn đề xuất hiện khi có ba, bốn bộ báo cáo, mỗi bộ tự định nghĩa dimension khách hàng và công thức doanh thu thuần: bạn quay lại đúng tình trạng nhiều nguồn sự thật mà kho sinh ra để chấm dứt.
Nguyên tắc phân vai thực dụng: những gì dùng chung nhiều nơi (dimension chung, bảng fact ở độ hạt chi tiết, quy tắc nghiệp vụ như phân bổ chiết khấu) nằm trong kho, viết bằng mã có quản lý phiên bản; những gì phục vụ trình bày (định dạng, phân cấp khoan sâu, phép so sánh cùng kỳ) nằm trong công cụ BI hoặc lớp ngữ nghĩa. Cách chia này cũng giúp đổi công cụ BI về sau mà không mất logic nghiệp vụ.
Câu hỏi thường gặp
Mô hình dữ liệu chiều có còn cần khi kho đám mây đã đủ nhanh?
Tốc độ chỉ là một lý do. Lý do lớn hơn là tính dễ hiểu và nhất quán: người dùng nghiệp vụ tìm được dữ liệu, các báo cáo dùng chung định nghĩa. Kho nhanh giúp bạn bớt lo tối ưu, nhưng không thay được việc chốt độ hạt và dimension chung.
Bảng dimension thời gian có thật sự cần không?
Rất nên có. Nó chứa sẵn các thuộc tính như thứ trong tuần, tuần, quý, năm tài chính, ngày lễ, tháng âm lịch nếu kinh doanh theo mùa Tết. Tính các thuộc tính này một lần trong bảng thời gian tránh việc mỗi báo cáo tự viết công thức khác nhau.
Quan hệ nhiều nhiều trong mô hình chiều xử lý thế nào?
Ví dụ một đơn hàng áp nhiều khuyến mãi, một bệnh nhân có nhiều chẩn đoán. Cách thường dùng là bảng cầu nối (bridge table) giữa fact và dimension, kèm trọng số phân bổ nếu cần cộng. Cần cẩn trọng vì đếm sai rất dễ xảy ra khi nối qua bảng cầu.
Dimension rác (junk dimension) là gì?
Là một dimension gom nhiều cờ và mã trạng thái nhỏ lẻ như phương thức thanh toán, có xuất hoá đơn hay không, kênh đặt hàng, thay vì để mỗi cờ thành một cột trong bảng fact hay một dimension riêng. Cách này giữ bảng fact gọn và vẫn lọc được theo các cờ đó.
Data vault có thay thế mô hình chiều không?
Data vault là phương pháp mô hình hoá tầng tích hợp, mạnh về lưu vết và mở rộng khi nguồn thay đổi nhiều. Nó thường nằm ở tầng giữa, còn tầng phục vụ người dùng vẫn được xuất ra dạng mô hình chiều. Hai cách bổ sung cho nhau hơn là thay thế.