Dưới đây là Bản ghi nhớ ôn thi & bảo vệ đồ án theo giọng chấm thi nghiêm khắc. Lưu ý: tôi thấy 3 file gồm đề bài DW, báo cáo BTL, và file “Yêu cầu BTL mining.md”. File thứ ba không đúng tên “Cách tính điểm/Ghi chú ca trước” và nội dung thiên về data mining, không phải ghi chú chấm DW. Vì vậy phần dưới được bám chặt vào đề bài, báo cáo của nhóm, và các lỗi/điểm yếu bạn nêu trực tiếp trong yêu cầu. (BTLKDL (1).pdf) (Bài tập lớn KDL (1).pdf) (Yêu cầu BTL mining.md)

BẢN GHI NHỚ ÔN THI & BẢO VỆ ĐỒ ÁN KHO DỮ LIỆU

Phần 1 — Red Flags: lỗi sai chí mạng phải tránh

1. Fact không được chứa “Mã đơn” và “Giá đặt” theo kiểu dữ liệu giao dịch gốc

Đây là điểm rất dễ bị hỏi xoáy vì nó đụng trực tiếp vào grain của Fact.

Trong báo cáo, nhóm đã xác định Fact_Sales có grain là:
mỗi dòng biểu diễn tổng số lượng bán và tổng doanh thu của một mặt hàng, cho một khách hàng, tại một cửa hàng, theo tháng. Fact_Inventory cũng được tổng hợp theo tháng ở mức mặt hàng — cửa hàng. (BTLKDL (1).pdf)

Vì vậy:

Mã đơn không được nằm trong Fact_Sales vì MaDon là mã giao dịch chi tiết ở hệ thống OLTP. Nếu đưa MaDon vào Fact, grain sẽ bị kéo xuống mức dòng đơn hàng / chi tiết đơn hàng, không còn là mức tổng hợp theo tháng nữa. Khi đó bảng Fact của bạn không còn phục vụ OLAP đúng nghĩa mà biến thành bản sao của bảng giao dịch.

Nói thẳng khi bảo vệ:

“Fact_Sales của nhóm em không lưu theo từng đơn. Nhóm em đã chọn grain là tổng hợp theo tháng, mặt hàng, khách hàng, cửa hàng. Vì vậy MaDon bị loại khỏi Fact để tránh phá vỡ grain và tránh biến DW thành OLTP thứ hai.”

Giá đặt cũng không nên lưu như một measure độc lập trong Fact_Sales nếu Fact đã được tổng hợp theo tháng. Lý do là GiaDat là đơn giá tại thời điểm giao dịch. Trong một tháng, cùng một mặt hàng có thể được bán nhiều lần với nhiều giá khác nhau. Nếu bạn đưa GiaDat vào dòng tổng hợp, câu hỏi sẽ là: giá nào? Giá đầu tháng, cuối tháng, trung bình, lớn nhất, nhỏ nhất, hay giá của đơn nào?

Cách đúng là dùng GiaDat trong ETL để tính ThanhTien = SUM(SoLuongDat * GiaDat). Sau khi tổng hợp, Fact chỉ cần giữ các measure phân tích được như SoLuongDat và ThanhTien. Báo cáo của nhóm cũng mô tả ThanhTien là độ đo additive, tính bằng tổng của số lượng đặt nhân giá đặt. (BTLKDL (1).pdf)

Câu trả lời chuẩn:

“GiaDat là dữ liệu giao dịch nguyên tử, không ổn định theo thời điểm. Trong DW tổng hợp theo tháng, em không lưu GiaDat như một measure độc lập vì nó không cộng gộp được và không đại diện duy nhất cho cả tháng. Em dùng GiaDat trong bước ETL để tính ThanhTien, sau đó lưu measure tổng hợp.”

Khóa chính của Fact được cấu thành như thế nào?

Theo mô hình trong báo cáo:

• Fact_Sales có khóa chính tổ hợp từ các khóa ngoại:

  • MaThoiGian
  • MaMH
  • MaCuaHang
  • MaKH

• Fact_Inventory có khóa chính tổ hợp từ:

  • MaThoiGian
  • MaMH
  • MaCuaHang

Báo cáo ghi rõ Fact_Sales tham chiếu 4 chiều thời gian, mặt hàng, địa lý/cửa hàng, khách hàng; còn Fact_Inventory tham chiếu 3 chiều thời gian, mặt hàng, địa lý/cửa hàng. (BTLKDL (1).pdf)

Phải nhớ: khóa chính của Fact không phải là mã giao dịch OLTP. Trong dimensional modeling, khóa Fact thường là tổ hợp các khóa chiều ở đúng grain đã chọn.

---

2. Chiều Thời gian không nên lưu chi tiết đến cấp “Ngày” trong bài này

Đây không phải vì “ngày là sai tuyệt đối”. Trong DW thực tế, nhiều hệ thống vẫn có ngày. Nhưng với bài này, grain nhóm chọn là tháng, và các yêu cầu OLAP trong báo cáo hướng tới phân tích theo Tháng / Quý / Năm. Báo cáo cũng định nghĩa Time Hierarchy là Year → Quarter → Month, không có Day. (BTLKDL (1).pdf)

Nếu bạn đưa cấp Ngày vào Dim_Time trong khi Fact đã tổng hợp theo tháng, sẽ sinh mâu thuẫn:

• Fact có MaThoiGian = 2025_03, nhưng Dim_Time lại có nhiều ngày 2025-03-01, 2025-03-02, ...
• Khi drill-down từ tháng xuống ngày, hệ thống không có dữ liệu đúng ở cấp ngày.
• Nếu cố gán toàn bộ số tháng vào một ngày nào đó, ví dụ ngày cuối tháng, thì phân tích theo ngày bị sai bản chất.
• Nếu nhân bản số liệu tháng cho từng ngày, tổng tháng sẽ bị phóng đại.

Câu trả lời nên nói rõ:

“Không phải Time Dimension không bao giờ được có ngày. Nhưng trong thiết kế của nhóm em, grain của Fact là tháng, nên chiều thời gian dừng ở tháng/quý/năm để đồng nhất với grain. Nếu thêm ngày, phải thay đổi grain của Fact xuống ngày và ETL cũng phải nạp theo ngày. Nếu không, drill-down xuống ngày là drill-down giả.”

Đây là tư duy giảng viên muốn nghe: Dimensional hierarchy phải tương thích với grain của Fact.

---

3. Dữ liệu từ IDB sang DW không được đổ theo từng ngày mà phải dùng GROUP BY, SUM, MAX/MIN/LAST

Đề bài yêu cầu xây kho dữ liệu phục vụ OLAP, không yêu cầu sao chép nguyên xi hệ thống giao dịch. Dữ liệu nguồn gồm các bảng đơn hàng, mặt hàng được đặt, mặt hàng được lưu trữ, cửa hàng, văn phòng đại diện, khách hàng... (Bài tập lớn KDL (1).pdf)

Báo cáo của nhóm đã nêu đúng nguyên tắc: dữ liệu từ IDB sang DW không nạp theo từng ngày/giao dịch chi tiết, mà phải dùng các hàm tổng hợp như SUM, MAX, GROUP BY theo thời gian và các chiều phân tích. (BTLKDL (1).pdf)

Vì sao giảng viên bắt lỗi nếu đổ từng ngày?

Vì đó là nhầm lẫn giữa OLTP / IDB và DW / OLAP.

IDB là nơi tích hợp, chuẩn hóa, giải quyết xung đột dữ liệu. DW là nơi lưu dữ liệu theo mô hình đa chiều, đã được tổ chức theo grain phân tích. Nếu đổ từng ngày, từng đơn, từng dòng chi tiết vào Fact mà không tổng hợp, bạn chưa làm đúng bước thiết kế kho dữ liệu; bạn chỉ đang “copy dữ liệu sang chỗ khác”.

Cụ thể:

• Fact_Sales phải dùng GROUP BY theo tháng, mặt hàng, cửa hàng, khách hàng.
• SoLuongDat dùng SUM.
• ThanhTien dùng SUM(SoLuongDat * GiaDat).
• Fact_Inventory không dùng SUM qua ngày, mà lấy giá trị chốt kỳ bằng logic LAST/MAX theo thời điểm kiểm kê cuối tháng.

Khi bị hỏi, trả lời như sau:

“IDB giữ dữ liệu tích hợp ở mức chi tiết. DW của nhóm em được thiết kế ở grain tháng, nên khi load vào Fact bắt buộc phải GROUP BY theo MaThoiGian, MaMH, MaCuaHang và MaKH nếu là Sales; hoặc MaThoiGian, MaMH, MaCuaHang nếu là Inventory. Các measure được tính bằng hàm tổng hợp phù hợp. Nếu nạp từng dòng ngày vào DW thì grain bị sai và OLAP roll-up dễ bị đếm/cộng sai.”

---

Phần 2 — Phân tích kỹ thuật chuyên sâu

2.1. Metadata: báo cáo có mấy loại? Bảng metadata trên DBMS dùng để làm gì?

Báo cáo của nhóm ghi rõ hệ thống lưu trữ 3 loại metadata chính:

1. Metadata cấu trúc
2. Metadata nghiệp vụ
3. Metadata vận hành / Operational Metadata (BTLKDL (1).pdf)

Metadata cấu trúc

Đây là metadata mô tả cấu trúc kỹ thuật của kho dữ liệu:

• Có bao nhiêu Fact?
• Có bao nhiêu Dimension?
• Fact nào nối với Dimension nào?
• Khóa chính, khóa ngoại là gì?
• Measure nào nằm trong Fact nào?

Với bài của bạn, metadata cấu trúc phải mô tả mô hình Fact Constellation gồm:

• Fact_Sales
• Fact_Inventory
• Dim_Time
• Dim_Item
• Dim_Location
• Dim_Customer

Báo cáo đã xác định mô hình chòm sao với 2 Fact và 4 Dimension dùng chung một số chiều như thời gian, mặt hàng, địa lý. (BTLKDL (1).pdf)

Metadata nghiệp vụ

Đây là phần giảng viên rất thích hỏi, vì nó kiểm tra bạn có hiểu ý nghĩa dữ liệu không.

Ví dụ:

• SoLuongDat: tổng số lượng hàng bán, additive.
• ThanhTien: doanh thu, additive.
• SoLuongTon: tồn kho cuối kỳ, semi-additive.
• LoaiKH: khách du lịch, khách bưu điện, hoặc cả hai.

Điểm cần nhấn mạnh:

Metadata nghiệp vụ giúp người dùng hiểu đúng ý nghĩa measure. Nếu không ghi rõ SoLuongTon là semi-additive, người dùng có thể cộng tồn kho tháng 1 + tháng 2 + tháng 3 và tạo ra số vô nghĩa.

Metadata vận hành

Đây là metadata về quá trình ETL:

• Lần load nào?
• Load bảng nào?
• Thời gian bắt đầu/kết thúc?
• Bao nhiêu dòng được nạp?
• Trạng thái thành công/thất bại?
• Có lỗi gì không?

Báo cáo nêu đây là loại metadata quan trọng được lưu vật lý trong Oracle để ghi lại lịch sử ETL/Data Lineage. (BTLKDL (1).pdf)

Khi bị hỏi “bảng metadata thiết kế thế nào?”, bạn nên trả lời ở mức thiết kế:

Một bảng metadata vận hành hợp lý có thể gồm:

text
ETL_METADATA_LOG
- LogID
- TenBangDich
- TenTienTrinhETL
- ThoiGianBatDau
- ThoiGianKetThuc
- SoDongNapThanhCong
- SoDongBiLoi
- TrangThai
- ThongBaoLoi

Ý nghĩa:

• LogID: định danh mỗi lần chạy ETL.
• TenBangDich: biết load vào bảng nào, ví dụ Fact_Sales.
• TenTienTrinhETL: biết procedure/script nào thực hiện.
• ThoiGianBatDau, ThoiGianKetThuc: phục vụ kiểm soát thời gian chạy.
• SoDongNapThanhCong: kiểm tra khối lượng dữ liệu.
• TrangThai: success/fail.
• ThongBaoLoi: phục vụ audit và sửa lỗi.

Câu trả lời gọn khi bảo vệ:

“Báo cáo của nhóm em có 3 loại metadata: cấu trúc, nghiệp vụ và vận hành. Metadata vận hành được lưu vật lý trong DBMS để ghi lineage của ETL: bảng nào được nạp, lúc nào, bao nhiêu dòng, trạng thái ra sao. Mục đích là kiểm soát, audit và debug quá trình nạp dữ liệu.”

---

2.2. Indexing: vì sao tách file Index và Data? Dùng B-Tree, Bitmap ở đâu?

Vì sao tạo tablespace Index riêng với tablespace Data?

Báo cáo của nhóm nêu rõ chiến lược tách dữ liệu bảng và chỉ mục vào hai tablespace/file vật lý khác nhau để giảm nghẽn I/O khi Oracle vừa đọc index vừa đọc dữ liệu bảng. (BTLKDL (1).pdf)

Cần giải thích chặt hơn:

Trong OLAP, truy vấn thường là:

• join Fact lớn với nhiều Dimension;
• lọc theo thời gian, vùng, loại khách;
• group by trên nhiều chiều;
• aggregate measure.

Nếu index và data nằm chung một file vật lý, truy vấn phải liên tục đọc cấu trúc index rồi quay sang đọc block dữ liệu. Khi dung lượng lớn, I/O bị tranh chấp. Tách tablespace giúp:

• quản trị lưu trữ rõ ràng hơn;
• có thể đặt index và data trên các datafile/đĩa khác nhau;
• giảm tranh chấp I/O;
• dễ rebuild, backup, monitor riêng phần index.

Cẩn thận: không nên nói “chắc chắn nhanh gấp nhiều lần” nếu không benchmark. Nói chuẩn hơn:

“Tách tablespace index và data giúp giảm I/O contention và thuận tiện quản trị. Hiệu quả thực tế phụ thuộc cấu hình lưu trữ, cache, optimizer và workload.”

Đây là cách trả lời an toàn trước giảng viên khó tính.

B-Tree Index dùng cho bảng/cột nào?

Theo báo cáo, nhóm dùng B-Tree Index cho:

• khóa chính các bảng Dimension;
• khóa ngoại trong Fact;
• ví dụ MaThoiGian, MaMH, MaCuaHang, MaKH trên Fact_Sales. (BTLKDL (1).pdf)

Lý do:

B-Tree phù hợp với cột có high cardinality hoặc dùng nhiều trong join/lookup. Các mã như MaKH, MaMH, MaCuaHang có nhiều giá trị khác nhau, nên dùng B-Tree để tăng tốc join Fact-Dimension.

Câu trả lời chuẩn:

“B-Tree dùng cho khóa chính Dimension và khóa ngoại Fact vì các cột mã định danh có độ phân biệt cao và được dùng thường xuyên trong join. Đây là mẫu truy vấn điển hình của star schema/constellation.”

Bitmap Index dùng cho bảng/cột nào?

Theo báo cáo, nhóm dùng Bitmap Index cho các cột phân loại ít giá trị:

• LoaiKH trong Dim_Customer
• Bang trong Dim_Location (BTLKDL (1).pdf)

Lý do:

Bitmap phù hợp với low cardinality: số lượng giá trị ít, lặp lại nhiều. OLAP hay lọc theo loại khách hoặc vùng/bang, nên bitmap giúp thực hiện phép AND/OR rất nhanh.

Ví dụ:

• LoaiKH = 'Khách du lịch'
• Bang = 'Miền Bắc'
• kết hợp hai điều kiện: khách du lịch ở một vùng cụ thể

Bitmap xử lý tốt dạng lọc kết hợp nhiều chiều.

Nhưng phải lưu ý khi bị hỏi sâu:

“Bitmap Index phù hợp với DW vì dữ liệu chủ yếu đọc, ít cập nhật từng dòng. Nếu là OLTP cập nhật liên tục thì bitmap không phù hợp do chi phí khóa và cập nhật cao.”

Câu này thể hiện bạn hiểu bản chất, không học vẹt.

---

2.3. Khối dữ liệu OLAP: logic sinh khối, drill-down/roll-up móc vào đâu?

Báo cáo cho biết nhóm dùng Oracle Analytics Workspace Manager (AWM), tạo các Dimension mapping với bảng Dimension trong DW, sau đó tạo cube từ các Fact. Cụ thể, có khối 4 chiều từ Fact_Sales, các khối 3 chiều/2 chiều sinh từ khối ban đầu; và khối 3 chiều từ Fact_Inventory, sau đó sinh các khối 2 chiều. (BTLKDL (1).pdf)

Logic sinh khối là gì?

Về bản chất, cube là lớp tổ chức dữ liệu đa chiều trên Fact và Dimension.

Với Sales_Cube, các chiều là:

• Time
• Item
• Location
• Customer

Measure:

• SoLuongDat
• ThanhTien

Với Inventory_Cube, các chiều là:

• Time
• Item
• Location

Measure:

• SoLuongTon

Bản chất cube không tự “phát minh” dữ liệu mới. Nó lấy dữ liệu từ Fact, map sang Dimension, rồi tổ chức/tiền tổng hợp theo các cấp phân cấp để truy vấn OLAP nhanh hơn.

Drill-down/Roll-up thực chất móc vào đâu?

Drill-down và roll-up không phải phép màu trên giao diện. Nó dựa vào:

1. Hierarchy trong Dimension
2. Measure trong Fact
3. Aggregate rule của measure

Ví dụ Time Hierarchy trong báo cáo là:

text
Year → Quarter → Month

Location Hierarchy là:

text
State/Bang → City/Thành phố → Store/Cửa hàng

Khi roll-up từ tháng lên quý, hệ thống lấy các dòng/cell ở cấp tháng và tổng hợp lên quý theo hàm của measure.

• Với SoLuongDat: SUM được.
• Với ThanhTien: SUM được.
• Với SoLuongTon: không SUM theo thời gian; phải lấy giá trị chốt kỳ phù hợp.

Khi drill-down từ Bang xuống Thành phố rồi Cửa hàng, hệ thống không “tìm lại mã đơn”. Nó đi theo hierarchy của Dim_Location và lấy measure từ cube/fact tương ứng.

Câu trả lời nên nói:

“Drill-down/Roll-up móc vào các cube đã được mapping với Fact và Dimension. Sales thao tác trên Sales_Cube, Inventory thao tác trên Inventory_Cube. Hệ thống dùng hierarchy của dimension để đổi cấp phân tích và dùng aggregate rule của measure để tính cell tương ứng.”

Khác biệt giữa bấm nút query và tương tác trực tiếp trên biểu đồ OLAP?

Đây là điểm dễ bị hỏi vì nhiều nhóm demo giao diện nhưng không hiểu bên dưới.

Bấm nút query thường là chạy một truy vấn/báo cáo cố định hoặc bán cố định. Người dùng chọn tham số, hệ thống sinh SQL/MDX/OLAP query rồi trả bảng kết quả.

Ví dụ:

• chọn tháng = 2025_03;
• chọn bang = Hà Nội;
• bấm “Tìm tồn kho”;
• hệ thống chạy truy vấn.

Tương tác trực tiếp trên biểu đồ OLAP là thao tác phân tích đa chiều động:

• click vào một cột để drill-down;
• kéo thả chiều;
• đổi trục;
• slice/dice trực tiếp;
• pivot từ Time x Location sang Item x Customer.

Bản chất cả hai đều truy xuất cube/fact/dimension, nhưng:

• query button: kịch bản cố định hơn;
• tương tác OLAP: người dùng điều hướng không gian đa chiều linh hoạt hơn.

Câu trả lời chuẩn:

“Bấm query là chạy truy vấn được lập trình sẵn theo tham số. Tương tác OLAP trên biểu đồ là thao tác động lên cube: drill, roll, slice, dice, pivot. Dữ liệu nền vẫn là các cube đã mapping với Fact và Dimension, nhưng mức linh hoạt và cách sinh truy vấn khác nhau.”

---

Phần 3 — Tóm tắt logic cốt lõi của báo cáo

3.1. Luồng dữ liệu tổng thể

Bước 1: Từ hai CSDL gốc

Đề bài cung cấp hai nguồn dữ liệu:

CSDL Văn phòng đại diện:

• Khách hàng
• Khách hàng du lịch
• Khách hàng bưu điện

CSDL Bán hàng:

• Văn phòng đại diện
• Cửa hàng
• Mặt hàng
• Mặt hàng được lưu trữ
• Đơn đặt hàng
• Mặt hàng được đặt (Bài tập lớn KDL (1).pdf)

Bước 2: Tích hợp vào IDB

Trong báo cáo, nhóm xử lý xung đột quan trọng nhất là xung đột thuộc tính “Thời gian”. Cùng tên “Thời gian” nhưng ý nghĩa khác nhau ở từng bảng:

• thời gian thành lập văn phòng;
• thời gian mở cửa cửa hàng;
• thời gian cập nhật mặt hàng;
• thời gian kiểm kê;
• thời gian đặt hàng;
• thời gian thêm khách hàng. (BTLKDL (1).pdf)

Đây là xử lý đúng về mặt tích hợp dữ liệu: cùng tên không có nghĩa cùng nghĩa. Nếu không đổi tên, metadata sẽ mơ hồ và ETL sang DW dễ sai.

IDB cũng giải quyết liên kết giữa hai nguồn:

• Khách hàng — Đơn đặt hàng qua MaKH
• Khách hàng — Văn phòng đại diện qua MaThanhPho
• Cửa hàng — Văn phòng đại diện qua MaThanhPho

Bước 3: Từ IDB sang DW

DW được thiết kế theo mô hình Fact Constellation gồm 2 Fact và 4 Dimension. Báo cáo nêu rõ mô hình này bao phủ hai nghiệp vụ chính: doanh số bán hàng và quản lý tồn kho. (BTLKDL (1).pdf)

Fact:

text
Fact_Sales
- MaThoiGian
- MaMH
- MaCuaHang
- MaKH
- SoLuongDat
- ThanhTien

Fact_Inventory
- MaThoiGian
- MaMH
- MaCuaHang
- SoLuongTon

Dimension:

text
Dim_Time
- MaThoiGian
- Thang
- Quy
- Nam

Dim_Item
- MaMH
- MoTa
- KichCo
- TrongLuong
- Gia

Dim_Location
- MaCuaHang
- MaThanhPho
- TenThanhPho
- DiaChiVP
- Bang
- ThoiGianThanhLap

Dim_Customer
- MaKH
- TenKH
- LoaiKH
- NgayDatHangDauTien

Câu tóm tắt để trả lời nhanh:

“Luồng dữ liệu của nhóm em là: hai CSDL nguồn được tích hợp vào IDB để giải quyết xung đột tên thuộc tính, đặc biệt là thuộc tính Thời gian, và thiết lập liên kết liên nguồn qua MaKH, MaThanhPho. Sau đó dữ liệu từ IDB được ETL sang DW theo mô hình Fact Constellation gồm Fact_Sales, Fact_Inventory và bốn chiều Dim_Time, Dim_Item, Dim_Location, Dim_Customer. Khi load Fact, nhóm em không copy giao dịch chi tiết mà tổng hợp theo grain tháng.”

---

3.2. SoLuongTon xử lý ETL thế nào để không cộng dồn sai?

Đây là câu chắc chắn nên chuẩn bị kỹ.

SoLuongTon là semi-additive measure. Báo cáo đã ghi rõ: SoLuongTon không cộng dồn theo thời gian, mà lấy số liệu chốt cuối tháng; không dùng SUM qua các tháng. (BTLKDL (1).pdf)

Tại sao?

Tồn kho là một snapshot tại thời điểm, không phải dòng phát sinh.

Ví dụ:

text
Ngày 01/03: tồn 100
Ngày 10/03: tồn 80
Ngày 31/03: tồn 70

Nếu cộng lại:

text
100 + 80 + 70 = 250

Số 250 là vô nghĩa. Tồn kho cuối tháng phải là 70.

Trong báo cáo, nhóm dùng logic Oracle:

sql
MAX(SoLuongTrongKho)
KEEP (DENSE_RANK LAST ORDER BY Thoi_Gian_Kiem_Ke)

Ý nghĩa:

• group theo tháng, mặt hàng, cửa hàng;
• trong mỗi nhóm, sắp xếp các lần kiểm kê theo thời gian;
• lấy bản ghi kiểm kê muộn nhất trong tháng;
• đưa SoLuongTrongKho của lần kiểm kê cuối cùng đó vào Fact_Inventory.

Điểm cần nói rõ: không dùng MAX(SoLuongTrongKho) thông thường, vì nó lấy số tồn lớn nhất, không phải số cuối kỳ. Báo cáo cũng đã cảnh báo đúng điểm này. (BTLKDL (1).pdf)

Câu trả lời chuẩn:

“SoLuongTon là semi-additive. Nhóm em không cộng tồn kho theo ngày/tháng. Khi ETL vào Fact_Inventory, nhóm em group theo MaThoiGian, MaMH, MaCuaHang và lấy số lượng tồn của lần kiểm kê cuối cùng trong tháng bằng KEEP DENSE_RANK LAST ORDER BY Thoi_Gian_Kiem_Ke. Như vậy số tồn là snapshot cuối kỳ, không bị cộng dồn sai.”

---

Các câu trả lời ngắn cần học thuộc

Hỏi: Vì sao Fact không có MaDon?
Vì grain của Fact_Sales là tháng — mặt hàng — cửa hàng — khách hàng, không phải đơn hàng. Đưa MaDon vào sẽ phá grain và biến Fact thành bảng giao dịch OLTP.

Hỏi: Vì sao không lưu GiaDat?
Vì GiaDat là đơn giá ở dòng giao dịch, không đại diện duy nhất cho dữ liệu đã tổng hợp theo tháng. Nó chỉ dùng trong ETL để tính ThanhTien = SUM(SoLuongDat * GiaDat).

Hỏi: PK của Fact là gì?
Fact_Sales: tổ hợp MaThoiGian, MaMH, MaCuaHang, MaKH.
Fact_Inventory: tổ hợp MaThoiGian, MaMH, MaCuaHang.

Hỏi: Vì sao Time chỉ tới tháng?
Vì grain của Fact là tháng. Nếu có ngày mà Fact không lưu theo ngày thì drill-down xuống ngày là sai hoặc giả.

Hỏi: Vì sao phải GROUP BY khi load DW?
Vì DW phục vụ phân tích theo grain tổng hợp. IDB giữ chi tiết; DW phải tổng hợp theo chiều và measure.

Hỏi: Metadata có mấy loại?
Ba loại: cấu trúc, nghiệp vụ, vận hành. Vận hành lưu log ETL để kiểm soát lineage, số dòng, trạng thái nạp.

Hỏi: B-Tree và Bitmap dùng thế nào?
B-Tree cho khóa PK/FK có cardinality cao, phục vụ join. Bitmap cho thuộc tính phân loại ít giá trị như LoaiKH, Bang, phục vụ lọc/gom nhóm OLAP.

Hỏi: OLAP drill-down móc vào đâu?
Móc vào cube đã mapping với Fact và Dimension. Drill/roll dựa trên hierarchy của Dimension và aggregate rule của measure.

Hỏi: SoLuongTon xử lý thế nào?
Là semi-additive, lấy snapshot cuối tháng bằng bản ghi kiểm kê muộn nhất, không SUM theo thời gian.

---

Nhận xét nghiêm khắc trước khi bảo vệ

Điểm mạnh của báo cáo là đã nêu được đúng các thành phần chính: IDB, DW, Fact Constellation, grain, measure additive/semi-additive, ETL tổng hợp, metadata, index và cube. Tuy nhiên khi bảo vệ, không được trả lời theo kiểu “vì trong báo cáo em làm vậy”. Phải luôn quay về 3 nguyên tắc:

1. Grain quyết định Fact lưu gì.
2. Measure quyết định hàm tổng hợp.
3. Hierarchy của Dimension quyết định drill-down/roll-up hợp lệ.

Chỉ cần bạn quên grain, giảng viên có thể đánh sập toàn bộ phần Fact, Time Dimension, ETL và Cube.