Kho dữ liệu và công nghệ OLAP tổng quan

Kho dữ liệu và công nghệ OLAP tổng quan

Kho dữ liệu và công nghệ OLAP: Tổng

Quan

GVLT: PSG.TS Lê Hoài Bắc SV: Nguyễn Thị An Nhơn

0712023

KHAI THÁC DỮ LIỆU VÀ ỨNG DỤNG LỚP CNTN07, NĂM HỌC 2009-2010

BÁO CÁO CHỦ ĐỀ TỔNG QUAN VỀ KHO DỮ LIỆU VÀ CÔNG NGHỆ OLAP

MỤC LỤC

1 KHO DỮ LIỆU LÀ GÌ? 5 1.1 KHÁC BIỆT GIỮA HỆ CƠ SỞ DỮ LIỆU GIAO DỊCH VÀ KHO DỮ LIỆU ……… 8 1.2 TẠI SAO CẦN CÓ KHO DỮ LIỆU RIÊNG BIỆT 10

2 MÔ HÌNH DỮ LIỆU ĐA CHIỀU 12 2.1 TỪ BẢNG DỮ LIỆU VÀ SPREADSHEET TỚI KHỐI DỮ LIỆU 12 2.2 STARS, SNOWFLAKES, FACT CONSTELLATIONS: LƯỢC ĐỒ CHO CƠ SỞ DỮ LIỆU ĐA CHIỀU 17 2.3 VÍ DỤ ĐỊNH NGHĨA LƯỢC ĐỒ SAO, LƯỢC ĐỒ BÔNG TUYẾT

VÀ LƯỢC ĐỒ CHÒM SAO 21 2.4 ĐỘ ĐO: PHÂN LOẠI VÀ TÍNH TOÁN 24 2.5 PHÂN CẤP KHÁI NIỆM 27 2.6 CÁC PHÉP XỬ LÝ TRÊN OLAP TRONG MÔ HÌNH DỮ LIỆU ĐA CHIỀU 30 2.7 MÔ HÌNH STARNET DÙNG CHO TRUY VẤN DỮ LIỆU ĐA

CHIỀU 35

3 KIẾN TRÚC KHO DỮ LIỆU……… 36

4 CÀI ĐẶT KHO DỮ LIỆU……… 50

5 TỪ VIỆC LƯU TRỮ DỮ LIỆU TRONG KHO DỮ LIỆU TỚI KHAI

THÁC DỮ LIỆU……… 62

6 TÓM TẮT……….70

GIỚI THIỆU

Kho dữ liệu: tổng quát hóa và tổng hợp dữ liệu vào một không gian đa

chiều Việc xây dựng kho dữ liệu liên quan tới việc làm sạch dữ liệu, chuyển đổi

dữ liệu và có thể được xem như một bước tiền xử lý quan trọng cho việc khai thác dữ liệu Hơn nữa, kho dữ liệu cung cấp công cụ cho quá trình phân tích trực tuyến (OLAP) cho việc phân tích tương tác của dữ liệu đa chiều, tạo điều kiện tổng quát hóa dữ liệu hiệu quả và khai thác dữ liệu Nhiều chức năng khai thác

dữ liệu khác, chẳng hạn như liên kết, phân loại, dự báo và phân nhóm, có thể được tích hợp với hoạt động OLAP để tăng cường khai thác kiến thức ở nhiều cấp độ trừu tượng Do đó, các kho dữ liệu ngày càng trở nên quan trọng cho phân tích dữ liệu và phân tích online sẽ cung cấp một nền tảng hiệu quả cho phân tích dữ liệu Vì vậy, lưu trữ dữ liệu trong kho dữ liệu và OLAP tạo thành một bước quan trọng trong quá trình khai phá tri thức Trong báo cáo này sẽ trình bày tổng quan về kho dữ liệu và công nghệ OLAP Đây là cái nhìn tổng quan cần thiết cho hiểu biết tổng thể khai thác dữ liệu và quá trình phát hiện kiến thức

Các tác giả nghiên cứu một định nghĩa dễ chấp nhận của kho dữ liệu và xem tại sao ngày càng nhiều tổ chức đang xây dựng kho dữ liệu cho việc phân tích dữ liệu Đặc biệt, là nghiên cứu các khối dữ liệu, mô hình dữ liệu đa chiều cho kho dữ liệu và OLAP, cũng như các hoạt động trong OLAP roll-up, drill-down, slicing, và dicing Đồng thời cũng xem xét các kiến trúc kho dữ liệu, bao gồm các bước thiết kế và xây dựng kho dữ liệu Tổng quan về cài đặt kho dữ liệu kiểm tra chiến lược của tính toán hiệu quả khối dữ liệu, chỉ mục trong

OLAP, và truy vấn trên OLAP Cuối cùng là cái nhìn vào việc khai thác online, một mô hình mạnh mẽ tích hợp kho dữ liệu và công nghệ OLAP trong khai thác

dữ liệu

"Vậy, chính xác kho dữ liệu là gì?" Kho dữ liệu đã được định nghĩa bằng nhiều cách, rất khó để có một định nghĩa chính xác Nói một cách nôm na, kho

dữ liệu là một cơ sở dữ liệu tồn tại riêng biệt với cơ sở dữ liệu của tổ chức Hệ thống kho dữ liệu cho phép tích hợp với một loạt các ứng dụng Chúng hỗ trợ xử

lý thông tin bằng cách cung cấp một nền tảng vững chắc của cơ sở dữ liệu mang tính lịch sử và thống nhất để phân tích

Theo Inmon toWilliam H., một chuyên gia hàng đầu trong việc xây dựng

hệ thống kho dữ liệu, "Một kho dữ liệu là một tập hợp dữ liệu hướng chủ đề, tích hợp, biến thể thời gian, ít biến động hỗ trợ cho quá trình đưa ra quyết định của doanh nghiệp" Tóm lại, Bốn từ khóa: hướng chủ đề, tích hợp, biến thể thời gian, ít biến động là bốn đặc điểm phân biệt kho dữ liệu với các hệ thống dữ liệu khác

Hướng chủ đề: Một kho dữ liệu được tổ chức xung quanh các chủ đề

chính, chẳng hạn như khách hàng, nhà cung cấp, sản phẩm, và bán hàng Vượt

ra khỏi sự tập trung vào hoạt động hàng ngày và xử lý giao dịch của một tổ chức, một kho dữ liệu tập trung vào mô hình hóa và phân tích các dữ liệu giúp cho việc đưa ra quyết định Do đó, kho dữ liệu thông thường cung cấp một cái

nhìn đơn giản và ngắn gọn về các chủ đề cụ thể bằng cách loại trừ dữ liệu thừa đối với quá trình đưa ra quyết định

Tích hợp: Một kho dữ liệu thường được xây dựng bởi việc tích hợp nhiều

nguồn dữ liệu khác nhau chẳng hạn như cơ sở dữ liệu quan hệ, các tập tin, và hồ

sơ giao dịch trực tuyến Làm sạch dữ liệu và kỹ thuật tích hợp dữ liệu được áp dụng để đảm bảo tính nhất quán trong việc ước đặt tên, mã hóa cấu trúc, đo đạt các thuộc tính,…

Biến thể-thời gian: Dữ liệu được lưu trữ để cung cấp thông tin mang tính

lịch sử (E.g., trong 50-10 năm qua) Tất cả các cấu trúc quan trọng trong kho dữ liệu chứa, hoặc ngầm chứa một phần tử của thời gian

Ít biến đổi: Một kho dữ liệu luôn luôn là kho riêng biệt về mặt vật lý đối

với dữ liệu trong xử lý giao tác hàng ngày Do việc tách biệt này, một kho dữ liệu không yêu cầu xử lý giao dịch, phụ c hồi, và cơ chế kiểm soát xử lý đồng thời Nó thường đòi hỏi chỉ có hai hoạt động trên dữ liệu là tải dữ liệu và làm mới dữ liệu

Tóm lại, một kho dữ liệu là một kho dữ liệu đồng nhất về ngữ nghĩa phục

vụ cho việc đưa ra quyết định, cung cấp và lưu trữ các thông tin mà doanh

nghiệp cần để đưa ra quyết định chiến lược Một kho dữ liệu cũng thường được xem như là một kiến trúc được xây dựng bằng cách tích hợp từ nhiều nguồn dữ liệu không đồng nhất

Dựa trên thông tin này, ta xem lưu kho dữ liệu là quá trình xây dựng và sử dụng kho dữ liệu Việc xây dựng một kho dữ liệu đòi hỏi phải làm sạch dữ liệu, tích hợp dữ liệu, và hợp nhất dữ liệu Việc sử dụng một kho dữ liệu thường đòi hỏi một tập hợp các công nghệ hỗ trợ đưa ra quyết định Điều này cho phép công nhân tri thức (Ví dụ, nhà quản lý, nhà phân tích, và giám đốc điều hành) sử

dụng kho dữ liệu để có được một tổng quan của dữ liệu, và để đưa ra quyết định một cách nhanh chóng và thuận tiện Một số tác giả sử dụng thuật ngữ "data warehousing" để chỉ quá trình xây dựng kho dữ liệu, trong khi thuật ngữ

"warehouse DBMS" được sử dụng để nói đến việc quản lý và sử dụng kho dữ liệu

"Các tổ chức đang sử dụng thông tin từ kho dữ liệu như thế nào?" Nhiều

tổ chức sử dụng thông tin này để hỗ trợ doanh nghiệp ra quyết định, bao gồm cả (1) tăng cường tập trung vào nhu cầu của khách hàng, bao gồm việc phân tích các mẫu mà khách hàng mua (Chẳng hạn như mua hàng ưu đãi, mua lại, ngân sách chu kỳ, và chi tiêu thụ); (2) tái định vị sản phẩm và quản lý sản phẩm bằng cách so sánh thực hiện bán hàng theo quý, theo năm, và theo vùng địa lý để đưa

ra chiến lược sản xuất; (3) phân tích hoạt động và tìm kiếm nguồn lợi nhuận; và (4) quản lý quan hệ khách hàng, làm cải chính môi trường, và quản lý chi phí tài sản công ty

Kho dữ liệu cũng rất hữu ích từ quan điểm của việc tích hợp các cơ sở dữ liệu không đồng nhất Để tích hợp các dữ liệu đó, và làm cho việc truy cập dễ dàng và hiệu quả là một thử thách lớn Đã có nhiều nỗ lực bỏ ra để đạt được mục tiêu này

Kho dữ liệu cung cấp một phương pháp xử lý truy vấn gọi là

update-driven để truy vấn dữ liệu từ nhiều nguồn khác nhau Do dữ liệu trong kho dữ liệu không thay đổi thường xuyên và còn được copy, xử lý, tổng hợp trước khi đưa vào lưu trữ nên việc truy vấn dễ hơn truy vấn trên cơ sở dữ liệu hoạt động

1.1 KHÁC BIỆT GIỮA HỆ CƠ SỞ DỮ LIỆU HOẠT ĐỘNG VÀ KHO

DỮ LIỆU

Bởi vì hầu hết mọi người đều quen thuộc với các hệ thống cơ sở dữ liệu quan hệ thương mại nên để hiểu kho dữ liệu dễ dàng ta sẽ so sánh hai loại hệ thống Nhiệm vụ chính của hệ thống cơ sở dữ liệu hoạt động là để thực hiện giao dịch trực tuyến và truy vấn Các hệ thống này được gọi là hệ thống xử lý hoạt động on-line (OLTP) Chúng bao gồm hầu hết các hoạt động hàng ngày của một tổ chức, chẳng hạn như thu mua, tồn kho, sản xuất, ngân hàng, đăng

ký, và kế toán Hệ thống kho dữ liệu, ngược lại, phục vụ người sử dụng hay công nhân tri thức trong vai trò phân tích dữ liệu và ra quyết định Hệ thống như vậy có thể tổ chức và thể hiện dữ liệu trong nhiều định dạng, để thích ứng với nhu cầu đa dạng của người sử dụng khác nhau Những hệ thống này được biết là hệ thống phân tích trực tuyến (OLAP)

Điểm khác biệt chủ yếu giữ OLTP và OLAP được tóm gọn như sau:

 Người sử dụng và định hướng của hệ thống: Một hệ thống OLTP là

định hướng khách hàng được sử dụng cho giao dịch và xử lý truy vấn bởi thư ký, khách hàng, và các chuyên gia công nghệ thông tin Một hệ thống OLAP là định hướng thị trường và được sử dụng cho phân tích dữ liệu bởi công nhân tri thức, bao gồm cả quản lý, điều hành, và các nhà phân tích

 Nội dung dữ liệu: hệ thống OLTP quản lý dữ liệu mang tính update

thông thường quá chi tiết để dễ dàng sử dụng cho việc ra quyết định Một

hệ thống OLAP quản lý số lượng lớn dữ liệu quá khứ, cung cấp các tiện ích cho tổng kết và tập hợp, và lưu trữ, quản lý thông tin ở các cấp độ khác Những tính năng này làm cho các dữ liệu dễ dàng sử dụng hơn trong việc ra quyết định

 Thiết kế dữ liệu: một hệ thống OLTP thường sử dụng mô hình thực thể

quan hệ và một thiết kế hướng ứng dụng Một hệ thống OLAP thường sử dụng mô hình sao hoặc bông tuyết và thiết kế dữ liệu hướng chủ đề

 Khung nhìn: Một hệ thống OLTP thường tập trung chủ yếu vào dữ liệu

hiện tại của tập đoàn hoặc của phòng ban, không chú ý tới dữ liệu lịch sử hay dữ liệu ở các tổ chức khác nhau Ngược lại, hệ thống OLAP thường

mở rộng các phiên bản của lược đồ dữ liệu do quá trình phát triển của tổ chức Hệ thống OLAP thường làm việc với thông tin từ nhiều tổ chức khác nhau, tổng hợp từ nhiều nguồn dữ liệu khác nhau

 Mô hình truy xuất: mô hình truy xuất của hệ thống OLTP bao gồm các

giao dịch Hệ thống như vậy yêu cầu có sự kiểm soát xử lý đồng thời và

cơ chế hồi phục Tuy nhiên, truy xuất hệ thống OLAP chủ yếu là quá trình đọc Bởi vì hầu hết các kho dữ liệu lưu trữ dữ liệu lịch sư hơn là dữ liệu mang tính cập nhật, mặc dù có rất nhiều truy vấn phức tạp

Bảng 1: So sánh giữa OLTP và OLAP

Tính chất Xử lý giao dịch Xử lý thông tin

Người dùng Thư ký, DBA, chuyên

gia cơ sở dữ liệu

Công nhân trí thức

Chức năng Hoạt động hàng ngày Yêu cầu thông tin lâu

dài, hỗ trợ đưa ra quyết định

Thiết kế DB Mô hình ER, hướng

ứng dụng

Mô hình sao, bông tuyết, hướng chủ đề

Dữ liệu đảm bào cập nhật Mang tính lịch sử, Tổng hợp Thô sơ, chi tiết Tổng hợp tốt, nhiều

chiều Đơn vị công việc Ngắn, giao dịch đơn

giản

Truy vấn phức tạp

Hoạt động Chỉ mục/Băm trên

Số lượng người dung Hàng ngàn Hàng

Kích thước DB 100MB tới GB 100GB tới TB

Độ ưu tiên Thực hiện nhanh, độ

sẵn sàng cao

Độ linh hoạt cao

dich

Độ thông suốt truy vấn

và thời gian đáp ứng

1.2 TẠI SAO CẦN CÓ KHO DỮ LIỆU RIÊNG BIỆT

Bởi vì cơ sở dữ liệu hoạt động lưu trữ một lượng lớn dữ liệu, bạn có thể tự hỏi, "Tại sao không thực hiện trực tuyến quá trình phân tích trực tiếp trên cơ sở

dữ liệu đó thay vì bỏ thêm thời gian và nguồn lực để xây dựng một kho dữ liệu riêng biệt?" Lý do cho việc tách này là giúp thúc đẩy hiệu suất của cả hệ thống Một cơ sở dữ liệu hoạt động được thiết kế và điều chỉnh để thực hiện những công việc như tạo chỉ mục và băm dùng khóa chính, tìm kiếm record, tối ưu truy vấn Trong khi đó, câu truy vấn trên kho dữ liệu thường phức tạp Chúng liên

quan đến việc tính toán trên nhóm lớn của dữ liệu ở mức tổng hợp, và có thể yêu cầu việc sử dụng của việc tổ chức dữ liệu, truy xuất, và phương pháp cài đặt dựa trên cái nhìn đa chiều Xử lý truy vấn OLAP trong cơ sở dữ liệu giao dịch có thể làm chậm quá trình làm việc của các xử lý giao dịch

Hơn nữa, một cơ sở dữ liệu giao dịch hỗ trợ việc xử lý đồng thời của nhiều giao dịch Đồng thời cần phải kiểm soát xử lý đồng thời và các cơ chế phục hồi, chẳng hạn như khóa và ghi nhật trí xử lý, để bảo đảm tính nhất quán

và an toàn cho giao dịch Một truy vấn OLAP thường chỉ đọc dữ liệu để tổng kết

và tập hợp Nếu áp dụng các cơ chế trên cho các hoạt động của OLAP, có thể gây nguy hiểm cho việc thực hiện các giao dịch đồng thời và do đó giảm đáng

kể thông lượng của một hệ thống OLTP

Sau cùng, việc tách kho dữ liệu với cơ sở dữ liệu giao dịch được dựa trên các cấu trúc khác nhau, nội dung, và sử dụng các dữ liệu trong hai hệ thống Việc hỗ trợ đưa ra quyết định yêu cầu dữ liệu có tính lịch sử, trong khi cơ sở dữ liệu giao dịch không thường duy trì dữ liệu lịch sử Trong bối cảnh đó, các dữ liệu giao dịch mặc dù dồi dào nhưng thường xa với việc đưa ra quyết định Việc

hỗ trợ quyết định đòi hỏi tính hợp nhất (chẳng hạn như tập hợp và tổng kết) của

dữ liệu từ các nguồn không đồng nhất, kết quả trong dữ liệu có chất lượng cao, sạch, và tích hợp Ngược lại, cơ sở dữ liệu giao dịch chỉ chứa dữ liệu chi tiết chưa xử lý, chẳng hạn như giao dịch, và cần phải được củng cố trước khi phân tích Bởi vì hai hệ thống cung cấp chức năng khá khác nhau và đòi hỏi khác nhau về các loại dữ liệu, nên rất cần thiết duy trì 2 loại cơ sở dữ liệu này riêng biệt Tuy nhiên, nhiều nhà cung cấp hệ thống quản lý cơ sở dữ liệu giao dịch

đang bắt đầu tối ưu hóa hệ thống để hỗ trợ truy vấn OLAP Nếu xu hướng này tiếp tục phát triển, sự tách biệt giữa các hệ thống OLTP và OLAP có thể sẽ giảm

đi

2 MÔ HÌNH DỮ LIỆU ĐA CHIỀU

Kho dữ liệu và các công cụ OLAP được triển khai trên một mô hình dữ liệu đa chiều Mô hình dữ liệu này xem dữ liệu ở dạng khối Trong phần này sẽ giới thiệu cách khối dữ liệu mô hình dữ liệu n chiều Ta cũng sẽ tìm hiểu về khái niệm phân cấp và làm thế nào chúng có thể được dùng trong thao tác cơ bản OLAP để khai thác ở nhiều cấp độ

2.1 TỪ BẢNG DỮ LIỆU VÀ BẢNG TÍNH TỚI KHỐI DỮ LIỆU

"Một khối dữ liệu là gì?" Một khối dữ liệu cho phép dữ liệu được mô hình

và được nhìn ở nhiều chiều Nó được xác định bởi các chiều và các độ đo

(facts) Nói chung, chiều là những khía cạnh hoặc thực thể mà tổ chức muốn lưu trữ Ví dụ, AllElectronics có thể tạo ra kho dữ liệu sales để lưu giữ những record

về doanh số bán hàng của cửa hàng trong các chiều về time, item, branch, và location Những chiều này cho phép cửa hàng lưu vết của những thứ như doanh

số bán hàng hằng tháng của các item, các branch và các location

Bảng 2: Một thể hiện 2 chiều của dữ liệu bán hàng cho AllElectronics theo các chiều time, item tại địa điểm của chi nhánh là “Vancouver”

Mỗi chiều có thể có một bảng liên kết với nó, được gọi là bảng chiều (dimension table) mô tả các chiều Ví dụ, một bảng chiều cho item có thể chứa các thuộc tính item_name, brand, và type Bảng chiều có thể được chỉ định bởi người sử dụng hoặc các chuyên gia, hoặc tự động tạo ra và điều chỉnh dựa trên các bảng phân phối dữ liệu

Một mô hình dữ liệu đa chiều thường được tổ chức xung quanh một chủ

đề trung tâm, ví dụ: sales Chủ đề này được đại diện bởi một bảng độ đo (fact table) Facts là số đo có dạng số Hãy xem chúng như số lượng mà để phân tích các mối quan hệ giữa các chiều Ví dụ về các fact cho kho dữ liệu sales bao gồm dollars_sold, units_sold, amount_budgeted Fact table bao gồm tên của facts, hay độ đo, và khóa chỉ tới các chiều liên quan của bảng chiều (dimention table)

Ta sẽ có được một hình ảnh rõ ràng về cách thức hoạt động của mô hình này khi chúng ta nhìn vào lược đồ đa chiều

Mặc dù ta thường nghĩ về hình khối như cấu trúc hình học 3-D, nhưng trong kho dữ liệu các khối dữ liệu có thể có n-chiều Để có được một sự hiểu biết tốt hơn về khối dữ liệu và các mô hình dữ liệu đa chiều, chúng ta hãy bắt

đầu bằng cách nhìn vào một khối lập phương dữ liệu đơn giản 2-D thực ra là một bảng thể hiện doanh số bán hàng từ AllElectronics Đặc biệt, ta sẽ nhìn dữ liệu bán hàng AllElectronics cho các item được bán mỗi quý tại thành phố

Vancouver Những dữ liệu này được hiển thị trong Bảng 3.2 Trong thể hiện 2-D này, doanh số bán hàng ở Vancouver được đặt trong các chiều time và item Độ

đo (fact) ở đây là dollars_sold Bây giờ, giả sử rằng ta muốn xem các dữ liệu bán hàng với một chiều thứ ba Ví dụ, giả sử ta muốn xem dữ liệu theo chiều time và item, cũng như location cho các thành phố Chicago, New York, Toronto, và Vancouver Những dữ liệu 3-D này được thể hiện trong Bảng 3.3 Các dữ liệu 3-

D của Bảng 3.3 được thể hiện như là một loạt các bảng 2-D Trên lý thuyết, ta cũng có thể thể hiện dữ liệu dưới dạng của một khối dữ liệu 3-D, như trong Hình 3.1

Bảng 3

Giả sử bây giờ ta muốn xem dữ liệu sale với một chiều thứ 4 được thêm vào chẳng hạn như supplier Xem thông tin trong 4-D sẽ trở nên khó khăn Tuy vậy, chúng ta có thể suy nghĩ một khối lập phương 4-D như là một loạt các hình khối 3-D, như trong hình 3.2 Nếu ta tiếp tục theo cách này, ta có thể hiển thị bất kỳ dữ liệu nào như là một loạt khối (n - 1)-D Các khối dữ liệu là một phép

mô hình hóa cho việc lưu trữ dữ liệu đa chiều Thực tế việc lưu trữ vật lý của dữ liệu có thể khác với biểu diễn logic của nó Điều quan trọng cần nhớ là dữ liệu khối dữ liệu là n-chiều và không giới hạn dữ liệu đến 3-D

Các bảng trên thể hiện dữ liệu ở các mức độ tổng hợp khác nhau Trong kho dữ liệu, khối dữ liệu liên hệ tới cuboid Cho một tập hợp các chiều, ta có thể tạo ra một lưới các cuboid, mỗi cuboid thể hiện dữ liệu ở các mức độ tổng hợp khác nhau, hay group-by Lưới của các cuboid sau đó được xem như khối dữ liệu Hình 3.3 cho thấy một lưới của các cuboid tạo thành một khối dữ liệu với các chiều time, item, location, supplier

Các cuboid giữ mức tổng kết thấp nhất được gọi là cuboid cơ sở Ví dụ, cuboid 4-D trong hình 3.2 là cuboid cơ sở cho time, item, location, tổng kết cho tất cả supplier Cuboid 0-D có mức độ tổng kết cao nhất, được gọi là cuboid

apex Trong ví dụ của chúng ta, đây là tổng doanh thu bán hàng, hay

dollars_sold, tóm tắt trên tất cả bốn chiều Các apex cuboid được thể hiện bởi tất

cả

2.2 STARS, SNOWFLAKES, FACT CONSTELLATIONS: LƯỢC ĐÒ CHO CƠ SỞ DỮ LIỆU ĐA CHIỀU

Mô hình dữ liệu thực thể-quan hệ thường được sử dụng trong thiết kế của

cơ sở dữ liệu quan hệ, nơi một lược đồ cơ sở dữ liệu bao gồm một tập các thực thể và các mối liên hệ giữa chúng Một mô hình dữ liệu như vậy phù hợp với xử

lý giao dịch trực tuyến Tuy nhiên, một kho dữ liệu đòi hỏi một lược đồ hướng chủ đề súc tích tạo thuận tiện cho việc phân tích dữ liệu online

Hầu hết các mô hình dữ liệu phổ biến là một mô hình đa chiều Như một

mô hình có thể tồn tại ở dạng của một lược đồ ngôi sao, lược đồ bông tuyết, hay lược đồ chòm sao Hãy xem xét mỗi một loại lược đồ

Lược đồ sao: là mô hình dữ liệu phổ biến nhất, trong đó kho dữ liệu chứa

(1) một bảng độ đo trung tâm lớn (fact table) có chứa phần lớn dữ liệu, không có

dư thừa dữ liệu, và (2) một tập hợp các bảng nhỏ hơn (dimention table), mỗi chiều có 1 bảng

Ví dụ 3.1 Lược đồ sao Một lược đồ cho doanh số bán hàng

AllElectronics được hiển thị trong hình 3.4 Sales được xem xét dưới 4 chiều time, item, brand, và địa điểm Lược đồ có bảng fact trung tâm cho sales có chứa các key cho mỗi chiều, cùng với hai độ đo: dollars_sold và units_sold Để giảm thiểu kích thước của bảng fact, ID cho các chiều do hệ thống tạo ra (như

time_key, item_key)

Chú ý rằng trong lược đồ sao, mỗi chiều được đại diện chỉ bởi một bảng,

và mỗi bảng có chứa một tập các thuộc tính Ví dụ, bảng chiều location chứa tập

thuộc tính {location key, street, city, province or state, country} Điều này có thể

dẫn tới dư thừa Ví dụ, "Vancouver" và "Victoria" được cả hai thành phố ở tỉnh của người Canada của British Columbia Thực thể cho các thành phố như vậy

trong bảng chiều location sẽ tạo ra sự dư thừa trong số các thuộc tính

province_or_state và country, đó là, (…,Vancouver, British Columbia, Canada)

và ( , Victoria, British Columbia,Canada) Hơn nữa, các thuộc tính trong một

bảng chiều có thể tạo thành hoặc là một hệ thống phân cấp hoặc một lưới

Lược đồ bông tuyết: Lược đồ bông tuyết là một biến thể của mô hình

lược đồ sao, trong đó một số bảng chiều được bình thường hóa, qua đó tiếp tục chia tách các dữ liệu vào các bảng mới Lược đồ kết quả hình thành một đồ thị lược đồ tương tự như một bông tuyết

Sự khác biệt lớn giữa các mô hình lược đồ bông tuyết và ngôi sao là bảng chiều của mô hình bông tuyết có thể được giữ trong hình thức bình thường hóa

để giảm dư thừa Bảng như vậy là dễ dàng để duy trì và tiết kiệm không gian lưu trữ Tuy nhiên, tiết kiệm không gian này là không đáng kể so với mức độ điển

hình của bảng fact Hơn nữa, cấu trúc bông tuyết có thể làm giảm hiệu quả của các trình duyệt, vì cần thực hiện nhiều phép kết Do đó, hiệu năng hệ thống có thể bị ảnh hưởng Do đó, mặc dù các lược đồ bông tuyết làm giảm sự dư thừa,

nó không phải là phổ biến như các lược đồ sao trong thiết kế kho dữ liệu

Ví dụ 3.2 Lược đồ Bông tuyết Một lược đồ bông tuyết cho doanh số bán hàng

AllElectronics được cho trong hình 3.5 Ở đây, trong bảng fact giống với bảng fact của sales với lược đồ sao trong hình 3.4 Sự khác biệt giữa hai lược đồ là trong định nghĩa của bảng chiều Bảng chiều cho item trong lược đồ sao được bình thường hóa trong lược đồ bông tuyết, kết quả cho ra bảng item và bảng

supplier mới Ví dụ, bảng chiều item bây giờ chứa các thuộc tính item_key, item name, brand, type, và supplier key, trong đó supplier_key liên kết với bảng chiều supplier, có chứa supplier_key và supplier_type Tương tự, bảng chiều của

location trong lược đồ sao có thể được đưa vào 2 bảng: location và city city_key trong bảng location mới liên kết tới chiều city Chú ý rằng có thể thực hiện trên province_or_state và country trong lược đồ bông tuyết trong hình 3.5 hình, khi muốn

Lược đồ chòm sao: Các ứng dụng phức tạp có thể yêu cầu nhiều bảng

fact để chia sẻ các bảng chiều Loại lược đồ này có thể được xem như là một tập các sao, và do đó được gọi là galaxy schema hay fact constellation

Ví dụ 3.3 Lược đồ chòm sao Trong hình 3.6 là một lược đồ chòm sao Lược đồ

này định nghĩa 2 bảng fact, sales và shipping Định nghĩa của bảng sales giống

như của lược đồ sao Bảng shipping có 5 chiều, hay 5 key: item_key,time_key, shipper_key, from_ location, và to_location và 2 độ đo là dollars_cost và

units_shipped Một lược đồ chòm sao cho phép các bảng chiều được chia sẻ

giữa các bảng fact Ví dụ, bảng chiều time, item và location được chia sẻ giữa các bảng fact của shipping và sales

Trong việc lưu trữ dữ liệu trong kho có sự phân biệt giữa data warehouse

và data mart Một data warehouse tập hợp thông tin từ nhiều chủ đề của tổ chức như khách hàng, mặt hàng, bán hàng, tài sản, nhân sự, nên giới hạn của nó là trên toàn tập đoàn Đối với kho dữ liệu, lược đồ chòm sao được dùng phổ biến,

bởi vì nó có thể mô hình hóa nhiều chủ đề có liên hệ với nhau Một data mart chỉ

là một tập con của data warehouse tập trung vào các chủ đề được chọn, và do đó giới hạn của nó chỉ là trong 1 phòng ban Trong data mart, lược đồ sao và bông tuyết được dùng phổ biến hơn vì các phòng ban thường chỉ tập trung vào một chủ đề

2.3 VÍ DỤ ĐỊNH NGHĨA LƯỢC ĐỒ SAO, LƯỢC ĐỒ BÔNG TUYẾT

VÀ LƯỢC ĐỒ CHÒM SAO

Ngôn ngữ truy vấn khai thác dữ liệu có thể được dùng đề xác định các công việc khai thác dữ liệu Đặc biệt, ta giải thích làm sao để định nghĩa data warehouse và data mart trong ngôn ngữ khai thác dữ liệu dựa trên SQL, gọi là DMQL

Data warehouse và data mart có thể được định nghĩa bằng cách dùng 2 ngôn ngữ gốc, 1 cho định nghĩa khối dữ liệu và 1 cho định nghĩa chiều Định nghĩa khối dữ liệu theo cú pháp sau:

define cube <cube name> [<dimension list>]: <measure list>

Định nghĩa chiều theo cú pháp sau:

define dimension <dimension name> as (<attribute or dimension list>)

Các ví dụ định nghĩa lược đồ sao, bông tuyết và chòm sao của các ví dụ 3.1 tới 3.3 ở trên dùng DMQL

Ví dụ 3.4 Định nghĩa lược đồ sao Lược đồ sao của ví dụ 3.1 và hình 3.4 được

định nghĩa như sau:

define cube sales star [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year) define dimension item as (item key, item name, brand, type, supplier type) define dimension branch as (branch key, branch name, branch type)

define dimension location as (location key, street, city, province or state,

country)

Câu define cube xác định khối dữ liệu sales_star có bảng fact sales của ví dụ

3.1 Câu lệnh này định nghĩa các chiều và 2 độ đo, dollars_sold và units_sold

Khối dữ liệu có 4 chiều time, item, branch, location Câu lệnh define dimension

dùng để định nghĩa các chiều

Ví dụ 3.5 Định nghĩa lược đồ bông tuyết Lược đồ bông tuyết của ví dụ 3.2 và

hình 3.5 được định nghĩa trong DMQL như sau:

define cube sales snowflake [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year) define dimension item as (item key, item name, brand, type, supplier

(supplier key, supplier type))

define dimension branch as (branch key, branch name, branch type)

define dimension location as (location key, street, city

(city key, city, province or state, country))

Định nghĩa này tương tự như định nghĩa lược đồ của sales_star (Ví dụ

3.4), khác là item và location được bình thường hóa Ví dụ, chiều item của khối

dữ liệu sales-star đã được hiện thực trong khối dữ liệu sales_snowflake vào 2

bảng chiều là item và supplier Chú ý là định nghĩa chiều supplier được đặt trong định nghĩa chiều item Định nghĩa supplier trong cách này ngầm tạo ra supplier_key trong định nghĩa bảng chiều item Tương tự, chiều location của khối dữ liệu sales_star đã được hiện thực hóa trong khối dữ liệu

sales_snowflake vào 2 bảng chiều location và city Định nghĩa chiều city đặt trong định nghĩa chiều location Theo cách này, city_key được ngầm tạo ra trong định nghĩa bảng chiều location

Ví dụ 3.6 Định nghĩa lược đồ chòm sao của lược đồ trong ví dụ 3.3 và hình 3.6 bằng DMQL như sau:

define cube sales [time, item, branch, location]:

dollars sold = sum(sales in dollars), units sold = count(*)

define dimension time as (time key, day, day of week, month, quarter, year) define dimension item as (item key, item name, brand, type, supplier type) define dimension branch as (branch key, branch name, branch type)

define dimension location as (location key, street, city, province or state,

country)

define cube shipping [time, item, shipper, from location, to location]:

dollars cost = sum(cost in dollars), units shipped = count(*)

define dimension time as time in cube sales

define dimension item as item in cube sales

define dimension shipper as (shipper key, shipper name, location as

location in cube sales, shipper type)

define dimension from location as location in cube sales

define dimension to location as location in cube sales

Câu lệnh define cube được dùng để định nghĩa khối dữ liệu của sales và

shipping, tương ứng với 2 bảng fact của lược đồ trong ví dụ 3.3 Chú ý chiều

time, item, location của khối dữ liệu sales được chia sẻ giữa khối sales và

shipping Điều này được thể hiện ở chiều time như sau Dưới câu lệnh define cube cho shipping, câu lệnh “define dimension time as time in cube sales”

được xác định

2.4 ĐỘ ĐO: PHÂN LOẠI VÀ TÍNH TOÁN

Một điểm đa chiều trong khối dữ liệu có thể được định nghĩa bởi một tập

của các cặp giá trị chiều, ví dụ <= “Q1”, location = “Vancouver”, item =

“computer”> Một độ đo của khối dữ liệu là một hàm số có thể được đánh giá

tại mỗi điểm của không gian khối dữ liệu Một giá trị độ đo tại 1 điểm được tính tương ứng với các giá trị chiều của điểm đó

Độ đo có thể được phân ra thành 3 loại dựa vào loại của hàm kết hợp: distributive, algebraic, holistic

 Distributive: Một hàm kết hợp là distributive nếu nó có thể được tính

toán bằng cách phân phối Giả sử dữ liệu được chia ra thành n tập hợp Ta

áp dụng hàm này vào mỗi tập hợp, kết quả cho ra n giá trị Nếu kết quả rút

ra từ n giá trị này giống với kết quả khi áp dụng hàm vào toàn bộ tập dữ

liệu chưa phân chia thì hàm là hàm distributed Ví dụ các hàm distributed

là: count(), sum(), min(), max() Một độ đo là distributed nếu nó được tính

từ hàm distributed

 Algebraic: hàm kết hợp là algebraic nếu nó có thể được tính toán bởi một

hàm algebraic với M tham số, mỗi tham số đó được tính bằng hàm

distributed, ví dụ hàm avg() được tính bằng sum()/count() Tương tự hàm min_M() và max_M() là hàm kết hợp algebraic Một độ đo algebraic được tính bằng hàm algebraic

 Holistic: Hàm holistic không có giới hạn về kích thước lưu trữ cần thiết

để mô tả các thành phần để kết hợp Ví dụ hàm median(), mode(), rank() Một độ đo là holistic nếu nó được tính bằng các hàm holistic

Hầu hết các ứng dụng khối dữ liệu yêu cầu tính toán hiệu quả cả độ đo distributed và algebraic Có nhiều kỹ thuật phục vụ cho việc này Nhưng, rất khó

để tính toán các độ đo holistic một cách hiệu quả mặc dù vẫn có một số phương pháp xấp xỉ các độ đo holistic Ví dụ thay vì tính median() một cách chính xác thì ta có thể áp dụng phương trình trong chương 2 để xấp xỉ giá trị của tập dữ liệu lớn Trong nhiều trường hợp, các kỹ thuật như vậy rất hiệu quả để vượt qua các khó khăn trong việc tính toán các độ đo holistic

Ví dụ: Rất nhiều độ đo của khối dữ liệu được tính bằng các phép tính kết hợp Trong hình 3.4, ta thấy lược đồ sao cho sales có 2 độ đo dollars_sold và units_sold Trong ví dụ 3.4, khối dữ liệu sales_star tương ứng với lược đồ được định nghĩa bằng các lệnh DMQL “Làm sao để các câu lệnh này kết hợp lại để tạo khối dữ liệu”

Giả sử mô hình dữ liệu quan hệ của lược đồ AllElectronics:

time(time key, day, day of week, month, quarter, year)

item(item key, item name, brand, type, supplier type)

branch(branch key, branch name, branch type)

location(location key, street, city, province or state, country)

sales(time key, item key, branch key, location key, number of units sold,

price)

Các lệnh DMQL trong ví dụ 3.4 được dịch sang câu truy vấn SQL, tạo ra khối

dữ liệu sales_star Ở đây, hàm sum() được dùng để tính dollars_sold và

units_sold:

select s.time key, s.item key, s.branch key, s.location key,

sum(s.number of units sold _ s.price), sum(s.number of units sold) from time t, item i, branch b, location l, sales s,

where s.time key = t.time key and s.item key = i.item key

and s.branch key = b.branch key and s.location key = l.location

key

group by s.time key, s.item key, s.branch key, s.location key

Khối dữ liệu tạo ra ở trên là cuboid cơ sở của khối dữ liệu sales_star Nó chứa tất cả các chiều trong định nghĩa của khối dữ liệu Ở đây có join key là key

để liên kết bảng fact và bảng chiều Bảng fact liên quan tới cuboid cơ sở thường được xem là bảng fact cơ sở

Bằng cách thay đổi mệnh đề group by, ta có thể tạo ra cuboids khác cho

khối dữ liệu sale_star Ví dụ, thay vì group by trên s.time, chúng ta có thể nhóm trên t.month để tính tổng các độ đo của mỗi group theo tháng Cũng như vậy,

loại bỏ các "group by s.branch_key" sẽ tạo ra một cuboid ở cấp cao hơn (nơi sales tổng hợp cho tất cả các chi nhánh, hơn là được chia nhỏ cho mỗi chi

nhánh) Giả sử chúng ta sửa đổi các truy vấn SQL trên bằng cách loại bỏ tất cả

mệnh đề group by Kết quả cho ra tổng của dollars_sold và tổng của units_sold

cho dữ liệu đã cho Cuboid 0-chiều này là apex cuboid của khối dữ liệu

sales_star Bên cạnh đó, các cuboid khác có thể được tạo ra bằng cách áp dụng phép chọn và phép kết trên cuboid cơ sở, kết quả cho ra lưới cuboid như mô tả ở phần 2.1 Mỗi cuboid tương ứng với các mức độ tổng hợp khác nhau của dữ liệu

đã cho Hầu hết công nghệ khối dữ liệu hiện tại chuyển độ đo của dữ liệu đa chiều sang dữ liệu số Tuy nhiên, các độ đo có thể được áp dụng vào các loại dữ liệu khác nhau như dữ liệu text, dữ liệu multimedia, dữ liệu spatial

2.5 PHÂN CẤP KHÁI NIỆM

Phân cấp khái niệm định nghĩa một chuỗi các mapping từ một tập các khái niệm cấp thấp đến các khái niệm cấp cao hơn, tổng quát hơn Xem một phân cấp khái niệm cho một chiều location Giá trị city của location bao gồm Vancouver, Toronto, New York, và Chicago Mỗi city được map tới một

province hay một state mà nó thuộc về Ví dụ, Vancouver có thể được map vào British Columbia, và Chicago được map vào Illinois Các province và state có thể lại được map đến các country mà chúng thuộc về, như Canada hay USA Các mapping này hình thành nên phân cấp khái niệm cho chiều location,

mapping một tập các khái niệm cấp thấp đến một khái niệm cấp cao hơn, tổng quát hơn Phân cấp khái niệm mô tả ở trên được thể hiện bằng hình 3.7

Rất nhiều phân cấp khái niệm được ngầm đặt trong lược đồ dữ liệu Ví dụ, giả sử chiều location được mô tả bằng các thuộc tính number, street, city,

province_or_state, zipcode, country Những thuộc tính này liên quan đến thứ tự

bao gồm, hình thành một phân cấp khái niệm như “street < city <

province_or_state < country” Phân cấp này được thể hiện ở hình 3.8(a) Thay vào đó, các thuộc tính của một chiều có thể được tổ chức vào một thứ tự không liên tục, tạo ra một lưới Ví dụ của thứ tự liên tục từng phần cho chiều time là day <{ week; month < quarter} < year Cấu trúc lưới này được thể hiện trên hình 3.8(b) Một phân cấp khái niệm là liên tục hoàn toàn hay liên tục từng phần giữa các thuộc tính trong lược đồ dữ liệu được gọi là phân cấp lược đồ Phân cấp khái niệm rất phổ biến trong nhiều ứng dụng có thể được định nghĩa trước trong hệ

thống khai thác dữ liệu, ví dụ như phân cấp khái niệm của chiều time Hệ thống

khai thác dữ liệu nên cung cấp cho người dùng sự linh hoạt để định nghĩa phân cấp khái niệm trước dựa trên nhu cầu của họ Ví dụ, người dùng có thể thích định nghĩa năm tính tài chính bắt đầu từ tháng 4 hay năm học bắt đầu từ ngày 1/9

Phân cấp khái niệm có thể được định nghĩa bằng cách phân rã hay gom nhóm các giá trị cho một chiều hoặc thuộc tính, cho ra kết quả một phân cấp gom nhóm tập hợp Một thứ tự liên tục hoàn toàn hay liên tục từng phần được định nghĩa giữa các nhóm của các giá trị Một ví dụ của phân cấp gom nhóm tập hợp được thể hiện trong hình 3.9 cho chiều price, trong đó đoạn giá trị

($X…$Y] chỉ một đoạn từ $X (không tính $X) đến $Y (có tính cả giá trị $Y)

Có thể có nhiều hơn một phân cấp khái niệm cho một thuộc tính hoặc một chiều, dựa vào các điểm nhìn khác nhau của người dùng Ví dụ, một người dùng

có thể thích tổ chức price bằng cách định nghĩa các đoạn cho inexpensive,

moderately_priced, và expensive

Phân cấp khái niệm có thể được cung cấp bằng tay bởi người dùng hệ thống, chuyên gia, kỹ sư, hay nhà phân tích dữ liệu Sự phát sinh tự động của các phân cấp khái niệm được bàn trong chương 2

Phân cấp khái niệm cho phép dữ liệu được kiểm soát ở nhiều cấp độ khác nhau của mức trừu tượng, ta sẽ thấy trong phần sau

2.6 CÁC PHÉP XỬ LÝ TRÊN OLAP TRONG MÔ HÌNH DỮ LIỆU ĐA CHIỀU

“Phân cấp khái niệm có tác dụng như thế nào trong OLAP?” Trong mô hình đa chiều, dữ liệu được tổ chức vào nhiều chiều, mỗi chiều bao gồm các cấp bậc khác nhau của độ trừu tượng được định nghĩa bởi phân cấp khái niệm Cách

tổ chức này cung cấp cho người dùng độ linh hoạt để nhìn dữ liệu dưới nhiều góc độ khác nhau Một số phép xử lý trên khối dữ liệu OLAP tồn tại để hiện thực những cái nhìn khác nhau này, cho phép truy vấn tích hợp và phân tích dữ liệu bằng tay Do đó, OLAP cung cấp môi trường thân thiện đối với người dùng

để phân tích dữ liệu tích hợp

Ví dụ 3.8 Các phép xử lý OLAP Nhìn vào các phép xử lý đặc trưng của

OLAP cho dữ liệu đa chiều Mỗi phép xử lý mô tả dưới đây được thể hiện trong hình vẽ 3.10 Tại tâm của hình vẽ là khối dữ liệu cho sales Khối dữ liệu chứa nhiều chiều location, time, item, trong đó location được tổng hợp từ các giá trị của city, time được tổng hợp từ các giá trị của quarters, và item được tổng hợp

từ các item type Để hỗ trợ cho việc giải thích, ta sẽ xem khối dữ liệu này như

khối dữ liệu trung tâm Độ đo là dollars_sold Dữ liệu được xem xét ở đây là cho các thành phố Chicago, NewYork, Toronto, và Vancouver

Roll-up: Phép roll-up thể hiện sự tổng hợp của các khối dữ liệu, bằng cách tiến lên cấp cao hơn trong phân cấp khái niệm của chiều hay làm giảm chiều Hình 3.10 thể hiện kết quả của phép roll-up thể hiện tai khối dữ liệu trung tâm bằng cách tiến lên cấp cao hơn trong phân cấp khái niệm cho chiều location trong hình 3.7 Phân cấp này đã được định nghĩa là phân cấp có thứ tự liên tục hoàn toàn ”street < city < province_or_state < country” Phép roll-up thể hiện sự tổng hợp dữ liệu bằng cách tiến lên trên phân cấp khái niệm của location từ cấp city đến cấp country Nói cách khác, thay vì gom nhóm dữ liệu dựa vào city thì khối dữ liệu kết quả gom dữ liệu bằng country

Khi roll-up được thể hiện bằng cách giảm chiều, 1 hay nhiều hơn 1 chiều được loại bỏ ra khỏi khối dữ liệu Ví dụ, xem xét khối dữ liệu sales bao gồm chỉ

2 chiều location và time Roll-up có thể được thể hiện bằng cách loại bỏ chiều time, kết quả cho ra là sự tổng kết của tất cả sales của location thay vì bằng locaton và time

Drill-down: Drill-down ngược lại với roll-up Nó duyệt từ dữ liệu ít chi

tiết hơn đến dữ liệu chi tiết hơn.Drill-down có thể được thực hiện bằng cách lùi xuống trên phân cấp khái niệm cho một chiều hay đưa ra thêm độ đo Hình 3.10 hiển thị kết quả của một phép drill-down thực hiện trên khối dữ liệu trung tâm bằng cách lùi xuống trên phân cấp khái niệm cho phân cấp khái niệm của time (phân cấp khái niệm của time là "day < month < quarter < year") Drill-up thực hiện bằng cách giảm dần phân cấp time từ cấp độ của quarter tới cấp chi tiết hơn Kết quả là khối dữ liệu liệt kê chi tiết tổng doanh số bán hàng mỗi tháng thay vì tổng hợp chúng bằng quarter

Bởi vì drill-down thêm chi tiết vào dữ liệu đã cho, nó có thể được thể hiện bằng cách thêm chiều vào khối dữ liệu Ví dụ, một phép drill-down trên khối dữ liệu trung tâm của hình 3.10 có thể thực hiện bằng cách thêm vào một chiều mới, như là customer_group

Slice và dice: Các phép slice lựa chọn trên một chiều của khối dữ liệu, kết

quả cho ra một khối dữ liệu nhỏ hơn Hình 3.10 cho thấy một phép slice, trong

đó dữ liệu sales được lựa chọn từ khối dữ liệu trung tâm theo chiều time với tiêu chí time =”Q1” Các phép dice định nghĩa một khối dữ liệu nhỏ hơn bằng cách thực hiện lựa chọn trên hai hay nhiều chiều Hình 3.10 cho thấy một phép dice

trên khối dữ liệu trung tâm với tiêu chí chọn trên 3 chiều: (location = “Toronto”

or “Vancouver”) and (time = “Q1” or “Q2”) and (item =“home entertainment”

or “computer”)

Pivot (xoay): Pivot (còn gọi là xoay) hiểu theo trực quan là quay trục dữ

liệu để cung cấp một thể hiện thay thế của dữ liệu Hình 3.10 hiển thị một phép pivot trong đó trục item và location trong lát cắt 2-D được quay Một ví dụ khác bao gồm cả quay trục trong khối dữ liệu 3-D, hay chuyển khối 3-D thành chuỗi các mặt 2-D

Các phép OLAP khác: Một số hệ thống OLAP cung cấp thêm phép drill

Ví dụ, drill-across thực hiện các truy vấn liên quan đến nhiều hơn 1 bảng fact Phép drill-through dùng các tiện ích của SQL để chuyển từ cấp tận cùng của khối dữ liệu xuống bảng dữ liệu quan hệ của người dùng cuối Phép xử lý khác

là ranking N mẫu hàng đầu (top N) hoặc N mẫu cuối (bottom N) trong danh sách, cũng như tính toán độ thay đổi trung bình, tỉ lệ tăng trưởng, lãi xuất, … OLAP cung cấp khả năng mô hình hóa phân tích, bao gồm bộ máy tính toán cho việc rút ra các tỉ lệ, các biến,…, và cho việc tính toán các độ đo trên các chiều

Nó có thể thiết lập nên việc tổng hợp và phân cấp các chiều OLAP cũng cung

cấp các mô hình chức năng để dự đoán, phân tích các xu hướng, phân tích thống

kê Trong ngữ cảnh này, một bộ máy OLAP là một công cụ phân tích dữ liệu mạnh mẽ

SO SÁNH HỆ THỐNG OLAP VỚI CƠ SỞ DỮ LIỆU THỐNG KÊ

Nhiều đặc tính của hệ thống OLAP, như sử dụng mô hình dữ liệu đa chiều

và phân cấp khái niệm, sự kết hợp của các độ đo với các chiều, và các phép

roll-up và drill-down, cũng tồn tại trong các hệ cơ sở dữ liệu thống kê (SDB) Một hệ

cơ sở sữ liệu thống kê là hệ cơ sở dữ liệu được thiết kế để hỗ trợ các ứng dụng thống kê Sự tương tự giữa 2 loại hệ thống ít khi được bàn luận, chủ yếu là do sự khác nhau về thuật ngữ và miền ứng dụng của nó

Tuy nhiên hệ thống OLAP và hệt thống SDB có những khác biệt như: SDB có xu hướng tập trung vào các ứng dụng kinh tế xã hội, OLAP hướng tới các ứng dụng trong doanh nghiệp Các vấn đề bí mật riêng tư có thể ảnh hưởng tới việc cho phép hay không việc hiển thị các chi tiết ở cấp thấp trong phân cấp Cuối cùng, không giống như SDB, hệ thống OLAP được thiết kế để kiểm soát lượng lớn dữ liệu hiệu quả

2.7 MÔ HÌNH STARNET DÙNG CHO TRUY VẤN DỮ LIỆU ĐA

CHIỀU

Truy vấn dữ liệu đa chiều có thể được dựa trên mô hình starnet Mô hình starnet bao gồm các dòng xuất phát từ cùng 1 điểm trung tâm, mỗi dòng thể hiện phân cấp khái niệm cho một chiều Mỗi cấp độ trừu tượng trên phân cấp được gọi là footprint Chúng hỗ trợ cho việc thực hiện các phép xử lý trên OLAP như drill-down và roll-up

Ví dụ 3.9 Startnet Một mô hình truy vấn starnet cho kho dữ liệu AllElectronic

được hiển thị trong hình 3.11 Mô hình này bao gồm 4 đường thẳng, thể hiện phân cấp khái niệm lần lượt cho các chiều time, item, location, customer Người dùng có thể roll-up theo chiều time từ month đến quarter, hoặc drill-down theo location từ country xuống city Phân cấp khái niệm có thể được dùng để tổng quát hóa dữ liệu bằng cách thay thế giá trị ở cấp độ thấp lên cấp độ cao hơn (ví

dụ từ “day” lên “year”) Hoặc chi tiết hóa dữ liệu bằng cách thay thế dữ liệu ở cấp cao xuống dữ liệu cấp thấp

3 KIẾN TRÚC KHO DỮ LIỆU

Trong phần này ta sẽ bàn luận các vấn đề về kiến trúc kho dữ liệu Phần

3.1 cho một tài khoản tổng quát để thiết kế và xây dựng kho dữ liệu Phần 3.2

mô tả kiến trúc 3 tầng của kho dữ liệu Phần 3.3 mô tả các công cụ cho người

dùng cuối và các tiện ích cho kho dữ liệu Phần 3.4 mô tả việc lưu trữ metadata

Phần 3.5 thể hiện các loại khác nhau của máy chủ kho dữ liệu trong OLAP

3.1 CÁC BƯỚC THIẾT KẾ VÀ XÂY DỰNG KHO DỮ LIỆU

Thiết kế của Kho dữ liệu: Framework phân tích kinh doanh

"Những gì nhà phân tích kinh doanh lấy được từ kho dữ liệu?" Trước tiên, có

một kho dữ liệu có thể cung cấp một lợi thế cạnh tranh bằng việc đưa ra thông

tin về hoạt động của doanh nghiệp, từ đó có thể đưa ra các điều chỉnh phù hợp

để chiến thắng các đối thủ cạnh tranh Thứ hai, một kho dữ liệu có thể nâng cao năng suất kinh doanh vì nó giúp cho việc thu thập thông tin nhanh chóng và hiệu quả Thứ ba, một kho dữ liệu giúp cho vệc quản lý quan hệ khách hàng bởi vì nó cung cấp một cái nhìn nhất quán về khách hàng và các mặt hàng trên tất cả các ngành nghề kinh doanh, tất cả các chi nhánh, và tất cả các thị trường Cuối cùng, một kho dữ liệu có thể giúp giảm chi phí bằng cách theo dõi xu hướng, mô hình,

và các ngoại lệ trong thời gian dài một cách nhất quán và đáng tin cậy

Để thiết kế một kho dữ liệu hiệu quả chúng ta cần phải hiểu và phân tích nhu cầu kinh doanh và xây dựng một khuôn khổ cho nó Việc xây dựng một hệ thống thông tin lớn và phức tạp như vậy được xem như là việc xây dựng một tòa nhà lớn và phức tạp, mà chủ sở hữu, kiến trúc sư, và người xây dựng có quan điểm khác nhau Những quan điểm được kết hợp để tạo thành một framework thể hiện quan điểm từ trên xuống, nhà điều hành kinh doanh, hoặc chủ sở hữu, cũng như từ dưới lên, quan điểm nhà điều khiển xây dựng, hoặc quan điểm nhà thi công của của hệ thống thông tin

Bốn cái nhìn khác nhau về thiết kế kho dữ liệu cần được xemm xét: cái nhìn trên-xuống, cái nhìn về nguồn dữ liệu, cái nhìn về kho dữ liệu, cái nhìn về truy vấn kinh doanh

 Cái nhìn trên-xuống: cho phép lựa chọn các thông tin thích hợp cần thiết

cho kho dữ liệu Thông tin này đáp ứng nhu cầu hiện tại và tương lai của doanh nghiệp

 Cái nhìn về nguồn dữ liệu: đưa ra thông tin được nắm bắt, thông tin

được lưu trữ và thông tin được quản lý bằng hệ thống giao dịch Thông tin này có thể được tài liệu hóa ở các cấp độ khác nhau về độ chi tiết và độ chính xác, từ các bảng dữ liệu nguồn để tích hợp chúng lại Các nguồn dữ