Kho dữ liệu là gì và khi nào doanh nghiệp cần nó

KHO DỮ LIỆU LÀ GÌ

Vì sao báo cáo chạy thẳng trên cơ sở dữ liệu bán hàng vừa chậm vừa sai và kho dữ liệu khắc phục thế nào


Đầu tháng Hai, giám đốc của chuỗi siêu thị mini giả định Sen Vàng Mart hỏi phòng phân tích: "Mùa Tết năm nay, doanh thu từng nhóm hàng ở từng vùng so với năm ngoái ra sao?" Một chuyên viên viết xong câu SQL nối năm bảng trong mười phút, chạy thẳng trên cơ sở dữ liệu bán hàng và có 75 dòng kết quả: rau củ đóng gói ở miền Trung tăng 36,8%, bánh kẹo miền Trung tăng 31,2%. Giám đốc hài lòng và hỏi thêm hai câu.

Câu thứ hai: "Khách hạng Vàng đóng góp bao nhiêu trong đó, so với năm ngoái?" Câu SQL vẫn chạy, vẫn ra số, nhưng bảng khách hàng chỉ ghi hạng hiện tại. Một khách lên hạng Vàng tháng Mười năm nay bị tính là khách Vàng cả trong Tết năm ngoái; con số đúng cú pháp nhưng sai ý nghĩa. Câu thứ ba: "So với năm 2023, hồi còn dùng Excel thì sao?" Dữ liệu đó không nằm trong cơ sở dữ liệu mà nằm rải rác trong tệp Excel của 18 cửa hàng, nơi một chai nước suối có bốn cái tên. Còn một điều chuyên viên không thấy: trong lúc câu SQL đầu tiên chạy, quầy thu ngân ở các cửa hàng phải chờ.

Ba lần vấp này, chậm và gây chờ, thiếu lịch sử, thiếu tích hợp, không phải lỗi của người viết SQL. Chúng là ba lý do khiến tổ chức xây thêm một hệ thống bên cạnh cơ sở dữ liệu tác nghiệp: kho dữ liệu (data warehouse). Bài viết gồm năm mục. Mục 1 phân biệt thông tin tác nghiệp với thông tin phân tích. Mục 2 nêu định nghĩa kho dữ liệu và ý nghĩa của từng đặc tính. Mục 3 mô tả các thành phần của một hệ kho dữ liệu. Mục 4 so sánh hai trường phái Inmon và Kimball. Mục 5 trình bày các bước xây kho, bắt đầu từ câu hỏi phân tích.

1. Thông tin tác nghiệp và thông tin phân tích

Thông tin tác nghiệp (operational information) phục vụ hoạt động hằng ngày: tính tiền cho khách, trừ điểm thưởng, in phiếu nhập. Thông tin phân tích (analytical information) phục vụ các quyết định cần phân tích dữ liệu: khung giờ nào đông khách nhất, nhóm hàng nào tăng ở vùng nào (Jukić, 2025). Điểm then chốt là thông tin phân tích được làm ra từ thông tin tác nghiệp: không ai nhập con số "bánh kẹo miền Trung tăng 31,2%"; nó là kết quả gộp hàng chục nghìn dòng hàng mà thu ngân đã ghi. Câu hỏi vì vậy không phải có nên tách hai loại dữ liệu hay không, mà là có nên tổ chức lại dữ liệu tác nghiệp thành một nơi riêng cho phân tích hay không.

1.1. Đo ba khác biệt trên dữ liệu thật

Khác biệt đầu tiên là lượng dữ liệu mỗi thao tác. Một lần bán hàng ghi một hóa đơn với trung bình 2,35 dòng hàng. Câu hỏi về Tết cần gộp 55.934 dòng hàng, gấp khoảng 24 nghìn lần một lần bán và trên thực tế hệ quản trị còn đọc lướt toàn bộ 939.668 dòng chi tiết để lọc ra chúng. Cơ sở dữ liệu tác nghiệp được tối ưu cho việc ghi vài dòng thật nhanh, không phải đọc gần một triệu dòng.

Khác biệt thứ hai là tranh chấp tài nguyên, đo được bằng cách chạy một báo cáo nặng song song với các lần ghi hóa đơn giả lập trên bản sao của cơ sở dữ liệu. Bảng 1 cho kết quả ở hai chế độ ghi nhật ký của SQLite.

Bảng 1. Quầy thu ngân ghi hóa đơn trong lúc một báo cáo nặng chạy khoảng 1,3 giây (đo trên bản sao, tình huống giả định)

Chế độ nhật ký Hóa đơn ghi được trong lúc báo cáo chạy Hóa đơn chờ lâu nhất Số hóa đơn chờ trên 100 ms
DELETE (mặc định) 1 1.295,6 ms 1
WAL 55 0,5 ms 0

Ở chế độ mặc định, một hóa đơn bình thường ghi mất chưa tới một mili giây, nhưng trong lúc báo cáo chạy, quầy chỉ ghi được một hóa đơn và hóa đơn đó phải chờ gần trọn 1,3 giây, vì người đọc giữ khóa trên cả tệp. Chế độ WAL cho người đọc làm việc trên một phiên bản cố định nên không chặn người ghi. Nhưng Bảng 1 không có nghĩa là bật WAL là xong. WAL gỡ được việc chặn nhau vì khóa, không gỡ được việc tranh nhau bộ xử lý, bộ nhớ và đĩa trên một máy chủ phục vụ 18 cửa hàng. Quan trọng hơn, nó không làm xuất hiện lịch sử hạng thành viên, cũng không đưa được dữ liệu Excel năm 2023 vào.

Khác biệt thứ ba là biểu diễn thời gian. Cơ sở dữ liệu tác nghiệp chỉ cần trạng thái hiện tại: giá niêm yết hôm nay, hạng thành viên hôm nay. So giá cao nhất mà từng sản phẩm được bán trong năm 2024 với giá niêm yết hiện tại cho thấy 171 trên 1.200 sản phẩm (14,3% danh mục) đã tăng giá từ giữa năm 2025 và bảng sản phẩm không còn dấu vết gì của giá cũ. Tương tự, doanh thu năm 2024 tính theo hạng hiện tại cho ba con số trông rất tin cậy: hạng Đồng 5,66 tỉ, Bạc 2,92 tỉ, Vàng 963 triệu đồng. Nhưng con số thứ ba trả lời câu hỏi "những người hiện là khách Vàng đã mua bao nhiêu năm 2024", không phải "khách hạng Vàng năm 2024 mua bao nhiêu".

1.2. Ba nhóm khác biệt

Jukić (2025) gom các khác biệt giữa hai loại thông tin thành ba nhóm: thành phần dữ liệu, kỹ thuật và chức năng. Bảng 2 tóm tắt ba nhóm, mỗi khác biệt kèm một bằng chứng ở Sen Vàng Mart.

Bảng 2. Ba nhóm khác biệt giữa thông tin tác nghiệp và thông tin phân tích (tình huống giả định)

Nhóm Khác biệt Tác nghiệp Phân tích Ở Sen Vàng Mart
Thành phần dữ liệu Tầm thời gian Vài tháng Nhiều năm Mười năm hóa đơn sẽ làm chậm quầy thu ngân
Mức chi tiết Chi tiết, tổng hợp khi cần Chi tiết và tổng hợp lưu sẵn Bảng tổng hợp trả lời câu hỏi Tết trong 12 ms
Biểu diễn thời gian Trạng thái hiện tại Hiện tại và các lát cắt quá khứ 171 sản phẩm mất giá cũ; chỉ còn hạng hôm nay
Kỹ thuật Lượng dữ liệu, tần suất Ít dòng, rất thường xuyên Rất nhiều dòng, thưa 2,35 dòng mỗi lần bán; 939.668 dòng cho câu hỏi Tết
Cập nhật Thêm, sửa, xóa liên tục Chỉ đọc, nạp định kỳ Báo cáo chặn quầy thu ngân 1,3 giây
Dư thừa Loại bỏ Chấp nhận nếu có lợi Lược đồ hình sao
Chức năng Người dùng Rất nhiều, cho việc cụ thể Ít hơn, cho quyết định Thu ngân 18 cửa hàng; ban giám đốc
Định hướng Hướng ứng dụng Hướng chủ đề Lược đồ cho màn hình thu ngân; chủ đề doanh số

Nguồn: dựa trên Jukić (2025).

Cạm bẫy phổ biến nhất ở đây là nghĩ rằng "chỉ cần thêm chỉ mục và chạy báo cáo vào ban đêm". Cách đó giải quyết được nhóm khác biệt kỹ thuật, nhưng không chạm tới hai nhóm còn lại: chạy lúc nửa đêm, doanh thu theo hạng vẫn sai, dữ liệu năm 2023 vẫn nằm ngoài. Khác biệt kỹ thuật là khác biệt duy nhất người ta cảm thấy được, qua sự chậm chạp, nên dễ bị coi là toàn bộ vấn đề. Bảng 2 vì vậy còn là một danh sách kiểm tra: nếu chỉ nhóm kỹ thuật gây khó, một bản sao chỉ đọc có thể đủ; nếu cần lịch sử hoặc cần gộp nhiều nguồn, tổ chức cần một kho dữ liệu đúng nghĩa.

2. Định nghĩa kho dữ liệu

Định nghĩa được trích nhiều nhất là của Inmon (2005): kho dữ liệu là một tập dữ liệu hướng chủ đề, tích hợp, không biến động và biến thiên theo thời gian, phục vụ việc ra quyết định của nhà quản lý. Jukić (2025) dùng một định nghĩa tổng quát hơn: kho dữ liệu là một kho có cấu trúc, chứa dữ liệu tích hợp, hướng chủ đề, phạm vi toàn doanh nghiệp, lưu lịch sử và biến thiên theo thời gian, với mục đích cho phép truy xuất thông tin phân tích; kho có thể lưu dữ liệu chi tiết, tổng hợp hoặc cả hai. Mỗi cụm từ trong định nghĩa là lời đáp cho một lần vấp ở đầu bài, như Bảng 3 cho thấy.

Bảng 3. Mỗi đặc tính của kho dữ liệu giải quyết một vấn đề cụ thể

Đặc tính Nghĩa là Vấn đề được giải quyết Hệ quả cho thiết kế
Có cấu trúc Là một cơ sở dữ liệu có siêu dữ liệu, không phải đống tệp Không phải đi tìm tệp nào chứa gì Có lược đồ, có từ điển dữ liệu
Tích hợp Gộp nhiều nguồn, thống nhất mã và đơn vị Excel 2023 và cơ sở dữ liệu bán hàng trả lời chung một câu hỏi Cần ETL làm sạch và đối chiếu
Hướng chủ đề Tổ chức quanh doanh số, nhập hàng, không quanh màn hình nhập liệu Không phải nối năm bảng cho mỗi câu hỏi Bảng sự kiện và bảng chiều
Toàn doanh nghiệp Một chủ đề gồm dữ liệu của mọi bộ phận Kinh doanh và marketing ra cùng một con số doanh thu Chiều dùng chung
Lưu lịch sử Tầm thời gian dài So được 2023, 2024, 2025 Dung lượng lớn
Biến thiên theo thời gian Giữ lát cắt ở nhiều thời điểm Biết khách nào hạng Vàng vào Tết năm ngoái Lưu phiên bản khi thuộc tính đổi

Nguồn: dựa trên Jukić (2025).

Hai đặc tính cuối của Bảng 3 hay bị hiểu lẫn. Lưu lịch sử (historical) nói về độ dài tầm thời gian. Biến thiên theo thời gian (time-variant) nói về cách dữ liệu gắn với thời gian: kho giữ lát cắt ở từng thời điểm để so quý I năm nay với quý I hai năm trước theo đúng tình trạng của từng lúc. Một cơ sở dữ liệu có thể giữ hai năm hóa đơn mà vẫn không biến thiên theo thời gian, chính là trường hợp của Sen Vàng Mart. Inmon (2005) nhấn thêm đặc tính không biến động (nonvolatile): người dùng kho không thêm, sửa, xóa; dữ liệu mới được nạp định kỳ và nối thêm vào dữ liệu cũ.

Cạm bẫy đi kèm định nghĩa là coi kho dữ liệu là bản sao lưu của cơ sở dữ liệu tác nghiệp. Một bản sao nguyên trạng giải quyết được tranh chấp tài nguyên, nhưng mang theo hai lần vấp còn lại: nó vẫn chỉ có hạng hiện tại và vẫn không có dữ liệu Excel. Tệ hơn, nếu bản sao bị ghi đè mỗi đêm thì lịch sử còn mất nhanh hơn: hôm qua khách là hạng Bạc, đêm nay bản sao chỉ còn hạng Vàng.

Câu cuối của định nghĩa nói về dữ liệu chi tiết (mỗi dòng hàng trên mỗi hóa đơn) và dữ liệu tổng hợp (doanh thu một ngày của một nhóm hàng ở một cửa hàng). Một bảng tổng hợp theo ngày, cửa hàng và nhóm hàng của Sen Vàng Mart có 283.330 dòng, gộp từ 939.668 dòng chi tiết. Dựng nó mất khoảng một giây và chỉ dựng một lần; sau đó câu hỏi Tết chạy trong 12 mili giây thay vì 463 mili giây. Đổi lại, bảng tổng hợp quên mọi thứ dưới mức ngày, cửa hàng, nhóm hàng: không trả lời được câu hỏi theo khung giờ, theo khách hay theo từng sản phẩm. Vì vậy kho thường giữ cả hai.

3. Các thành phần của hệ kho dữ liệu

Một hệ kho dữ liệu có ba thành phần cốt lõi, gồm hệ thống nguồn, hạ tầng ETL và chính kho dữ liệu và phần lớn có thêm ứng dụng phía người dùng (Jukić, 2025). Hình 1 vẽ các thành phần này cho Sen Vàng Mart.

Sơ đồ thành phần hệ kho dữ liệu: bốn nguồn gồm cơ sở dữ liệu bán hàng, tệp Excel cũ, đăng ký từ ứng dụng và lịch âm đi qua ETL vào kho dữ liệu, từ kho tách ra hai kho chủ đề kinh doanh và marketing, rồi đến ứng dụng BI

Hình 1. Các thành phần hệ kho dữ liệu của Sen Vàng Mart (tình huống giả định). Nguồn: dựa trên Jukić (2025).

Hệ thống nguồn (source systems) là các cơ sở dữ liệu và tệp tác nghiệp có dữ liệu hữu ích cho phân tích. Trở thành nguồn không làm thay đổi cách chúng phục vụ người dùng tác nghiệp. Nguồn có thể ở trong tổ chức hoặc ở ngoài, như lịch âm để biết Tết rơi vào ngày nào mỗi năm. Hạ tầng ETL (extraction, transformation, load) làm ba việc: trích xuất dữ liệu từ nguồn, biến đổi cho khớp cấu trúc của kho và bảo đảm chất lượng, rồi nạp vào kho. Đây là nơi bốn tên của chai nước suối được quy về một mã, nơi cửa hàng đếm theo thùng được đổi sang chai; ETL thường là phần tốn công nhất của cả dự án. Bài Đo chất lượng dữ liệu theo sáu chiều đi sâu vào phần làm sạch.

Kho dữ liệu là nơi chứa dữ liệu phân tích đã tích hợp, thường nạp theo chu kỳ mỗi đêm hoặc mỗi giờ. Ứng dụng BI cho phép người không viết SQL dùng kho qua báo cáo, bảng điều khiển và công cụ phân tích trực tuyến, như bài Ba cách hiểu đúng về trí tuệ kinh doanh mô tả. Giữa kho và người dùng có thể có các kho dữ liệu chủ đề (data mart), phạm vi hẹp hơn, thường chỉ một chủ đề. Kho chủ đề phụ thuộc lấy dữ liệu từ kho chung, như hai hộp kinh doanh và marketing ở Hình 1; kho chủ đề độc lập có nguồn và ETL riêng.

Cạm bẫy ở thành phần này là mỗi phòng ban một kho chủ đề độc lập. Dựng một kho nhỏ cho phòng kinh doanh mất vài tuần, dựng kho toàn doanh nghiệp mất vài tháng, nên nhiều tổ chức đi đường tắt. Một năm sau, phòng kinh doanh và phòng marketing báo hai con số doanh thu tháng Giêng khác nhau, vì một bên tính cả hóa đơn bị hủy, bên kia không; một bên quy vùng theo tỉnh, bên kia theo mã cửa hàng. Đó chính là chuyện 18 tệp Excel lặp lại ở quy mô lớn hơn.

4. Hai trường phái Inmon và Kimball

Hai người có ảnh hưởng lớn nhất tới nghề kho dữ liệu đề xuất hai cách tổ chức khác nhau. Hình 2 đặt hai kiến trúc cạnh nhau.

Hai kiến trúc kho dữ liệu: bên trái Inmon với nguồn và ETL vào kho trung tâm chuẩn hóa rồi tách ra ba kho chủ đề; bên phải Kimball với nguồn và ETL vào hai bảng sự kiện bán hàng và nhập hàng dùng chung ba chiều ngày, sản phẩm, cửa hàng

Hình 2. Kiến trúc Inmon và Kimball. Nguồn: dựa trên Inmon (2005) và Kimball & Ross (2013).

Trường phái Inmon coi kho dữ liệu là một cơ sở dữ liệu phân tích tích hợp, thiết kế bằng mô hình ER và được chuẩn hóa như bài Chuẩn hóa cơ sở dữ liệu 1NF, 2NF, 3NF và BCNF mô tả (Inmon, 2005). Mọi việc tích hợp diễn ra ở kho trung tâm; từ đó tách ra các kho chủ đề phụ thuộc cho từng nhóm người dùng và người dùng hiếm khi truy vấn thẳng kho trung tâm. Trường phái Kimball coi kho dữ liệu là một mô hình chiều: một tập lược đồ hình sao, mỗi lược đồ quanh một bảng sự kiện cho một chủ đề (Kimball & Ross, 2013). Điểm then chốt là các chiều dùng chung (conformed dimensions) như thời gian, sản phẩm, cửa hàng được thiết kế một lần và mọi bảng sự kiện cùng nối vào. Nhờ đó "nhóm hàng Bánh kẹo" có cùng một nghĩa ở cả chủ đề bán hàng lẫn nhập hàng. Bảng 4 so sánh hai trường phái.

Bảng 4. So sánh hai trường phái Inmon và Kimball

Tiêu chí Inmon Kimball
Cấu trúc kho trung tâm Chuẩn hóa (ER, quan hệ) Mô hình chiều (các lược đồ hình sao)
Nơi tích hợp Kho chuẩn hóa ở giữa Các chiều dùng chung
Thời gian tới kết quả đầu tiên Dài: phải xây kho trung tâm trước Ngắn: xây từng chủ đề một
Chi phí ban đầu Cao Thấp hơn, tăng dần theo số chủ đề
Khi nguồn thay đổi nhiều Linh hoạt hơn Phải sửa chiều và bảng sự kiện liên quan
Phù hợp khi Tổ chức lớn, nhiều nguồn chồng chéo Cần kết quả sớm, chủ đề rõ, đội nhỏ

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

Trên thực tế, hai cách thường được kết hợp: mô hình chiều có thể dùng ngay ở bước thu thập yêu cầu để trình bày "đo cái gì, theo những góc nào" với nhà quản lý, kể cả khi kho thật được xây chuẩn hóa (Jukić, 2025). Với một chuỗi cỡ Sen Vàng Mart và một đội phân tích nhỏ cần kết quả trong vài tuần, cách Kimball thực dụng hơn và bài Lược đồ hình sao, bảng sự kiện và bảng chiều đi tiếp theo hướng đó.

Kho dữ liệu ngày nay khác thời Inmon và Kimball viết sách ở ba điểm. Phần lớn kho mới chạy trên dịch vụ đám mây với dữ liệu lưu theo cột, giúp truy vấn đọc nhiều dòng nhưng ít cột nhanh hơn nhiều (Abadi et al., 2008). Lưu trữ và tính toán được tách rời và tính tiền theo mức dùng. Thứ tự ETL thường đổi thành ELT: nạp dữ liệu thô vào trước, biến đổi sau ngay trong kho. Bài Chọn nền tảng phân tích dữ liệu năm 2026 so sánh các nền tảng cụ thể. Các khái niệm của bài này không đổi theo công nghệ.

5. Các bước phát triển kho dữ liệu

Kho dữ liệu được phát triển qua một chuỗi bước: thu thập và xác định yêu cầu, mô hình hóa, tạo kho, xây ETL và phát triển ứng dụng BI song song, triển khai, sử dụng và quản trị, rồi lặp lại với phiên bản kế tiếp (Jukić, 2025). Bước đầu tiên quyết định thành bại: nếu yêu cầu sai, mọi bước sau đều vô ích.

Khác biệt lớn nhất so với cơ sở dữ liệu tác nghiệp nằm ở dạng của yêu cầu. Bài Mô hình thực thể liên kết ER và cách đọc bản số thu yêu cầu dưới dạng quy tắc ghi chép, như "mỗi hóa đơn lập tại đúng một cửa hàng". Ở kho dữ liệu, yêu cầu là câu hỏi phân tích và mỗi câu được tách thành bốn phần: chỉ số cần đo, các chiều để cắt và gộp, độ mịn thấp nhất phải giữ và nguồn cung cấp dữ liệu. Bảng 5 tách bốn trong tám câu hỏi của ban giám đốc Sen Vàng Mart.

Bảng 5. Tách câu hỏi của nhà quản lý thành chỉ số, chiều và chỗ thiếu (tình huống giả định)

Câu hỏi Chỉ số Chiều phân tích Chỗ thiếu trong cơ sở dữ liệu bán hàng
Doanh thu mùa Tết theo nhóm hàng, vùng, so với năm trước Doanh thu, số lượng Ngày, vùng, nhóm hàng Cột vùng; ngày Tết mỗi năm
Đóng góp của khách hạng Vàng Doanh thu, số khách Hạng lúc mua, tháng Lịch sử hạng thành viên
Khuyến mãi có làm tăng doanh số? Doanh thu, số lượng Khuyến mãi, sản phẩm, tuần Dòng hàng không ghi khuyến mãi đã áp dụng
Cửa hàng mới so với cửa hàng cũ cùng số tháng hoạt động Doanh thu Cửa hàng, tháng thứ mấy từ khai trương Dữ liệu trước 2024 nằm trong Excel

Bảng 5 cho thấy hai điều. Thứ nhất, các câu hỏi gom về vài chủ đề dùng chung các chiều thời gian, sản phẩm, cửa hàng, đúng cấu trúc chiều dùng chung của Kimball. Thứ hai, mọi chỗ thiếu đều thuộc hai loại đã gọi tên ở đầu bài: thiếu lịch sử và thiếu tích hợp. Một nguyên tắc nữa là yêu cầu chỉ có thể dựa trên dữ liệu tồn tại hoặc thu thập được; chuỗi không có thiết bị đếm khách vào cửa, nên câu hỏi về tỉ lệ khách vào mà không mua phải gác lại. Cách đặt câu hỏi phân tích tốt được bàn kỹ trong bài Đặt đúng câu hỏi phân tích.

Yêu cầu được thu theo vòng lặp và có thể sửa sau bất kỳ bước nào, nhưng không được thay đổi ngầm: người xây kho không tự ý thêm bảng hay cột mà yêu cầu không nêu; nếu thấy cần, phải bổ sung yêu cầu trước, sửa mô hình rồi mới xây (Jukić, 2025). AI hữu ích ở bước này: dán một câu hỏi của nhà quản lý vào trợ lý AI và yêu cầu nó tách thành chỉ số, chiều, độ mịn và nguồn theo khung Bảng 5. AI thường tách tốt phần chỉ số và chiều, nhưng hay bỏ sót cột "chỗ thiếu" vì nó không biết cơ sở dữ liệu của bạn thiếu gì và đó lại là cột quan trọng nhất.

Kết luận

Kho dữ liệu không ra đời vì người viết SQL kém, mà vì cơ sở dữ liệu tác nghiệp được thiết kế cho một việc khác. Ba lần vấp của Sen Vàng Mart cho thấy điều đó: báo cáo chặn quầy thu ngân 1,3 giây, doanh thu theo hạng trả lời nhầm câu hỏi, dữ liệu năm 2023 nằm ngoài hệ thống. Thêm chỉ mục hay chạy báo cáo ban đêm chỉ chữa được lần vấp thứ nhất.

Định nghĩa kho dữ liệu, gồm tích hợp, hướng chủ đề, toàn doanh nghiệp, lưu lịch sử và biến thiên theo thời gian, là lời đáp cho từng lần vấp. Inmon và Kimball đưa ra hai con đường để xây nó, khác nhau ở cấu trúc kho trung tâm nhưng giống nhau ở một nguyên tắc: tích hợp một lần, ở một nơi, thay vì để mỗi phòng ban tự dựng kho riêng. Và mọi dự án kho dữ liệu nên bắt đầu từ câu hỏi phân tích, không phải từ bảng.

Đọc thêm

Tài liệu tham khảo

Abadi, D. J., Madden, S. R., & Hachem, N. (2008). Column-stores vs. row-stores: How different are they really? In Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data (pp. 967–980). ACM. https://doi.org/10.1145/1376616.1376712

Inmon, W. H. (2005). Building the data warehouse (4th ed.). Wiley. https://www.wiley.com/en-us/Building+the+Data+Warehouse%2C+4th+Edition-p-9780764599446

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

Enjoyed this article?

Share it with your network