Nghiên cứu và xây dựng kho dữ liệu sản phẩm tại Ngân hàng TMCP Đại Dương dựa trên nền tảng hệ quản trị CSDL Oracle 10g

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



NGUYỄN ĐỨC BÌNH




NGHIÊN CỨU VÀ XÂY DỰNG KHO DỮ LIỆU SẢN
PHẨM TẠI NGÂN HÀNG TMCP ĐẠI DƯƠNG TRÊN
NỀN TẢNG HỆ QUẢN TRỊ CSDL ORACLE 10G




LUẬN VĂN THẠC SĨ












Hà Nội - 2014

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



NGUYỄN ĐỨC BÌNH




NGHIÊN CỨU VÀ XÂY DỰNG KHO DỮ LIỆU SẢN
PHẨM TẠI NGÂN HÀNG TMCP ĐẠI DƯƠNG TRÊN
NỀN TẢNG HỆ QUẢN TRỊ CSDL ORACLE 10G

Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60.48.10


LUẬN VĂN THẠC SĨ


Cán bộ hướng dẫn khoa học: GS.TS. Vũ Đức Thi.

Hà Nội - 2014



LỜI CẢM ƠN

Trước hết, em xin gửi lời cảm ơn trân trọng nhất tới GS.TS. Vũ Đức Thi,
Viện CNTT, Viện KH&CN VN, người đã trực tiếp hướng dẫn, giúp em định
hướng , tận tình chỉ bảo và hỗ trợ em trong suốt quá trình nghiên cứu và thực
hiện luận văn.
Em xin gửi lời cám ơn tới các thầy cô trong khoa Công Nghệ Thông Tin
cùng toàn thể các thầy cô trường Đại học Công Nghệ đã tận tình dạy dỗ và dìu
dắt chúng em trong suốt thời gian học tập tại trường.
Em xin gửi lời cảm ơn tới Ngân hàng TMCP Đại Dương đã tạo môi
trường để em nghiên cứu và cài đặt thử nghiệm hệ thống thành công.
Cuối cùng em xin gửi lời cám ơn tới gia đình, bạn bè, những người luôn
luôn bên cạnh và tạo mọi điều kiện thuận lợi nhất để em có thể hoàn thành tốt
luận văn.

Hà Nội, tháng 10 năm 2014
Sinh viên : Nguyễn Đức Bình
Lớp K18 Khoa Công Nghệ Thông tin, Trường Đại Học Công Nghệ

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm nghiên
cứu, tìm hiểu của riêng cá nhân tôi. Trong toàn bộ nội dung của luận văn,

những điều được trình bày hoặc là của cá nhân tôi hoặc là được ổng hợp từ
nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và
được trích dẫn hợp pháp.
Tôi xin hoàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định
cho lời cam đoan của mình.

MỤC LỤC
PHẦN MỞ ĐẦU. 1
CHƯƠNG 1: LÝ THUYẾT KHO DỮ LIỆU 4
1.1. Tổng quan về kho dữ liệu. 4
1.1.1. Lịch sử phát triển của kho dữ liệu: 4
1.1.2. Định nghĩa. 5
1.2. Đặc trưng kho dữ liệu 5
1.2.1. Tính bền vững. 5
1.2.2. Biến thời gian. 5
1.2.3. Hướng chủ đề. 6
1.2.4. Tính tích hợp. 7
1.3. Sự khác nhau giữa hệ thống OLTP và kho dữ liệu 7
1.4. Kiến trúc kho dữ liệu. 9
1.4.1. Kiến trúc kho dữ liệu cơ bản 9
1.4.2. Kiến trúc kho dữ liệu với vùng đệm. 9
1.4.3. Kiến trúc kho dữ liệu với vùng đệm và kho dữ liệu cục bộ. 10
1.5. Thiết kế kho dữ liệu 10
1.5.1. Thiết kế logic và thiết kế vật lý trong kho dữ liệu 10
1.5.2. Thiết kế logic. 11
1.6. Lược kho dữ liệu. 12
1.6.1. Lược đồ sao. 12
1.6.2. Lược đồ bông tuyết. 12
1.6.3. So sánh lược đồ sao và bông tuyết. 13
1.6.4. Lược đồ khác. 14

1.7. Thiêt kế vật lý. 14
1.7.1. Chuyển thiết kế logic thành thiết kế vật lý. 14
1.7.2. Tạo thiết kế vật lý 14
1.8. Đối tượng trong kho dữ liệu. 15
1.8.1. Sự kiện và bảng sự kiện. 15
1.8.2. Chiều và bảng chiều. 15
1.8.3. Khối dữ liệu. 15
1.9. Chiến lược xây dựng kho dữ liệu: 18
1.9.1. Chiến lược từ trên xuống. 18
1.9.2. Chiến lược từ dưới lên 19
1.9.3. So sánh 02 phương pháp thiết kế 20
1.9.4. Chiết xuất dữ liệu. 22
1.9.5. Chuyển đổi dữ liệu. 22

1.9.6. Nạp dữ liệu. 23
1.10. Kho dữ liệu cục bộ. 28
CHƯƠNG 2: XÂY DƯNG KHO DỮ LIỆU SẢN PHẨM 30
2.1. Giới thiệu. 30
2.1.1. Ngân hàng TMCP Đại Dương. 30
2.1.2. Hệ thống CORE BANKING. 31
2.1.3. Thực trạng hệ thống. 33
2.2. Xây dựng kho dữ liệu 34
2.2.1. Đặc tả các thông tin cơ bản của dự án: 34
2.2.2. Phân tích nghiệp vụ. 35
2.2.3. Xây dựng kho dữ liệu trung tâm. 39
2.2.4. Xây dựng kho dữ liệu cục bộ. 47
CHƯƠNG 3: CÀI ĐẶT, THỬ NGHIỆM 49
3.1. Giới thiệu về công cụ Oracle Warehouse Builder. 49
3.2. Môi trường cài đặt và các thành phần: 50
3.3. Cài đặt với Oracle Warehouse Builder 50

3.3.1. Xây dựng bảng chiều. 50
3.3.2. Xây dựng cube 52
3.3.3. Thiết lập nguồn, chiết xuất và xử lý dữ liệu. 53
3.3.4. Triển khai. 55
3.3.4. Nạp dữ liệu vào kho dữ liệu. 56
3.4. Báo cáo dựa trên kho dữ liệu. 50
KẾT LUẬN VÀ ĐỊNH HƯỚNG. 60
TÀI LIỆU THAM KHẢO 61








Danh

mục

các

ký

hiệu,

chữ

viết

tắt




Ký

hiệu

Chuỗi

văn

bản

gốc

Mô

tả

3NF Third Normal Form Chuẩn hóa 3NF
Client/Server
OLAP
Client/Server Online Analytical
Processing
Xử lý phân tích trực tuyến
khách/chủ
CNTT
Information Technology

Công nghệ thông tin
CSDL Database Cơ sở dữ liệu
DDL Data Define Language Ngôn ngữ định nghĩa dữ liệu
OWB
Oracle Warehouse Build
Công cụ xây dụng kho dữ liệu
DBMS Database Management System Hệ quản trị cơ sở dữ liệu
DF
Datafile
Tệp dữ liệu
DWH Data Warehouse Kho dữ liệu
DSS Decision Support System Hỗ trợ quyết định

ETL
Extraction, Transportation,
Loading

Trích suất, Trao đổi, Tải
ID
ID
Định danh
NN NOT NULL Khác rỗng
OD
Oracle Designer
Sản phẩm
OLAP On Line Analytical Processing Xử lý phân tích trực tuyến
OLTP On Line Transaction Processing Xử lý tác nghiệp trực tuyến

DANH MỤC HÌNH VẼ ĐỒ THỊ
Hinh 1. 1: Sơ đồ luồng dữ liệu 4

Hinh 1. 2: Tính bền vững của DWH. 5
Hinh 1. 3: Đặc trưng biến thời gian. 6
Hinh 1. 4: Đặc trưng hướng chủ đề 6
Hinh 1. 5: Đặc trưng tính tích hợp. 7
Hinh 1. 6: So sánh OLTP với DWH. 8
Hinh 1. 7: Kiến trúc kho dữ liệu cơ bản. 9
Hinh 1. 8: Kiến trúc kho dữ liệu vùng đệm. 9
Hinh 1. 9: Kiến trúc DWH với vùng đệm, DM. 10
Hinh 1. 10: Lược đồ ngôi sao. 12
Hinh 1. 12: So sánh 2 lược đồ bông tuyết và ngôi sao. 13
Hinh 1. 11: Lược đồ hình bông tuyết. 13
Hinh 1. 13: So sánh thiết kế logic với thiết kế vật lý. 14
Hinh 1. 14: Khối dữ liệu 3 chiều. 16
Hinh 1. 15: Phép cắt dữ liệu. 17
Hinh 1. 16: Phép khoan dữ liệu. 17
Hinh 1. 17: Phép quay dữ liệu. 18
Hinh 1. 18: Chiến lược xây dựng DWH. 18
Hinh 1. 19: Kiển trúc Inmon 19
Hinh 1. 20: Kiến trúc Kimball 19
Hinh 1. 21: So sánh 2 cách Kimball và Inmon. 21
Hinh 1. 22: Quá trình ETL. 21
Hinh 1. 23: Cấu trúc chiều cơ bản. 23
Hinh 1. 24: Chiều thời gian. 25
Hinh 1. 25: Quá trình hợp nhất các chiều phụ thuộc. 26
Hinh 1. 26: Kiến trúc kho dữ liệu cục bộ độc lập. 28
Hinh 1. 27: Kiến trúc Kho dữ liệu cục bộ phụ thuộc. 29

Hình 2. 1: Giới thiệu Ocean Bank. 30
Hình 2. 2: Mô tả core banking. 32
Hình 2. 3: Sơ đồ hệ thống dữ liệu tại Ocean Bank. 33

Hình 2. 4: Luồng nghiệp vụ huy động. 35
Hình 2. 5: Luồng nghiệp vụ cho vay. 35
Hình 2. 6: Mô hình thực thể của nghiệp vụ huy động & cho vay trên core. 37

Hình 2. 7: Mô hình CSDL quan hệ của nghiệp vụ huy động trên core. 38
Hình 2. 8: Kiến trúc kho dữ liệu Ocean Bank. 40
Hình 2. 9: Mô hình giải pháp luồng dữ liệu. 41
Hình 2. 10: Bảng danh sách thực thể dữ liệu cho kho và nguồn. 41
Hình 2. 11: Bảng danh sách dữ liệu tham khảo đẩy vào kho dữ liệu. 42
Hình 2. 12: Bảng danh sách dữ liệu chiều thay đổi theo thời gian. 42
Hình 2. 13: Thêm thành phần thời gian vào dữ liệu. 43
Hình 2. 14: Bảng dữ liệu chính trong kho. 43
Hình 2. 15: Tạo thêm dữ liệu tính toán, tổng hợp. 45
Hình 2. 16: Danh sách các chiều và phân cấp. 45
Hình 2. 17: Thiết kế CSDL của kho dữ liệu. 47
Hình 2. 18: Lược đồ khối dữ liệu cục bộ về huy động. 48

Hình 3. 1: Các thành phần của OWB. 49
Hình 3. 2: Bảng chiều thời gian. 51
Hình 3. 3: Phân cấp bảng chiều thời gian. 51
Hình 3. 4: Bảng chiều loại hình tiền gửi . 51
Hình 3. 5: Phân cấp chiều loại hình tiền gửi. 52
Hình 3. 6: Bảng chiều khách hàng. 52
Hình 3. 7: Phân cấp bảng chiều khách hàng. 52
Hình 3. 8: Khối cube huy động. 53
Hình 3. 9: Đơn vị đo Cube. 53
Hình 3. 10: Chiều của cube. 53
Hình 3. 11: Thiết lập nguồn dữ liệu. 54
Hình 3. 12: Chiết xuất và xử lý dữ liệu chiều thời gian. 54
Hình 3. 13: Chiết xuất và xử lý dữ liệu chiều loại hình tiền gửi. 54

Hình 3. 14: Chiết xuất và xử lý chiều phân loại khách hàng. 54
Hình 3. 15: Giao diện triển khai thiết kế logic. 55
Hình 3. 16: Giao diện thiết kế kịch bản nạp dữ liệu vào kho. 56
Hình 3. 17: Thông tin về tiến trình nạp dữ liệu. 56
Hình 3. 18: Mã nguồn nạp dữ liệu vào kho. 57
Hình 3. 19: Dữ liệuchiều loại hình tiền gửi . 57
Hình 3. 20: Dữ liệu cube. 58


1

PHẦN MỞ ĐẦU.
1. ĐẶT VẤN ĐỀ.
Hệ thống giao dịch Ngân hàng là một hệ thống với số lượng giao dịch
cực lớn hàng ngày được thực hiện trải dài trên các phần mềm nghiệp vụ như
core bank, Internet Banking, Mobi Banking, Smart Banking… Qua đó tại ra
một khối dữ liệu khổng lồ lưu trữ trải dài trên nhiều hệ thống nghiệp vụ và
không nhất quán. Gây khó khăn việc xử lý và khai thác thông tin hữu ích một
cách nhanh chóng để giúp nhà quản trị, lãnh đạo đưa ra các quyết sách đúng
đắn, kịp thời và hiệu quả cho cơ quản, tổ chức của mình. Ví dụ: thông qua
việc nghiên cứu thói quen mua sắm của các khách hàng thì eBay, Amazon có
biết chính xác các sản phẩm bạn muốn mua là gì để đưa ra gợi ý. Điều ngày
giúp cho khách hàng tiết kiệm thời gian, doanh nghiệp bán được nhiều hàng
hơn.
Với hệ thống dữ liệu tổ chức dữ liệu tốt có thể giúp doanh nghiệp xây
dựng các mô hình dự báo như một công ty viễn thông có thể dự đoán tốt hơn
về việc khách hàng rời mạng. Hay Wal-Mal có thể dự đoán sản phẩm nào sẽ
được bán ra. Đặc biệt với lĩnh vực dịch vụ có số lượng lớn giao dịch như tài
chính, hàng không, viễn thông… nhu cầu về việc tổ chức dữ liệu lớn để đáp
ứng yêu cầu phân tích dự báo là vô cùng cần thiết.

Cuộc khủng hoảng kinh tế năm 2010 đã khiến các tổ chức tài chính
phải nhìn nhận lại định hướng phát triển bền vững thông qua công tác dự báo
nhằm quản lỷ rủi ro mức thấp nhất và nâng cao chất lượng phục vụ khách
hàng dựa trên việc nâng cấp hệ thống phần mềm hoạt động ôn định, dựa trên
nhu cầu của khách hàng. Hệ thống nghiệp vụ liên tục bị quá tải phần lớn là
do tài nguyên dành cho việc thực hiện các báo cáo, các báo cáo nhằm nghiên
cứu nhu cầu khách hàng không thể thực hiện hoặc mất quá nhiều thời gian.
Để giải quyết vấn đề trên, tôi đề xuất xây dựng kho dữ liệu theo phương
pháp tiếp cận phù hợp để giải quyết bái toán. Kho dữ liệu sẽ là nền tảng cho
việc triển khai hệ thống báo cáo phân tích tách biệt với hệ thống giao dịch
nghiệp vụ.

2

2. Mục tiêu luận văn.
Trên cơ sở tính cấp thiết và tính thực tiễn của việc triể khai xây dựng
một hệ thống phục vụ báo cáo phân tích tách biệt với hệ thống giao dịch
nghiệp vụ. Tôi đã nghiên cứu và tìm hiểu, chọn đề tài luận văn là “Nghiên
cứu và xây dựng kho dữ liệu sản phẩm tại Ngân hàng TMCP Đại Dương
dựa trên nền tảng hệ quản trị CSDL Oracle 10g”.
Đây là một vấn đề lớn và khó khăn, tôi bước đầu đã tìm hiểu và làm chủ
được kiến thức về kiến trúc kho dữ liệu. Mục đích của luận văn là nghiên cứu
lý thuyết và áp dụng kiến thức theo cách phù hợp để tiến hành xây dựng kho
dữ liệu tại Ngân hàng TMCP Đại Dương đáp ứng nhu cầu sử dụng hiện tại và
làm nền tảng cho việc triển khai hệ thống Business Intelligence
3. Phương pháp và phạm vi nghiên cứu luận văn.
Đây là đề tài lớn mang tính áp dụng công nghệ và tính đặc thù của từng
lĩnh vực khi triển khai. Để đảm bảo chất lượng và trong khẳ năng cho phép
đề tài xin giới hạn vào nhưng phần cốt lõi của kiến trúc kho dữ liệu trong lĩnh
vực ngân hàng trên nền tảng công nghệ Oracle gồm:

 Tìm hiểu về kiến trúc kho dữ liệu và tính cần thiết cũng như sự khác
biệt so với hệ thống giao dịch nghiệp vụ.
 Tìm hiểu về giải pháp kiến trúc kho dữ liệu của nhà cung cấp giải pháp
Oracle và các công nghệ hỗ trợ việc phân tích dữ liệu nhằm triết xuất
thông tin: Oracle warehouse build, Oracle Business Intelligence
Discover
 Nghiên cứu giải pháp xây dựng kho dữ liệu phù hợp với thực trạng về
nhân lực, chi phí tại Ngân hàng TMCP Đại Dương.
 Tìm hiểu các kiến thức cơ bản về nghiệp vụ ngân hàng thương mại và
cách tổ chức dữ liệu tại hệ thống giao dịch nghiệp vụ tại Ngân hàng
TMCP Đại Dương.
 Tìm hiểu về nhu cầu dữ liệu tri thức từ Ban Điều hành để tổ chức dữ
liệu phù hợp.
 Xây dựng kho dữ liệu với chủ đề sản phẩm dựa trên nền tảng công
nghệ Oracle và thiết lập công cụ khai thác dữ liệu từ kho dữ liệu để
chứng mình tính khả thi và đáp ứng yêu cầu của kho dữ liệu đã xây
dựng.

3

4. Nội dung luận văn.
Luận văn được thực hiện dựa trên nhu cầu thực tế tại Ngân hàng TMCP
Ocean Bank. Và dựa trên quá tính tìm hiểu thực tế nhu cầu và nghiên cứu,
đánh giá các giải pháp công nghệ. Luận được tổ chức thành các nội dung
chính như sau:
Mở đầu: Đặt vấn đề, mục tiêu và phạm vi nghiên cứu của luận văn.
Chương 1: Cơ sở lý thuyết - Trình báy về kiến trúc kho dữ liệu gồm các khái
niêm cơ bản: Định nghĩa kho dữ liệu, kiến truc kho dữ liệu, đặc trưng kho dữ
liệu phương pháp xây dựng kho dữ liệu, phương pháp khai thác dữ liệu theo
mô hình OLAP.

Chương 2: Xây dựng giải pháp kho dữ liệu - Nghiên cứu thực trạng hệ thống
và giải pháp xây dựng kho dữ liệu sản phẩm phù hợp với thực trạng tại Ngân
hàng TMCP Đại Dương.
Chương 3: Cài đặt, thử nghiệm và đánh giá – Cài đặt kho dữ liệu với công
cụ hỗ trợ Oracle Warehouse Build trên nền tảng Oracle 10g.
Kết luận, định hướng: Tổng kết lại kết quả luận văn đã đạt được, kinh
nghiệm từ được trong quá trình thực hiện luận văn. Và đưa định hướng phát
triển trong tương lai.

4

CHƯƠNG 1: LÝ THUYẾT KHO DỮ LIỆU
1.1. Tổng quan về kho dữ liệu.
1.1.1. Lịch sử phát triển của kho dữ liệu:
Kho dữ liệu đã được phát triển vào cuối những năm 1980 để đáp ứng
nhu cầu ngày càng tăng về phân tích dữ liệu và quản lý thông tin nhưng
không thể đạt được bởi hệ thống OLTP. Do hệ thống OLTP được thiết kế để
tối ưu hóa cho giao dịch nghiệp vụ, số lượng dữ liệu giao dịch đã được phát
triển một cách nhanh chóng giữa các phòng ban trong một tổ chức nên việc
thực hiện tích hợp dữ liệu khó khăn hơn. Điều này tạo ra khó khăn cho việc
báo cáo (tích hợp & phân tích dữ liệu).
Kết quả là, một hệ thống riêng được gọi là kho dữ liệuđược thiết kế để
giải quyết vấn đề này. Kho dữ liệu chứa các dữ liệu được tập hợp từ nhiều
nguồn khác nhau như dữ liệu quan hệ, các tập tin phẳng, bảng tính, dữ liệu
từ các nguồn bên ngoài tổ chức…. Và được tổ chức trong một cách tối ưu
hóa cho mục đích báo cáo. Với nền tảng kho dữ liệu được tổ chức tốt sẽ là cơ
sở để triển khai các công cụ báo cáo thân thiện với người sử dụng.

Hinh 1. 1: Sơ đồ luồng dữ liệu

5

1.1.2. Định nghĩa.
Có nhiều định nghĩa kho dữ liệu những chúng đều có một số điểm
chung giống nhau. Theo Bill Inmon - người được biết đến như là cha đẻ của
kho dữ liệu, kho dữ liệu được quy định như sau:
"Data warehoue là một tập hợp dữ liệu tương đối ổn định (nonvolatile) ,
liên kết với thời gian (time-variant), được tích hợp (integrated) theo một chủ
đề (subject-oriented) nhằm hỗ trợ quá trình tạo quyết định về mặt quản lý
(Support management’s decision making process)"
1.2. Đặc trưng kho dữ liệu.
1.2.1. Tính bền vững.
Khi thông tin đã đưa vào kho dữ liệu, dữ liệu không nên thay đổi. Điều
này là hợp lý vì mục đích của một kho dữ liệu là để cho phép ta phân tích
những gì đã xảy ra. Dữ liệu đưa vào kho dữ liệu chỉ để đọc, việc sửa dữ liệu
hầu như không được tiến hành vì điều này có thể dẫn đến phá vỡ sự toàn vẹn.
Thông thường người ta không yêu cầu giảm thời gian đưa dữ liệu vào kho dữ
liệu xuống mức tối thiểu, nhưng cần tối ưu hoá kho dữ liệu sao cho các truy
vấn phục vụ cho việc phân tích đạt tốc độ tốt nhất. Các sơ đồ quan hệ sẽ tạo ra
các Index hợp lý cũng như tạo ra sẵn các dữ liệu kết hợp.

Hinh 1. 2: Tính bền vững của DWH.

1.2.2. Biến thời gian.
Yêu cầu quan trọng cho kho dữ liệu là phạm vi về thời gian dài hơn so
với các hệ thống tác nghiệp. Cơ sở dữ liệu tác nghiệp: dữ liệu có giá trị hiện
thời. Còn dữ liệu của kho dữ liệu: cung cấp thông tin lịch sử (ví dụ như, 5-10
năm trước). Và yếu tố thời gian được lưu trữ trong CSDL.

6


Hinh 1. 3: Đặc trưng biến thời gian.

1.2.3. Hướng chủ đề.
Dữ liệu được tổ chức theo các đối tượng chính hoặc các quá trình kinh
doanh. Ví dụ phổ biến của các dữ liệu theo định hướng đối tượng là khách
hàng, sản phẩm, nhà cung cấp và giao dịch bán… Tập trung vào việc mô
hình hóa và phân tích dữ liệu nhằm hỗ trợ đưa ra quyết định, mà không tập
trung vào các hoạt động hay các xử lý giao dịch hàng ngày

Hinh 1. 4: Đặc trưng hướng chủ đề.


7

1.2.4. Tính tích hợp.
Dữ liệu từ nhiều nguồn khác nhau như từ của các phòng ban trong tổ
chức, từ các nguồn bên ngoài. Và nguồn dữ liệu khác nhau có thể có những
cách khác nhau để xác định một đối tượng cụ thể. Tuy nhiên, trong một kho
dữ liệu chỉ có một định nghĩa của sản phẩm. Điều này đạt được bằng cách sử
dụng giải quyết xung đột về cách xác định đối tượng trong kho dữ liệu. Và
khi chúng ta đạt được điều này, chúng ta nói rằng dữ liệu được tích hợp.
Hinh 1. 5: Đặc trưng tính tích hợp.


1.3. Sự khác nhau giữa hệ thống OLTP và kho dữ liệu
Về cơ bản hệ thống OLTP và kho dữ liệu có một điểm khác biệt chính
đó là kho dư liệu không được tổ chức theo dạng chuẩn 3NF. Nhưng 3NF lại

là chuẩn cho hầu hết các hệ thống OLTP.

8

Sự khác nhau giữa hệ OLTP và kho dữ liệu

OLTP Kho dữ liệu
Tổ chức
Ở dạng chuẩn 3NF Mô hình chiều
Chỉ mục
Ít: tối ưu cho giao dịch
Nhiều: Tối ưu cho báo cáo
Liên kết bàng
Ít Nhiều
Dư thừa dữ liệu
Không
Có
Dữ liệu tổng hợp
Hiếm Phổ biến
Hinh 1. 6: So sánh OLTP với DWH.

Kho dữ liệu và các hệ thống OLTP có những yêu cầu rất khác nhau. Dưới
đây là một số ví dụ về sự khác biệt giữa các kho dữ liệu điển hình và các hệ
thống OLTP
 Khối lượng công việc: Kho dữ liệu được thiết kế để phù hợp truy vấn đặc
biệt và phân tích dữ liệu. Nên khối lượng dữ liệu cần được xử lý không
biết trước được có thể rất nhỏ hoặc rất lớn. Do đó, kho phải được tối ưu
hóa để thực hiện tốt cho một loạt các thể truy vấn và các hoạt động phân
tích. Hệ thống OLTP thiết kế hỗ trợ các các giao dịch đã được định nghĩa
trước.

 Việc chỉnh sửa dữ liệu: kho dữ liệu được cập nhật một cách thường xuyên
bởi quá trình ETL (chạy đêm hoặc hàng tuần) sử dụng kỹ thuật biến đổi
dữ liệu với số lượng lớn. Người sử dụng cuối không trực tiếp cập nhập
kho dữ liệu trừ một số trường hợp đặc biệt như khai phá dữ liệu… Ngược
lại, hệ thống OLTP thì người sử dụng thường xuyên tạo, cập nhập dữ liệu
vào cơ sở dữ liệu. Cơ sở dữ liệu OLTP là luôn được cập nhật và phản ánh
tình trạng hiện tại của mỗi giao dịch kinh doanh.
 Mô hình thiết kế: Kho dữ liệu sử dụng mô hình chiều (như mô hình sao)
để tối ưu hóa việc truy vấn và phân tích dữ liệu. OLTP sử dụng mô hình
thiết kế theo chuẩn (như 3NF) để tối ưu hóa các hoạt động câp
nhập/thêm/xóa và để đảm bảo tính nhất quán của dữ liệu.
 Hoạt động thông thường: Dữ liệu hoạt động thông thường kho dữ liệu có
thể là hàng nghìn hoặc hàng triệu bản ghi. OLTP truy cập thông thường
chỉ liên quan đến một số lượng ít bản ghi.
 Dữ liệu lịch sử: Kho dữ liệu có thể dữ liệu với thời gian dài như 5 năm, 10
năm… nhằm mục đích hỗ trợ quá trình phân tích. OLTP chỉ lưu dữ liệu
trong thời gian ngắn. Đó là những dữ liệu cần thiết để

9

1.4. Kiến trúc kho dữ liệu.
1.4.1. Kiến trúc kho dữ liệu cơ bản
Với kiến trúc cơ bản, người sử dụng cuối cùng nhận được dữ liệu từ
các hệ thống nguồn thông qua kho dữ liệu.

Hinh 1. 7: Kiến trúc kho dữ liệu cơ bản.

Siêu dữ liệu và dữ liệu thô của một hệ thống OLTP truyền thống là
sẵn có. Tóm lược rất có giá trị trong kho dữliệu, vì chúng tính toán trước các
hoạt động lâu dài như truy vấn kho dữ liệu điển hìnhđể lấy thông tin về lượng

hàng được bán trong tháng
1.4.2. Kiến trúc kho dữ liệu với vùng đệm.

Hinh 1. 8: Kiến trúc kho dữ liệu vùng đệm.

Với kiến trúc này, cần làm sạch và xử lý dữ liệu hoạt động trước khi
đưa nó vào kho dữ liệu, mặc dù hầu hết kho dữ liệu sử dụng một vùng trung
gian thay thế. Một vùng trung gian sẽ làm đon giản hoá việc quản lý kho dữ
liệu chung.

10

1.4.3. Kiến trúc kho dữ liệu với vùng đệm và kho dữ liệu cục bộ.
Mặc dù kiến trúc trong hình 7 là khá phổ biến, tùy theo yêu cầu ta có
thể kiếntrúc kho dữ liệu cho các nhóm khác nhau bên trong của tổ chức. Điều
này có thế thực hiện bằng cách thêm các kho dữ liệu cục bộ, đó là các hệ
thống được thiết kế cho một phạm vi cụ thể của doanh nghiệp. Hình 8 minh
hoạ một ví dụ nơi mua, bán hàng, và hàng tồn kho được tách ra. Trong ví dụ
này, một nhà phân tích tài chính có thể muốn phân tích dữ liệu lịch sử cho
mua và bán

Hinh 1. 9: Kiến trúc DWH với vùng đệm, DM.

1.5. Thiết kế kho dữ liệu
1.5.1. Thiết kế logic và thiết kế vật lý trong kho dữ liệu
Để xây dựng một kho dữ liệu thì cần xác định các yêu cầu kinh doanh
và thống nhất phạm vi ứng dụng để từ đó đưa ra một bản thiết kế khái niệm.
Bây giờ cần phải chuyển thiết kế khái niệm thành một hệ thống chuyển giao.
Để làm như vậy, cần tạo ra các thiết kế logic và thiết kế vật lý cho các kho dữ
liệu. Cần xác định:

 Nội dung dữ liệu cụ thể.
 Mối quan hệ bên trong và giữa các nhóm dữ liệu.
 Môi trường hệ thống hỗ trợ kho dữ liệu.
 Quá trình biến đổi dữ liệu cần thiết.
 Tần suất mà dữ liệu được làm mới.
Thiết kế logic xem xét các mối quan hệ logic giữa các chủ thể. Thiết
kế vật lýxem xét cách thức hiệu quả nhất của việc lưu trữ và gọi ra các đối
tượng, cũng như xử lý chúng từ một chuyển dịch và quan điểm sao lưu, phục
hồi.
Thiết kế hướng tới các nhu cầu của người dùng cuối. Người dùng cuối
thường muốn thực hiện phân tích và xem xét dữ liệu tổng hợp, hơn là giao

11

tác riêng lẻ. Tuy nhiên, người dùng cuối có thể không biết những gì họ cần
cho đến khi họ nhìn thấy nó. Ngoài ra, một thiết kế được lên kế hoạch chu
đáo có tính đến sự tăng trưởng và thay đổi khi nhu cầu của người dùng thay
đổi và tiến hóa. Với thiết kế logic, tập trung vào các yêu cầu thông tin và lưu
các chi tiết thực thi cho sau này.
1.5.2. Thiết kế logic.
Một thiết kế logic là trừu tượng và dựa trên các khái niệm. Ta không
đề cập tới những chi tiết cài đặt vật lý. Ta chỉ đề cập tới việc xác định những
loại thông tin mà ta cần. Một kỹ thuật ta cần sử dụng làm mô hình cho các
yêu cầu thông tin logic của tổ chức là mô hình thực thể quan hệ. Mô hình
thực thể quan hệ liên quan đến việc xác định những thứ quan trọng (thực
thể), các tính chất của những thuộc tính, và làm thế nào chúng liên hệ được
với nhau (các mối quan hệ).
Quá trình thiết kế logic liên quan đến việc sắp xếp dữ liệu thành một
chuỗi các mối quan hệ logic được gọi là các thực thể và thuộc tính. Một thực
thể đại diện cho một mảng của thông tin. Trong cơ sở dữ liệu quan hệ, một

thực thể thường ánh xạ tới một bảng. Một thuộc tính là một thành phần của
một thực thể giúp xác định tính duy nhất của thực thể. Trong cơ sở dữ liệu
quan hệ, một thuộc tính ánh xạ tới một cột.
Để chắc chắn rằng dữ liệu ta có là nhất quán, ta cần phải sử dụng định
danh duy nhất. Một định danh duy nhất là một cái gì đó ta thêm vào bảng để
ta có thể phân biệt các phần tử giống nhau khi nó xuất hiện ở những nơi khác
nhau. Trong một thiết kế vật lý, đó thường là một chính khoá.
Trong khi sơ đồ thực thể quan hệ theo truyền thống được kết hợp với
các mô hình chuẩn hóa mức cao như các ứng dụng OLTP, kỹ thuật vẫn còn
hữu ích cho thiết kế kho dữ liệu ở dạng mô hình chiều. Trong mô hình chiều,
thay vì tìm cách phát hiện các đơn vị nguyên tử của thông tin (như các thực
thể và các thuộc tính) và tất cả các mối quan hệ giữa chúng, ta xác định thông
tin đó thuộc về một bảng sự kiện trung tâm và thông tin đó thuộc các bảng
chiều liên kết của chúng. Ta xác định các chủ thể nghiệp vụ hoặc các trường
dữ liệu, xác định các mối quan hệ giữa các chủ thể kinh doanh, và tên các
thuộc tính cho mỗi chủ thể.
Thiết kế logic kết quả nên là một tập thực thể và thuộc tính tương ứng
với các bảng sự kiện và các bảng chiều và một mô hình của dữ liệu hoạt động
từ nguồn thành thông tin hướng chủ thể trong lược đồ kho dữ liệu đích.
Ta có thể tạo ra những thiết kế logic sử dụng bút và giấy, hoặc sử
dụng một công cụ thiết kế như Oracle Warehouse Builder, đặc biệt được thiết

12

kế để hỗ trợ cho mô hình hóa quá trình ETL; hoặc Oracle Designe, một công
cụ mô hình hóa mục đích chung.
1.6. Lược kho dữ liệu.
1.6.1. Lược đồ sao.
Đây là lược đồ phổ biến nhất được sử dụng trong thiết kế chiều trong
kho dữ liệu. Có một bảng sự kiện tại trung tâm của lược đồ bao quanh bởi

một số bảng chiều Trong lược đồ sao, kích thước liên quan đến nhóm lại với
nhau như là các cột trong bảng kích thước và được sử dụng để lưu trữ dữ liệu
của sự kiện được lưu trữ trong sự kiện (fact).

1.6.2. Lược đồ bông tuyết.
Bao gồm một bảng sự kiện bao quanh bởi nhiều bảng chiều có thể
được kết nối với bảng chiều khác thông qua mối quan hệ nhiều-một. Lược đồ
bông tuyết là một loại lược đồ sao, tuy nhiên nó là phức tạp hơn so với một
lược đồ sao. Lược đồ bông tuyết được thiết kế từ các lược đồ sao bằng cách
tiếp tục chuẩn hóa các bảng kích thước để loại bỏ dữ liệu dư thừa. Do đó
trong lược đồ bông tuyết, thay vì có một bảng kích thước lớn kết nối với một
bảng thực tế thì sẽ có một nhóm các bảng kích thước nhiều. Giản đồ này
cũng giúp tiết kiệm không gian tuy nhiên nó làm tăng số lượng của bảng kích
thước.
Hinh 1. 10: Lược đồ ngôi sao.

13


1.6.3. So sánh lược đồ sao và bông tuyết.
Tùy theo thực tế mà ta lựa chọn lược đồ hình sao hay tuyết rơi. Việc
lựa chọn được cân nhắc giữa 2 yếu tố: thời gian đáp ứng truy vấn và mức độ
kiểm soát tính chặt chẽ dữ liệu. Lược đồ dạng tuyết rơi có thể thích hợp khi
dữ liệu bảng chiều trở nên quá lớn và nhiều thuộc tính.
Tuy sự khác nhau thể hiện rất nhỏ về mặt lý thuyết nhưng khi thực
hiện chúng trong thực tế có thể dẫn tới các kết quả khác hẳn nhau.
Sau đây là một số so sánh cơ bản giữa 2 lược đồ.
Lược đồ sao Lược đồ bông tuyết
Dễ hiểu
Dễ dàng hơn cho người

dùng doanh nghiệp và các
nhà phân tích truy vấn dữ
liệu.
Có thể là khó khăn hơn cho người
dùng doanh nghiệp và các nhà
phân tích do số lượng dữ liệu phải
xử lý
Chiều bảng
Chỉ có một bảng chiều cho
mỗi chiều. Bảng chiều
không theo chuẩn 3NF.
Nhiều hơn 1 bảng chiều cho mỗi
chiều. Bảng chiều chuẩn hóa theo
3NF.
Truy vấn phức tạp
Các truy vấn là rất đơn giản
và dễ hiểu
Truy vấn phức tạp hơn do phải kết
hợp các khóa ngoại giữa các bảng
chiều
Hiệu suất truy vấn
Hiệu suất cao. Engine có
thể tối ưu hóa và tăng hiệu
suất truy vấn.
Có nhiều liên kết khóa ngoài nên
thời gian truy vấn lâu hơn so với
lược đồ sao.
Không gian lưu trữ
Tốn nhiều không gian lưu
trữ cho dữ liệu chiều

Tốn ít không gian lưu trữ dữ liệu
chiều
Số lượng khóa ngoại

Ít
Nhiều
Loại data
warehouse
Phù hợp với bất kỳ kho dữ
liệu nào (lớn hoặc nhỏ)
Phù hợp với kho dữ liệu nhỏ, kho
dữ liệu cục bộ.
Hinh 1. 12: So sánh 2 lược đồ bông tuyết và ngôi sao.

Hinh 1. 11: Lược đồ hình bông tuyết.

14

1.6.4. Lược đồ khác.
Một số lược đồ trong các môi trường kho dữ liệu sử dụng dạng chuẩn ba
hơn là lược đồ hình sao. Một lược đồ khác mà đôi khi hữu ích là lược đồ
bông tuyết, đó là một lược đồ hình sao với các chiều chuẩn hóa trong một
cấu trúc cây
1.7. Thiêt kế vật lý.
1.7.1. Chuyển thiết kế logic thành thiết kế vật lý.
Thiết kế logic là cái ta vẽ với bút và giấy hoặc thiết kế với Oracle
Warehouse Builder hoặc Oracle Designer trước khi xây dựng kho dữ liệu.
Thiết kế vật lý là việc tạo cơ sở dữ liệu với các lệnh SQL. Trong quá trình
thiếtkế vật lý, ta chuyển đổi dữ liệu thu thập được trong pha thiết kế logic
vào một mô tả của cấu trúc cơ sở dữ liệu vật lý.

1.7.2. Tạo thiết kế vật lý
Trong pha thiết kế vật lý, ta xác định một mô hình cho kho dữ liệu
gồm các thực thể, các thuộc tính, và các mối quan hệ. Các thực thể được liên
kết với nhau sử dụng các mối quan hệ. Các thuộc tính được sử dụng để mô tả
các thực thể. Định danh duy nhất phân biệt giữa một trường hợp của một
thực thể với các trường hợp khác

Hinh 1. 13: So sánh thiết kế logic với thiết kế vật lý.

Trong thiết kế vật lý, ta phải chuyển các lược đồ thiết kế logic thành
các cấu trúc dữ liệu thực tế. Cụ thể , ta phải ánh xạ:
 Các thực thể tới các bảng.
 Các mối quan hệ tới các ràng buộc khóa chính.
 Các thuộc tính tới các cột.
 Các định danh duy nhất tới các ràng buộc khóa duy nhất.
Một khi ta đã chuyển thiết kế logic thành một thiết kế vật lý, ta sẽ cần
phải tạo ra một số hoặc tất cả các cấu trúc sau:
 Các không gian bảng.

15

 Các bảng và các bảng phân vùng.
 Các khung nhìn.
 Các ràng buộc toàn vẹn.
 Các chiều.
1.8. Đối tượng trong kho dữ liệu.
1.8.1. Sự kiện và bảng sự kiện.
Sự kiện gần như là các hoạt động tác nghiệp của doanh nghiệp hay tổ
chức. Không giống như bảng chiều, bảng sự kiện thường lưu thông tin về bản
thân hoạt động tác nghiệp được thực thi. Bảng sự kiện bao gồm các đại lượng

có thể đo lường, đơn vị đo lường trong hoạt động của doanh nghiệp. Mỗi
DWH bao gồm một hoặc nhiều bảng sự kiện
Tính chất quan trọng nhất của bảng sự kiện là nó chứa các dữ kiện
kiểu số, có thể tính tổng hay theo một công thức toán học nào đó để cung cấp
thông tin mang tính lịch sử về quá trình tác nghiệp của đơn vị. Mỗi bảng sự
kiện chứa một chỉ mục nhiều phần, như các khóa ngoài, là các khóa chính tại
các bảng chiều có liên quan và chứa các thuộc tính của những bản ghi sự
việc.
1.8.2. Chiều và bảng chiều.
Chiều là một mặt khía cạnh nghiệp vụ mà đơn vị muốn dựa vào đó để
xác định kết quả hoạt động. Chiều thường được xác định từ các thực thể kinh
doanh có tác động đến kết quả. Sau một thời gian, có thể chiều này bị loại bỏ
vì mức độ tác động đến sự thay đổi hầu như không có, chiều mới có thể được
phát hiện và ghi nhận.
Một bảng chiều là bảng chứa các thuộc tính khác nhau có mục đích
giải thích cho khóa chiều trong bảng dữ kiện. Các thuộc tính này chỉ ra hoàn
cảnh của thực thể mà sự kiện nghiệp vụ diễn ra. Khác với bảng sự kiện, bảng
chiều có chứa các thông tin có tính chất mô tả. Giá trị các thuộc tính ở bảng
chiều về sau thường được sử dụng để làm nhãn cho cột hay hàng thống kê.
1.8.3. Khối dữ liệu.
Một khối dữ liệu về cơ bản là có thể có N chiều (N-D). Những cạnh
của khối được gọi là các chiều (dimensions), mà đó là các mặt hoặc các thực
thể ứng với những khía cạnh mà tổ chức muốn ghi nhận. Mỗi chiều có thể
kết hợp với một bảng chiều (dimension table) nhằm mô tả cho chiều đó. Ví
dụ, một bảng chiều của Sản phẩm có thể chứa những thuộc tính như
MaSanpham, Mota, Tensanpham, LoaiSP,… mà có thể được chỉ ra bởi nhà
quản trị hoặc các nhà phân tích dữ liệu. Với những chiều không được phân
loại, như là Thời gian, hệ thống kho dữ liệu sẽ có thể tự động phát sinh tương

16

ứng với bảng chiều (dimension table) dựa trên loại dữ liệu. Cần nói thêm
rằng, chiều Thời gian trên thực tế có ý nghĩa đặc biệt đối với việc hỗ trợ
quyết định cho các khuynh hướng phân tích. Thường thì nó được mong muốn
có một vài tri thức gắn liền với lịch và những mặt khác của chiều thời gian.
Chúng ta có thể hình dung khối dữ liệu được tổ chức xung quanh một
chủ đề được thể hiện bởi một bảng sự kiện (fact table) của nhiều độ đo số
học (là các đối tượng của phân tích). Ví dụ, một bảng sự kiện có thể chứa số
mặt hàng bán, thu nhập, tồn kho, ngân sách,… Mỗi độ đo số học phụ thuộc
vào một tập các chiều cung cấp ngữ cảnh cho độ đo đó. Vì thế, các chiều kết
hợp với nhau được xem như xác định duy nhất độ đo, là một giá trị trong
không gian đa chiều. Ví dụ như một kết hợp của Sản phẩm, Thời gian, Thị
trường vào 1 thời điểm là một độ đo duy nhất so với các kết hợp khác.

Hinh 1. 14: Khối dữ liệu 3 chiều.

Vì vậy, nếu mỗi chiều chứa nhiều mức trừu tượng, dữ liệu có thể được
xem từ nhiều khung nhìn linh động khác nhau. Một số thao tác điển hình của
khối dữ liệu như roll-up (tăng mức độ trừu tượng), drill-down (giảm mức độ
trừu tượng hoặc tăng mức chi tiết), slice and dice (chọn và chiếu), và pivot
(định hướng lại khung nhìn đa chiều của dữ liệu), cho phép tương tác truy
vấn và phân tích dữ liệu rất tiện lợi. Những thao tác đó được biết như Xử lý
phân tích trực tuyến (On-Line Analytical Processing – OLAP)
Lát cắt (Slice - dice) Lát cắt là một “mặt phẳng” được chỉ ra bởi một tập
các chiều nằm trong tập chiều của khối tại các giá trị cố định của các chiều
còn lại.