LƯỢC ĐỒ HÌNH SAO TRONG KHO DỮ LIỆU

Bảng sự kiện, bảng chiều, độ mịn, ba loại độ đo và chiều thay đổi chậm qua kho của một chuỗi siêu thị

---

Giám đốc của chuỗi siêu thị mini giả định Sen Vàng Mart muốn biết khách hạng Vàng đóng góp bao nhiêu trong mùa Tết, so với năm trước. Trên cơ sở dữ liệu bán hàng, câu hỏi này cần một câu SQL nối năm bảng, có các mốc ngày Tết gõ tay và cho ra một kết quả sai: bảng khách hàng chỉ nhớ hạng hôm nay, nên khách vừa lên hạng tháng trước bị tính là khách Vàng cả trong Tết năm ngoái.

Trên kho dữ liệu được thiết kế lại, cùng câu hỏi chỉ cần ba bảng: một bảng ghi các lần bán, một bảng ngày đã biết mùa Tết, một bảng khách hàng nhớ mỗi khách mang hạng nào trong khoảng thời gian nào. Kết quả đúng là: Tết Giáp Thìn 2024 có 438 khách đang mang hạng Vàng mua hàng, đóng góp 68.498.600 đồng; Tết Ất Tỵ 2025 chỉ còn 348 khách với 54.202.300 đồng, trong khi doanh thu mùa Tết toàn chuỗi tăng 2,9%. Đó là một phát hiện đáng để phòng chăm sóc khách hàng điều tra và nó không thể có được trên cơ sở dữ liệu tác nghiệp.

Khoảng cách giữa hai lời giải là nội dung của mô hình hóa chiều (dimensional modeling), cách thiết kế kho dữ liệu mà bài Kho dữ liệu là gì và khi nào doanh nghiệp cần nó gọi là trường phái Kimball. Bài viết gồm sáu mục. Mục 1 giới thiệu bảng sự kiện, bảng chiều và lược đồ hình sao. Mục 2 trình bày độ mịn và quy trình thiết kế bốn bước. Mục 3 phân loại độ đo theo cách được phép gộp. Mục 4 giải thích khóa thay thế và chiều thời gian. Mục 5 bàn chiều thay đổi chậm, lời giải cho bài toán hạng thành viên. Mục 6 bàn lược đồ bông tuyết và vì sao thường không nên dùng.

1. Bảng sự kiện, bảng chiều và lược đồ hình sao

Mô hình hóa chiều dùng đúng các khái niệm quan hệ quen thuộc như bảng, khóa chính, khóa ngoại, nhưng phân biệt hai loại bảng (Jukić, 2025; Kimball & Ross, 2013). Bảng chiều (dimension table) chứa các mô tả về doanh nghiệp: sản phẩm tên gì, thuộc nhóm nào; cửa hàng ở vùng nào; ngày nào là cuối tuần. Cột của bảng chiều là căn cứ để phân tích, như doanh thu theo nhóm hàng hay theo vùng. Bảng sự kiện (fact table) chứa các độ đo (measures) của chủ đề phân tích như doanh thu, số lượng, cùng các khóa ngoại trỏ tới bảng chiều.

Một mẹo nhận diện là viết câu hỏi phân tích thành câu tiếng Việt: danh từ đo được là độ đo, những gì đứng sau từ "theo" là thuộc tính chiều. "Doanh thu theo vùng và nhóm hàng trong mùa Tết" cho một độ đo (doanh thu) và ba thuộc tính chiều (vùng, nhóm hàng, mùa Tết). Kết quả của mô hình hóa chiều là một lược đồ hình sao (star schema): bảng sự kiện ở giữa, các bảng chiều tỏa ra xung quanh, như Hình 1.

Hình 1. Lược đồ hình sao doanh số của Sen Vàng Mart (tình huống giả định). Nguồn: dựa trên Jukić (2025).

Lược đồ trong Hình 1 không được vẽ từ con số không mà được suy ra từ lược đồ quan hệ của hệ bán hàng cộng với các nguồn bổ sung. Hai bảng hóa đơn và chi tiết hóa đơn gộp thành bảng sự kiện; sản phẩm và nhóm hàng gộp thành chiều sản phẩm; cửa hàng được thêm cột vùng; khách hàng ghép với nhật ký xét hạng; chiều ngày được dựng từ lịch, kể cả lịch âm.

Chiều sản phẩm vì thế lặp lại tên nhóm hàng cho mọi sản phẩm của nhóm, đúng phụ thuộc bắc cầu mà bài Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF đã tách ra để loại bỏ. Ở đây sự lặp lại được giữ lại có chủ đích. Chuẩn hóa loại dư thừa vì dư thừa sinh ra dị thường cập nhật; người dùng kho không cập nhật, còn quy trình nạp kiểm soát mọi thay đổi, nên dị thường không có chỗ xảy ra (Jukić, 2025). Đổi lại, người phân tích bớt được một phép kết nối cho mỗi câu hỏi theo nhóm hàng.

2. Độ mịn và quy trình bốn bước

Độ mịn (grain) của một bảng sự kiện là câu trả lời cho câu hỏi "một dòng của bảng này là gì?" (Jukić, 2025). Đây là khái niệm trụ cột của mô hình hóa chiều, vì mọi quyết định khác đều phụ thuộc vào nó: có những chiều nào, có những độ đo nào, bảng lớn bao nhiêu, trả lời được câu hỏi nào. Kimball và Ross (2013) đề xuất thiết kế mỗi bảng sự kiện theo bốn bước, đúng thứ tự, như Bảng 1.

Bảng 1. Quy trình bốn bước thiết kế bảng sự kiện áp vào Sen Vàng Mart

Nguồn: dựa trên Kimball & Ross (2013).

Độ mịn phải đi trước vì chiều và độ đo được định nghĩa theo độ mịn. Nếu một dòng là một hóa đơn, "sản phẩm" không còn là một chiều vì một hóa đơn có nhiều sản phẩm và doanh thu theo nhóm hàng không trả lời được. Nếu một dòng là một dòng hàng, sản phẩm là chiều, nhưng tổng tiền hóa đơn không còn là độ đo của dòng đó. Sen Vàng Mart chọn độ mịn chi tiết nhất mà nguồn có, 939.668 dòng cho hai năm, vì các câu hỏi gộp lên được từ dữ liệu chi tiết nhưng không bao giờ tách xuống được từ dữ liệu đã gộp.

Hai cột trong Hình 1 cần giải thích thêm. SoHD được giữ lại để đếm số hóa đơn và tính giá trị giỏ hàng, nhưng không có bảng chiều nào đi kèm vì mọi thông tin của hóa đơn đã nằm ở các chiều khác; một khóa như vậy gọi là chiều suy biến (degenerate dimension). GioTrongNgay giữ giờ của lần bán thẳng trong bảng sự kiện thay vì tạo một chiều riêng.

Cạm bẫy kinh điển ở bước này là trộn độ mịn. Một yêu cầu nghe rất hợp lý: "thêm cột tổng tiền hóa đơn vào bảng sự kiện để khỏi phải tính". Nhưng cột đó thuộc độ mịn hóa đơn, trong khi bảng ở độ mịn dòng hàng, nên một hóa đơn ba dòng có tổng tiền lặp lại ba lần. Cộng cột mới cho 177.688.046.900 đồng, gấp 3,22 lần doanh thu thật là 55.227.007.500 đồng. Lỗi này nguy hiểm vì nó nằm sẵn trong thiết kế, nên mọi người dùng, mọi báo cáo đều mắc phải mà không ai viết sai câu SQL nào.

3. Ba loại độ đo

Không phải độ đo nào cũng cộng được theo mọi chiều. Kimball và Ross (2013) chia độ đo thành ba loại theo phép gộp hợp lệ. Ghi rõ loại của từng độ đo là một phần của thiết kế, vì nếu không, công cụ BI sẽ mặc định cộng mọi thứ. Bảng 2 tóm tắt ba loại.

Bảng 2. Ba loại độ đo và cách gộp đúng (tình huống giả định)

Nguồn: dựa trên Kimball & Ross (2013).

Độ đo bán cộng được thường xuất hiện trong bảng ảnh chụp định kỳ, nơi mỗi dòng ghi trạng thái ở cuối một kỳ. Số khách hạng Vàng cuối mỗi quý cộng được qua các cửa hàng nhưng không cộng được qua thời gian: cộng tám quý cho 9.118, một con số vô nghĩa vì cùng một khách bị đếm lại ở mỗi quý họ còn hạng Vàng. Câu trả lời đúng là giá trị cuối kỳ, 1.206 khách, hoặc trung bình các quý, khoảng 1.140, tùy câu hỏi.

Độ đo không cộng được là cạm bẫy khó thấy hơn. Doanh thu mùa Tết năm 2025 so với 2024 tăng 3,5% ở miền Bắc, 4,9% ở miền Trung và 1,6% ở miền Nam. Cộng ba tỉ lệ được 10,0%, lấy trung bình được 3,3%, trong khi tăng trưởng thật của cả chuỗi là 2,9%. Trung bình sai vì miền Trung, vùng tăng nhanh nhất, chỉ chiếm khoảng một phần năm doanh thu nhưng được tính ngang với hai vùng lớn. Cách tránh đơn giản: bảng sự kiện chỉ lưu các thành phần cộng được như doanh thu từng năm, còn tỉ lệ được tính sau khi gộp. Đây cũng là cơ chế của nghịch lý mà bài Nghịch lý Simpson trong phân tích dữ liệu phân tích.

4. Khóa thay thế và chiều thời gian

Mỗi bảng chiều trong Hình 1 có một khóa chính mới như SanPhamKey, KhachHangKey, bên cạnh mã cũ từ hệ tác nghiệp. Khóa thay thế (surrogate key) là một số nguyên không mang nghĩa, thường đánh tăng dần, chỉ có một việc là làm khóa chính trong kho (Jukić, 2025). Mã tác nghiệp như MaSP vẫn được giữ làm cột thường, gọi là khóa tự nhiên. Có ba lý do không dùng thẳng mã tác nghiệp làm khóa.

Lý do thứ nhất là lịch sử: chiều thay đổi chậm ở Mục 5 cần nhiều dòng cho cùng một khách, mỗi dòng một giai đoạn mang một hạng, nên MaKH không còn duy nhất. Lý do thứ hai là tích hợp: khi nạp thêm tệp Excel cũ, hai nguồn có thể dùng hai mã cho cùng một sản phẩm, hoặc một mã cho hai sản phẩm khác nhau; khóa do kho cấp không phụ thuộc nguồn nào. Lý do thứ ba là dòng đặc biệt: khoảng 65% hóa đơn không có khách thành viên. Nếu để khóa ngoại trống, mọi phép kết nối thường sẽ đánh rơi các dòng đó, nên kho dành sẵn dòng có khóa 0 mang nghĩa "Vãng lai" trong chiều khách hàng và "Không khuyến mãi" trong chiều khuyến mãi.

Hầu như mọi kho dữ liệu đều có một chiều thời gian, thường là chiều được dùng nhiều nhất. DIM_NGAY có một dòng cho mỗi ngày, 731 dòng cho 2024 và 2025, kèm mọi thuộc tính mà người phân tích muốn cắt theo. Nhiều thuộc tính như thứ trong tuần hay quý tính được bằng hàm ngày giờ, nhưng mùa Tết thì không, vì Tết theo âm lịch và phải gõ tay mốc từng năm. Với cột MuaTet trong chiều ngày, câu hỏi Tết không còn mốc ngày gõ tay nào; năm sau chỉ cần thêm Tết Bính Ngọ 2026 vào DIM_NGAY, câu SQL không phải sửa một từ. Khóa của DIM_NGAY là ngoại lệ có chủ đích: NgayKey có dạng YYYYMMDD như 20250115, vì ngày không bao giờ đổi thuộc tính nên khóa có nghĩa không gây hại.

5. Chiều thay đổi chậm

Thuộc tính của bảng chiều thay đổi, nhưng thưa: một khách đổi hạng vài năm một lần, một sản phẩm đổi giá mỗi năm một lần. Bảng chiều có thuộc tính như vậy gọi là chiều thay đổi chậm (slowly changing dimension, SCD). Câu hỏi thiết kế là khi thuộc tính đổi, kho làm gì với giá trị cũ. Ba cách phổ biến nhất được gọi là loại 1, 2 và 3 (Jukić, 2025; Kimball & Ross, 2013), như Bảng 3.

Bảng 3. Ba cách xử lý chiều thay đổi chậm

Nguồn: dựa trên Jukić (2025) và Kimball & Ross (2013).

Loại 2 là cách dùng nhiều nhất và là lời giải cho bài toán hạng thành viên. Khi khách KH00015 lên hạng Vàng ngày 01/4/2025, dòng cũ mang hạng Bạc không bị sửa giá trị; nó chỉ được đóng lại bằng ngày hết hiệu lực 31/3/2025. Một dòng mới với khóa thay thế mới được thêm cho hạng Vàng. Mỗi dòng sự kiện, khi nạp, được gắn với phiên bản đúng vào ngày bán. Trong kho của Sen Vàng Mart, 3.019 trên 12.000 khách có nhiều hơn một phiên bản. Hình 2 cho thấy khác biệt khi tính doanh thu năm 2024 theo hai cách.

Hình 2. Doanh thu năm 2024 theo hạng lúc mua và theo hạng hiện tại (tình huống giả định).

Cột màu xám trong Hình 2 là câu trả lời mà cơ sở dữ liệu tác nghiệp cho; cột màu xanh là câu trả lời đúng. Chênh lệch lớn nhất nằm ở hạng Bạc, 3,33 tỉ so với 2,92 tỉ đồng: trong doanh thu mà khách mang hạng Bạc tạo ra năm 2024, khoảng 0,91 tỉ thuộc về những khách nay đã xuống hạng Đồng và 0,23 tỉ thuộc về những khách nay đã lên Vàng. Tổng ba hạng ở hai cách tính bằng nhau: doanh thu không mất đi đâu, chỉ bị xếp nhầm chỗ.

Điều quan trọng nhất của mục này là kho dữ liệu không tự sinh ra quá khứ. Giá niêm yết cũ còn tái dựng được từ đơn giá trên hóa đơn, nhưng hạng thành viên thì không, vì hóa đơn không ghi hạng. Lời giải phải đến từ một nguồn khác, ở đây là nhật ký xét hạng mà phòng chăm sóc khách hàng ghi mỗi quý. Loại 2 chỉ giữ được lịch sử từ khi có một nguồn ghi lại lịch sử, hoặc từ ngày kho bắt đầu chụp trạng thái của nguồn mỗi lần nạp. Tổ chức nào muốn phân tích lịch sử của một thuộc tính phải bắt đầu ghi nó từ hôm nay.

Cạm bẫy đi kèm loại 2 là nối bằng khóa tự nhiên mà quên điều kiện phiên bản hiện hành. Muốn tính doanh thu năm 2024 theo hạng hiện tại, người phân tích nối dòng sự kiện tới phiên bản lúc mua, rồi từ MaKH nối tiếp tới phiên bản hiện hành. Nếu quên điều kiện "đang hiện hành", phép nối thứ hai khớp với mọi phiên bản của khách và mỗi dòng sự kiện của một khách có ba phiên bản bị nhân ba. Doanh thu năm 2024 vì thế tăng từ 27,14 lên 29,84 tỉ đồng, tức 9,9%, mà câu SQL không báo lỗi gì.

6. Lược đồ bông tuyết

Nếu chuẩn hóa các bảng chiều, chẳng hạn tách nhóm hàng khỏi chiều sản phẩm hay tách vùng khỏi chiều cửa hàng, lược đồ hình sao trở thành lược đồ bông tuyết (snowflake schema). Bông tuyết thường không được dùng trong mô hình hóa chiều (Jukić, 2025). Lợi ích duy nhất là bớt vài chục nghìn byte lặp lại trong một bảng chiều nhỏ, không đáng so với cái giá: thêm phép kết nối cho người phân tích, thêm bảng cho công cụ BI phải hiểu và quay lại đúng vấn đề mà kho dữ liệu sinh ra để giải quyết. Bông tuyết chỉ có lý khi một nhánh của chiều thật sự lớn và thay đổi độc lập, như một danh mục hàng nhiều tầng do một bộ phận khác quản lý.

Khi thêm chủ đề thứ hai như nhập hàng, kho có thêm một bảng sự kiện dùng chung các chiều ngày, sản phẩm, cửa hàng với bảng bán hàng; tập các bảng sự kiện dùng chung chiều như vậy gọi là chòm sao sự kiện (fact constellation). Đây là hình dạng thường gặp nhất của một kho Kimball trưởng thành và là nền cho các bảng điều khiển trong bài Power BI là gì? Lộ trình tự học Power BI cho người mới.

AI hữu ích khi thiết kế lược đồ hình sao ở hai việc: đề xuất bảng chiều và độ đo từ một danh sách câu hỏi phân tích và viết câu SQL trên lược đồ đã có. Nhưng AI hay mắc đúng hai cạm bẫy của bài này. Nó dễ đồng ý thêm cột tổng tiền hóa đơn vào bảng dòng hàng vì yêu cầu nghe hợp lý và khi viết câu nối với chiều loại 2, nó thường nối bằng mã khách mà quên điều kiện phiên bản. Hãy luôn yêu cầu AI phát biểu độ mịn của bảng trước khi đề xuất bất cứ cột nào.

Kết luận

Lược đồ hình sao biến câu hỏi năm bảng có kết quả sai thành câu hỏi ba bảng có kết quả đúng. Bảng sự kiện ghi các lần bán, bảng chiều mô tả bối cảnh và sự lặp lại trong bảng chiều là có chủ đích vì người dùng kho không cập nhật. Mọi quyết định thiết kế bắt đầu từ độ mịn; trộn độ mịn làm doanh thu phình lên 3,22 lần mà không câu SQL nào sai.

Hai nhóm sai sót còn lại đến từ cách gộp và cách nhớ quá khứ. Độ đo bán cộng được và không cộng được phải được ghi rõ để công cụ BI không cộng bừa. Chiều thay đổi chậm loại 2 cho biết khách mang hạng gì lúc mua và nhờ đó phát hiện số khách Vàng mua Tết giảm từ 438 xuống 348, nhưng nó chỉ giữ được lịch sử từ khi có nguồn ghi lại lịch sử. Kho dữ liệu không tự sinh ra quá khứ.

Đọc thêm

• Kho dữ liệu là gì và khi nào doanh nghiệp cần nó
• Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF
• Đo chất lượng dữ liệu theo sáu chiều
• Nghịch lý Simpson trong phân tích dữ liệu
• Power BI là gì? Lộ trình tự học Power BI cho người mới
• Phân tích cohort trong giữ chân khách hàng

Tài liệu tham khảo

Jukić, N. (2025). Database systems: Introduction to databases and data warehouses (3rd ed.). Prospect Press. https://www.prospectpressvt.com/textbooks/jukic-database-systems-introduction-to-databases-and-data-warehouses-3-0

Kimball, R., & Ross, M. (2013). The data warehouse toolkit: The definitive guide to dimensional modeling (3rd ed.). Wiley. https://www.wiley.com/en-us/The+Data+Warehouse+Toolkit:+The+Definitive+Guide+to+Dimensional+Modeling,+3rd+Edition-p-9781118530801