ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC KINH TẾ - LUẬT

______________________

BÁO CÁO GIỮA KỲ

HỌC PHẦN: NHÀ KHO DỮ LIỆU VÀ TÍCH HỢP

CHỦ ĐỀ: MÔ HÌNH DỮ LIỆU KHÁI NIỆM, MÔ

HÌNH DỮ LIỆU LOGIC VÀ MÔ HÌNH DỮ LIỆU
VẬT LÝ

Giảng viên hướng dẫn: Nhóm 3:

TS. Lê Bá Thiền K224161812 - Phạm Thị Thúy Hằng
K224161816 - Thái Khắc Hiếu
K224161832 - Huỳnh Lê Đông Quân
K224161840 - Thái Thị Ngọc Tuyền
K224161846 - Lê Hoàng Yến

Thành phố Hồ Chí Minh, ngày 11 tháng 7 năm 2024

 MỤC LỤC
I. Mô hình dữ liệu khái niệm (Conceptual Data Model) .................................................2
1.1. Giới thiệu Mô hình dữ liệu khái niệm ............................................................... 2
1.2. Ứng dụng của Mô hình dữ liệu khái niệm .........................................................2
II. Mô hình dữ liệu logic (Logical Data Model) ..............................................................2
2.1. Giới thiệu Mô hình dữ liệu logic ....................................................................... 2
2.2. Thiết kế Mô hình dữ liệu logic .......................................................................... 3
2.2.1. Giới thiệu lược đồ .................................................................................... 3
2.2.2. Lược đồ 3NF ........................................................................................... 3
2.2.3. Lược đồ hình sao (Star Schema) .............................................................4
2.2.4. Lược đồ hình bông tuyết (Snowflake Schema) ....................................... 6
2.3. Các đối tượng trong Mô hình chiều dữ liệu ...................................................... 6
2.3.1. Fact table .................................................................................................. 6
2.3.2. Dimension table ....................................................................................... 7
2.4. Các khái niệm thiết kế trong mô hình chiều ......................................................8
2.4.1. Thao tác vơi nhiều lược đồ hình sao ........................................................8
2.4.2. Data Grain ................................................................................................ 9
2.4.3. Embedded Hierarchy ................................................................................9
2.4.4. Degenerate Dimensions ......................................................................... 10
2.4.5. Junk Dimension ......................................................................................11
2.4.6. Factless Fact Tables ............................................................................... 11
2.5. Bốn bước thiết kế mô hình chiều dữ liệu ........................................................ 13
III. Mô hình dữ liệu vật lý (Physical Data Model) ........................................................14
3.1. Chuyển từ Logical qua Physical Design ......................................................... 14
3.2. Physical Design Structures .............................................................................. 14
3.2.1. Tablespaces ............................................................................................ 14
3.2.2. Tables and Partitioned Tables ................................................................15
3.2.3. Views ......................................................................................................16
3.2.4. Integrity Constraints ...............................................................................17
IV. So sánh Mô hình khái niệm, Mô hình logic và Mô hình vật lý .............................. 21
TÀI LIỆU THAM KHẢO ............................................................................................. 22

1
I. Mô hình dữ liệu khái niệm (Conceptual Data Model)
1.1. Giới thiệu Mô hình dữ liệu khái niệm
Khái niệm: Mô hình dữ liệu khái niệm cung cấp cái nhìn tổng thể về toàn bộ
nhà kho dữ liệu và mô tả các đối tượng chính, không đi vào chi tiết.
Phương pháp: Mô hình E-R - mô tả cấu trúc và các ràng buộc của cơ sở dữ
liệu mà không phụ thuộc vào phần mềm (chẳng hạn như hệ quản trị cơ sở dữ liệu)
Các thành phần chính của mô hình dữ liệu khái niệm:
Các thực thể (Entities) là các đối tượng hoặc khái niệm đại diện cho một cái gì
đó có ý nghĩa đối với tổ chức như Customers / Orders / Products.
Mối quan hệ (Relationship) mô tả cách các thực thể khác nhau tương tác với
nhau bao gồm: 1:1, 1:Many, Many:Many.
Quy tắc nghiệp vụ (Business Rules) xác định các điều kiện hoặc ràng buộc chi
phối tính toàn vẹn của dữ liệu và mối quan hệ giữa các thực thể. Ví dụ như “Một đơn
hàng phải bao gồm ít nhất một sản phẩm để có hiệu lực”, “Không thể đặt hàng nếu
mức tồn kho của sản phẩm là 0”.
1.2. Ứng dụng của Mô hình dữ liệu khái niệm
Mô hình khái niệm được sử dụng khi lập kế hoạch sơ bộ, với mục đích làm rõ
các các yêu cầu và quy tắc nghiệp vụ về data của các stakeholders.
Mô hình khái niệm được tạo bởi các kiến ​ ​ trúc sư dữ liệu và các
stakeholders nhằm cung cấp cho các stakeholders một bức ảnh toàn cảnh dễ hiểu về
các khái niệm hoặc thực thể có liên quan và mối quan hệ giữa chúng.

II. Mô hình dữ liệu logic (Logical Data Model)

2.1. Giới thiệu Mô hình dữ liệu logic
Mô hình dữ liệu Logic (Logical Data Model) là một mô hình dữ liệu ở mức
trừu tượng, mô tả cấu trúc dữ liệu và các mối quan hệ logic giữa các đối tượng. Có thể
nói mô hình dữ liệu logic là phiên bản tinh vi hơn của mô hình khái niệm (Conceptual

2
Data Model). Còn mô hình dữ liệu vật lý (Physical Data Model) lại tiếp tục được xây
dựng cải tiến thêm dựa trên mô hình dữ liệu logic, nhưng được bổ sung vào các chi
tiết cụ thể về cách dữ liệu được triển khai như thế nào trong hệ quản trị cơ sở dữ liệu
và tối ưu hóa để nâng cao hiệu suất hệ thống.
Mô hình dữ liệu này tập trung xác định các loại thông tin cần thiết, cách tổ
chức dữ liệu mà không đi sâu vào các chi tiết về cách dữ liệu sẽ được lưu trữ, cách cài
đặt, triển khai cơ sở dữ liệu vật lý.
Mô hình dữ liệu logic có thể được sử dụng để thể hiện chính xác các yêu cầu
bằng ngôn ngữ kỹ thuật, giúp đảm bảo rằng cấu trúc dữ liệu phù hợp với mục tiêu
kinh doanh và kỹ thuật của hệ thống. Trong quá trình xây dựng mô hình dữ liệu, có
hai kỹ thuật phổ biến thường được áp dụng:
Mô hình ER (Entity-Relationship Model)
Mô hình ER tập trung vào việc làm rõ các đơn vị thông tin như các thực thể,
thuộc tính và các mối quan hệ giữa các thực thể. Mô hình này thường liên quan đến
các mô hình được chuẩn hóa cao như các ứng dụng OLTP (xử lý giao dịch trực tuyến).
Mô hình chiều dữ liệu (Dimensional model)
Mô hình dữ liệu chiều xác định thông tin nào thuộc về bảng sự kiện trung tâm
(bảng Fact) và thông tin nào thuộc về các bảng chiều liên kết với nó (bảng Dim). Mô
hình này sẽ phù hợp hơn với mô hình ER với yêu cầu phân tích và tối ưu hóa truy vấn
trong kho dữ liệu (Data warehouse).

2.2. Thiết kế Mô hình dữ liệu logic

2.2.1. Giới thiệu lược đồ
Lược đồ (Schema) là tập hợp các đối tượng cơ sở dữ liệu, bao gồm bảng
(tables), chế độ xem (views), chỉ mục (indexes) và đối tượng đồng dạng (synonyms).
Các đối tượng trong lược đồ có thể được tổ chức theo nhiều cách khác nhau, tạo thành
các loại lược đồ khác nhau như: Third Normal Form (3NF), Star Schema, Snowflake
Schema, Hybrid Schema,...
Ngoài dựa vào yêu cầu từ phía người dùng, các lược đồ cũng có thể được thiết
kế dựa vào mô hình dữ liệu nguồn. Ví dụ như có thể lấy mô hình dữ liệu nguồn của
doanh nghiệp A và thiết kế ngược mô hình dữ liệu logic cho kho dữ liệu.
2.2.2. Lược đồ 3NF
Chuẩn hóa (Normalization) là một quy trình thiết kế cơ sở dữ liệu nhằm đảm
bảo rằng mỗi dữ liệu chỉ được lưu trữ tại một vị trí duy nhất, giúp giảm thiểu sự dư
thừa và duy trì tính toàn vẹn của dữ liệu. Quá trình chuẩn hóa có nhiều cấp độ, với ba
cấp độ chuẩn hóa đầu tiên là:
- Dạng chuẩn hóa thứ nhất (1NF): Không có nhóm dữ liệu lặp lại và không có
các hàng trùng lặp, đồng thời mỗi bảng phải có một khóa chính.
- Dạng chuẩn hóa thứ hai (2NF): Đáp ứng 1NF và mọi cột không khóa đều phải
phụ thuộc hoàn toàn vào khóa chính.

3
 - Dạng chuẩn hóa thứ ba (3NF): Đáp ứng 2NF và không có sự phụ thuộc bắc
cầu giữa các thuộc tính không khóa.
Thiết kế mô hình ở dạng chuẩn thứ ba (3NF) giúp giảm thiểu sự dư thừa dữ liệu
và ngăn ngừa các vấn đề khi chèn, cập nhật, và xóa dữ liệu. Mô hình này với ưu điểm
đáp ứng được yêu cầu hiệu suất cao, xử lý nhanh chóng và chính xác, đã được sử dụng
từ lâu trong các hệ thống OLTP (xử lý giao dịch trực tuyến).
Lược đồ 3NF có tính linh hoạt cao, cho phép mở rộng hệ thống dễ dàng bằng
cách thêm bảng mà không ảnh hưởng đến các quy trình hiện tại. Tuy nhiên, điều này
cũng có thể gây khó khăn trong kho dữ liệu khi phải thao tác với nhiều bảng. Vì khi
đối với những truy vấn đơn giản, lược đồ này cũng cần phải thực hiện nhiều phép join,
dẫn đến hiệu suất truy vấn giảm.
Một số khái niệm và lưu ý quan trọng ở quy trình thiết kế lược đồ 3NF trong
kho dữ liệu bao gồm:
Khóa chính (Primary Keys)
Thuộc tính xác định duy nhất một bản ghi trong bảng. Vì truy vấn thường phải
kết nối nhiều bảng, cần chọn khóa chính cẩn thận để đảm bảo không bị trùng lặp dữ
liệu. Nên chọn ít thuộc tính nhất có thể, tốt nhất là 1 hoặc 2. Nếu không có thuộc tính
nào phù hợp làm khóa chính, cần kết hợp nhiều thuộc tính lại với nhau. Trong trường
hợp này, nếu dữ liệu thay đổi thường xuyên, việc sử dụng khóa thay thế (surrogate
key) như ID là giải pháp tốt nhất.
Khóa ngoại (Foreign Key Relationships)
Các mối quan hệ khóa chính - khóa ngoại thể hiện sự tương quan logic giữa các
thực thể dữ liệu. Mặc dù các ràng buộc khóa ngoại luôn được thực thi trong hệ thống
OLTP, nhưng trong kho dữ liệu, các ràng buộc này thường chỉ mang tính chất khai
báo và không được thực thi, dựa vào quy trình ETL để đảm bảo tính nhất quán của dữ
liệu. Điều này giúp tối ưu hóa truy vấn tốt hơn, vì không phải kiểm tra các ràng buộc
khóa ngoại trong lúc truy vấn.
Phi chuẩn hóa (Denormalization)
Mặc dù chuẩn hóa giúp bảo toàn tính linh hoạt và khả năng mở rộng, nhưng
trong một số trường hợp, quá trình phi chuẩn hóa sẽ được ưu tiên thực hiện để giảm
bớt gánh nặng cho nhà phát triển và hệ thống cơ sở dữ liệu, đặc biệt khi các khối
thông tin đó được sử dụng cùng nhau và được nâng cấp thường xuyên. Tuy nhiên, cần
thận trọng khi thực hiện quy trình phi chuẩn hóa vật lý để đảm bảo tính trung lập của
dữ liệu, có thể duy trì tính linh hoạt cho hệ thống và tránh làm mất khả năng mở rộng
hoặc dữ liệu bị thay đổi dễ dàng.
2.2.3. Lược đồ hình sao (Star Schema)
Lược đồ hình sao (Star Schema) là một lược đồ phổ biến nhất để thiết kế quy
trình mô hình hóa trong kho dữ liệu. Lược đồ này được gọi là Lược đồ sao vì sơ đồ
của nó trông giống một ngôi sao, với các điểm tỏa ra từ một bảng trung tâm. Mỗi lược
đồ sao được xem như một nhà kho dữ liệu con, tập trung vào một lĩnh vực cụ thể.

4
 Mục tiêu của lược đồ hình sao là tối ưu hóa hiệu suất bằng cách giữ cho các
truy vấn trở nên đơn giản và có thể cung cấp thời gian phản hồi nhanh. Toàn bộ thông
tin liên quan đến từng mức độ được lưu trữ trong một hàng duy nhất trong bảng. Vì
vậy, lược đồ hình sao chấp nhận sự dư thừa dữ liệu (phi chuẩn hóa) trong các bảng
chiều (dimension).
Trong lược đồ hình sao, dữ liệu được chia thành hai phần chính:
- Fact (Bảng sự kiện): Là các phép đo của một sự kiện nào đó, chẳng hạn như
một giao dịch bán hàng. Các sự kiện này thường được biểu diễn bằng các con số, ví
dụ như Số lượng bán (Quantity Sold), Giá bán (Unit Price),...
- Dimension (Bảng chiều): Là các danh mục để xác định sự kiện, chẳng hạn
như ngày, địa điểm, và sản phẩm.
Trong lược đồ này, mỗi bảng chiều chỉ kết nối trực tiếp với một bảng sự kiện,
làm cho cấu trúc dữ liệu trở nên đơn giản và giảm số lượng phép join khi truy vấn.
Điều này giúp tối ưu hóa tốc độ và hiệu suất của hệ thống, đặc biệt trong các kho dữ
liệu lớn.

Hình ..: Ví dụ về lược đồ hình sao (nguồn: Viblo)

So với thiết kế dạng chuẩn thứ ba (3NF), số lượng bảng trong mô hình
dimensional chỉ là một phần rất nhỏ. Mặc dù star schema thường bị đánh giá là hạn
chế sự linh hoạt trong phân tích so với các thiết kế 3NF, điều này không hoàn toàn
chính xác. Bởi vì một mô hình dimensional được thiết kế tốt là mô hình có thể mở
rộng được để cho phép các kiểu phân tích mới, và Star Schemas đã được chứng minh
là hiệu quả trong các doanh nghiệp lớn trong nhiều năm qua.
Trên thực tế, cả hai kỹ thuật thường được sử dụng cùng nhau trong mô hình
lược đồ lai (hybrid schema model). Star schema cung cấp một lớp nền tảng 3NF để

5
lưu trữ, nhằm giảm thiểu sự dư thừa và đảm bảo tính nhất quán của dữ liệu. Lớp nền
tảng này hoạt động như phần dữ liệu cốt lõi, trong khi star schemas giúp tổ chức dữ
liệu, dễ dàng truy vấn và phân tích, đóng vai trò là phần trung tâm của lớp tối ưu hóa
hiệu suất và truy cập.
2.2.4. Lược đồ hình bông tuyết (Snowflake Schema)
Lược đồ hình bông tuyết là loại lược đồ phức tạp hơn lược đồ hình sao nhưng
lược đồ này được coi là một loại biến thể của lược đồ hình sao. Một lược đồ có thể
được gọi là “Snowflake Schema” nếu lược đồ đó có một hoặc nhiều bảng Dimension
không kết nối trực tiếp với bảng Fact mà phải kết nối thông qua các bảng Dimension
khác.
Lược đồ Snowflake chuẩn hóa các bảng Dimension để loại bỏ sự dư thừa, có
nghĩa là dữ liệu của Dimension được chia thành nhiều bảng nhỏ thay vì gom chung
vào một bảng lớn. Điều này giúp tiết kiệm không gian lưu trữ, giảm lượng dữ liệu
trùng lặp và tăng cường tính nhất quán của dữ liệu. Tuy nhiên, nó cũng làm tăng số
lượng bảng Dimension và yêu cầu thêm nhiều khóa chính (PK). Do đó, các truy vấn
trở nên phức tạp hơn vì cần nhiều phép nối (joins) hơn, dẫn đến giảm hiệu suất thời
gian truy vấn.
Sơ đồ Snowflake cung cấp một cấu trúc dữ liệu chuẩn hóa cao và chi tiết, phù
hợp với các ứng dụng đòi hỏi mức độ chính xác và tính nhất quán cao của dữ liệu,
cũng như khi cần lưu trữ dữ liệu với độ chi tiết và phức tạp lớn.

Hình ..: Ví dụ về lược đồ hình bông tuyết (nguồn: Viblo)

2.3. Các đối tượng trong Mô hình chiều dữ liệu

2.3.1. Fact table

6
 Fact tables lưu trữ các phép đo trong kinh doanh có thể phân tích và kiểm tra,
thường là số liệu có thể cộng được. Một bảng Fact thường có hai loại cột chính: cột
chứa số liệu (còn gọi là measurements) và cột là khóa ngoại (foreign keys) liên kết
đến các bảng Dimensions.
Các bảng fact thường có nhiều hàng nhưng không có quá nhiều cột, chứa dữ
liệu ở cấp độ chi tiết hoặc đã được tổng hợp dưới dạng bảng (summary tables). Đối
với các bảng tổng hợp, dữ liệu thường có cùng mức độ tổng hợp. Bảng fact là những
bảng lớn nhất trong mô hình kho dữ liệu, trong đó với nhiều Star Schema, bảng fact
chiếm hơn 90% dung lượng lưu trữ.
Có ba loại số liệu chính trong bảng fact:
- Additive (có thể cộng): Loại phổ biến nhất, có thể cộng qua bất kỳ chiều nào.
Ví dụ: doanh số bán hàng có thể cộng doanh thu từ nhiều cửa hàng hoặc nhiều ngày
để có tổng doanh thu.
- Non-additive (không thể cộng): Không thể cộng được. Ví dụ: trung bình của
các nhóm không thể cộng lại để tính trung bình tổng thể.
- Semi-additive (bán cộng): Có thể cộng qua một số chiều, nhưng không thể
cộng qua các chiều khác. Ví dụ: lượng tồn kho có thể cộng lại theo nhiều kho, nhưng
không thể cộng qua thời gian vì hàng tồn của ngày này không thể cộng với ngày khác.
Có ba cách chính để thêm hàng vào bảng fact tạo nên ba loại bảng fact:
- Transaction-based (theo giao dịch): Ghi lại dữ liệu cho từng giao dịch riêng lẻ
ở mức chi tiết nhất. Mỗi khi có giao dịch xảy ra, một hàng mới sẽ được thêm vào bảng
fact. Đây là loại phổ biến nhất. Ví dụ: mỗi lần khách hàng mua sản phẩm, một hàng
mới được thêm vào với thông tin chi tiết về giao dịch.
- Periodic snapshot (chụp nhanh định kỳ): Ghi lại dữ liệu vào các thời điểm cố
định như cuối ngày, tuần hoặc tháng. Dữ liệu sẽ được ghi lại ngay cả khi không có
giao dịch mới, rất phù hợp cho các quy trình kinh doanh phức tạp. Ví dụ: bảng ghi lại
số liệu bán hàng hàng tháng như doanh thu, chi phí, lợi nhuận.
- Accumulating snapshot (chụp nhanh tích lũy): Theo dõi một quy trình ngắn
hạn, ghi lại các mốc quan trọng trong quy trình và cập nhật hàng nhiều lần khi tiến
trình diễn ra. Ví dụ: quy trình mua hàng với các mốc như "đơn hàng được tạo", "đơn
hàng được giao" và "hóa đơn thanh toán". Mỗi khi tiến trình đạt đến một mốc mới,
hàng tương ứng sẽ được cập nhật.
2.3.2. Dimension table
Bảng Dimension chứa thông tin ngữ cảnh cho dữ liệu cho bảng Fact và thường
là các dữ liệu dạng văn bản mang tính mô tả chi tiết. Ví dụ đối với dữ liệu về tiếp thị,
các bảng dimension có thể bao gồm thông tin về thời gian, khu vực tiếp thị, và sản
phẩm. Các thuộc tính của dimension giúp mô tả các giá trị dữ liệu trong ngữ cảnh này.
Bảng Dimension hoạt động như các bảng tra cứu (lookup tables) hoặc bảng
tham chiếu (reference tables) cho phép người dùng chọn các giá trị để giới hạn các
truy vấn. Ví dụ khi truy vấn doanh thu theo địa điểm hoặc loại hàng hóa, người dùng

7
tương tác chủ yếu với các bảng dimension, trong khi bảng fact chỉ cung cấp các số
liệu cần thiết.
So với bảng Fact, bảng Dimension thường có ít hàng hơn nhưng lại có nhiều
cột hơn. Một yếu tố quan trọng của bảng Dimension là sự tồn tại của hệ thống phân
cấp (hierarchy). Hệ thống này có dữ liệu được thu thập ở mức chi tiết thấp nhất, sau
đó có thể được tổng hợp thành các tổng số cấp cao hơn. Điều này giúp việc phân tích
dễ dàng và đáng tin cậy hơn. Ví dụ, bảng Dimension "địa điểm" có thể chứa các cột
cho địa chỉ, mã bưu điện, thành phố, bang, và quốc gia. Nhờ vậy, khi muốn truy vấn
doanh thu của thành phố Hồ Chí Minh (10 cửa hàng), người dùng không cần phải chỉ
định từng cửa hàng cụ thể trong thành phố đó.
Một bảng Dimension có thể được thể hiện bằng nhiều hệ thống phân cấp. Ví dụ:
- Phân cấp danh mục sản phẩm (Product Category Hierarchy): Sản phẩm →
Danh mục phụ sản phẩm (smartphones) → Danh mục chính (điện tử).
- Phân cấp nhà cung cấp (Supplier Hierarchy): Sản phẩm → Nhà cung cấp →
Khu vực nhà cung cấp (sản phẩm cụ thể → nhà cung cấp → quốc gia nhà cung cấp).
Các công cụ truy vấn sử dụng các hệ thống phân cấp này để cho phép người
dùng phân tích sâu hoặc tổng hợp dữ liệu ở các mức độ chi tiết khác nhau, tạo nên một
trong những lợi ích chính của kho dữ liệu.
Hệ thống phân cấp cũng là yếu tố quan trọng trong việc tối ưu hóa truy vấn
phức tạp. Nếu cơ sở dữ liệu đã biết mối quan hệ giữa các mức quý và năm, nó có thể
tự động viết lại truy vấn tổng hợp doanh thu theo quý thành tổng hợp theo năm, nhờ
vào tính tự động hiểu biết về các phụ thuộc chiều (dimensional dependencies) giữa
các khoảng thời gian này.

2.4. Các khái niệm thiết kế trong mô hình chiều

2.4.1. Thao tác vơi nhiều lược đồ hình sao
Lược đồ hình sao phân tách dữ liệu thành các quy trình riêng biệt, đòi hỏi cách
xử lý hiệu quả và đáng tin cậy để truy xuất dữ liệu khi các lệnh truy vấn bao gồm
nhiều lược đồ khác nhau. Bus Architecture có thể giải quyết vấn đề này thông qua
việc sử dụng các Conformed Dimensions và Conformed Facts:
- Confỏrmed Dimensions: Là các bảng Dimension được chia sẻ và đồng nhất
giữa nhiều Star Schema khác nhau. Ví dụ bảng Dimension “Khách hàng” có thể được
sử dụng nhiều trong các lược đồ như bán hàng, dịch vụ khách hàng,.. Nhưng vẫn có
thể giữ nguyên định dạng và giá trị dữ liệu nhất quán trên các quy trình này.
- Conformed Facts: Các cột Facts có cùng ý nghĩa trong nhiều bảng Fact. Ví dụ,
"lợi nhuận" trong bất kỳ bảng fact nào cũng được tính bằng công thức "doanh thu - chi
phí", có thể đảm bảo tính đồng nhất trong các tính toán và phân tích giữa các quy trình
kinh doanh khác nhau.

8
Hình ..: Ví dụ về lược đồ hình sao sử dụng các Conformed Dimensions và Conformed
Facts (nguồn: )

2.4.2. Data Grain

Data Grain được sử dụng để chỉ các mức độ chi tiết của dữ liệu:
- Mức độ chi tiết cao (Fine Grain): Lưu trữ từng mục riêng lẻ được mua bởi
mỗi khách hàng. Ví dụ, nếu một khách hàng mua ba sản phẩm khác nhau, mỗi giao
dịch sẽ được ghi lại chi tiết trong bảng Fact.
- Mức độ chi tiết thấp (Coarse Grain): Lưu trữ các chỉ số tổng, tức là tổng
doanh số theo từng ngày, hoặc tổng số lượng, giá trị hàng bán trong một ngày mà
không phân biệt chi tiết từng giao dịch cụ thể hay từng loại sản phẩm.

Trong các kho dữ liệu hiện đại, việc lưu trữ dữ liệu ở mức độ chi tiết càng cao
thì sẽ càng được khuyến khích vì điều này cho phép khả năng phân tích tối đa của các
truy vấn.
Khuyến nghị mỗi bảng Fact nên lưu trữ chỉ một mức độ chi tiết nhất định để
tránh sợ mơ hồ về phạm vi của mỗi hàng dữ liệu. Điều này giúp đảm bảo việc truy vấn
dữ liệu chính xác và dễ dàng quản lý bảo trì bảng dữ liệu.
2.4.3. Embedded Hierarchy
Trong mô hình dimensional cổ điển với các lược đồ hình sao, dữ liệu thường
được lưu trữ ở mức độ chi tiết nhất định.

9
 Tuy nhiên, trong một số trường hợp, có thể xuất hiện tình huống mà nhiều mức
độ chi tiết tồn tại trong cùng một bảng. Ví dụ: Một bảng fact “bán hàng” có thể chứa
cả dữ liệu cấp độ giao dịch (transaction-level) và tổng hợp theo ngày theo sản phẩm
(day-level rollup), hoặc tổng hợp theo tháng theo sản phẩm (month-level rollup).
Để giải quyết vấn đề này, bảng Fact sẽ cần phải có một cột chỉ định mức độ chi
tiết (level-column) nhằm biểu thị cấp bậc trong hệ thống phân cấp áp dụng cho mỗi
hàng dữ liệu. Cột này cho biết mỗi hàng dữ liệu thuộc về mức độ chi tiết nào trong hệ
thống phân cấp (ví dụ: giao dịch, ngày, tháng). Qua đó người dùng có thể hiểu rõ hơn
về ngữ cảnh và chi tiết của dữ liệu khi thực hiện truy vấn.

2.4.4. Degenerate Dimensions

Các chiều suy biến (Degenerate Dimensions) chỉ ra các bảng Dimension không
chứa bất kỳ dữ liệu mô tả nào ngoại trừ khóa chính. Những Dimension này không có
bảng riêng lẻ mà chỉ được đại diện trực tiếp bởi các cột trong bảng fact. Các chiều suy
biến này là những cột thuộc về bảng Fact mà không cần liên kết với một bảng
Dimension khác, nhưng vẫn đóng vai trò quan trọng trong việc truy vấn và phân tích
dữ liệu.
Ví dụ về trong một bảng Fact về giao dịch bán hàng, có thể có một cột "Order
Number" đại diện cho mỗi giao dịch, nhưng không có bảng Dimension chứa các thuộc
tính mô tả về số đơn hàng đó (như ngày giao hàng, thông tin sản phẩm trong đơn hàng,
v.v.). Thay vào đó, dữ liệu của Order Number chỉ xuất hiện trong bảng Fact mà không
liên kết với bất kỳ bảng Dimension nào.

10
 2.4.5. Junk Dimension
Junk Dimension là một kỹ thuật có lược đồ hình sao nhằm kết hợp nhiều thuộc
tính có số lượng giá trị duy nhất thấp và gắn các cờ thành một bảng Dimension duy
nhất. Kỹ thuật này giúp xử lý các thuộc tính phi phân tích nhưng vẫn quan trọng trong
việc phân tích kinh doanh, mà không cần phải tạo quá nhiều bảng dimension nhỏ lẻ.

2.4.6. Factless Fact Tables

Factless Fact Tables là một loại bảng fact đặc biệt trong kho dữ liệu, mà không
chứa các dữ liệu đo lường như thông thường. Thay vì lưu trữ các số liệu như doanh

11
thu hay số lượng, bảng này chỉ chứa các khóa ngoại kết nối đến các bảng Dimension
liên quan. Bảng này được sử dụng để ghi nhận các sự kiện đã xảy ra hoặc phân tích
các trường hợp không xảy ra, từ đó cung cấp cái nhìn chi tiết hơn về các hoạt động
hoặc thiếu sót trong dữ liệu.
Một số ứng dụng của Factless Fact Tables:
- Ghi nhận sự kiện xảy ra: Một số sự kiện không nhất thiết phải có số liệu đo
lường cụ thể nhưng vẫn có thể được ghi nhận. Ví dụ: bảng theo dõi sự hiện diện của
sinh viên không có số liệu đo lường như điểm số hay doanh thu. Tuy nhiên, bảng
factless fact này có thể chứa các khóa ngoại liên quan đến các bảng dimension như
Ngày, Sinh viên, Giáo viên, Lớp học,..
- Phân tích các sự kiện không xảy ra: Factless Fact Tables có thể giúp phân tích
những sự kiện không xảy ra thông qua việc so sánh giữa các bảng:
Bảng Phủ Sóng (Coverage Table): Liệt kê tất cả các khả năng có thể xảy ra,
ví dụ như dự kiến tham dự (expected attendance). Bảng này chứa tất cả các kết hợp có
thể có của sinh viên và lớp học trong một ngày cụ thể, đại diện cho việc tất cả các sinh
viên dự kiến sẽ tham gia lớp học.

Bảng Hoạt Động (Activity Table): Ghi lại các sự kiện đã thực sự xảy ra, ví dụ
như thực tế tham dự (actual attendance).

Khi trừ hai bảng này, kết quả nhận được sẽ là các sự kiện không xảy ra (ví dụ:
những sinh viên đã không tham gia lớp học). Kết quả này có thể giúp phân tích những
sự kiện vắng mặt hoặc thiếu sót.

12
 2.5. Bốn bước thiết kế mô hình chiều dữ liệu
Bước 1: Chọn lựa quy trình nghiệp vụ (Business process)
Một quy trình nghiệp vụ là một hoạt động ở mức độ thấp được thực hiện trong
một tổ chức, chẳng hạn như nhận đơn đặt hàng, hóa đơn, nhận thanh toán,...
Xác định Quy trình nghiệp vụ nào quan trọng mà doanh nghiệp thật sự quan
tâm, cần phân tích và tổng hợp dữ liệu bằng cách kết hợp những hiểu biết về yêu cầu
nghiệp vụ với nguồn dữ liệu hiện tại.
Bước 2: Xác định độ mịn (grain)
Xác định độ mịn (grain) nghĩa là xác định chính xác thông tin thể hiện trên một
dòng của bảng sự kiện. Nó trả lời cho câu hỏi "Bạn mô tả một hàng duy nhất trong
bảng sự kiện như thế nào?" Các mức độ mịn được xác định dựa trên các hoạt động
thực tế và là bản ghi các sự kiện trong quá trình kinh doanh của doanh nghiệp.
Bước 3: Nhận dạng các dimensions
Để nhận dạng các chiều của mô hình, cần trả lời câu hỏi,"Các nhà kinh doanh
mô tả các dữ liệu thu được từ các sự kiện trong các quy trình nghiệp vụ như thế nào?"
Nếu đã xác định được độ mịn, các chiều có thể dễ dàng được nhận ra bằng cách đặt
các câu hỏi "ai (who), cái gì (what), ở đâu (where), khi nào (when), tại sao (why) và
như thế nào (how)" liên quan đến sự kiện này.
Ngoài ra, một mô tả về độ mịn một cách chi tiết sẽ giúp xác định được các
chiều cơ bản của bảng sự kiện. Sau đó nhà thiết kế sẽ có thêm các chiều khác nếu việc
bổ sung các bảng chiều không làm thay đổi độ mịn của bảng sự kiện.
Bước 4: Nhận dạng các facts
Các dữ liệu sự kiện được xác định thông qua việc trả lời câu hỏi, "Các quy trình
nghiệp vụ được đo lường qua những yếu tố nào?". Người dùng doanh nghiệp thường
rất quan tâm đến việc phân tích các số liệu hiệu suất hoạt động. Tất cả các dữ liệu sự
kiện trong một thiết kế phải phù hợp với độ mịn được xác định ở bước 2.

13
III. Mô hình dữ liệu vật lý (Physical Data Model)
3.1. Chuyển từ Logical qua Physical Design
Trong quá trình thiết kế vật lý, các lược đồ mong đợi được chuyển thành các
cấu trúc cơ sở dữ liệu thực tế. Tại giai đoạn này, cần ánh xạ những điều sau:
• Entities → tables
• Relationships → foreign key constraints
• Attributes → columns
• Primary unique identifiers → primary key constraints
• Unique identifiers → unique key constraints
Để chuyển đổi thiết kế logic thành thiết kế vật lý cần phải tạo một số hoặc tất cả
các cấu trúc sau: tablespace, table, phân vùng trên table hoặc table được tổ chức theo
index, các index bao gồm các index được phân vùng, dạng Views, Integrity
constraints, Materialized views và Dimensions.

Hình 3.1: Khái quát về logical design và physical design

3.2. Physical Design Structures

3.2.1. Tablespaces
Theo quan điểm thiết kế, tablespace là nơi chứa cấu trúc thiết kế vật lý. Một
tablespace bao gồm một hoặc nhiều datafile, là những cấu trúc vật lý bên trong hệ điều
hành đang sử dụng.
Mỗi datafile chỉ được liên kết với một tablespace.
Tablespace thường sử dụng khi muốn gom nhóm các đối tượng liên quan với
nhau lại. Giống với Schema, chúng đều được dùng để phân loại dữ liệu, tuy nhiên, nếu
như schema phân loại dữ liệu ở mức logical thì tablespace phân loại dữ liệu ở mức
physical.

14
 Hình 3. : Minh họa tablespace.
Tablespaces cần được phân chia theo các tiêu chí cụ thể để dễ dàng quản lý và
tối ưu hóa hiệu suất hệ thống cơ sở dữ liệu, như theo loại dữ liệu (table, index), kích
thước (sales, products), đơn vị kinh doanh (HR, finance,...). Tablespace là mức phân
chia lớn nhất khi muốn thực hiện backup (sao lưu) hoặc phục hồi dữ liệu. Vì thế, việc
thiết kế tablespaces hợp lý sẽ ảnh hưởng đến độ khả dụng của dữ liệu và các thao tác
bảo trì.
Đối với các cơ sở dữ liệu rất lớn, có thể sử dụng các ultralarge data file để chứa
nhiều dữ liệu hơn trong một tệp tablespace duy nhất. Điều này giúp đơn giản hóa việc
quản lý tệp và lưu trữ lượng dữ liệu khổng lồ.
3.2.2. Tables and Partitioned Tables
Tables là đơn vị lưu trữ cơ bản, chứa dữ liệu thô trong kho dữ liệu.
Partitioned tables giúp quản lý khối lượng dữ liệu lớn bằng cách chia nhỏ thành
các phần dễ quản lý hơn. Tiêu chí chính để phân vùng là manageability (khả năng
quản lý), mặc dù việc này thường cải thiện hiệu suất nhờ partition pruning (loại bỏ
phân vùng) hoặc parallel processing (xử lý song song).
● Partitioning pruning
Khái niệm: Partitioning pruning là một tính năng hiệu suất thiết yếu cho kho dữ
liệu.
Trong partitioning pruning, trình tối ưu hóa phân tích các mệnh đề FROM và
WHERE trong các câu lệnh SQL để loại bỏ các phân vùng không cần thiết khi xây
dựng danh sách truy cập phân vùng. Chức năng này cho phép Oracle Database chỉ
thực hiện các thao tác trên các phân vùng có liên quan đến câu lệnh SQL.
Ví dụ: Table ORDERS chứa hồ sơ lịch sử về các đ lớp ơn hàng và bảng này đã
được phân vùng theo ngày. Một truy vấn yêu cầu các đơn hàng trong một tuần sẽ chỉ
truy cập bảy phân vùng của bảng ORDERS. Nếu bảng có dữ liệu lịch sử trong hai
năm, truy vấn này sẽ truy cập bảy phân vùng thay vì 730 phân vùng. Truy vấn này có
khả năng thực thi nhanh hơn 100 lần chỉ với partitioning pruning.
● Parallel processing

15
 Parallel processing (xử lý song song) là kỹ thuật thực hiện nhiều tác vụ đồng
thời bằng cách chia nhỏ công việc và phân bổ cho nhiều đơn vị xử lý (processor) hoặc
máy tính khác nhau. Thay vì một CPU xử lý toàn bộ dữ liệu từ đầu đến cuối, parallel
processing sẽ chia khối lượng dữ liệu thành nhiều phần và phân bổ cho nhiều CPU
hoặc máy xử lý cùng lúc. Mỗi CPU sẽ xử lý một phần của dữ liệu, giúp rút ngắn thời
gian thực hiện truy vấn.
Ví dụ: Khi cần tính tổng doanh thu từ một bảng giao dịch bán hàng nhiều năm,
thay vì một máy tính quét toàn bộ bảng dữ liệu, hệ thống có thể chia nhỏ bảng thành
các phân vùng (partition) theo năm hoặc theo tháng và giao cho mỗi bộ xử lý thực
hiện tính toán tổng doanh thu cho một khoảng thời gian nhất định. Kết quả từ các bộ
xử lý này sẽ được ghép lại để cho ra kết quả cuối cùng nhanh hơn.

Table Compression (Nén bảng)

Có thể tiết kiệm dung lượng đĩa bằng cách nén các heap-organized tables.
Partitioned tables là ứng viên phổ biến cho việc nén.
Nén bảng giảm việc sử dụng bộ nhớ (đặc biệt là buffer cache) và có thể giúp cải
thiện hiệu suất cho các truy vấn chỉ đọc. Tuy nhiên, nén bảng sẽ tốn thêm tài nguyên
CPU.
Ví dụ: Nếu bạn có một bảng chứa nhiều dữ liệu thừa, chẳng hạn như bảng có
nhiều khóa ngoại (Order) thì nên sử dụng table compression. Tuy nhiên, đối với các
bảng có nhiều hoạt động cập nhật (Inventory), nén có thể không phù hợp vì sẽ tốn tài
nguyên để xử lý các thay đổi (thay đổi Stock_Level mỗi khi có giao dịch nhập hoặc
xuất kho). Điều này làm chậm hiệu suất thay vì cải thiện nó.
Bảng Sales_Report (Báo cáo doanh thu) phù hợp với table compression vì nó
thường không thay đổi sau khi được tạo ra, và chủ yếu sử dụng để đọc và phân tích.
Các kiểu bảng chứa nhật ký giao dịch (Transaction log) thường không phù hợp với
table compression vì thường xuyên được cập nhật với các giao dịch mới.
3.2.3. Views

16
 View là một cách trình bày dữ liệu được thiết kế riêng từ một hoặc nhiều bảng
hoặc các view khác trong cơ sở dữ liệu. Nó lấy đầu ra từ một truy vấn và xử lý như
một bảng thông thường, giúp người dùng có thể truy cập và thao tác dữ liệu mà không
cần phải thao tác trực tiếp với table gốc. Một điểm đáng chú ý là view không yêu cầu
không gian lưu trữ trong cơ sở dữ liệu, vì nó chỉ là một lớp ảo dựa trên kết quả của
truy vấn. Ngoài ra, view cũng có thể được sử dụng để giới hạn truy cập, cho phép các
nhóm người dùng khác nhau chỉ xem được những thông tin nhất định, giúp đảm bảo
bảo mật và quyền truy cập dữ liệu.
Ví dụ: Giả sử bảng Employees chứa thông tin nhân viên, bao gồm
Employee_ID, Name, Position, Salary, và Department_ID. Bạn muốn hạn chế bộ phận
nhân sự hoặc IT không thấy cột lương. Để giải quyết, có thể tạo view tên
Employee_Public_View chỉ bao gồm các cột Employee_ID, Name, và Position, giúp
các bộ phận này xem thông tin cần thiết mà không truy cập được lương.

Hình 3. Minh họa cách Views được lấy từ một query

3.2.4. Integrity Constraints
Khái niệm: Integrity constraints (Ràng buộc toàn vẹn) cung cấp cơ chế đảm bảo
dữ liệu tuân thủ các hướng dẫn do quản trị viên cơ sở dữ liệu chỉ định, được sử dụng
để thực thi các quy tắc kinh doanh liên quan đến cơ sở dữ liệu và để ngăn chặn thông
tin không hợp lệ trong các table, đảm bảo tính nhất quán của dữ liệu.
Why Integrity Constraints are Useful in a Data Warehouse
Ràng buộc toàn vẹn trong kho dữ liệu khác với ràng buộc trong môi trường
OLTP. Trong môi trường OLTP, chúng chủ yếu ngăn chặn việc chèn dữ liệu không
hợp lệ vào bản ghi, đây không phải là vấn đề lớn trong môi trường kho dữ liệu vì độ
chính xác đã được đảm bảo trước khi dữ liệu được tải vào hệ thống. Trong môi trường
Data warehouse, integrity constraints được sử dụng để viết lại truy vấn.
Các loại ràng buộc phổ biến nhất bao gồm:
- NOT NULL yêu cầu cung cấp giá trị. (phổ biến nhất)
- UNIQUE có nghĩa là không có giá trị trùng lặp.
- PRIMARY KEY xác định duy nhất các bản ghi.

17
 - FOREIGN KEY duy trì tính nhất quán giữa các bảng liên quan.
Một số mục đích cơ bản của các ràng buộc:
● Enforcement (Thực thi): Để sử dụng ràng buộc để thực thi, ràng buộc
phải ở trạng thái ENABLE. Một ràng buộc được bật đảm bảo rằng tất cả các sửa đổi
dữ liệu trên một bảng (hoặc các bảng) nhất định đều đáp ứng các điều kiện của ràng
buộc. Các hoạt động sửa đổi dữ liệu tạo ra dữ liệu vi phạm ràng buộc sẽ không thành
công với lỗi vi phạm ràng buộc.
● Validation (Xác thực): Để sử dụng ràng buộc để xác thực, ràng buộc
phải ở trạng thái VALIDATE. Nếu ràng buộc được xác thực, thì tất cả dữ liệu hiện có
trong bảng thỏa mãn ràng buộc.
Lưu ý rằng xác thực không phụ thuộc vào việc thực thi. Mặc dù ràng buộc
thông thường trong hệ thống hoạt động vừa được bật vừa được xác thực, bất kỳ ràng
buộc nào cũng có thể được xác thực nhưng không được bật hoặc ngược lại (được bật
nhưng không được xác thực).
● Belief (Niềm tin): Trong một số trường hợp, các điều kiện cho một ràng
buộc nhất định là đúng do đó không cần phải xác thực hoặc thực thi ràng buộc. Tuy
nhiên, các ràng buộc đó vẫn tồn tại để cải thiện hiệu suất và tối ưu hóa truy vấn. Khi
sử dụng ràng buộc theo cách này, nó được gọi là ràng buộc niềm tin hoặc RELY và
ràng buộc đó phải ở trạng thái RELY. Trạng thái RELY cung cấp một cơ chế để thông
báo rằng một ràng buộc nhất định được cho là đúng. Trạng thái RELY chỉ ảnh hưởng
đến các ràng buộc chưa được xác thực.
a. Materialized Views
Materialized Views là kết quả truy vấn đã được lưu trữ trước, giúp giảm thiểu
thời gian xử lý khi thực thi các câu lệnh SQL. Thay vì phải tính toán lại mỗi khi truy
vấn, kết quả đã được lưu trữ có thể được truy cập nhanh chóng. Materialized Views
tương tự như các bảng hoặc bảng phân vùng và hoạt động giống như một index (chỉ
mục), vì chúng được sử dụng một cách tự động và giúp cải thiện hiệu suất truy vấn.
Chúng được sử dụng chủ yếu để loại bỏ các chi phí liên quan đến các phép nối
(joins) hoặc tổng hợp (aggregations) phức tạp, đặc biệt là đối với các lớp truy vấn lớn
hoặc quan trọng. Điều này giúp tránh việc thực thi lại các truy vấn tốn kém về tài
nguyên, cải thiện đáng kể hiệu suất cho các hệ thống xử lý dữ liệu lớn.
Sự khác biệt chính giữa view thông thường và materialized view là cách xử lý
dữ liệu. Một view thông thường chỉ là một truy vấn định nghĩa một virtual table (bảng
ảo) – nghĩa là nó không lưu trữ dữ liệu, mà chỉ tạo ra dữ liệu ngay lập tức khi truy vấn
được thực thi. Ngược lại, materialized view là một dạng view mà kết quả của truy vấn
đã được chạy và lưu trữ dưới dạng một bảng thực tế. Điều này có nghĩa là khi bạn truy
vấn một materialized view, bạn đang truy cập dữ liệu đã được lưu trữ, không phải tính
toán lại từ đầu.
Ví dụ, một bảng giao dịch lớn với hàng triệu bản ghi và thường xuyên cần thực
hiện phép tổng hợp dữ liệu (như tính tổng doanh thu hàng tháng), thay vì thực thi phép

18
tính này mỗi lần, có thể tạo một materialized view để lưu kết quả tổng hợp. Điều này
giúp giảm tải và tăng tốc truy vấn.
Materialized Views thường được xây dựng vì lý do hiệu suất và độ ổn định, đặc
biệt trong các tình huống mạng không ổn định hoặc khi bạn cần thực hiện các truy vấn
dài trong giờ ngoài cao điểm để tránh ảnh hưởng đến hiệu suất hệ thống chính.
b. Indexes and Partitioned Indexes
Indexes
Index là các cấu trúc tùy chọn liên kết với các table hoặc cluster, giúp tăng tốc
độ truy vấn bằng cách tối ưu hóa cách dữ liệu được truy cập. Index không chứa dữ
liệu gốc, mà chỉ chứa các chỉ mục giúp định vị nhanh các hàng trong bảng. Nó giống
như một bảng tra cứu, cho phép truy vấn tìm kiếm nhanh hơn mà không cần phải quét
toàn bộ bảng.
Trong môi trường data warehouse, ngoài B-tree indexes (chỉ mục cây B truyền
thống), bitmap indexes là loại chỉ mục rất phổ biến do chúng được tối ưu hóa cho các
thao tác theo tập hợp dữ liệu (set-oriented operations).
B-tree Indexes
B-tree indexes là loại chỉ mục phổ biến, được sử dụng để tìm kiếm và truy cập
dữ liệu theo khóa nhanh chóng. Nó sắp xếp dữ liệu theo cấu trúc cây, giúp tìm kiếm
một cách hiệu quả. Chỉ mục này phù hợp cho các hệ thống OLTP hoặc các trường hợp
cần truy vấn từng bản ghi nhanh chóng.
Ví dụ: Bảng Employees và thường xuyên truy vấn theo Employee_ID thì có thể
tạo B-tree index trên cột Employee_ID để tăng tốc độ truy vấn tìm kiếm theo mã nhân
viên.
Bitmap indexes
Bitmap indexes là các cấu trúc index được tối ưu hóa cho các hoạt động hướng
tập hợp dữ liệu, chẳng hạn như các phép lọc dựa trên nhiều điều kiện. Thay vì lưu các
vị trí bản ghi trong danh sách, bitmap indexes lưu trữ các bit (0 hoặc 1) để biểu diễn
các bản ghi có hoặc không có giá trị cần tìm. Thường dùng cho các dữ liệu có tính
trùng lặp giá trị như giới tính, loại xếp hạng,...
Ví dụ: bảng Customers với các cột như Customer_ID, Gender (Male, Female),
Membership_Status (Diamond, Gold, Silver), và Region (North, South, East, West, và
Central). Với bitmap index, mỗi giá trị trong các cột này sẽ được biểu diễn bằng một
bitmap (chuỗi bit), trong đó mỗi bit đại diện cho một bản ghi trong bảng và có giá trị 1
nếu bản ghi đó có giá trị tương ứng, và 0 nếu không. Khi muốn tìm các khách hàng
nam, Gold members và sống ở North, cơ sở dữ liệu sẽ thực hiện phép toán AND trên
các bitmap tương ứng. Kết quả sau phép toán AND sẽ là: “1 0 0 0 1 0 0 …”. Như vậy,
chỉ có các bản ghi tại các vị trí thứ nhất và thứ năm là thỏa mãn cả ba điều kiện: khách
hàng nam, thành viên Gold, và sống ở khu vực North.
Ngoài ra, chúng cần thiết cho một số phương pháp truy cập dữ liệu được tối ưu
hóa như star transformation. Star transformation là một phương pháp tối ưu hóa truy

19
vấn, thường được sử dụng trong các thiết kế Star Schema (lược đồ sao). Trong các
truy vấn kiểu này, bitmap indexes giúp giảm đáng kể chi phí truy vấn bằng cách
nhanh chóng lọc các kết hợp giữa bảng sự kiện (fact table) và bảng chiều (dimension
table).
Index giống như table ở chỗ có thể phân vùng chúng, mặc dù chiến lược phân
vùng không phụ thuộc vào cấu trúc bảng. Phân vùng indexes giúp quản lý kho dữ liệu
dễ dàng hơn trong quá trình làm mới và cải thiện hiệu suất truy vấn.
Partitioned Indexes
Partitioning indexes (phân vùng chỉ mục) là kỹ thuật chia nhỏ chỉ mục thành
nhiều phần dựa trên các quy tắc phân vùng. Điều này giúp quản lý dữ liệu hiệu quả
hơn trong quá trình làm mới dữ liệu (refresh) và cải thiện hiệu suất truy vấn trong các
hệ thống dữ liệu lớn. Một điều quan trọng là chiến lược phân vùng của chỉ mục không
phụ thuộc vào cấu trúc phân vùng của bảng.

Hình 3. : B-tree index và Bitmap index

20
 IV. So sánh Mô hình khái niệm, Mô hình logic và Mô hình vật lý
Mô hình khái niệm Mô hình logic Mô hình vật lý

Cấu trúc Mô hình ER: thực thể, Mô hình đa chiều: Tables, columns,
dữ liệu mối quan hệ bảng fact and bảng views, indexes,
Dimension integrity constraints
Mô hình ER: thực thể,
mối quan hệ và các
khóa

Mục đích Làm rõ các yêu cầu và Làm rõ cách dữ liệu sẽ Xem xét cách hiệu quả
quy tắc nghiệp vụ về được tổ chức và quản nhất để lưu trữ và truy
data của các lý trong hệ thống, thể xuất các
stakeholders hiện chính xác các yêu đối tượng cũng như xử
cầu bằng ngôn ngữ kỹ lý chúng theo góc độ
thuật. vận chuyển và sao
Tạo ra một cơ sở vững lưu/phục hồi.
chắc cho việc thiết kế
Physical Data Model.

Người sử Các stakeholders và Data Architects và Các Developers và

dụng business analysts Business Analyst. Quản trị viên cơ sở dữ
liệu

Tập trung Là cấp độ tổng quát Mô tả chi tiết hơn về Triển khai thực tế của
vào nhất, cung cấp cái cấu trúc dữ liệu và các mô hình logic. Tập
nhìn tổng thể về dữ mối quan hệ logic giữa trung vào cách thức
liệu từ góc độ kinh các thực thể trong hệ lưu trữ và truy xuất dữ
doanh mà không đi thống, tập trung vào liệu sao cho hiệu quả,
sâu vào chi tiết kỹ cách tổ chức dữ liệu mà đồng thời đảm bảo tính
thuật. không liên quan đến khả dụng và an toàn
cách lưu trữ vật lý của dữ liệu.

21
 TÀI LIỆU THAM KHẢO
Erwin, Conceptual Data Modeling (n.d.). Retrieved from
https://www.irwin.com/learn/conceptual.aspx
Olin, T., & Olin, T. (2024, January 25). Understanding data modeling and data model
types.
Retrieved From Https://www.agiledataengine.com/blog-old/data-modeling-
and-data-model-types
Viblo. (2024, October 6). Data Modeling là gì? Lợi ích mà data modeling?
Retrieved From https://viblo.asia/p/data-modeling-la-gi-loi-ich-ma-data-
modeling-5pPLkPzZVRZ
Gabriel M. Kuper and Moshe Y. Vardi. 1993. The logical data model. ACM Trans.
Database
Syst. 18, 3 (Sept. 1993), 379–413. Retrieved From
https://doi.org/10.1145/155271.155274
Thinhnotes. (2022, May 28). 15 phút thực hành với sơ đồ ERD. Retrieved From
https://thinhnotes.com/chuyen-nghe-ba/15-phut-thuc-hanh-voi-so-do-erd/
Lee, C. (2024, October 6). What is a logical data model? [Blog Spot] Retrieved From
https://www.gooddata.com/blog/how-build-logical-data-models-scale-
analytical-applications/
Amazon. Mô hình dữ liệu vật lý và logic – Điểm khác biệt trong lập mô hình dữ liệu.
(n.d.).
Retrieved from https://aws.amazon.com/vi/compare/the-difference-between-
logical-and-physical-data-model/
Indaacademy. (2022, March 1). Tìm hiểu về index partition, phân biệt local index và
global
index. Retrieved from https://indaacademy.vn/sql/tim-hieu-ve-index-partition-
phan-biet-local-index-va-global-index/
Paul L., Viv S. & Ingrid S. (2003), Oracle Database Data Warehousing Guide,
California,
US
Thanh H. T., Cuong T. C. & Hien L. T. K. (2016), Phân Tích Kho Dữ Liệu Trong
Kinh
Doanh, TP. Hồ Chí Minh : NXB Đại học Quốc gia TP.Hồ Chí Minh
GeeksforGeeks. (2024, April 26). Introduction of database normalization. Retrieved
from
https://www.geeksforgeeks.org/introduction-of-database-normalization/

22