ĐẠI HỌC QUỐC GIA TP.HCM
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
BÀI THU HOẠCH
HỆ HỖ TRỢ RA QUYẾT ĐỊNH
GVHD: PGS. TS. ĐỖ PHÚC
HVTH: ĐOÀN VĂN HUYÊN CH1301091
NGUYỄN HỮU LỘC CH1301023
ỨNG DỤNG
DATA WAREHOUSE VÀ OLAP
HỖ TRỢ RA QUYẾT ĐỊNH
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
TP HCM, tháng 06 năm 2014NHẬN XÉT CỦA GVHD


khó khăn.
Từ những vấn đề trên những nhà quản trị đòi hỏi một hệ thống có thể hỗ trợ họ ra
quyết định. Hệ thống đó phải thật chính xác và khách quan và hỗ trợ nhà quản trị ra quyết
định thật chính xác và nhanh chóng. Từ đó nhiều hệ hỗ trợ ra quyết định ra đời. Đó cũng
là một thành phần quan trọng trong hệ thống quản trị doanh nghiệp thông minh –
Business Intelligence (BI).
Trong số những hệ hỗ trợ ra quyết định, có thể nói OLAP là công cụ đơn giản và nhanh
chóng nhất. Tuy là nó cần các nhà quản trị phải bỏ thêm ít thời gian và trí óc để phân tích
các báo cáo thu được, nhưng nó làm việc rất nhanh và chi phí bỏ ra cũng rất thấp. Nó
thích hợp cho các quyết định kinh doanh dựa trên số liệu thu thập được trong quá trình
hoạt động của tổ chức, doanh nghiệp. Dữ liệu được cập nhật liên tục và những nhà quản
trị có thể phân tích và ra quyết định tức thời. Để hoạt động tốt OLAP cần kết hợp với một
Data Warehouse (kho dữ liệu) – nơi chứ tất cả dữ liệu cần thiết cho quá trình tạo lập báo
cáo, xây dựng bảng biểu. OLAP và Data Warehouse có mối quan hệ mật thiết tạo nên một
hệ hỗ trợ ra quyết định mạnh mẽ và đơn giản.
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 4
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
I. HỆ HỖ TRỢ RA QUYẾT ĐỊNH
1. Khái niệm
Hệ hỗ trợ ra quyết định là phương pháp lấy tri thức đúng để cho ra quyết định hợp
lý vào đúng lúc và có mức phí hợp lý. Đó là sự kết hợp giữa tri thức và việc tạo lập
quyết định. (Knowledge – Decision making).
Khái niệm hệ hỗ trợ ra quyết định được đề xuất bởi Michael S.Scott Morton vào
những năm 1970. Hệ hỗ trợ ra quyết định bao gồm:
- Phần mềm máy tính.
- Chức năng hỗ trợ ra quyết định.
- Làm việc với bài toán có cấu trúc yếu.
- Hoạt động theo cách tương tác với người dùng.
- Được trang bị nhiều mô hình phân tích và mô hình dữ liệu.


Bảng I.3.1: Các hệ hỗ trợ ra quyết định.
Tên Lĩnh vực ứng dụng
GADS: Geodata Analysis Display System Phân tích và cung cấp tài nguyên địa lý
PMS: Portfolio Management System Tư vấn và quản trị đầu tư
IRIS:Industrial Relations Information
Phân tích chất lượng và bố trí nhân lực
trong sản xuất
PROJECTOR Hoạch định kế hoạch tài chính
IFPS:Interactive Financial Planning System Phân tích tài chính, giá thành, sản phẩm
BRANDAID
Phân tích thị trường, ngân sách, quảng
cáo
4. Các thành phần của một hệ hỗ trợ ra quyết định
Một cách hình dung về các thành phần của một hệ hỗ trợ ra quyết định (DDS –
decision support system) và quan hệ giữa chúng là sử dụng các khái niệm đối thoại
(dialog), dữ liệu (data) và mô hình (model). Đối với những người thiết kế hệ thống
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 7
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
DDS cũng như những người sử dụng hệ thống, điều quan trọng là hiểu được các
thành phần này được thiết kế như thế nào. Người sử dụng cần phải biết có thể yêu
cầu cái gì ở DDS. Người thiết kế phải biết được DDS có thể cung cấp cái gì.
Hình I.4.1: Mô hình hệ hỗ trợ ra quyết định
Các kỹ thuật mới có nhiều ảnh hưởng đến các thành phần đối thoại, dữ liệu, và mô
hình; ví dụ như giao diện đồ họa hay cơ sở dữ liệu quan hệ. Ngoài ra trí tuệ nhân
tạo cũng cung cấp các khả năng biểu diễn và sử dụng mô hình trong những hình
thức mới.
• Thành phần đối thoại:
Từ cách nhìn của người sử dụng, thành phần đối thoại là toàn bộ hệ thống. Cách
dùng hệ thống, hướng dẫn cách vận hành của hệ thống và thể hiện các trả lời của
hệ thống đều thông qua thành phần đối thoại. Bennett gọi các yếu tố này bằng

HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 9
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
tế, còn theo nghĩa hẹp nó mô tả về cách vận hành của hệ thống và không thực
hiện một phép tối ưu nào.
Nói về tính tình cờ, hầu hết các hệ thống đều mang tính xác suất, nghĩa là hành
vi của hệ thống không thể được đoán trước một cách chính xác, các dữ liệu nhập
vào đều mang tính xác suất thống kê và các dữ liệu xuất ra cũng vậy. Tuy vậy, đa
số các mô hình toán học đều là mô hình tất định (determintistic). Các mô hình
tiền định thường dễ xây dựng hơn, ít tốn kém về thời gian và tiền bạc hơn.
Về tính tổng quát, có mô hình có thể chỉ được dùng với một hệ thống (custom-
build model), nhưng cũng có những mô hình được xây dựng chung cho nhiều hệ
thống khác nhau (ready-build model). Nói chung, custom-build model cung cấp
một cái nhìn kỹ hơn về một hệ thống cụ thể, tuy nhiên thường tốn kém hơn để
xây dựng vì phải làm từ những việc nhỏ nhất.
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 10
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
II. DATA WAREHOUSE – KHO DỮ LIỆU
1. Data Warehouse là gì?
Kho dữ liệu là một cơ sở dữ liệu được tập hợp từ nhiều nguồn của một tổ chức và
chủ yếu được dùng cho việc báo cáo (reporting) và phân tích (analysis)
hay
Kho dữ liệu là tuyển tập các cơ sở dữ liệu tích hợp, hướng chủ đề, được thiết kế để
hỗ trợ cho chức năng trợ giúp quyết định
2. Các mục tiêu của Data Warehouse
2.1 Truy cập dễ dàng
Thông tin lưu trữ trong data warrehouse phải trực quan và dễ hiểu đối với
người dùng. Nói cách khác, dữ liệu nên được trình bày thông qua các tên gọi
quen thuộc và gần gũi với nghiệp vụ của người dùng.
Có thể phân chia businiess user ra 2 loại. Người dùng cấp thấp chủ yếu thao tác
trên các thông tin chi tiết. Chẳng hạn như nhập số liệu về một khách hàng, theo

Trading trong database A được thể hiện đầy đủ như trên, nhưng trong database
B có khi lại được trình bày dưới dạng viết tắt như Intl. Biz Trading.
Một đặc điểm nữa của dữ liệu database là không có database nào chứa dữ liệu
sạch 100%. Cho dù có là dữ liệu của một công ty hàng đầu về IT như Google,
Amazon, Microsoft… đảm bảo vẫn có lỗi. Database càng to càng dễ có dữ liệu
không sạch. Một ví dụ dễ thấy là một trường Description có thể chứa các ký tự
điều khiển CR LF. Điều này xảy ra khi người dùng nhấn Enter nhiều lần để tạo
ra các đoạn văn bản trong cùng một ô area box. Nhiều lúc dữ liệu sai xuất hiện
trong database là do lỗi lập trình. Tôi đã gặp một trường hợp như sau. Một
trường datetime trong Oracle database có giá trị hẳn hoi (not null) nhưng
không sao convert được sang kiểu varchar2. Tìm hiểu một hồi mới thấy trong
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 12
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
một số bản ghi, giá trị thực của trường đó là… vô định, tức là dữ liệu thì có
nhưng nó không mang một giá trị cụ thể nào. Lý do có lẽ là một Java developer
nào đó khi tạo lập một Date instance …. quên mất không assign một giá trị nào
cho đối tượng đó. Do vậy, đối tượng thì có nhưng giá trị thực trong nó thì vô
định. Về mặt kỹ thuật mà nói, điều này vẫn hợp lệ nên vẫn được chèn vào
database. Chỉ khi nào convert dữ liệu thì lỗi này mới xuất hiện, nếu không nó
sẽ “nằm im” trong suốt cả vòng đời của ứng dụng mà không ai biết.
Nói vậy để thấy, trước khi được đưa vào data warehouse, dữ liệu cần phải được
làm sạch và đảm bảo về chất lượng. Có làm sạch rồi thì việc đồng nhất dữ liệu
mới trở nên dễ dàng. Một nguyên tắc đơn giản được đặt ra cho quá trình này là:
- Nếu dữ liệu có cùng tên, chúng bắt buộc phải cùng chỉ đến một thực thể.
- Ngược lại, nếu dữ liệu chỉ đến các thực thể khác nhau, chúng phải được
đặt tên khác nhau.
Đây chính là những công việc chủ đạo của quá trình ETL (Extract – Transform
– Load).
2.3 Thích nghi với thay đổi
Thay đổi là điều không thể tránh khỏi cho bất cứ ứng dụng nào, không riêng gì

Đồng thời, từ data warehouse, người ta có thể xây dựng các cube mà không tốn
quá nhiều công sức. Dựa trên cube, các công cụ phân tích sẽ được dùng để
phân tích dữ liệu cực kỳ nhanh chóng và trực quan.
2.6 Thành công
Hiển nhiên sản phẩm được tạo ra cũng phải hướng đến thành công. Trong
trường hợp của data warehouse, nó phải đem lại giá trị thực tế cho người dùng
như đã nói ở trên và phải được dùng liên tục thì mới được coi là thành công.
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 14
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
Việc có hay không có Data Warehouse trong một tổ chức hoàn toàn không
mang tính bắt buộc. Không có data warehouse, người ta vẫn có thể tạo ra
report nhưng dĩ nhiên mất nhiều công sức hơn. Để được công nhận, giá trị
business mà data warehoue đem lại phải lớn hơn công sức và tiền của bỏ ra đầu
tư vào nó.
Trong nhiều tổ chức, business user ban đầu thường không hề có chút ý niệm về
data warehouse hoặc thậm chí hoài nghi về nó. Nhưng một khi người dùng đã
quen với nó, người ta sẽ thích nó và muốn ngày càng có nhiều dữ liệu hơn
trong data warehouse đơn giản bởi vì nó cung cấp rất nhiều lựa chọn và hỗ trợ
ra quyết định khá tốt. Đó gọi là thành công.
3. Cấu trúc dữ liệu cho Data Warehouse
Vì dữ liệu trong kho dữ liệu rất lớn và không có những thao tác như sửa đổi hay tạo
mới nên nó được tối ưu cho việc phân tích và báo cáo. Các thao tác với dữ liệu của
kho dữ liệu dựa trên cơ sở là Mô hình dữ liệu đa chiều (multidimensional data
model), được mô hình vào đối tượng gọi là data cube. Data cube là nơi trung tâm
của vấn đề cần phân tích, nó bao gồm một hay nhiều tập dữ kiện (fact) và các dữ
kiện được tạo ra từ nhiều chiều dữ kiện khác nhau (dimention).
Ví dụ: Một thống kê doanh số bán hàng dựa trên ba yếu tố là: địa điểm, thời gian và
chủng loại hàng. Data cube là vấn đề “Thống kê bán hàng” với ba chiều là ba yếu
tố: địa điểm, thời gian và chủng loại hàng. Bảng fact là bảng tổng hợp dữ liệu của
mối liên quan của doanh số với 3 yếu tố.

phân tích cho các ứng dụng client.
Trong khi kho dữ liệu và data mart lưu trữ dữ liệu cho phân tích, thì OLAP là kỹ
thuật cho phép các ứng dụng client truy xuất hiệu quả dữ liệu này. OLAP cung cấp
nhiều lợi ích cho người phân tích, cho ví dụ như:
- Cung cấp mô hình dữ liệu đa chiều trực quan cho phép dễ dàng lựa chọn, định
hướng và khám phá dữ liệu.
- Cung cấp một ngôn ngữ truy vấn phân tích, cung cấp sức mạnh để khám phá
các mối quan hệ trong dữ liệu kinh doanh phức tạp.
- Dữ liệu được tính toán trước đối với các truy vấn thường xuyên nhằm làm cho
thời gian trả lời rất nhanh đối với các truy vấn đặc biệt.
- Cung cấp các công cụ mạnh giúp người dùng tạo các khung nhìn mới của dữ
liệu dựa trên một tập các hàm tính toán đặc biệt.
OLAP được đặt ra để xử lý các truy vấn liên quan đến lượng dữ liệu rất lớn mà nếu
cho thực thi các truy vấn này trong hệ thống OLTP sẽ không thể cho kết quả hoặc sẽ
mất rất nhiều thời gian.
2. Mô hình dữ liệu đa chiều
Các nhà quản lý kinh doanh có khuynh hướng suy nghĩ theo “nhiều chiều”
(multidimensionally). Ví dụ như họ có khuynh hướng mô tả những gì mà công ty
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 17
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
làm như sau: “Chúng tôi kinh doanh các sản phẩm trong nhiều thị trường khác
nhau, và chúng tôi đánh giá hiệu quả thực hiện của chúng tôi qua thời gian”.
Những người thiết kế kho dữ liệu thường lắng nghe cẩn thận những từ đó và họ
thêm vào những nhấn mạnh đặc biệt của họ như: “Chúng tôi kinh doanh các sản
phẩm trong nhiều thị trường khác nhau, và chúng tôi đánh giá hiệu quả thực hiện
của chúng tôi qua thời gian”.
Suy nghĩ một cách trực giác, việc kinh doanh như một khối (cube) dữ liệu, với các
nhãn trên mỗi cạnh của khối (xem hình bên dưới). Các điểm bên trong khối là các
giao điểm của các cạnh. Với mô tả kinh doanh ở trên, các cạnh của khối là Sản
phẩm, Thị trường, và Thời gian. Hầu hết mọi người đều có thể nhanh chóng hiểu và

các thuộc tính như Năm, Quý, Tháng và Ngày. Mặt khác, các thuộc tính của một
chiều có thể được tổ chức vào một lưới mà chỉ ra một phần trật tự của chiều. Vì thế,
cũng với chiều Thời gian có thể được tổ chức thành Năm, Quý, Tháng, Tuần và
Ngày. Với sự sắp xếp này, chiều Thời gian không còn phân cấp vì có những tuần
trong năm có thể thuộc về nhiều tháng khác nhau.
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).
Những nhà ra quyết định thường có những câu hỏi có dạng như “tính toán và xếp
hạng tổng số lượng hàng hoá bán được theo mỗi quốc gia (hoặc theo mỗi năm)”. Họ
cũng muốn so sánh hai độ đo số học như số lượng hàng bán và ngân sách được
tổng hợp bởi cùng các chiều. Như vậy, một đặc tính để phân biệt của mô hình dữ
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 19
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
liệu đa chiều là nó nhấn mạnh sự tổng hợp của các độ đo bởi một hoặc nhiều chiều,
mà đó là một trong những thao tác chính yếu để tăng tốc độ xử lý truy vấn.
3. Các mô hình lưu trữ hỗ trợ OLAP
Dịch vụ OLAP hỗ trợ nhiều mô hình lưu trữ dữ liệu khác nhau, mỗi mô hình có các
ưu và khuyết điểm riêng, chúng được sử dụng tuỳ theo mục đích khai thác.
3.1 Mô hình Multidimensional OLAP (MOLAP)
Mô hình OLAP đa chiều (MOLAP) lưu trữ dữ liệu cơ sở (là dữ liệu từ các
bảng của kho dữ liệu hoặc data mart) và thông tin tổng hợp (là các độ đo được
tính toán từ các bảng) trong các cấu trúc đa chiều gọi là các khối (cube). Các
cấu trúc này được lưu bên ngoài cơ sở dữ liệu data mart hoặc kho dữ liệu.
Hình III.3.1: Mô hình dữ liệu MOLAP
Lưu trữ các khối (cube) trong cấu trúc MOLAP là tốt nhất cho các truy vấn

một cấu trúc ROLAP để giảm không gian đĩa bị chiếm dụng, hơn nữa còn để
loại trừ dữ liệu trùng lắp. Lưu trữ dữ liệu trong cấu trúc ROLAP cung cấp các
lợi ích sau:
- ROLAP cho phép Cube Builder tự động tạo chỉ mục.
- ROLAP ánh xạ các tổng hợp có sẵn từ data mart hoặc kho dữ liệu. OLAP
Manager được phép xử dụng các tổng hợp có sẵn để tổng hợp mà không
cần tính toán lại cho mỗi truy vấn.
- ROLAP tạo đòn bẩy cho hệ quản trị cơ sở dữ liệu quan hệ nhằm cho các
nhà quản trị hệ thống duy trì nó hiệu quả hơn.
- ROLAP hỗ trợ Microsoft SQL Server, Oracle, Access và Open Database
Connectivity (ODBC).
3.3 Mô hình Hybird OLAP (HOLAP)
Mô hình OLAP lai (HOLAP) là sự kết hợp giữa MOLAP và ROLAP.
Hình III.3.3: Mô hình dữ liệu HOLAP
Lưu trữ các khối (cube) trong cấu trúc HOLAP là tốt nhất cho các truy vấn
tổng hợp dữ liệu thường xuyên dựa trên một lượng lớn dữ liệu cơ sở. Ví dụ,
chúng ta sẽ lưu trữ dữ liệu bán hàng theo hàng quý, hàng năm trong cấu trong
MOLAP và dữ liệu hàng tháng, hàng tuần và hàng ngày trong cấu trúc ROLAP.
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 22
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
Lợi ích của việc lưu trữ trong cấu trúc HOLAP là:
- Lấy dữ liệu trong khối (cube) nhanh hơn bằng cách sử dụng xử lý truy vấn
tốc độ cao của MOLAP.
- Tiêu thụ ít không gian lưu trữ hơn MOLAP.
- Tránh trùng lắp dữ liệu.
3.4 So sách các mô hình
Bảng III.3.1: Bảng so sánh tổng hợp ba mô hình lưu trữ hỗ trợ OLAP
MOLAP ROLAP HOLAP
Lưu trữ dữ liệu cơ sở Khối Bảng quan hệ Bảng quan hệ
Lưu trữ thông tin tổng hợp Khối Bảng quan hệ Khối

nhiều partition. Mỗi partition có thể lấy dữ liệu một nguồn dữ liệu khác nhau và có
thể lưu trong một vị trí riêng biệt (separate). Dữ liệu của một partition có thể được
cập nhật độc lập với các partition khác trong một khối. Ví dụ, dữ liệu của một khối
có thể được chia theo thời gian, với một partition chứa dữ liệu của năm hiện hành,
một partition khác chứa dữ liệu của năm trước, và một partition thứ ba chứa tất cả
dữ liệu của các năm trước nữa.
Các partition của một khối có thể được lưu trữ độc lập trong các cách thức khác
nhau với các mức độ tổng kết khác nhau. Các partition không thể hiện đối với người
dùng, đối với họ một khối (cube) là một đối tượng đơn, và chúng cung cấp các tuỳ
chọn đa dạng để quản lý dữ liệu OLAP.
Một khối ảo (virtual cube) là một khung nhìn luận lý (logic) của các phần chia của
một hoặc nhiều khối. Một khối ảo có thể được sử dụng để kết (join) các khối khác
nhau để chia sẻ một chiều chung nào đó, ví dụ như có thể kết giữa khối Bán hàng và
khối Kho nhằm các mục đích phân tích đặc biệt nào đó trong khi duy trì các khối
tách biệt cho đơn giản. Các chiều (dimension) và các độ đo (measure) có thể được
chọn từ các khối được kết để thể hiện trong khối ảo.
5. Mô hình kiến trúc dịch vụ OLAP
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 24
Hệ hỗ trợ ra quyết định PGS. TS. Đỗ Phúc
Kiến trúc dịch vụ OLAP gồm 2 thành phần: Server và Client
Hình III.5.1: Mô hình kiếm trúc dịch vụ OLAP
5.1 Kiến trúc thành phần Server
HVTH: Đoàn Văn Huyên – Nguyễn Hữu Lộc Trang 25