Dưới đây là bản ghi chú bảo vệ theo kiểu giảng viên hỏi xoáy — mình trả lời đúng trọng tâm. Bản này bám vào 3 nguồn: file cách tính điểm, báo cáo nhóm, và đề bài gốc môn Kho dữ liệu. (Cô hỏi bài tập lớn như thế nào.txt) (BTLKDL (1).pdf) (Bài tập lớn KDL (1).pdf)

---

PHẦN 1: RÀ SOÁT “CẠM BẪY” CHẤM ĐIỂM

1. Fact & Dimension: Vì sao “Mã đơn không bao giờ nằm trong bảng Fact”?

• Bản chất kỹ thuật:

  • Bảng Fact trong DW không phải bản sao bảng giao dịch OLTP.
  • Mã đơn là định danh chi tiết của một giao dịch cụ thể.
  • Trong bài này, grain của Fact_Sales không phải “mỗi dòng chi tiết đơn hàng”, mà là:
    • một mặt hàng
    • một khách hàng
    • một cửa hàng
    • một tháng
  • Vì vậy, nếu đưa MaDon vào Fact thì grain bị kéo về mức chi tiết đơn hàng, làm Fact giống OLTP.

• Câu trả lời khi cô hỏi:

  • “Thưa cô, nhóm em không đưa MaDon vào Fact_Sales vì Fact của nhóm em lưu dữ liệu đã tổng hợp theo Tháng – Khách hàng – Cửa hàng – Mặt hàng. Nếu đưa MaDon vào thì mỗi dòng Fact trở thành chi tiết từng đơn hàng, làm mất tính tổng hợp của kho dữ liệu.”

• Nhóm em đã giải quyết thế nào:

  • Trong mô hình DW của nhóm, Fact_Sales gồm:
    • khóa chiều: MaThoiGian, MaMH, MaCuaHang, MaKH
    • độ đo: SoLuongDat, ThanhTien
  • Không có MaDon trong Fact_Sales. Báo cáo cũng nêu khóa chính của Fact_Sales là tập hợp khóa ngoại đến 4 chiều. (BTLKDL (1).pdf)

• Cạm bẫy:

  • Không nói: “Vì không cần nên bỏ.”
  • Phải nói: “Vì grain của Fact đã tổng hợp, MaDon là chi tiết tác nghiệp, không phù hợp với DW.”

---

2. Vì sao “Giá đặt không cho vào bảng Fact”?

• Bản chất kỹ thuật:

  • GiaDat là giá tại từng dòng đặt hàng cụ thể.
  • Nếu lưu trực tiếp GiaDat trong Fact thì nó không phải độ đo tổng hợp tốt:
    • cộng giá đặt của nhiều đơn không có ý nghĩa;
    • trung bình giá đặt cũng không phải yêu cầu chính;
    • giá đặt gắn với từng transaction, không phải giá trị phân tích tổng hợp.
  • Trong DW, cái cần phân tích là:
    • SoLuongDat
    • ThanhTien = SUM(SoLuongDat * GiaDat)

• Cách nhóm em xử lý đúng:

  • Không đưa GiaDat như một cột độ đo độc lập trong Fact.
  • Dùng GiaDat ở nguồn IDB trong bước ETL để tính:
    • ThanhTien = SUM(SoLuongDat * GiaDat)
  • Sau đó chỉ lưu ThanhTien đã tổng hợp vào Fact_Sales. Báo cáo ghi rõ ThanhTien là độ đo cộng gộp, tính bằng SUM(SoLuongDat * GiaDat). (BTLKDL (1).pdf)

• Câu trả lời mẫu:

  • “Thưa cô, GiaDat chỉ được dùng trong ETL để tính ThanhTien, chứ không lưu riêng trong Fact. Vì giá đặt là dữ liệu chi tiết theo giao dịch, không mang ý nghĩa tổng hợp. Fact chỉ lưu các độ đo phục vụ phân tích như SoLuongDat và ThanhTien.”

---

3. Chiều thời gian: Vì sao “Chiều thời gian không có ngày”?

• Bản chất kỹ thuật:

  • Đề bài yêu cầu thiết lập chiều thời gian để phục vụ báo cáo OLAP. Nhưng theo ghi chú chấm điểm, cô nhấn mạnh: không đưa ngày vào chiều thời gian vì sẽ làm mô hình giống OLTP. (Cô hỏi bài tập lớn như thế nào.txt)
  • Trong bài của nhóm, grain thời gian là tháng, không phải ngày.
  • Dim_Time nên gồm:
    • MaThoiGian
    • Thang
    • Quy
    • Nam
  • Không nên trình bày chiều thời gian có cấp Ngày.

• Hạt nhân thời gian nhóm đang dùng:

  • Fact_Sales: tổng số lượng bán và doanh thu theo tháng.
  • Fact_Inventory: số tồn kho chốt cuối kỳ theo tháng.
  • MaThoiGian được tạo theo dạng YYYY_MM, ví dụ: 2025_03.

• Câu trả lời mẫu:

  • “Thưa cô, nhóm em không thiết kế cấp ngày trong Dim_Time vì kho dữ liệu cần dữ liệu tổng hợp. Nhóm em dùng grain thời gian là tháng, sau đó phân cấp lên Quý và Năm để phục vụ drill-down và roll-up.”

• Cạm bẫy cực nguy hiểm trong demo:

  • Trong báo cáo có ảnh danh sách cube xuất hiện tên dạng TIME_DAY. Khi bảo vệ, không được demo hoặc nhấn mạnh TIME_DAY.
  • Nếu cô hỏi, phải nói:
    • “Phần thiết kế chuẩn của nhóm em là Year → Quarter → Month. Nếu trong tên cube có chữ DAY thì đó là phần đặt tên/thừa khi sinh khối, nhóm em không sử dụng cấp ngày trong mô hình phân tích chính.”

---

4. Độ đo tồn kho: Semi-additive Measure — phần dễ mất điểm nhất

4.1. Semi-additive measure là gì?

• Semi-additive measure là độ đo bán cộng gộp:

  • cộng được theo một số chiều;
  • nhưng không cộng được theo chiều thời gian.

• Với SoLuongTon:

  • Có thể cộng theo:
    • mặt hàng
    • cửa hàng
    • thành phố
  • Nhưng không được cộng theo:
    • ngày
    • tháng
    • quý
    • năm

• Ví dụ dễ hiểu:

  • Ngày 1 tồn 100 cái.
  • Ngày 2 tồn 80 cái.
  • Ngày 3 tồn 60 cái.
  • Không được nói tồn tháng = 100 + 80 + 60 = 240.
  • Đúng phải lấy số tồn tại thời điểm chốt kỳ, ví dụ cuối tháng là 60.

---

4.2. Vì sao không dùng SUM cho tồn kho?

• SUM phù hợp với doanh số, số lượng bán, doanh thu.

• SUM không phù hợp với tồn kho theo thời gian vì tồn kho là snapshot tại một thời điểm.

• Nếu cộng tồn kho qua nhiều ngày hoặc nhiều tháng thì bị phóng đại số liệu.

• Câu trả lời mẫu:

  • “Thưa cô, SoLuongTon là độ đo bán cộng gộp. Nó không được cộng dồn theo thời gian. Khi phân tích theo tháng, nhóm em lấy số tồn ở lần kiểm kê cuối cùng của tháng, không cộng tất cả lần kiểm kê.”

---

4.3. Nhóm em mapping tồn kho bằng MAX() KEEP như thế nào?

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

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

• Ý nghĩa kỹ thuật:

  • ORDER BY Thoi_Gian_Kiem_Ke:
    • sắp xếp các lần kiểm kê trong tháng theo thời gian.
  • DENSE_RANK LAST:
    • lấy lần kiểm kê muộn nhất trong tháng.
  • MAX(SoLuongTrongKho) KEEP (...):
    • lấy số lượng tồn kho tại lần kiểm kê cuối cùng.
  • GROUP BY theo:
    • MaThoiGian
    • MaMH
    • MaCuaHang

• Vì sao không dùng MAX thông thường?

  • MAX(SoLuongTrongKho) thường chỉ lấy số tồn lớn nhất.
  • Nhưng số tồn lớn nhất không chắc là số tồn cuối kỳ.
  • Ví dụ:
    • Ngày 5 tồn 900.
    • Ngày 30 tồn 300.
    • MAX thường = 900, sai.
    • KEEP LAST ORDER BY Thoi_Gian_Kiem_Ke = 300, đúng.

• Báo cáo đã ghi rõ nhóm dùng MAX(...) KEEP (DENSE_RANK LAST ORDER BY Thoi_Gian_Kiem_Ke) để chốt số tồn ở lần kiểm kê muộn nhất của tháng. (BTLKDL (1).pdf)

---

4.4. Vì sao không đổ dữ liệu tồn kho theo ngày?

• Vì kho dữ liệu cần summary, không phải lưu chi tiết OLTP.

• Nếu đổ tồn kho từng ngày:

  • số dòng tăng mạnh;
  • khi roll-up tháng dễ bị cộng sai;
  • mô hình mất tính tổng hợp;
  • demo OLAP dễ bị cô bắt lỗi “giống OLTP”.

• Câu trả lời mẫu:

  • “Nhóm em không đổ tồn kho theo ngày vì bài yêu cầu kho dữ liệu mang tính tổng hợp. Với tồn kho, nhóm em chỉ lưu số tồn chốt cuối tháng. Dữ liệu nguồn có thể có nhiều lần kiểm kê, nhưng khi vào DW thì đã được tổng hợp theo tháng.”

---

5. Khóa chính của bảng Fact là gì?

• Định nghĩa đúng:

  • Khóa chính của bảng Fact là tổ hợp các khóa ngoại trỏ đến các Dimension tại đúng grain của Fact.
  • Một bảng Fact gồm:
    • các khóa chiều
    • các độ đo

• Fact_Sales:

  • Khóa chính nên là:
    • MaThoiGian
    • MaMH
    • MaCuaHang
    • MaKH
  • Độ đo:
    • SoLuongDat
    • ThanhTien

• Fact_Inventory:

  • Khóa chính nên là:
    • MaThoiGian
    • MaMH
    • MaCuaHang
  • Độ đo:
    • SoLuongTon

• Phân biệt khóa và độ đo:

  • Khóa trả lời câu hỏi: “Số liệu này thuộc thời gian nào, mặt hàng nào, cửa hàng nào, khách hàng nào?”
  • Độ đo trả lời câu hỏi: “Giá trị phân tích là bao nhiêu?”
  • MaKH, MaMH, MaCuaHang, MaThoiGian là tọa độ phân tích.
  • SoLuongDat, ThanhTien, SoLuongTon là số liệu phân tích.

• Câu trả lời mẫu:

  • “Thưa cô, khóa chính của Fact không phải là một mã đơn hay mã dòng giao dịch. Khóa chính là tổ hợp các khóa chiều. Với Fact_Sales, khóa chính là MaThoiGian + MaMH + MaCuaHang + MaKH. Các cột còn lại như SoLuongDat và ThanhTien là độ đo.”

---

PHẦN 2: SỔ TAY GIẢI THÍCH KIẾN THỨC KỸ THUẬT CỐT LÕI

1. Mô hình dữ liệu: Fact Constellation

• Nhóm dùng mô hình Fact Constellation, còn gọi là mô hình chòm sao.

• Mô hình có 2 bảng Fact:

  • Fact_Sales: phân tích bán hàng.
  • Fact_Inventory: phân tích tồn kho.

• Hai Fact dùng chung các chiều:

  • Dim_Time
  • Dim_Item
  • Dim_Location

• Riêng Fact_Sales có thêm:

  • Dim_Customer

• Báo cáo nêu rõ hệ thống được thiết kế theo Fact Constellation với hai Fact trọng tâm là fact_sales và fact_inventory, chia sẻ các Dimension chung. (BTLKDL (1).pdf)

• Câu trả lời mẫu:

  • “Nhóm em chọn Fact Constellation vì bài toán có hai tiến trình nghiệp vụ khác nhau: bán hàng và tồn kho. Hai tiến trình này dùng chung các chiều thời gian, mặt hàng, địa lý, nhưng có độ đo khác nhau nên không gộp vào một Fact.”

---

2. Tích hợp IDB: xử lý xung đột dữ liệu

2.1. Xung đột tên trường thời gian

• Trong hai CSDL nguồn, nhiều bảng đều có thuộc tính Thời gian.

• Nhưng mỗi Thời gian có nghĩa khác nhau:

  • Thoi_Gian_Thanh_Lap: thời gian thành lập văn phòng đại diện.
  • Thoi_Gian_Mo_Cua: thời gian mở cửa cửa hàng.
  • Thoi_Gian_Cap_Nhat: thời gian cập nhật mặt hàng.
  • Thoi_Gian_Kiem_Ke: thời gian kiểm kê tồn kho.
  • Thoi_Gian_Dat_Hang: thời gian đặt hàng.
  • Thoi_Gian_Them_KH: thời gian thêm khách hàng.

• Bản chất kỹ thuật:

  • Đây là xử lý xung đột đồng âm.
  • Cùng tên “Thời gian” nhưng khác nghĩa nghiệp vụ.
  • Nếu không đổi tên, IDB bị nhập nhằng, ETL về sau sai ngữ nghĩa.

• Câu trả lời mẫu:

  • “Trong bước tích hợp IDB, nhóm em xử lý xung đột đồng âm của thuộc tính Thời gian bằng cách đổi tên theo đúng nghĩa nghiệp vụ của từng bảng. Đây là bước bắt buộc để dữ liệu tích hợp không bị mơ hồ.”

---

2.2. Quan hệ Khách hàng ISA

• Đề bài có hai loại khách hàng:

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

• Một khách hàng có thể thuộc:

  • chỉ du lịch;
  • chỉ bưu điện;
  • hoặc cả hai.

• Nhóm thiết kế:

  • KHACH_HANG là supertype.
  • KH_DU_LICH và KH_BUU_DIEN là subtype.
  • Hai bảng con dùng MaKH vừa là khóa chính, vừa là khóa ngoại về bảng cha.

• Báo cáo mô tả rõ mô hình kế thừa khách hàng bằng bảng cha KHACH_HANG và hai bảng con KH_DU_LICH, KH_BUU_DIEN. (BTLKDL (1).pdf)

• Câu trả lời mẫu:

  • “Nhóm em dùng quan hệ ISA vì khách hàng có thuộc tính chung và thuộc tính riêng. KHACH_HANG lưu phần chung, còn KH_DU_LICH và KH_BUU_DIEN lưu phần riêng. Vì một khách hàng có thể thuộc cả hai loại nên khi ETL sang Dim_Customer, nhóm em dùng LEFT JOIN và CASE WHEN để phân loại.”

---

2.3. Cạm bẫy: Văn phòng đại diện phải nối với Khách hàng

• File cách tính điểm ghi rõ: Văn phòng đại diện không nối với khách hàng là sai. (Cô hỏi bài tập lớn như thế nào.txt)

• Vì đề bài nói:

  • mỗi khách hàng sống ở một thành phố;
  • mỗi thành phố có một văn phòng đại diện;
  • công ty ưu tiên đáp ứng đơn hàng từ kho ở thành phố khách hàng sinh sống.

• Câu trả lời mẫu:

  • “Nhóm em có nối Văn phòng đại diện với Khách hàng thông qua MaThanhPho, vì khách hàng sống tại một thành phố và văn phòng đại diện quản lý địa bàn thành phố đó.”

---

3. ETL: Vì sao sinh dữ liệu vào Fact chứ không sinh vào IDB?

• IDB là tầng tích hợp dữ liệu nguồn.

• DW/Fact là tầng phục vụ phân tích.

• Khi demo kho dữ liệu, cái cần đủ lớn là:

  • Fact_Sales
  • Fact_Inventory
  • các bảng Dimension

• File cách tính điểm nhấn mạnh: sinh thẳng vào bảng Fact, không cần sinh IDB và số lượng đơn hàng tối thiểu phải đủ lớn để đúng nghĩa warehouse. (Cô hỏi bài tập lớn như thế nào.txt)

• Bản chất kỹ thuật:

  • Nếu sinh vào IDB rồi mới ETL, mất thời gian và không chứng minh trực tiếp năng lực DW.
  • Demo cần chứng minh:
    • Fact có nhiều dòng;
    • Cube có dữ liệu;
    • OLAP chạy được;
    • drill-down/roll-up hoạt động.

• Nhóm em đã làm:

  • Sinh dữ liệu Dimension:
    • 72 mốc thời gian
    • 100 cửa hàng/văn phòng đại diện
    • 500 mặt hàng
    • 10.000 khách hàng
  • Sinh dữ liệu Fact:
    • mục tiêu 500.000 dòng Fact_Sales
    • 100.000 dòng Fact_Inventory
  • Báo cáo cũng nêu dùng stored procedure và commit định kỳ mỗi 10.000 dòng để tối ưu Oracle. (BTLKDL (1).pdf)

• Cảnh báo điểm trừ:

  • Ảnh báo cáo thể hiện Fact_Sales khoảng 499.999 dòng, trong khi ghi chú chấm điểm yêu cầu tối thiểu 500.000.
  • Trước khi demo, phải sửa để số dòng >= 500.000.
  • Khi cô hỏi, không nói “xấp xỉ 500.000”. Phải show count rõ ràng.

---

4. Metadata: có mấy loại và nhóm tạo bảng gì?

• Nhóm dùng 3 loại Metadata:

• Metadata cấu trúc

  • Mô tả cấu trúc DW:
    • Fact nào;
    • Dimension nào;
    • khóa nào;
    • quan hệ nào.
  • Ví dụ:
    • Fact_Sales có 4 chiều.
    • Fact_Inventory có 3 chiều.

• Metadata nghiệp vụ

  • Giải thích ý nghĩa nghiệp vụ của dữ liệu.
  • Ví dụ:
    • SoLuongTon là semi-additive measure.
    • ThanhTien là doanh thu tổng hợp.
    • Dim_Time dùng cấp Năm – Quý – Tháng.

• Metadata vận hành

  • Ghi log quá trình ETL.
  • Dùng để biết:
    • bảng nào được nạp;
    • nạp lúc nào;
    • số dòng bao nhiêu;
    • thành công hay lỗi.

• Báo cáo ghi rõ hệ thống lưu 3 loại metadata: cấu trúc, nghiệp vụ, và vận hành, trong đó metadata vận hành được lưu trực tiếp trên DBMS để theo dõi lịch sử ETL. (BTLKDL (1).pdf)

• Bảng nhóm đã tạo: ETL_METADATA_LOG

  • Mục đích:
    • lưu lịch sử ETL;
    • chứng minh trên máy là nhóm có metadata thật, không chỉ ghi lý thuyết.
  • Các trường nên trình bày:
    • LogID
    • TenBangDich
    • ThoiGianBatDau
    • ThoiGianKetThuc
    • SoDongCapNhat
    • TrangThai

• Câu trả lời mẫu:

  • “Nhóm em có 3 loại metadata: cấu trúc, nghiệp vụ, và vận hành. Trên máy, nhóm em tạo bảng ETL_METADATA_LOG để lưu metadata vận hành, ghi lại bảng đích, thời gian nạp, số dòng nạp và trạng thái ETL.”

---

5. Index: vì sao phải tạo file Index riêng?

• File cách tính điểm yêu cầu phải trả lời rõ:

  • dùng index loại nào;
  • bảng nào dùng index đó;
  • vì sao;
  • tại sao phải có file index riêng. (Cô hỏi bài tập lớn như thế nào.txt)

• Nhóm thiết kế 2 tablespace/file:

  • DATA_TBS: lưu dữ liệu bảng.
  • INDEX_TBS: lưu chỉ mục.
  • Báo cáo minh họa tạo file dữ liệu riêng cho tablespace data và index. (BTLKDL (1).pdf)

• Lý do kỹ thuật:

  • Truy vấn OLAP thường vừa đọc bảng Fact lớn, vừa đọc Index.
  • Nếu dữ liệu và index nằm chung một file vật lý:
    • dễ gây nghẽn I/O;
    • đầu đọc phải nhảy liên tục;
    • truy vấn chậm.
  • Tách riêng giúp:
    • quản lý tốt hơn;
    • giảm contention;
    • tăng hiệu năng khi truy vấn nhiều chiều.

• Câu trả lời mẫu:

  • “Nhóm em tách Index sang tablespace riêng để giảm nghẽn I/O khi Oracle vừa đọc dữ liệu Fact vừa đọc cây chỉ mục. Đây là cách tổ chức vật lý giúp truy vấn OLAP hiệu quả hơn.”

---

6. Phân biệt B-Tree Index và Bitmap Index

6.1. B-Tree Index

• Dùng cho:

  • khóa chính Dimension;
  • khóa ngoại trong Fact.

• Ví dụ:

  • MaKH
  • MaMH
  • MaCuaHang
  • MaThoiGian

• Lý do:

  • Các cột này có high cardinality.
  • Nhiều giá trị khác nhau.
  • B-Tree phù hợp cho:
    • tìm kiếm theo mã;
    • join Fact với Dimension;
    • lọc trên khóa.

• Câu trả lời mẫu:

  • “B-Tree dùng cho các cột khóa vì các cột này có độ phân biệt cao và thường tham gia join giữa Fact và Dimension.”

---

6.2. Bitmap Index

• Dùng cho cột low cardinality, tức ít giá trị phân loại.

• Nhóm dùng cho:

  • LoaiKH trong Dim_Customer
  • Bang trong Dim_Location

• Lý do:

  • LoaiKH chỉ có vài giá trị:
    • khách du lịch;
    • khách bưu điện;
    • cả hai.
  • Bang cũng là thuộc tính phân vùng/địa lý có số giá trị hữu hạn.
  • Bitmap rất nhanh với truy vấn OLAP dạng:
    • lọc theo loại khách;
    • lọc theo bang;
    • kết hợp nhiều điều kiện bằng AND/OR.

• Báo cáo giải thích B-Tree dùng cho PK/FK và Bitmap dùng cho cột low cardinality như LoaiKH và Bang. (BTLKDL (1).pdf)

• Câu trả lời mẫu:

  • “Bitmap Index phù hợp với các thuộc tính phân loại ít giá trị như LoaiKH và Bang. OLAP hay lọc và gom nhóm theo các thuộc tính này nên Bitmap giúp xử lý nhanh bằng phép toán bit.”

---

PHẦN 3: KỊCH BẢN DEMO THỰC CHIẾN

Mục tiêu demo

• Không demo lan man.
• Không chỉ mở SQL rồi query.
• Phải chứng minh được:
  • có Fact
  • có Dimension
  • có Cube
  • có Metadata
  • có Index
  • có Drill-down/Roll-up đúng OLAP
  • biết đang móc vào khối nào

File cách tính điểm nhấn mạnh: phải show được khối, phải nói rõ đang móc vào khối nào, drill-down thì móc vào khối nào; nếu chỉ bấm nút ngày/tháng/năm thì giống query thường, không được tính là demo OLAP chuẩn. (Cô hỏi bài tập lớn như thế nào.txt)

---

1. Bước 1 — Mở mô hình DW và nhắc grain

• Mở sơ đồ DW.

• Chỉ vào Fact_Sales:

  • “Đây là Fact bán hàng.”
  • “Grain: mặt hàng – khách hàng – cửa hàng – tháng.”
  • “Độ đo: SoLuongDat, ThanhTien.”
  • “Khóa chính: MaThoiGian + MaMH + MaCuaHang + MaKH.”

• Chỉ vào Fact_Inventory:

  • “Đây là Fact tồn kho.”
  • “Grain: mặt hàng – cửa hàng – tháng.”
  • “Độ đo: SoLuongTon.”
  • “SoLuongTon là semi-additive, không SUM theo thời gian.”

• Chỉ vào các Dimension:

  • Dim_Time
  • Dim_Item
  • Dim_Location
  • Dim_Customer

• Câu chốt:

  • “Mô hình của nhóm em là Fact Constellation, gồm 2 Fact chia sẻ các chiều chung.”

---

2. Bước 2 — Show dữ liệu lớn trong Fact

• Mở SQL Developer hoặc công cụ DB.

• Chạy/hiển thị số dòng:

  • Fact_Sales >= 500.000 dòng
  • Fact_Inventory khoảng 100.000 dòng
  • Dim_Time = 72 tháng
  • Dim_Item = 500 mặt hàng
  • Dim_Location = 100 cửa hàng
  • Dim_Customer = 10.000 khách hàng

• Câu nói khi demo:

  • “Dữ liệu được sinh trực tiếp vào các bảng Fact và Dimension của DW. Nhóm em không sinh vào IDB vì demo kho dữ liệu cần chứng minh Fact lớn và Cube có dữ liệu phân tích.”

• Cảnh báo:

  • Nếu máy đang hiện Fact_Sales = 499.999, phải sửa trước.
  • Không để cô nhìn thấy số này rồi hỏi “tối thiểu 500.000 đâu?”

---

3. Bước 3 — Show Cube trong Oracle AWM

• Mở Oracle Analytics Workspace Manager.

• Mở workspace:

  • CUBE_DW

• Expand:

  • Dimensions
    • CUSTOMER_DIM
    • ITEM_DIM
    • LOCATION_DIM
    • TIME_DIM
  • Cubes
    • SALES_CUBE
    • INVENTORY_CUBE

• Câu nói bắt buộc:

  • “Đây là tầng OLAP Server. Các khối đã được tạo sẵn từ Fact, không phải lúc demo mới query trực tiếp từ bảng giao dịch.”

• Với SALES_CUBE:

  • nói rõ:
    • nguồn: Fact_Sales
    • measures: SoLuongDat, ThanhTien
    • dimensions: Time, Item, Location, Customer

• Với INVENTORY_CUBE:

  • nói rõ:
    • nguồn: Fact_Inventory
    • measure: SoLuongTon
    • dimensions: Time, Item, Location
    • aggregation theo thời gian: không SUM, dùng số chốt cuối kỳ.

• Báo cáo có phần cài đặt khối OLAP bằng Oracle Analytics Workspace Manager, tạo dimension và mapping với bảng dimension trong DW. (BTLKDL (1).pdf)

---

4. Bước 4 — Show mapping Cube

• Trong AWM, mở mapping của SALES_CUBE.

• Chỉ vào:

  • Fact_Sales.SoLuongDat → measure SoLuongDat
  • Fact_Sales.ThanhTien → measure ThanhTien
  • Fact_Sales.MaThoiGian → Time Dimension
  • Fact_Sales.MaMH → Item Dimension
  • Fact_Sales.MaCuaHang → Location Dimension
  • Fact_Sales.MaKH → Customer Dimension

• Câu nói:

  • “Đây là mapping từ bảng Fact và Dimension ở DW lên Cube. Nghĩa là báo cáo OLAP đang đọc dữ liệu đã được tổ chức đa chiều.”

• Mở mapping của INVENTORY_CUBE.

• Chỉ vào:

  • Fact_Inventory.SoLuongTon → measure SoLuongTon
  • MaThoiGian → Time
  • MaMH → Item
  • MaCuaHang → Location

• Câu nói:

  • “Với tồn kho, nhóm em chỉ lấy số tồn cuối tháng. Measure này không cộng dồn theo thời gian.”

---

5. Bước 5 — Show Metadata trên hệ thống

• Mở bảng:

  • ETL_METADATA_LOG

• Show các cột:

  • TenBangDich
  • ThoiGianBatDau
  • ThoiGianKetThuc
  • SoDongCapNhat
  • TrangThai

• Câu nói:

  • “Đây là Operational Metadata. Nó ghi lại quá trình ETL: bảng nào được nạp, thời gian nạp, số dòng nạp và trạng thái thành công/thất bại.”

• Nếu cô hỏi “có mấy loại metadata?”:

  • trả lời ngay:
    • “Có 3 loại: metadata cấu trúc, metadata nghiệp vụ, và metadata vận hành.”

• Nếu cô hỏi “metadata nghiệp vụ của SoLuongTon là gì?”:

  • trả lời:
    • “SoLuongTon là semi-additive measure, chỉ lấy số tồn chốt cuối kỳ, không cộng dồn theo thời gian.”

---

6. Bước 6 — Show Index và file Index riêng

• Mở phần storage/tablespace hoặc chạy truy vấn hiển thị:

  • DATA_TBS
  • INDEX_TBS

• Chỉ rõ:

  • bảng nằm ở DATA_TBS
  • index nằm ở INDEX_TBS

• Show danh sách index:

  • B-Tree index trên khóa:
    • MaThoiGian
    • MaMH
    • MaCuaHang
    • MaKH
  • Bitmap index trên:
    • Dim_Customer.LoaiKH
    • Dim_Location.Bang

• Câu nói:

  • “Nhóm em dùng B-Tree Index cho các khóa vì các khóa có độ phân biệt cao và phục vụ join. Nhóm em dùng Bitmap Index cho LoaiKH và Bang vì đây là các thuộc tính phân loại ít giá trị, rất phù hợp với truy vấn OLAP.”

• Nếu cô hỏi “tại sao phải tạo file Index riêng?”:

  • trả lời:
    • “Để giảm nghẽn I/O khi Oracle vừa đọc bảng Fact lớn vừa đọc Index. Tách index sang tablespace riêng giúp quản trị và truy vấn OLAP hiệu quả hơn.”

---

7. Bước 7 — Demo Drill-down đúng chuẩn OLAP

Kịch bản tốt nhất: Drill-down doanh thu từ Năm → Quý → Tháng

• Mở biểu đồ doanh thu từ SALES_CUBE.

• Chọn:

  • Measure: ThanhTien
  • Time level ban đầu: Nam
  • Có thể để Location ở mức Bang
  • Item và Customer để All

• Câu nói trước khi bấm:

  • “Hiện tại em đang móc vào SALES_CUBE, measure là ThanhTien, chiều thời gian đang ở cấp Năm.”

• Trên biểu đồ:

  • bấm trực tiếp vào một cột năm, ví dụ 2024.
  • hệ thống bung xuống:
    • Quý
    • hoặc Tháng, tùy cấu hình hierarchy.

• Câu nói sau khi bấm:

  • “Đây là thao tác Drill-down. Em không chạy SQL query mới, mà đang đi xuống cấp thấp hơn trong Time hierarchy của Cube: từ Năm xuống Quý/Tháng.”

• Nếu dùng các cube materialized 2D/3D đã tạo sẵn, nói rõ:

  • “Mức tổng quan đang đọc khối theo TIME_NAM. Khi drill xuống tháng, hệ thống đọc khối chi tiết hơn theo TIME_THANG trong cùng logic OLAP.”

• Câu cấm nói:

  • Không nói: “Em bấm nút tháng để query.”
  • Phải nói: “Em drill-down trực tiếp trên biểu đồ theo phân cấp thời gian.”

---

8. Bước 8 — Demo Roll-up đúng chuẩn OLAP

• Đang ở biểu đồ cấp Tháng.

• Bấm breadcrumb hoặc thao tác quay lên cấp Quý/Năm.

• Câu nói:

  • “Đây là Roll-up, tức cuộn lên từ cấp chi tiết Tháng về cấp tổng hợp Quý/Năm.”

• Nhấn mạnh:

  • Với Fact_Sales:
    • roll-up dùng SUM cho ThanhTien và SoLuongDat.
  • Với Fact_Inventory:
    • không roll-up bằng SUM theo thời gian.
    • phải dùng số tồn cuối kỳ hoặc logic LAST/MAX KEEP.

• Câu trả lời nếu cô hỏi “Roll-up tồn kho thế nào?”:

  • “Với tồn kho, roll-up theo thời gian không cộng các tháng lại. Nếu xem tồn kho theo quý hoặc năm, phải lấy số tồn tại kỳ cuối cùng phù hợp, vì SoLuongTon là semi-additive.”

---

9. Bước 9 — Demo Slice/Dice/Pivot ngắn gọn

Slice

• Chọn một lát dữ liệu:
  • Bang = Hà Nội
  • hoặc LoaiKH = Khách du lịch
• Câu nói:
  • “Đây là Slice, em cố định một chiều để xem lát dữ liệu tương ứng.”

Dice

• Chọn nhiều điều kiện:
  • Bang = Hà Nội
  • Nam = 2025
  • LoaiKH = Khách bưu điện
• Câu nói:
  • “Đây là Dice, em lọc đồng thời nhiều chiều để lấy một khối con.”

Pivot

• Đổi trục biểu đồ:
  • trục X từ Thời gian sang Bang
  • series từ Bang sang LoaiKH
• Câu nói:
  • “Đây là Pivot, em xoay chiều phân tích để nhìn cùng một measure dưới góc nhìn khác.”

---

10. Bước 10 — Chốt demo bằng 3 câu ăn điểm

• Câu 1:

  • “Mô hình của nhóm em là Fact Constellation, gồm Fact_Sales và Fact_Inventory, dùng chung các chiều Time, Item, Location.”

• Câu 2:

  • “Fact của nhóm em không lưu chi tiết OLTP như MaDon hay GiaDat; Fact chỉ lưu khóa chiều và độ đo tổng hợp theo grain đã xác định.”

• Câu 3:

  • “Riêng SoLuongTon là semi-additive measure, nên nhóm em không SUM theo thời gian mà dùng logic lấy số tồn chốt cuối kỳ bằng MAX KEEP DENSE_RANK LAST.”

---

DANH SÁCH CÂU HỎI CÔ CÓ THỂ HỎI VÀ CÂU TRẢ LỜI NHANH

“Fact của em gồm những gì?”

• “Fact gồm khóa chiều và độ đo. Ví dụ Fact_Sales gồm khóa MaThoiGian, MaMH, MaCuaHang, MaKH và độ đo SoLuongDat, ThanhTien.”

“Khóa chính Fact là gì?”

• “Là tổ hợp các khóa chiều. Với Fact_Sales là MaThoiGian + MaMH + MaCuaHang + MaKH. Với Fact_Inventory là MaThoiGian + MaMH + MaCuaHang.”

“Tại sao không có mã đơn?”

• “Vì mã đơn là chi tiết giao dịch OLTP. Grain của Fact đã là tổng hợp theo tháng, khách hàng, cửa hàng, mặt hàng.”

“Tại sao không lưu giá đặt?”

• “Vì giá đặt là dữ liệu chi tiết theo giao dịch, không phải độ đo tổng hợp. Nhóm em dùng nó trong ETL để tính ThanhTien, rồi lưu ThanhTien vào Fact.”

“Tồn kho có cộng theo tháng được không?”

• “Không. SoLuongTon là semi-additive, không SUM theo thời gian. Phải lấy số tồn chốt cuối kỳ.”

“Metadata có mấy loại?”

• “Có 3 loại: cấu trúc, nghiệp vụ, vận hành. Nhóm em có bảng ETL_METADATA_LOG để lưu metadata vận hành.”

“Bitmap Index dùng ở đâu?”

• “Dùng cho cột ít giá trị phân loại như LoaiKH và Bang.”

“B-Tree Index dùng ở đâu?”

• “Dùng cho khóa chính, khóa ngoại, các cột có độ phân biệt cao như MaKH, MaMH, MaCuaHang, MaThoiGian.”

“Drill-down khác query SQL thế nào?”

• “Drill-down là đi xuống cấp thấp hơn trong hierarchy của Cube, ví dụ Năm → Quý → Tháng, thao tác trực tiếp trên biểu đồ hoặc OLAP viewer. Query SQL chỉ là chạy lại câu lệnh lọc/gom nhóm, không chứng minh được khai thác khối OLAP.”