Kho Dữ Liệu BI: 4 Bước Thiết Kế Và 4 Yếu Tố Schema

Chào bạn, lại là Trí đây! Phần lớn kho dữ liệu hỏng không phải vì chọn sai công cụ. Chúng hỏng vì người làm bắt đầu từ công cụ thay vì bắt đầu từ câu hỏi kinh doanh.

Trả lời nhanh: Kho dữ liệu là cơ sở dữ liệu gom dữ liệu từ nhiều hệ thống nguồn về một chỗ để phục vụ phân tích. Thiết kế nó đi theo bốn bước của Kimball: chọn quy trình kinh doanh, khai báo mức chi tiết, xác định dimension, xác định fact. Đúng thứ tự đó, không đảo.

• Bước một quyết định ba bước còn lại, nên đừng vội mở công cụ
• Một schema dùng được cần bốn yếu tố, thiếu cái nào cũng sinh lỗi về sau
• Đặt tên theo một quy ước duy nhất ngay từ đầu
• Tiền phải lưu bằng kiểu số thập phân cố định, không dùng số thực dấu phẩy động
• Schema là thứ sống, sửa tiếp khi nhu cầu kinh doanh đổi

Cập nhật tháng 9/2026

1. Kho Dữ Liệu Là Gì Và Khác Cơ Sở Dữ Liệu Thường Ở Đâu?

Kho dữ liệu là một loại cơ sở dữ liệu gom dữ liệu từ nhiều hệ thống nguồn về một chỗ, làm cho chúng nhất quán và truy cập nhanh để phục vụ việc ra quyết định. Điểm khác so với cơ sở dữ liệu thường nằm ở mục đích, chứ không nằm ở công nghệ.

Cơ sở dữ liệu của phần mềm bán hàng phục vụ việc ghi giao dịch. Nó chỉ biết chuyện bán hàng, và nó tối ưu để ghi cho nhanh. Kho dữ liệu thì gom dữ liệu bán hàng, dữ liệu marketing, dữ liệu kho và dữ liệu chăm sóc khách hàng lại, rồi tối ưu để đọc và tổng hợp.

Việc dựng kho dữ liệu thường do chuyên gia kho dữ liệu đảm nhiệm, nhưng người làm BI tham gia vào phần thiết kế. Lý do đơn giản: người làm BI là người biết các câu hỏi kinh doanh cần trả lời, mà câu hỏi kinh doanh chính là thứ quyết định kho dữ liệu trông ra sao.

Nếu bạn chưa rõ nghề này làm gì trong doanh nghiệp, bài giới thiệu về business intelligence là chỗ nên đọc trước khi vào phần kỹ thuật bên dưới.

2. Ba Thứ Phải Chốt Trước Khi Bắt Tay Thiết Kế

Trước khi vẽ bảng đầu tiên, người thiết kế cần trả lời được ba câu. Bỏ qua bước này là nguyên nhân phổ biến nhất khiến kho dữ liệu dựng xong rồi không trả lời được câu hỏi người ta thật sự cần.

Thứ nhất là nhu cầu kinh doanh. Doanh nghiệp muốn trả lời câu hỏi gì, giải quyết vấn đề gì. Các biểu mẫu chiến lược BI giúp bạn lấy được câu trả lời này từ các bên liên quan thay vì tự đoán. Một bệnh viện lưu hồ sơ bệnh nhân để theo dõi diễn biến sức khỏe có yêu cầu dữ liệu khác hẳn một công ty tài chính phân tích xu hướng thị trường để quyết định đầu tư.

Thứ hai là hình dạng và khối lượng dữ liệu. Hình dạng nói về các bảng, dòng và cột sẽ bày ra sao. Khối lượng thì phải tính cả hiện tại lẫn vài năm tới, vì một thiết kế chạy tốt với một triệu dòng có thể sập ở mức một trăm triệu dòng.

Thứ ba là mô hình hệ thống sẽ theo, gồm cả cơ sở dữ liệu lẫn các công cụ phân tích sẽ cắm vào. Ràng buộc của công cụ ảnh hưởng tới thiết kế, nên biết trước vẫn hơn phát hiện muộn.

3. Bốn Bước Thiết Kế Kho Dữ Liệu Theo Kimball

Quy trình bốn bước này do Kimball Group công bố và đã thành chuẩn chung của ngành. Thứ tự các bước là bắt buộc, vì mỗi bước tạo ra căn cứ cho bước sau.

1. Chọn quy trình kinh doanh cần đo. Một cửa hàng bán lẻ thì quy trình chính là bán hàng. Một phòng khám thì có thể là lượt khám. Chọn một quy trình, không chọn cả công ty.
2. Khai báo mức chi tiết. Một dòng trong bảng đại diện cho cái gì: một sản phẩm trong một đơn, một đơn hàng, hay tổng một ngày. Đây là quyết định khó nhất và cũng là quyết định tốn kém nhất nếu sửa sau.
3. Xác định các dimension. Khi đã biết một dòng là gì, bạn hỏi tiếp: ai, cái gì, ở đâu, khi nào. Với bán lẻ, câu trả lời thường là khách hàng, sản phẩm, chi nhánh, thời gian, chương trình khuyến mãi.
4. Xác định các fact. Cuối cùng mới tới các con số đo được: số lượng đặt, tổng tiền hàng, tổng thuế, tổng chiết khấu, tổng tiền thực thu.

Kimball Group nói rõ rằng đáp án cho bốn câu hỏi này đến từ hai phía: nhu cầu của doanh nghiệp và thực tế của dữ liệu nguồn. Thiếu một trong hai phía thì bản thiết kế hoặc là đẹp mà không dựng được, hoặc là dựng được mà không ai cần.

Làm xong bốn bước, bạn sẽ thấy một bảng fact ở giữa với các bảng dimension vây quanh. Đó chính là star schema, và tôi đã viết riêng về star schema khác snowflake thế nào nếu bạn cần phần so sánh.

4. Một Schema Dùng Được Cần Bốn Yếu Tố Nào?

Schema là bản mô tả cách dữ liệu được tổ chức. Nó không chứa dữ liệu, nó mô tả hình dạng của dữ liệu và các quan hệ bên trong. Về sau bạn sẽ dùng chính nó để kiểm tra dữ liệu mới đổ vào, nên thiếu sót ở đây sẽ thành lỗi ở khắp nơi.

Yếu tố thứ hai có một hệ quả mà hướng dẫn của Microsoft cho Power BI nhấn mạnh: bảng dimension và bảng fact phải tách bạch, đừng trộn hai vai trò vào một bảng. Trộn rồi thì công cụ báo cáo không biết nên lọc theo cột nào và tổng hợp theo cột nào.

Yếu tố thứ ba là chỗ đau nhất khi doanh nghiệp gộp hệ thống. Hệ thống marketing gọi cột đó là mã người dùng, hệ thống bán hàng gọi là mã khách hàng. Trong kho dữ liệu bạn phải chọn đúng một tên và giữ nguyên, nếu không mọi phép nối sau này đều phải viết thêm một lớp dịch.

5. Đặt Tên Bảng Và Cột Thế Nào Cho Đỡ Khổ Về Sau?

Chọn một quy ước rồi dùng nó cho toàn bộ hệ thống. Quy ước phổ biến nhất trong ngành dữ liệu là snake case: viết thường hết, các từ nối nhau bằng dấu gạch dưới, ví dụ ngay_tao_don hoặc tong_tien_hang.

Lý do chọn snake case không nằm ở thẩm mỹ. Nhiều hệ quản trị cơ sở dữ liệu phân biệt chữ hoa chữ thường theo cách khác nhau, còn dấu cách thì buộc bạn phải bọc tên trong ngoặc kép mỗi lần gọi. Viết thường và gạch dưới tránh được cả hai chuyện đó.

Vài quy tắc nhỏ giúp đỡ mệt về sau. Đặt tên bảng theo cái nó chứa chứ không theo hệ thống nguồn, vì hệ thống nguồn sẽ đổi. Giữ tên cột khóa giống nhau qua các bảng để người đọc đoán được quan hệ. Tránh viết tắt mà chỉ đội bạn hiểu, vì ba năm nữa người khác sẽ ngồi vào chỗ bạn.

Bạn đã bao giờ mở lại một bảng mình tự làm sáu tháng trước và không nhớ cột đó nghĩa là gì chưa? Nếu rồi, bạn biết vì sao quy ước đặt tên quan trọng hơn vẻ ngoài của nó.

6. Chọn Sai Kiểu Dữ Liệu Thì Hỏng Ở Đâu?

Chỗ hỏng nặng nhất là tiền. Giá tiền lưu bằng kiểu số thực dấu phẩy động sẽ sinh sai số làm tròn, và sai số đó tích lại qua hàng triệu phép tính.

Không nên dùng số thực dấu phẩy động để xử lý tiền, vì khả năng phát sinh lỗi làm tròn.

Tài liệu chính thức của PostgreSQL, mục về kiểu dữ liệu tiền tệ

Cách xử lý là dùng kiểu số thập phân cố định, thường viết là decimal(10,2), nghĩa là giữ tối đa 10 chữ số và đúng 2 chữ số sau dấu thập phân. Với đô la Mỹ, đơn vị nhỏ nhất là 0,01 USD, nên một giá trị kiểu 0,001 USD là thứ không tồn tại và không nên để hệ thống tạo ra được.

Với tiền Việt, bạn cân nhắc lại số chữ số thập phân vì đồng không có đơn vị nhỏ hơn 1 đồng trong giao dịch thông thường. Cái bẫy nằm ở chỗ khác: khi tính chiết khấu hay chia đều, phần lẻ sinh ra phải có quy tắc làm tròn rõ ràng. Lệch 1 đồng mỗi giao dịch, nhân với 10 triệu giao dịch, là 10 triệu đồng chênh lệch giữa báo cáo và sổ sách.

PostgreSQL còn có kiểu tiền riêng chiếm 8 byte, phạm vi chạy tới hơn 92 triệu tỷ đơn vị tiền tệ. Nó tiện nhưng phụ thuộc vào thiết lập vùng của máy chủ, nên nhiều đội vẫn chọn kiểu số thập phân cho chắc.

Các cột khác cũng có lựa chọn riêng. Thời điểm tạo đơn nên dùng kiểu dấu thời gian thay vì ngày, vì bạn sẽ cần biết giờ. Các cột chữ độ dài thay đổi thì dùng kiểu chuỗi có giới hạn thay vì cố định, để đỡ tốn chỗ.

7. Câu Hỏi Thường Gặp

Doanh nghiệp nhỏ có cần kho dữ liệu riêng không?

Chưa chắc cần ngay. Khi dữ liệu còn nằm gọn trong một phần mềm và báo cáo vẫn chạy nhanh, một bản sao chạy ban đêm là đủ. Kho dữ liệu đáng dựng khi bạn phải nối dữ liệu từ ba hệ thống trở lên và làm thủ công mỗi tháng.

Bước nào trong bốn bước hay bị làm sai nhất?

Bước khai báo mức chi tiết. Nhiều đội bỏ qua nó và để mỗi bảng một mức khác nhau, kết quả là các phép cộng ra số sai mà không ai phát hiện trong nhiều tháng. Chốt mức chi tiết trước khi thêm bất kỳ cột nào.

Schema thiết kế xong rồi có sửa được không?

Sửa được và chắc chắn sẽ phải sửa. Khi doanh nghiệp có câu hỏi mới mà hệ thống chưa trả lời được, bạn thêm bảng hoặc thêm cột rồi cập nhật schema. Tối ưu cơ sở dữ liệu là việc lặp đi lặp lại suốt vòng đời hệ thống.

Có nên đặt tên bảng và cột bằng tiếng Việt không dấu không?

Được, miễn là nhất quán và đội bạn đọc hiểu. Nhiều công ty Việt Nam dùng tiếng Anh cho tên kỹ thuật để dễ tra tài liệu và dễ bàn giao khi có người nước ngoài tham gia. Quan trọng là chọn một hướng rồi giữ, đừng trộn hai thứ trong cùng một hệ thống.

Nếu hệ thống nguồn có tên cột khác nhau thì xử lý ở đâu?

Ở khâu đưa dữ liệu vào kho, không phải ở khâu báo cáo. Bạn quy về một tên chuẩn trong kho dữ liệu, rồi ghi lại bản đối chiếu giữa tên gốc và tên chuẩn. Để việc này tới lúc làm báo cáo thì mỗi người sẽ tự dịch một kiểu.

Kho dữ liệu khác data mart thế nào?

Kho dữ liệu là nơi gom toàn bộ, data mart là một phần nhỏ cắt ra phục vụ một phòng ban hoặc một chủ đề. Dữ liệu đổ vào kho mà chưa sạch thì cả hai đều vô dụng, và đó là nguyên nhân khiến nhiều dự án BI thất bại. Đội tài chính có data mart riêng, đội marketing có data mart riêng, cả hai cùng lấy nguồn từ kho chung.

8. Lời Kết Từ Tác Giả

Bốn bước của Kimball nhìn thì đơn giản, nhưng cái khó nằm ở chỗ chúng bắt bạn nói chuyện với người kinh doanh trước khi động vào công cụ. Đó là phần nhiều người làm kỹ thuật ngại nhất và cũng là phần quyết định dự án sống hay chết.

Việc nên làm nếu bạn đang có sẵn một hệ thống báo cáo: mở một bảng bất kỳ ra và hỏi một dòng trong đây đại diện cho cái gì. Trả lời không dứt khoát được là dấu hiệu mức chi tiết chưa từng được chốt, và đó là chỗ nên sửa trước.

Có một chuyện tôi vẫn thấy tranh cãi chưa ngã ngũ. Với các nền tảng phân tích hiện đại lưu theo cột và nén rất mạnh, nhiều người cho rằng không cần mô hình hóa kỹ như thời Kimball nữa, cứ đổ dữ liệu thô vào rồi xử lý sau. Tôi chưa thấy bên nào đưa ra bằng chứng đủ thuyết phục cho cả hai phía. Nếu bạn đã thử cả hai cách trên dự án thật, kể tôi nghe kết quả.

Bài này có ích thì chia sẻ cho người đang xây hệ thống dữ liệu, và theo dõi blog để nhận bài mới.

9. Nguồn Tham Khảo

• Kimball Group, "Four-Step Dimensional Design Process", kimballgroup.com. Tổ chức do Ralph Kimball sáng lập, nơi phát triển bộ kỹ thuật mô hình chiều
• PostgreSQL, tài liệu chính thức mục 8.2 về kiểu dữ liệu tiền tệ, postgresql.org
• Microsoft Learn, "Understand star schema and the importance for Power BI", hướng dẫn chính thức về mô hình dữ liệu