OLAP và ứng dụng OLAP và ứng dụng

Giới thiệu Công nghệ Olap. Olap trong Oracle service. Ứng dụng trong phân tích thu nhập chi phí MSB Giới thiệu Công nghệ Olap. Olap trong Oracle service. Ứng dụng trong phân tích thu nhập chi phí MSB Giới thiệu Công nghệ Olap. Olap trong Oracle service. Ứng dụng trong phân tích thu nhập chi phí MSB Giới thiệu Công nghệ Olap. Olap trong Oracle service. Ứng dụng trong phân tích thu nhập chi phí MSB

LUẬN VĂN THẠC SĨ KỸ THUẬT

Người hướng dẫn khoa học:

PGS TS NGUYỄN KIM ANH

HÀ NỘI – 2013

MUC LUC

LỜI CẢM ƠN 2

DANH MỤC VIẾT TẮT 3

DANH MỤC HÌNH VẼ 4

LỜI MỞ ĐẦU 6

CHƯƠNG 1: CÔNG NGHỆ OLAP 9

1.1 Giới thiệu về Data Warehouse 9

1.1.1 Định nghĩa data warehouse 9

1.1.2 Các đặc trưng của kho dữ liệu 10

1.1.3 Kiến trúc của kho dữ liệu [7] 13

1.1.4 Ứng dụng của kho dữ liệu 16

1.2 Tổng quan về OLAP 16

1.2.1 Định nghĩa OLAP 16

1.2.2 Tại sao phải xây dựng các ứng dụng OLAP 17

1.2.3 Các đặc điểm của ứng dụng OLAP 24

1.2.4 Tổ chức và xử lý dữ liệu của hệ thống OLAP 31

1.2.5 Các mô hình OLAP[7] 33

CHƯƠNG II OLAP TRONG ORACLE SERVICE 41

2.1 OLAP trong Oracle[7] 41

2.1.1 Tích hợp đầy đủ công nghệ đa chiều 41

2.1.2 Quản trị, phát triển ứng dụng dễ dàng 41

2.1.3 Bảo mật 42

2.1.4 Hiệu năng và tính sẵn sàng cao 42

2.1.5 Giảm thiểu chi phí 43

2.1.6 Hỗ trợ Report và dashboard trong Oracle OLAP 43

2.2 Các thành phần trong Oracle OLAP 45

2.2.1 Cube 46

2.2.2 Measure 47

2.2.3 Dimension 47

2.2.4 Hierachie và Level 49

2.3 Quy trình thiết kế các đối tượng trong Oracle OLAP 52

2.3.1 Xây dựng Dimension 52

2.3.2 Xây dựng Fact 53

2.3.3 Phân tích và xử lý dữ liệu 53

2.4 OLAP với công cụ Oracle và công cụ IBM 55

2.4.1 Công cụ Oracle 55

2.4.2 Công cụ IBM 61

2.4.3 So sánh các công cụ 65

CHƯƠNG 3 ỨNG DỤNG TRONG PHÂN TÍCH THU NHẬP CHI PHÍ MSB 69

3.1 Bài toán 69

3.2 Phân tích 69

3.2.1 Phân tích bài toán 69

3.2.2 Giải pháp thực hiện 70

3.3 Mô hình hệ thống 70

3.3.1 Mô hình tổng quan 70

3.3.2 Mô hình thiết kế cơ sở dữ liệu 71

3.4 Thiết kế chi tiết 74

3.4.1 Thiết kế Kho dữ liệu DW 74

3.4.2 Thiết kế OLAP 78

3.4.3 Thiết kế Report 85

3.5 Kết quả 88

3.5.1 Báo cáo thu nhập chi phí 88

3.5.2 Báo cáo kinh doanh 89

3.5.3 Báo cáo phân tích 90

3.5.4 Bảng phân tích 91

3.5.5 Báo cáo thống kê 95

KẾT LUẬN 97

4.1 Những điều đã làm được 97

4.2 Những điều còn hạn chế 97

TÀI LIỆU THAM KHẢO 98

LỜI CẢM ƠN

Lời đầu tiên, tác giả xin bày tỏ lòng biết ơn chân thành và sâu sắc tới PGS.TS Nguyễn Kim Anh, người đã tận tình và nghiêm khắc hướng dẫn để luận văn này được hoàn thành

Tác giả chân thành cảm ơn Viện Công nghệ thông tin và truyền thông, Viện Đào tạo Sau Đại học, trường Đại học Bách khoa Hà Nội, đã tạo mọi điều kiện thuận lợi cho tác giả trong quá trình học tập và nghiên cứu Cảm ơn các thầy cô đã cùng tác giả trao đổi những kiến thức và kinh nghiệm quý báu để giúp cho luận văn được hoàn thiện hơn Tác giả cũng gửi lời cảm ơn tới đồng nghiệp, Công ty Cổ phần giải pháp phần mềm tài chính và Ngân hàng Thương mại Cổ phần Hàng Hải đã tạo điều kiện thuận lợi để giúp tác giả hoàn thành luận văn

Bên cạnh đó, sự quan tâm của gia đình, bạn bè là nguồn động viên không thể thiếu để giúp tác giả hoàn thành luận văn này Xin chân thành cảm ơn

Học viên: Nguyễn Thị Hồng Lớp: 12ACNTT-HY

DANH MỤC VIẾT TẮT

OLAP Online Analytical Processing Xử lý phân tích trực tuyến

DW Data warehouse Kho dữ liệu

ETL Extract, Transform, Load Lọc, Truyển đổi, Tải OLTP Online Transaction Processing Xử lý giao dịch trực tuyến

Data Mart Data Mart Kho dữ liệu chuyên đề Drill-down Drill-down Khoan xuống

Drill-across Drill-across Khoan ngang

Drill-through Drill-through Khoan xuyên

Dimension Dimension Chiều

DANH MỤC HÌNH VẼ

Hình 1.1 Mô hình DW 9

Hình 1.2 Đặc trưng DW 11

Hình 1.3 Tính ổn định trong DW 13

Hình 1.4 Kiến trúc DW 14

Hình 1.5 Kiến trúc DW-Staging 15

Hình 1.6 Kiến trúc DW-Staging-Data Marts 15

Hình 1.7 Vị trí OLAP 25

Hình 1.8 Mô hình Fact-Dimension 27

Hình 1.9 Biểu diễn mô hình Fact-Dimension 28

Hình 1.10 Mô hình phân cấp 29

Hình 1.11 Mô hình ROLAP 34

Hình 1.12: Mô hình dữ liệu ROLAP 35

Hình 1.13 Lược đồ hình sao 35

Hình 1.14 Lược đồ bông tuyết 36

Hình 1.15 Mô hình MOLAP 37

Hình 1.16 Mô hình HOLAP 39

Hình 1.17 ROLAP và MOLAP 40

Hình 2.1 Bảng tổng hợp tạo trong ứng dụng Oracle 44

Hình 2.2 Báo cáo dạng biểu đồ về hiệu xuất theo quý 44

Hình 2.4 Báo cáo tổng hợp theo các năm 45

Hình 2.5 Mối quan hệ các đối tượng chiều 46

Hình 3.1 Mô hình tổ chức hệ thống 71

Hình 3.2 Mô hình lưu thông tin giá vốn 73

Hình 3.3 Mô hình lưu thông tin lịch sử giao dịch 74

Hình 3.4 Màn hình lọc điều kiện 89

Hình 3.5 Báo cáo thu nhập chi phí quy đổi VND 89

Hình 3.7 Báo cáo kinh doanh toàn hàng 90

Hình 3.8 Báo cáo phân tích thu nhập chi phí 91

Hình 3.9 Bảng phân tích lợi nhuận theo phân hệ 92

Hình 3.10 Bảng phân tích thu nhập chi phí theo ngân hàng chuyên doanh 93

Hình 3.11 Báo cáo phân hệ tiền vay (Loan) 93

Hình 3.12 Báo cáo huy động vốn 94

Hình 3.13 Báo cáo cho sản phẩm tiền gửi 94

Hình 3.14 Bảng phân tích lợi nhuận theo phân hệ và sản phẩm 95

Hình 3.15 Top 10 khách hàng 96

LỜI MỞ ĐẦU

Cùng với sự tiến bộ không ngừng của khoa học và công nghệ, ngày càng xuất hiện nhiều ứng dụng cơ sở dữ liệu với các yêu cầu phân tích đặc biệt Trong lĩnh vực quản trị và phân tích cơ sở dữ liệu, các thiết kế cơ sở dữ liệu quan hệ thông thường bắt đầu bộc lộ nhiều nhược điểm Điều này làm phát sinh nhu cầu nghiên cứu về việc thiết kế

cơ sở dữ liệu đa chiều đáp ứng được nhu cầu phân tích của doanh nghiệp Vấn đề lọc, tách dữ liệu cũng là bài toán khó cho những cơ sở dữ liệu lớn Để giải quyết vấn đề này, cấu trúc kho dữ liệu ( data warehouse - DW) được xây dựng đáp ứng nhu cầu thực tế

Việc phân tích, đánh giá kết quả kinh doanh dựa trên nhiều mặt đòi hỏi nhà quản lý phải dựa trên kết quả từ nhiều khía cạnh Để hỗ trợ nhà quản lý, việc xây dựng DW OLAP đem lại nhiều kết quả cao trong quá trình phân tích và đánh giá doanh thu Thực trạng hệ thống dữ liệu của Ngân hàng thương mại cổ phần Hàng Hải được lấy từ nhiều nguồn khác nhau, dữ liệu giữa các hệ thống không đồng bộ như: Kondor, Credit Card, Core, vTreasury … Yêu cầu từ trung tâm tài chính là đưa tất cả dữ liệu về một

cơ sở dữ liệu thống nhất Đồng thời xây dựng được báo cáo hỗ trợ nghiệp vụ phân tích thu nhập chi phí, quản lý lỗ lãi, phân bổ lợi nhuận, …

Từ những yêu cầu thực tế, nhu cầu phải xây dựng kho dữ liệu OLAP là cần thiết Chúng tôi xây dựng DW chung cho toàn ngân hàng, các hệ thống báo cáo và phân tích lấy dữ liệu từ DW đưa vào các khối OLAP để phân tích dữ liệu Dữ liệu thô trước khi đưa vào DW được xử lý trên vùng đệm DW gọi là Staging, lưu trữ dữ liệu hàng ngày,

và vùng lưu dữ liệu thô lịch sử của hệ thống nguồn gọi là Hstaging

Mục đích của chính luận văn là nghiên cứu “Xây dựng hệ thống phân tích trực tuyến trên nền tảng Data warehouse” Đây là bài toán có nhiều ứng dụng để giải quyết các phát sinh từ nhu cầu thực tế Các ngân hàng đang ngày càng cải tiến cơ sở hạ tầng và công nghệ đáp ứng yêu cầu phân tích, đánh giá kết quả hoạt động kinh doanh của chi nhánh, hội sở cũng như toàn ngân hàng

Mô hình OLAP đã và đang được phân tích, xây dựng trên nhiều hệ thống như Oracle, DB2, … Các bài toán phân tích trực tuyến đã được đề xuất, được ứng dụng trên nhiều

hệ thống ngân hàng trên thế giới Hiện nay tại Việt nam, ngân hàng thương mại cổ phần Hàng Hải là một trong những ngân hàng đầu tiên xây dựng hệ thống kho dữ liệu tập trung DW làm tiền đề cho các ứng dụng OLAP sau này Kho dữ liệu tập trung được lưu trữ trong cơ sở dữ liệu Oracle, hệ thống báo cáo được xây dựng trên công cụ kéo thả Cognos theo mô hình BDM (Banking data model – Mô hình dữ liệu ngân hàng) của IBM

Ngoài Lời cảm ơn, Lời mở đầu, Kết luận, Danh sách tài liệu tham khảo, nội dung chính của luận văn được trình bày trong ba chương Cụ thể:

Chương 1: “Công nghệ OLAP”, nhắc lại một số khái niệm và đặc trưng cơ bản về DW

và OLAP Giới thiệu tổng quan về mô hình và quy trình xây dựng OLAP

Chương 2: “OLAP trong Oracle service” giới thiệu chi tiết về OLAP, các thành phần

và quy trình thiết kế OLAP trong cơ sở dữ liệu Oracle và công cụ hỗ trợ của IBM (Banking data model – Mô hình dữ liệu ngân hàng) Đưa ra giải pháp thiết kế kho OLAP trên cơ sở dữ liệu Oracle và sử dụng IBM Cognos để xây dựng báo cáo BI Chương 3: “Ứng dụng trong phân tích thu nhập chi phí tại MSB”, đưa ra ứng dụng thực tế áp dụng mô hình OLAP trên nền tảng kho dữ liệu tập trung – DW tại ngân hàng thương mại cổ phần Hàng Hải – MSB xây dựng trên cơ sở dữ liệu Oracle

Hệ thống ứng dụng OLAP đã và đang được vận hành trên hội sở chính và toàn chi nhánh của MSB Chúng tôi vẫn đang tiếp tục nghiên cứu nhằm tối ưu các thuật toán xây dựng hệ thống

Luận văn được hoàn thành tại Viện Công nghệ thông tin và truyền thông, trường Đại học Bách khoa Hà Nội, dưới sự hướng dẫn của PGS.TS Nguyễn Kim Anh Mặc dù đã rất cố gắng, song luận văn chắc chắn vẫn còn nhiều thiếu sót Tác giả rất mong nhận được sự góp ý của các thầy cô và đồng nghiệp để luận văn được hoàn thiện hơn Xin chân thành cảm ơn

Hà Nội, ngày 25 tháng 11 năm 2013

CHƯƠNG 1: CÔNG NGHỆ OLAP

1.1 Giới thiệu về Data Warehouse

1.1.1 Định nghĩa data warehouse

Hình 1.1 Mô hình DW Kho dữ liệu (data warehouse), gọi một cách chính xác hơn là kho thông tin, 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 và phân tích, được thiết kế với việc tiếp cận các ý kiến trong mọi lĩnh vực kinh doanh Nó cung cấp các công cụ để đáp ứng thông tin cần thiết cho các nhà quản trị kinh doanh tại mọi cấp độ tổ chức – không những chỉ là những yêu cầu dữ liệu phức hợp, mà còn là điều kiện thuận tiện nhất để đạt được việc lấy thông tin nhanh, chính xác Kho dữ liệu là một sự pha trộn của nhiều công nghệ, bao gồm các cơ sở dữ liệu đa chiều và mối quan hệ giữa chúng, kiến trúc chủ khách, giao diện người dùng đồ họa, …

Kho dữ liệu thường rất lớn tới hàng trăm GB hay thậm chí hàng Terabyte Kho dữ liệu được xây dựng để tiện lợi cho việc truy cập theo nhiều nguồn, nhiều kiểu dữ liệu khác nhau sao cho có thể kết hợp được cả những ứng dụng của các công nghệ hiện đại và kế thừa được từ những hệ thống đã có sẵn từ trước

Kho dữ liệu là một cơ sở dữ liệu quan hệ được thiết kế để truy vấn và phân tích nhanh hơn so với quá trình xử lý giao dịch Nó thường lưu dữ liệu lịch sử từ các dữ liệu giao dịch, nhưng nó có thể lưu dữ liệu từ nhiều nguồn khác Nó tách biệt việc phân tích từ giao dịch và việc tổ chức để hợp nhất dữ liệu từ nhiều nguồn

Môi trường kho dữ liệu bao gồm các giải pháp trích xuất dữ liệu, truyền dữ liệu, thay đổi dữ liệu và tải dữ liệu (ETL), cơ cấu OLAP, công cụ phân tích khách hàng, và ứng dụng quản lý tiến trình thu thập dữ liệu và cung cấp dữ liệu cho nghiệp vụ

* Ý nghĩa của kho dữ liệu [1]

- Truy cập dữ liệu một cách thống nhất:

o Thu thập và kết hợp thông tin từ nhiều nguồn vào một vùng chung nhất Các thông tin được lấy từ nhiều hệ thống, được lọc, tách và chuyển đổi vào một nguồn duy nhất

o Cung cấp một khung nhìn tích hợp Khung nhìn tích hợp được thể hiện qua giao diện hệ thống hỗ trợ Người dùng có thể dễ dàng thao tác trên

o Hỗ trợ khả năng chia sẻ Dữ liệu được chia sẻ, phân tách cho nhiều hệ thống dùng chung

- Chuyển đổi dữ liệu thành thông tin: Cung cấp thông tin chính xác đúng thời điểm và đúng định dạng Dữ liệu được chuyển đổi về dạng thống nhất theo nguyên tắc của hệ thống DW

1.1.2 Các đặc trưng của kho dữ liệu

Hình 1.2 Đặc trưng DW [9]

1.1.2.1 Hướng đối tượng

Kho dữ liệu được thiết kế để giúp phân tích dữ liệu Nó tập trung vào việc mô hình hóa

và phân tích dữ liệu hỗ trợ nhà quản lý ra quyết định mà không tập trung vào các xử lý thông thường Nó được tổ chức xung quanh các chủ thể chính, như khách hàng (customer), sản phẩm (product), bán hàng (sales)

DW tập trung vào việc mô hình hóa và phân tích dữ liệu cho các nhà quản lý đưa ra quyết định, mà không tập trung vào các hoạt động hay các xử lý toàn tác hàng ngày Cung cấp một khung nhìn đơn giản và súc tích xung quanh các sự kiện của các chủ thể

Ví dụ với dữ liệu của một ngân hàng, sử dụng kho dữ liệu ta có thể trả lời các câu hỏi

“Số dư các tài khoản thuộc nhóm nợ hai là bao nhiêu ?”,“ Trích lập dự phòng chung,

dự phòng cụ thể của một chi nhánh là bao nhiêu?”, “Có bao nhiêu tài khoản phát sinh mới trong ngày/tháng?”

1.1.2.2 Tính tích hợp

Tính tích hợp là mối quan hệ gần gũi với hướng đối tượng Kho dữ liệu sẽ gộp dữ liệu

từ nhiều nguồn khác nhau ( MS SQL, Oracle, DB2, Sysbase ) về một nguồn chung (Oracle ) Hiện nay có rất nhiều công cụ hỗ trợ việc chuyển đổi, tích hợp dữ liệu từ nhiều nguồn vào nguồn duy nhất như IBM Datastage của IBM hay ODI của Oracle hay SIIS của Microsoft

Tính tích hợp cũng thể hiện trong việc khai phá và đưa các dạng dữ liệu về chung một dạng đồng nhất Như mô tả hình bên dưới, các tài khoản thanh toán, tài khoản vay, tài khoản séc đều sẽ được DW đưa chung vào một chủ thể Tài khoản

1.1.2.3 Tính ổn định

Tính ổn định có nghĩa là dữ liệu khi nhập vào kho dữ liệu ít bị biến đổi, thao tác cập nhật, xóa ít khi được thực hiện Dữ liệu trong kho dữ liệu chỉ có thao tác thêm mới; đọc Mục tiêu của kho dữ liệu là để lưu trữ dữ liệu lịch sử Do đó không thể thay đổi

dữ liệu đã được tổng hợp lưu lại trong kho

Hình 1.3 Tính ổn định trong DW

1.1.2.4 Gắn với thời gian

Để có quyết định về phương hướng kinh doanh, người ra quyết định cần có dữ liệu trong một phạm vi thời gian đủ dài Điều này ngược với quá trình xử lý OLTP ở chỗ hiệu quả của yêu cầu phụ thuộc vào dữ liệu lịch sử được di chuyển tới kho lưu trữ Mục tiêu của DW là sự thay đổi theo thời gian Dữ liệu lưu trữ theo thời gian

- Yêu cầu quan trọng đối với 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:

o Cơ sở dữ liệu tác nghiệp: Dữ liệu chỉ có giá trị hiện thời, dữ liệu đang tác nghiệp, đang xử lý

o 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)

o Yếu tố thời gian được lưu trữ trong CSDL Lưu vết thời gian để hỗ trợ truy cập, phân tích, đánh giá

1.1.3 Kiến trúc của kho dữ liệu [7]

1.1.3.1 Kiến trúc cơ bản

Hình 1.4 Kiến trúc DW Kiến trúc cơ bản này bao gồm ba vùng: Nguồn dữ liệu; Kho; Dữ liệu sau xử lý (User, Reporting, Mining) Trong hình vẽ chúng ta thấy siêu dữ liệu (metadata) và dữ liệu thô của hệ thống OLTP cũng được thể hiện ở DW, bên cạnh đó thấy xuất hiện dữ liệu tổng hợp (summary data) Tổng hợp là một lợi thế của kho dữ liệu bởi vì nó đã tính toán sẵn kết quả phục vụ cho báo cáo, truy vấn

1.1.3.2 Kiến trúc bao gồm vùng Staging

Ở kiến trúc trên, chúng ta phải làm sạch và xử lý dữ liệu trước khi đẩy vào kho dữ liệu Trong kiến trúc này, kho dữ liệu sử dụng một khu vực trung gian để xử lý dữ liệu trước khi đẩy vào kho, nó gọi là Staging Hình vẽ dưới minh họa cho kiến trúc này

Hình 1.5 Kiến trúc DW-Staging

Dữ liệu từ nhiều nguồn có nền tảng khác nhau (Oracle, DB2, Sysbase, MS SQL…) sẽ được gom, chuyển đổi, tập hợp về Staging trên một nền tảng chung

1.1.3.3 Kiến trúc bao gồm vùng Staging và Data Marts (Kho dữ liệu chủ đề)

Hình 1.6 Kiến trúc DW-Staging-Data Marts Kiến trúc ở mục trên khá phổ biến nhưng ta có thể tùy chỉnh thêm để phục vụ các bộ phận khác nhau Data marts được hiểu là các vùng dữ liệu theo chủ đề Do đó trong kiến trúc này, chúng ta sẽ thêm vùng data mart vào để phân tách dữ liệu theo mục đích khác nhau, phục vụ đối tượng khác nhau

1.1.4 Ứng dụng của kho dữ liệu

Kho dữ liệu – DW là thuật ngữ khá phổ biến hiện nay cho các cơ sở dữ liệu lớn, đặc biệt trong lĩnh vực ngân hàng Hiện nay các ngân hàng lớn như Vietcombank, Techcombank, BIDV, … đang và đã lên kế hoạch xây dựng các kho dữ liệu chung Việc xây dựng kho dữ liệu tạo nền tảng cho các ứng dụng phân tích của ngân hàng Nó

là bước đệm để phát triển các ứng dụng OLAP

1.2 Tổng quan về OLAP

1.2.1 Định nghĩa OLAP

OLAP (On-Line Analytical Processing – Xử lý phân tích trực tuyến) là một thuật ngữ dùng để chỉ các ứng dụng và kỹ thuật nhằm thu thập, quản lý, tổ chức và biểu diễn dữ liệu đa chiều cho mục đích phân tích và tổng hợp

Trong vòng hơn 10 năm trở lại đây, một lượng đáng kể dữ liệu tác nghiệp đã được chuyển vào lưu trữ trong các cơ sở dữ liệu (CSDL) quan hệ CSDL quan hệ đã được sử dụng rộng rãi trong nhiều lĩnh vực với sự quan tâm đặc biệt đến việc xử lý giao dịch

Để thành công trên đấu trường này, các nhà sản xuất CSDL quan hệ đặt việc xử lý có hiệu quả cao một lượng lớn các giao dịch nhỏ và khả năng sẵn sàng chịu lỗi của dữ liệu lên thành các vấn đề quan trọng hàng đầu Các hệ thống hoạt động theo mô hình này gọi là các hệ thống giao dịch trực tuyến OLTP ( On-Line Transaction Processing) Các hệ thống OLTP được đặc trưng bởi nhiều người sử dụng tạo, cập nhật, truy vấn từng bản ghi riêng lẻ Do đó các cơ sở dữ liệu OLTP được tối ưu hóa các giao dịch cập nhật Trong khi đó các ứng dụng OLAP được sử dụng bởi các nhà phân tích và quản

lý, những người thường mong muốn có một cái nhìn ở mức độ tổng hợp cao hơn của

dữ liệu Vì vậy, các cơ sở dữ liệu OLAP được tối ưu cho việc xử lý phân tích

Như phần trên đã trình bày, các hãng sản xuất hệ quản trị CSDL quan hệ cũng đã đưa

ra các công cụ để xây dựng các kho dữ liệu trong thời gian gần đây Kho dữ liệu lưu trữ các thông tin mang tính chiến thuật để trả lời các câu hỏi như “Ai?” và “Cái gì?” về các sự kiện trong quá khứ Một câu hỏi thường được gửi đến kho dữ liệu có dạng như sau: “Tổng thu nhập của Ngân hàng trong quý 2 là bao nhiêu?”

Một điều quan trọng là ta cần phân biệt giữa các khả năng của một kho dữ liệu với các khả năng của một hệ thống OLAP Khác với kho dữ liệu thường được xây dựng dựa trên mô hình quan hệ, OLAP sử dụng một khung nhìn đa chiều của các dữ liệu tổng hợp nhằm cung cấp sự truy cập nhanh chóng đến các thông tin mang tính chiến lược

để thực hiện phân tích dữ liệu đó sâu hơn

OLAP cho phép các nhà phân tích, các nhà quản lý, các nhân viên điều hành có thể hiểu thấu ý nghĩa bên trong của dữ liệu thông qua việc truy cập nhanh chóng, ổn định

và có giao tiếp với nhiều dạng khung nhìn dữ liệu

Trong khi OLAP cũng có khả năng trả lời các câu hỏi “Ai?” và “Cái gì?” thì chính khả năng trả lời được các câu hỏi “Cái gì/Nếu?” và “Tại sao?” đã tách biệt OLAP với các kho dữ liệu OLAP cho phép ra quyết định về các hoạt động trong tương lai Một phép tính thông thường trong OLAP phức tạp hơn việc tổng hợp dữ liệu một cách đơn giản,

ví dụ OLAP sẽ cho ta lời giải của câu hỏi sau: “Giá bán nước ngọt có ga cho các đại lý

sẽ bị ảnh hưởng như thế nào nếu giá xi-rô tăng lên 200 đồng/lít và chi phí vận chuyển giảm xuống 100 đồng/km” OLAP và kho dữ liệu là sự bổ sung cho nhau Kho dữ liệu lưu trữ và quản lý dữ liệu OLAP sử dụng dữ liệu trong kho dữ liệu để phân tích, tổng hợp trên nền các khung nhìn đa chiều Từ đó thu được các thông tin chiến lược nhằm mục đích hỗ trợ quyết định và quản lý

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

Vậy OLAP là gì, ta có thể định nghĩa nó như sau:

OLAP là một loại công nghệ phần mềm cho phép các phân tích, quản lý và thực hiện

để đạt được cái nhìn sâu sắc tới dữ liệu một cách nhanh chóng, nhất quán, truy cập một cách rộng rãi về thông tin được chuyển đổi từ dữ liệu thô để phản ánh chiều thực tế của doanh nghiệp theo cách hiểu của người dùng

Định nghĩa về OLAP chứa đựng nhiều yếu tố chính: Tốc độ, nhất quán, truy cập có tính tương tác và cái nhìn đa chiều về tất cả các yếu tố chính

1.2.2 Tại sao phải xây dựng các ứng dụng OLAP

Dữ liệu tác nghiệp đã tăng lên đều đặn và đáng kể trong khoảng 20 năm qua Trước đây các doanh nghiệp và các cơ quan chính phủ làm việc với dữ liệu vào cỡ Megabyte

và Gigabyte, còn ngày nay họ đang phải làm việc với dữ liệu ở mức Terabyte và Petabyte Với dữ liệu lớn như vậy thì việc hiểu được ý nghĩa hàm chứa bên trong dữ liệu là hết sức cần thiết Do vậy, nhu cầu của doanh nghiệp trong việc phân tích dữ liệu

kỹ càng hơn, tổng hợp nhanh hơn, cho các thông tin có chất lượng cao hơn đang ngày càng tăng lên

Thị trường ngày nay có tính cạnh tranh và sôi động hơn rất nhiều so với trước đây Các doanh nghiệp kinh doanh thành công hay thất bại phụ thuộc rất nhiều vào sự tinh

vi, tốc độ xử lý của hệ thống thông tin của họ, mà đặc biệt là khả năng phân tích, tổng hợp sử dụng hệ thống đó Càng nhanh chóng nắm bắt được tình hình kinh doanh, tình hình tổ chức doanh nghiệp mình cũng như nhu cầu, thị hiếu của thị trường thì các doanh nghiệp càng tận dụng được nhiều cơ hội phát triển Doanh nghiệp hoạt động trong một môi trường kinh tế phát triển nhanh, cạnh tranh khốc liệt nên vai trò của mỗi

cá nhân trong sự phát triển chung của doanh nghiệp ngày càng cao Điều này dẫn đến

số lượng các cá nhân của một tổ chức, những người phải thực hiện các phân tích phức tạp cũng tăng lên

Những hạn chế của hệ thống OLTP trong việc phân tích dữ liệu

Các hệ quản trị CSDL quan hệ và các công cụ cung cấp giao diện cho người sử dụng gắn liền với chúng được xây dựng và tối ưu cho việc phát triển các hệ thống xử lý giao dịch trực tuyến (OLTP) Các hệ thống này chủ yếu cho phép người sử dụng có thể hỏi đáp, cập nhật dữ liệu, tổng hợp dữ liệu một cách đơn giản Do vậy, chúng có rất nhiều hạn chế khi ta muốn sử dụng chúng để phân tích dữ liệu trực tuyến Các nhược điểm

đó là: Quản lý kém hiệu quả các quan hệ đa chiều; các khả năng phân tích được xây dựng sẵn trong hệ thống rất hạn chế; và sự tổng hợp dữ liệu hết sức khó khăn

1.2.2.1 Cơ sở dữ liệu quan hệ không thể quản lý có hiệu quả các quan hệ đa chiều

Cấu trúc hai chiều: CSDL quan hệ cổ điển về cơ bản là không được thiết kế để phục

vụ quản lý được các cấu trúc đa chiều Dữ liệu được lưu trữ trong các bảng quan hệ theo cách thông thường sẽ biểu diễn các cấu trúc đa chiều được trải phẳng ra

Dữ liệu đa chiều được trải phẳng ra giống như việc ta vẽ các bản vẽ kỹ thuật của mô hình ba chiều của một tòa nhà theo các góc chiếu khác nhau Để xây dựng lại mô hình thì ta cần phải tìm ra các bản vẽ có liên quan với nhau và kết hợp các bản vẽ đó để tạo nên bức tranh hai chiều của mô hình ba chiều Việc xây dựng lại mô hình bằng cách liên kết các bản vẽ hai chiều là khó, cần nhiều công sức và rất dễ mắc lỗi Người sử dụng gặp khó khăn với các công cụ hỏi đáp dữ liệu sử dụng SQL: một tập hợp nhiều các bảng quan hệ biểu diễn nhiều chiều sẽ làm cho người sử dụng khó có thể hiểu và

sử dụng Người sử dụng phải biết dữ liệu được chứa trong các bảng nào, các bảng được liên kết với nhau như thế nào và làm thế nào để xây dựng được câu truy vấn SQL đúng để liên kết các bảng lại với nhau

Kết nối nhiều bảng và hiệu năng kém trở thành vấn đề: Người sử dụng phải quan tâm

đến việc tối ưu các câu truy vấn để đạt được hiệu năng khả dĩ Một CSDL quản lý bán hàng có thể có các bảng và thành phần dữ liệu như sau:

Bảng 1: Product Sales/Sales office 1.000.000 bộ

Bảng 2: Product Description 1.000 bộ

Bảng 3: Sales office/District Cross Ref 100 bộ

Bảng 4: District/Region Cross Ref 10 bộ

CSDL được chuẩn hóa trên tiết kiệm không gian lưu trữ bởi vì mỗi sản phẩm, văn phòng bán hàng, văn phòng quận và vùng chỉ xuất hiện một lần trong CSDL Một câu truy vấn cần tổng hợp và so sánh dữ liệu về văn phòng bán hàng, quận và vùng phải kết nối bốn bảng lại với nhau Mỗi bản ghi phải được so sánh với mọi bộ trong mọi bảng khác Trong CSDL này cho phép kết nối như trên có thể phải thực hiện đến 1000

tỷ phép so sánh (1.000.000 * 1.000 * 100 *10) Quá trình so sánh này thường phải thực hiện trên các câu truy vấn có tính chất phân tích và tổng hợp Vì vậy nếu nhiều sử dụng cùng thực hiện nhiều câu truy vấn như trên có thể làm cho hệ thống quản trị bị quá tải

Các cơ sở dữ liệu phi chuẩn làm giảm hiệu năng và cạn kiệt tài nguyên hệ thống: Do

các kết nối nhiều bảng sử dụng tài nguyên và khó hiểu đối với người dử dụng cho nên hầu hết các nhà sản xuất CSDL quan hệ đều khuyên là người sử dụng nên tạo ra các bảng phi chuẩn đặc biệt nhằm hỗ trợ cho các xử lý có yêu cầu phân tích và tổng hợp Các bảng phi chuẩn là các bảng mà đã được kết nối trước Điều này có lợi là nó tránh được việc phải tiêu phí thời gian cho việc thực hiện kết nối nhưng thực hiện này có nhiều nhược điểm, các nhược điểm được xét đến cả trong hiệu năng và việc sử dụng tài nguyên hệ thống

Làm cạn kiệt tài nguyên hệ thống: Sự phi chuẩn tạo ra các bảng dữ liệu cực lớn bởi vì

trong mỗi bản ghi dữ liệu được lưu trữ dư thừa Các câu truy vấn OLAP sẽ phải tìm kiếm trong các bảng rất lớn làm cho chi phí xử lý câu truy vấn chưa chắc đã rẻ hơn so với chi phí của việc kết nối bảng CSDL lớn nghĩa là các câu truy vấn phải thực hiện nhiều lần vào/ra đĩa hơn khi tìm kiếm trong toàn bộ hoặc một phần CSDL Tìm kiếm trong một CSDL lớn cũng có xu hướng đẩy một lượng dữ liệu lớn vào vùng đệm gây tràn bộ nhớ, điều này ảnh hưởng đến các chương trình khác cùng chạy trong hệ thống

Hiệu năng hoạt động kém: Trong ví dụ CSDL bán hàng, mỗi mặt hàng có thể chứa

một chỉ dẫn sản phẩm, một văn phòng bán hàng, một quận, một vùng Nếu phần chỉ dẫn sản phẩm chiếm đến 25 byte, các trường khác chiếm 10 byte thì sẽ có 55 byte được thêm vào trong mỗi bản ghi Product Sales Nếu bản ghi này ban đầu có kích thước 10 byte và ta có 10 triệu bản ghi cần được phân tích thì kích thước của bảng sẽ tăng từ khoảng 100 megabyte lên 550 megabyte Bất kỳ câu truy vấn nào phải tìm kiếm trong bảng này sẽ phải tìm kiếm trong lượng dữ liệu nhiều gấp hơn 5 lần với hiệu quả giảm đi tương ứng Trong điều kiện đó thì việc đạt được thời gian trả lời nhanh là không thể thực hiện được Như vậy, mặc dù thực hiện các bảng phi chuẩn đã loại bỏ việc phải thực hiện kết nối nhưng chưa hẳn nó đã làm tăng hiệu quả xử lý Trong thực

tế, đối với một số câu hỏi hiệu quả đạt được còn giảm đi

Dữ liệu thưa làm cho CSDL lớn hơn: Sự phi chuẩn làm tăng độ thưa trong CSDL

Hình dung rằng mỗi bản ghi Product Sales được gắn thêm một trường để ghi kho hàng

và 25% số bản ghi có kho hàng gắn với chúng và 75% không có Khi bảng ghi chuẩn được tạo ra, 75% số bản ghi sẽ không chứa thông tin trong trường kho hàng Không gian lãng phí này sẽ làm tăng kích thước của CSDL ảnh hưởng đến hiệu quả thực hiện

Phải vào/ra đĩa nhiều hơn: Các bảng phi chuẩn lớn không thể đặt toàn bộ vào trong bộ

nhớ vì vậy hệ thống sẽ phải thực hiện nhiều thao tác vào/ra hơn để nhận dữ liệu Tốc

độ vào/ra ổ đĩa chậm hơn rất nhiều so với nhận dữ liệu từ bộ nhớ Các bảng lớn cần chỉ số để tăng tốc độ truy nhập nhưng chúng cũng làm tăng đáng kể thời gian cần thiết

để tải và cập nhật CSDL

1.2.2.2 Sự hạn chế trong khả năng phân tích của hệ quản trị CSDL quan hệ

Hệ quản trị CSDL quan hệ không có các khả năng vốn có thể thực hiện các thao tác OLAP cơ bản như tổng hợp theo mức (roll-up), xem các mức chi tiết (drill-down), phân hoạch (slicing and dicing) và quản lý các quan hệ phức tạp giữa các bảng và trong một bảng Hệ quản trị CSDL quan hệ chỉ có một số hàm xây dựng sẵn thao tác trên một chiều duy nhất

Sự hạn chế về chức năng: Ví dụ như SQL chỉ có thể thực hiện SUM và AVG cùng một

trường trong các bản ghi nhưng không thể SUM và AVG cho nhiều cột trên cùng một hàng Người sử dụng có thể tạo ra một biểu thức liên quan đến nhiều trường trong một bảng ghi trong một bảng duy nhất nhưng biểu thức đó không thể tham chiếu đến các bảng khác trừ khi các bảng này đã được kết nối trước trong một khung nhìn Các hạn chế này là các hạn chế vốn có trong mô hình quan hệ bởi vì nó chỉ làm việc với các bảng hai chiều

Các công cụ truy vấn của người sử dụng: Bất kỳ một thao tác phân tích nào vượt ra

khỏi các câu lệnh select và update quan hệ cơ bản thì đều phải được xử lý bằng các công cụ dành cho người sử dụng

Yêu cầu về thiết kế cụ thể và lập trình: Các công cụ này thường đòi hỏi nhiều công sức

trong việc lập trình và thiết kế cụ thể để có thể đạt được sự thể hiện tốt và các chức năng cần thiết như các tính toán liên quan đến nhiều phần tử phức tạp, lập báo cáo chuyên dụng …

Vấn đề về hiệu năng của mạng và hệ thống: Các chương trình của người sử dụng chạy

trên máy PC đầu tiên phải lấy dữ liệu từ CSDL quan hệ và sau đó chuyển dữ liệu này

về cho chương trình thông qua mạng máy tính Do các ứng dụng OLAP thường làm việc với các CSDL rất lớn nên chắc chắn phải truyền trên mạng một lượng dữ liệu lớn

về cho các chương trình, trước khi các chương trình này có thể thực hiện các thao tác tổng hợp, xem mức chi tiết hơn, phân hoạch …

Truyền một lượng dữ liệu lớn không chỉ làm giảm đáng kết hiệu năng của chương trình mà nó còn nhanh chóng làm cho mạng bị quá tải gây ảnh hưởng tới các người dùng khác trên mạng Máy phục vụ OLAP có thể trực tiếp thực hiện các thao tác phân tích, do vậy chỉ có các kết quả được truyền lại cho người sử dụng để hiển thị và phân tích sâu hơn

1.2.2.3 Các hệ quản trị CSDL quan hệ không thể dễ dàng tổng hợp dữ liệu

Công việc phân tích thường yêu cầu các dữ liệu được tổng hợp nhưng dữ liệu trong CSDL quan hệ thường được lưu trữ dưới dạng chi tiết Trong một số trường hợp ta có thể tổng hợp dữ liệu trong CSDL quan hệ bằng cách sử dụng câu lệnh SELECT kết hợp với các hàm có sẵn như Sum, AVG và mệnh đề GROUP BY Các phép tổng hợp đơn giản đó không thể thực hiện được các thao tác như tổng hợp dữ liệu theo các mức cao dần và chi tiết hóa theo từng mức giảm dần

Chi phí tài nguyên cho việc tính toán lớn: Mặc dù các phép tổng hợp đó là các phép

tính toán khá đơn giản nhưng chi phí của chúng khá đắt Để tổng hợp dữ liệu ta thường phải chạy các chương trình duyệt tất cả các bộ trong CSDL Nhiều chương trình cùng một lúc gửi các câu truy vấn mang tính tổng hợp đến hệ quản trị - điều này là thường xuyên trong các ứng dụng phân tích – có thể làm cho hệ quản trị bị quá tải

Chi phí thời gian: Bên cạnh chi phí cao, người sử dụng có thể phải mất nhiều thời gian

trước khi có được câu trả lời cần thiết, để xoay xở được với vấn đề chi phí cao và tốn thời gian trong các câu truy vấn tổng hợp, các tổ chức thường tạo ra các bảng tổng hợp chứa dữ liệu tổng hợp thường được sử dụng Các bảng tổng hợp phải được người sử dụng xác định trước và những cái không được thì sẽ không sẵn sàng để sử dụng Đây

là một hạn chế nghiêm trọng đối với việc phân tích trực tuyến

Khó sử dụng: Nhiều bảng tổng hợp – mỗi bảng cho một loại tổng hợp sẽ làm cho cấu

trúc của CSDL rất phức tạp và rắc rối, gây khó khăn khi sử dụng Người sử dụng phải biết được bảng tổng hợp nào tồn tại và thông tin gì chứa trong từng bảng tổng hợp có thể sử dụng Nắm được các thông tin này trong một hệ thống phức tạp đối với những người không tham gia thiết kế CSDL không phải là điều đơn giản

Cập nhật ảnh hưởng đến xử lý: Các bảng tổng hợp phải được cập nhật định kỳ để bảo

đảm tính thống nhất và tính chính xác của từng thông tin trong các bảng Các lần cập nhật phải được sắp xếp thời gian sao cho chúng không ảnh hưởng đến công việc xử lý bình thường và để cho chúng không làm cho hệ quản trị bị bận quá mức Do vậy, khoảng thời gian giữa các lần cập nhật cho mỗi bảng là khá lớn, các bảng có thể không đồng bộ với nhau tại một thời điểm nào đó Điều này khiến cho quá trình phân tích bị trì hoãn hoặc dẫn tới các kết quả không thống nhất

Người sử dụng bị hạn chế trong sử dụng: Dù người sử dụng đang dùng CSDL tổng

hợp hay chi tiết thì các câu truy vấn phân tích vẫn có các ảnh hưởng không thể dự đoán trước trong môi trường quan hệ Bởi vì rất khó có thể đánh giá được ảnh hưởng của các câu truy vấn phức tạp của người sử dụng, cho nên họ hiếm khi được phép truy cập trùy ý vào CSDL Họ chỉ được phép sử dụng các câu truy vấn đã được xây dựng sẵn, được thiết kế với ảnh hưởng tối thiểu đến hệ thống Họ có thể thay đổi các điều kiện tìm kiếm và sắp xếp nhưng không thể được phép xây dựng các câu truy vấn theo mong muốn Do đó, các nhà phân tích kinh doanh bị hạn chế rất nhiều các phép phân tích mà họ muốn thực hiện

Như vậy, để có thể đáp ứng một cách có hiệu quả nhu cầu phân tích và tổng hợp dữ liệu của các doanh nghiệp thì ta cần phải phát triển một mô hình tổ chức dữ liệu đặc thù phục vụ cho việc phân tích và các công cụ phân tích tổng hợp đi kèm với nó Tổ chức này sẽ cho phép các nhà phân tích có thể quan sát dữ liệu theo nhiều chiều, thực hiện các phân tích nhiều chiều và đáp ứng được yêu cầu về tốc độ xử lý nhanh

1.2.3 Các đặc điểm của ứng dụng OLAP

Các ứng dụng OLAP có thể đáp ứng nhiều công việc của một tổ chức Ví dụ như phòng tài chính sử dụng OLAP để lập dự thảo ngân sách, ước tính chi phí hoạt động cho từng đơn vị, phân tích tình hình tài chính và lập mô hình tài chính Phân tích và dự đoán doanh số tiêu thụ là hai ứng dụng OLAP thường thấy trong các phòng tiêu thụ sản phẩm Trong số các ứng dụng khác, phòng tiếp thị sử dụng OLAP để phân tích nghiên cứu thị trường, phân tích khách hàng, dự báo số lượng tiêu thụ, phân tích tình hình quảng cáo, …

Đối với tất cả các ứng dụng trên đây, điểm mạnh của OLAP chính là khả năng cung cấp cho các nhà quản lý các thông tin họ cần để đưa ra các quết định hiệu quả về các hướng hoạt động chiến lược của doanh nghiệp Kim chỉ nam của một ứng dụng OLAP thành công là khả năng cung cấp thông tin đúng lúc cần thiết Ví dụ như khả năng cung cấp thông tin kịp thời để có được một quyết định hiệu quả, điều này đòi hỏi phải

có thông tin ở nhiều mức đọ tổng hợp khác nhau chứ không chỉ yêu cầu thông tin ở mức cần thiết

Các thông tin kịp thời là các dữ liệu đã được tính toán, chúng thường phản ánh các quan hệ phức tạp và thường được tính toán tức thời Phân tích và mô hình hóa các quan hệ phức tạp chỉ có thể thực hiện được nếu như thời gian trả lời của hệ thống luôn nhỏ Thêm nữa, bởi vì bản chất của quan hệ dữ liệu là không thể biết trước cho nên mô hình dữ liệu chắc chắn sẽ rất linh động Một mô hình thật sự linh động đảm bảo chắc chắn các hệ thống OLAP có thể đáp ứng tốt được các yêu cầu kinh doanh luôn thay đổi khi cần thiết nhằm hỗ trợ quyết định có hiệu quả Hình dưới đây mô tả vai trò của ứng dụng OLAP trong việc hỗ trợ phân tích và ra quyết định

Hình 1.7 Vị trí OLAP Mặc dù các ứng dụng OLAP được áp dụng rất nhiều vào lĩnh vực hoạt động khác nhau nhưng việc đưa ra một định nghĩa cũng như các tiêu chuẩn để kiểm định một ứng dụng OLAP thì các nhà nghiên cứu CSDL vẫn còn chưa đi đến thống nhất Năm 1993 E.F Codd trong báo cáo “Providing On-line Analytical Processing to User-Analysis: An IT mandate” [3]

đã đưa khái niệm OLAP và 12 tiêu chuẩn để đánh giá một ứng dụng OLAP Sau đó vào năm 1995, ông đã bổ sung thêm 6 tiêu chuẩn nữa Trong luận văn này tôi muốn sử dụng các tiêu chuẩn ngắn gọn hơn được đưa ra bởi Nigel Pendse Các tiêu chuẩn này được viết tắt bởi từ FASMI – Fast Analysis of Shared Multidimensional Information (Phân tích nhanh thông tin đa chiều chia sẻ):

1.2.3.1 Nhanh (Fast)

Hệ thống phải đảm bảo mọi đáp ứng được đưa ra trong khoảng 5 giây, với thao tác phân tích đơn giản nhất mất không đến 1 giây và hầu như không có thao tác nào mất quá 20 giây Mặc dù người sử dụng có thể được khuyến cáo là một thao tác có thể diễn

ra lâu hơn nhưng như vậy thì họ sẽ bị lãng trí và ảnh hưởng đến chuỗi phân tích OLAP mong muốn cung cấp cho người sử dụng tốc độ phân tích bằng “tốc độ suy nghĩ” Điều này đòi hỏi thời gian đáp ứng các câu hỏi của quan hệ phải nhỏ Tốc độ này không dễ đạt được khi thao tác với một lượng dữ liệu lớn và đặc biệt là khi người

sử dụng được phép thực hiện các câu truy vấn tùy ý yêu cầu các tính toán tức thì

1.2.3.2 Hỗ trợ các phân tích (Analysis) và tính toán phức tạp

Nhiệm vụ thực sự của một ứng dụng OLAP là khả năng thực hiện các phân tích phức tạp của nó Các ứng dụng OLAP phải có khả năng thực hiện các phép phân tích kinh doanh logic và thống kê thuộc phạm vi ứng dụng và có liên quan đến người sử dụng Các yêu cầu phân tích là rất đa dạng, chúng phụ thuộc vào thị trường cụ thể của từng ứng dụng OLAP Nó có thể bao gồm phân tích theo trục thời gian, phân tích chi phí, thu nhập, phân tích cái gì/nếu (what/if), đạt tới mục tiêu (goal seeking) … Để đạt được hiệu quả cao thường đòi hỏi sử dụng các chương trình toán học có liên quan Phân tích doanh số tiêu thụ và quảng cáo của một công ty và các đối thủ cạnh tranh của nó đòi hỏi phải mô hình hóa các quan hệ phức tạp giữa các bên tham gia Thế giới thực là rất phức tạp do vậy khả năng mô hình hóa các quan hệ phức tạp là hết sức quan trọng trong các ứng dụng xử lý phân tích

Phần mềm OLAP phải cung cấp các công cụ tính toán mạnh nhưng ngắn gọn Để làm cho các nhà phát triển thuận tiện hơn và người sử dụng độc lập hơn thì cách sử dụng các công cụ tính toán đó phải dễ hiểu và phi thủ tục Nếu như phương thức để tạo ra các phép tính mong muốn không dễ hiểu thì sẽ mất thời gian xây dựng đồng thời việc

sử dụng cũng sẽ gặp khó khăn Nếu như phương thức tính toán là thủ tục thì các thay đổi đối với hệ thống không thể thực hiện kịp thời dẫn tới ta không thể sử dụng được các thông tin đúng lúc

Trong khi các hệ thống xử lý giao dịch được đánh giá dựa trên khả năng thu thập và quản lý dữ liệu thì các hệ thống phân tích được đánh giá trên khả năng tạo thông tin từ

dữ liệu, tức là khả năng phân tích

Hệ thống phải thực hiện mọi yêu cầu về an ninh và nếu các truy cập ghi dữ liệu đồng thời là cần thiết thì phải đảm bảo tính toàn vẹn dữ liệu Không phải mọi ứng dụng đều cần người sử dụng cập nhật dữ liệu, nhưng để đáp ứng nhu cầu ngày càng tăng này thì

hệ thống phải có khả năng điều khiển nhiều thao tác cập nhật kịp thời và an toàn Đây

là mặt yếu nhất của các sản phẩm OLAP dẫn tới sự hình dung là các ứng dụng OLAP thường chỉ cho phép đọc với sự điều khiển hết sức đơn giản

1.2.3.3 Quan sát và xử lý dữ liệu theo nhiều chiều (Multidimensional)

Đây chính là đặc điểm quan trọng nhất của các ứng dụng OLAP Các khung nhìn đa chiều biểu diễn bản chất của mô hình thực sự của doanh nghiệp Rất hiếm khi mô hình doanh nghiệp có ít hơn ba chiều Các nhà quản lý thường xem xét dữ liệu về tài chính theo tình huống, bộ phận, dòng sản phẩm, … và thời gian; xem xét dữ liệu doanh số bán ra theo sản phẩm, vùng tiêu thụ, kênh bán hàng và thời gian bán hàng

Chúng ta đều biết rằng phân tích hướng chiều là thế mạnh của OLAP Bất kỳ hệ thống OLAP nào mà không có phân tích đa chiều đều không hữu ích Vì vậy để có cái nhìn

rõ ràng về hệ thống OLAP đối với chiều phân tích chúng ta bắt đầu với mô hình dạng sao đơn giản Mô hình sao sẽ có 3 chiều sản phẩm, thời gian, kho lưu trữ; bảng sự kiện chứa thông tin kinh doanh [10]

PRODUCT

PK Product_key

Product_name Sub_category Category Product_line Department

TIME

PK Time_key

Date Month Quater Year

STORE

PK Store_key

Store_name Territory Region

Hình 1.8 Mô hình Fact-Dimension Đây là mô hình cơ bản xây dựng từ thuộc tính của các bảng chiều, lấy thuộc tính

“product_name” từ bảng Product, “month” từ bảng Time và “store_name” từ bảng Store làm khóa Chúng ra cùng xem khối lập phương thể hiện các giá trị của các thuộc tính theo các đường biên của khối lập phương như hình bên dưới 1.9 Xa hơn chúng ta hình dung việc kinh doanh cho mặt hàng áo khoác trong tháng một ở New York là giao của ba đường với giá trị Product = „Coats”, Month = “Jan”, Store =”New York”

Nếu biểu diễn dữ liệu theo ba chiều lên tập giấy thì cột có thể hiển thị Product, hàng sẽ hiển thị Month và mỗi trang là dữ liệu theo chiều thứ ba Mỗi một trang giấy là một mặt cắt, cắt khối lập phương dọc theo cột Store

Hình 1.9 Biểu diễn mô hình Fact-Dimension

Một khung nhìn dữ liệu đa chiều ngoài khả năng phân hoạch (“slice and dice” – thao tác chọn trong mô hình quan hệ) còn cung cấp nhiều khả năng khác; nó cung cấp cơ sở cho việc xử lý phân tích nhờ việc truy cập dữ liệu linh hoạt Thiết kế CSDL phải hỗ trợ cho các cấu trúc thứ bậc và đa thứ bậc, không nên giới hạn thao tác nào được thực hiện trên một chiều Người sử dụng phải có khả năng phân tích dữ liệu theo bất cứ chiều nào, ở bất kỳ mức độ tổng hợp nào với cùng tính năng và sự dễ dàng Phần mềm OLAP nên cung cấp các khung nhìn dữ liệu theo kiểu cách tự nhiên và dễ sử dụng, tránh cho người sử dụng phải biết về các thông tin được lấy từ các câu truy vấn phức tạp Hình dưới đây thể hiện mô hình phân cấp được hỗ trợ trong OLAP.[7]

Hình 1.10 Mô hình phân cấp Sau cùng, người sử dụng có lẽ không cần phải hiểu về sự bố trí các bảng, các phép kết nối tinh vi và các bảng dữ liệu tổng hợp Cho dù một yêu cầu của người sử dụng có phức tạp như thế nào thì hệ thống OLAP phải đảm bảo thời gian đáp ứng ổn định Người sử dụng không nên bị ảnh hưởng do sự phức tạp của các truy vấn của họ

1.2.3.4 Lượng thông tin hệ thống có thể xử lý

Thông tin là tất cả dữ liệu và thông tin được suy diễn từ dữ liệu bất kể nó được lưu trữ

ở đâu và có liên quan nhiều hay ít đến ứng dụng Chúng ta đang đánh giá khả năng của nhiều sản phẩm trên cơ sở khối lượng dữ liệu đầu vào mà chúng có thể xử lý, chứ không phải là khối lượng dữ liệu mà chúng có thể lưu trữ Khả năng của các sản phẩm rất khác nhau – các sản phẩm OLAP lớn có thể thao tác với khối lượng dữ liệu lớn gấp hàng nghìn lần so với các sản phẩm nhỏ nhất Để đánh giá còn phải xem xét nhiều khía cạnh như lư trữ nhân đôi dữ liệu, yêu cầu về bộ nhớ truy cập ngẫu nhiên (RAM), việc sử dụng không gian đĩa, hiệu năng hoạt động, khả năng tích hợp với các kho dữ liệu

Các tiêu chuẩn trên đây hoàn toàn không liên quan đến các kỹ thuật triển khai cụ thể một ứng dụng OLAP Các kỹ thuật sẽ được sử dụng để đạt được các mục tiêu trên bao gồm rất nhiều như: Kiến trúc Client/Server, tiếp cận hướng đối tượng, tổ chức lưu trữ tối ưu, xử lý đa luồng … Các kỹ thuật này không phải là đối tượng được quan tâm trong FASMI Tóm lại ta có thể nói FASMI là một tiêu chuẩn hướng đến người sử dụng do đó dễ hiểu và thuận lợi trong việc đánh giá tổng quát một sản phẩm OLAP

Những lợi ích của các sản phẩm OLAP:

Các chương trình OLAP thành công sẽ làm tăng hiệu suất làm việc của các nhà quản

lý kinh doanh, những người phát triển và của cả doanh nghiệp Với sự linh hoạt vốn có của hệ thống OLAP người sử dụng chương trình OLAP trở nên độc lập hơn trong công việc Các nhà quản lý không còn phụ thuộc vào đội ngũ làm tin học để thực hiện các thay đổi về mô hình, tạo các phép kết nối … Quan trọng hơn, OLAP cho phép các nhà quản lý có thể mô hình hóa vấn đề đáng lẽ ra không thể giải quyết được khi sử dụng các hệ thống kém linh động hơn có thời gian đáp ứng chậm và không ổn định Kiểm soát và truy nhập được càng nhiều thông tin mang tính chiến lược đồng nghĩa với việc

hỗ trợ quyết định hiệu quả hơn

Các nhà phát triển tin học cũng được lợi khi sử dụng các phần mềm OLAP Mặc dù ta

có thể xây dựng một hệ thống OLAP sử dụng phần mềm thiết kế cho hệ thống xử lý giao dịch và thu thập dữ liệu nhưng điều đó chắc chắn không phải là sự sử dụng có hiệu quả thời gian phát triển Bằng việc sử dụng các phần mềm thiết kế chuyên dụng cho OLAP Các nhà phát triển có thể xây dựng các ứng dụng cho người sử dụng nhanh hơn, do vậy cung cấp dịch vụ tốt hơn Đưa các ứng dụng vào hoạt động càng nhanh bao nhiêu thì cũng giảm sự ách tắc trong công việc bấy nhiêu

OLAP tạo sự thuận lợi trong công việc vì nó cho phép người sử dụng có thể tạo ra các

mô hình riêng của họ khác dễ dàng Tuy nhiên, khác với cá chương trình đơn lẻ chạy trên máy PC, các ứng dụng OLAP phụ thuộc vào kho dữ liệu và các hệ thống xử lý giao dịch để cập nhật dữ liệu nguồn của chúng Do vậy người sử dụng có thể thực hiện các công việc của mình mà không làm mất tính thống nhất của dữ liệu

Cuối cùng bằng việc cung cấp khả năng cho phép mô hình hóa các vấn đề thực tế và

sử dụng nhân lực hiệu quả hơn OLAP cho phép toàn bộ doanh nghiệp đáp ứng nhanh hơn các yêu cầu của thị trường Điều này thường đem lại nhiều thu nhập và lợi ích cho doanh nghiệp

1.2.4 Tổ chức và xử lý dữ liệu của hệ thống OLAP

Hầu hết dữ liệu trong các ứng dụng OLAP bắt nguồn từ các hệ thống khác Tuy nhiên trong một số ứng dụng (chẳng hạn như lập kế hoạch và dự thảo ngân sách) dữ liệu có thể được thu thập bởi chính ứng dụng OLAP đó Khi dữ liệu được lấy từ các ứng dụng khác ta cần phải sao chép lại và lưu trữ dữ liệu đó ở một nơi riêng tách khỏi nguồn dữ liệu gốc để sử dụng cho ứng dụng OLAP Đó có thể là một kho dữ liệu hoặc phổ biến hơn là một data mart ( kho dữ liệu hướng vào một chủ đề nhất định) Việc cần thiết phải lưu trữ tách riêng xuất phát từ các vấn đề sau:

Sự thể hiện: Các ứng dụng OLAP thường rất lớn nhưng thường được sử dụng để thực

hiện các phép phân tích có giao tiếp với người sử dụng Độ phức tạp của các phép phân tích này không thể dự đoán trước được Do đó OLAP luôn yêu cầu truy nhập dữ liệu rất nhanh, vì vậy dữ liệu cần được lưu trữ trong một cấu trúc tối ưu riêng biệt để

có thể truy nhập mà không làm ảnh hưởng đến hoạt động của các hệ thống giao dịch

Nhiều nguồn dữ liệu: Các hệ thống OLAP thường nhận dữ liệu từ nhiều nguồn khác

nhau, có thể là các nguồn bên ngoài và từ các chương trình chạy trên PC Quá trình hợp nhất các nguồn dữ liệu có thẻ rất phức tạp bởi vì các hệ thống cung cấp đó có thể khác nhau về hoạt động cũng như nghiệp vụ Ví dụ như trong ngân hàng, nguồn dữ liệu không chỉ lấy từ riêng hệ thống Core banking mà còn lấy từ các hệ thống thẻ (card), trái phiếu (Treasury), hệ thống xếp hạng tín dụng …

Làm sạch dữ liệu: Dữ liệu thô lấy từ các hệ thống giao dịch luôn chứa đựng nhiều lỗi

cần phải làm sạch trước khi sẵn sàng để phân tích Trong các lỗi này ngoài một phần nhỏ các lỗi do vô tình còn tồn tại các lỗi do sự cố ý hoặc thiếu trách nhiệm của người nhập dữ liệu

Chỉnh sửa dữ liệu: Có rất nhiều lý do tại sao cần chỉnh sửa dữ liệu trước khi nó được

sử dụng để phân tích Để việc chỉnh sửa được thực hiện mà không ảnh hưởng đến các

hệ thống giao dịch thì dữ liệu của hệ thống OLAP cần được tách riêng Các lý do đó phải chỉnh sửa dữ liệu có thể là:

- Các công ty con ở nước ngoài có thể hoạt động trong quy định kế toán khác, do vậy dữ liệu phải được sửa đổi cho phù hợp trước khi có thể sử dụng

- Cơ cấu quản lý, hoạt động, luật pháp của các công ty có thể khác nhau

Tính đồng bộ của dữ liệu: Nếu dữ liệu trong chương trình OLAP được lấy từ các

nguồn khác nhau thì rất có thể chúng được cập nhật theo các chu kỳ khác nhau Để đảm bảo việc phân tích được thực hiện dựa trên dữ liệu thống nhất thì dữ liệu cần phải được lưu trữ trong một kho dữ liệu hoặc trực tiếp trong cơ sở dữ liệu OLAP

Tính lịch sử: Đa số các ứng dụng OLAP bao gồm thời gian như là một chiều, và nhiều

kết quả hữu ích được rút ra từ các phân tích theo trục thời gian Để có được điều này ta cần phải lưu trữ dữ liệu của nhiều năm trực tuyến, các hệ thống giao dịch cung cấp dữ liệu cho ứng dụng OLAP chắc chắn không làm việc này

Dữ liệu tổng hợp: Dữ liệu tác nghiệp chắc chắn là rất chi tiết Tuy nhiên các thao tác

hỗ trợ quyết định yêu cầu quan sát dữ liệu ở mức tổng hợp cao hơn Nếu quan tâm đến hiệu quả của hệ thống thì ta cần phải lưu trữ dữ liệu ở mức độ tổng hợp Điều này khó

Cập nhật dữ liệu: Nếu như chương trình cho phép người sử dụng thay đổi hoặc nhập

dữ liệu thì rõ ràng là chương trình phải có CSDL riêng để tránh việc ghi đè lên dữ liệu tác nghiệp chính thức của hệ thống giao dịch

Để có thể lưu trữ dữ liệu hoạt động của hệ thống OLAP một cách hiệu quả ta có ba lựa chọn chủ yếu Ta sẽ tìm hiểu cụ thể hơn trong mục [1.2.5] các mô hình OLAP bên dưới

- ROLAP: Relation Online Analytical Processing

- MOLAP: Multidimensional Online Analytical Processing

- HOLAP: Hybrid Online Analytical Processing

- DOLAP: Desktop Online Analytical Processing

1.2.5.1 Mô hình ROLAP

Đây là một lựa chọn khá hiển nhiên, đặc biệt là nếu dữ liệu được lấy từ một hệ quản trị CSDL quan hệ Điều này có thể là do bản thân kho dữ liệu được triển khai sử dụng hệ quản trị CSDL quan hệ hoặc bản thân các hệ thống thao tác lưu trữ dữ liệu của nó trong CSDL quan hệ Trong hầu hết các trường hợp, dữ liệu sẽ được tổ chức theo một cấu trúc phi chuẩn như sơ đồ sao (star schema) hoặc một trong các biến thể của nó như

sơ đồ bông tuyết ( snowflake schema) CSDL chuẩn hóa không thích hợp cho việc phân tích do nhiều nguyên nhân dữ liệu tổng hợp được lưu trữ trong bảng tổng hợp riêng

Trong mô hình ROLAP, dữ liệu được lưu theo kiểu hàng và cột Mô hình này thể hiện

dữ liệu cho người dùng ở dạng chiều nghiệp vụ Để ẩn đi cấu trúc lưu trữ với người dùng và thể hiện dữ liệu nhiều chiều, tầng ngữ nghĩa gọi là tầng metadata sẽ được tạo Tầng metadata hỗ trợ việc ánh xạ các chiều tới các bảng quan hệ, đồng thời hỗ trợ việc tổng hợp dữ liệu Metadata có thể được lưu trữ trong cơ sở dữ liệu quan hệ

Hình 1.11 Mô hình ROLAP Hình vẽ trên thể hiện kiến trúc trong mô hình ROLAP, đây là kiến trúc 3 tầng Máy chủ phân tích ở tầng Application, nó sẽ tạo ra các View đa chiều Hệ thống đa chiều tại tầng Presentation cung cấp View đa chiều cho người dùng Khi người dùng cần truy vấn phức tạp dựa trên các View này, câu truy vấn sẽ chuyển thành các lệnh SQL trong

cơ sở dữ liệu quan hệ Không giống như mô hình MOLAP, cấu trúc đa chiều tĩnh không được tạo ra và lưu trữ

Mô hình OLAP quan hệ (ROLAP) lưu trữ dữ liệu cơ sở và thông tin tổng hợp trong

Hình 1.12: Mô hình dữ liệu ROLAP

Dữ liệu được tìm thấy tại điểm giao của 1 cột và 1 hàng

Có 2 kiểu mô hình dữ liệu:

Lược đồ hình sao (Star): Một chiều chỉ được xây dựng từ một bảng chiều

Hình 1.13 Lược đồ hình sao Lược đồ hình bông tuyết (Snowflake): Một chiều được xây dựng từ nhiều bảng chiều

Hình 1.14 Lược đồ bông tuyết

ROLAP thích hợp cho các truy vấn dữ liệu theo thời gian thực ( xảy ra thường xuyên

và đòi hỏi độ chính xác tức thời)

Ví dụ: Xem thông tin chứng khoán; Các báo cáo phân tích hàng ngày, báo cáo so sánh đối chiều dư nợ ngân hàng …

Hình 1.15 Mô hình MOLAP

Dữ liệu đa chiều được tính toán trước và lưu vào trong cơ sở dữ liệu đa chiều Cơ chế của MOLAP trong tầng Application sẽ đẩy View của dữ liệu đa chiều từ MDDB tới người sử dụng

Hệ thống quản lý dữ liệu đa chiều là một hệ thống phần mềm riêng Những hệ thống này cung cấp khả năng hợp nhất dữ liệu và tạo ra các dữ liệu tổng hợp đưa vào MDDB

từ DW trong suốt quá trình xử lý Vì vậy nó đáp ứng được một cách nhanh chóng cho người sử dụng khi yêu cầu dữ liệu có tính chất tổng hợp

Mô hình MOLAP lưu trữ dữ liệu cơ sở (là dữ liệu từ các bảng của kho dữ liệu) 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 khối

Dữ liệu được tìm thấy tại điểm giao của các chiều

Dữ liệu trong MOLAP cần phải được xử lý sau một thời gian nhất định để cập nhật lại những dữ liệu mới trong DW

MOLAP thích hợp cho các truy vấn tổng hợp dữ liệu theo thời gian dài

Ví dụ: Tổng hợp doanh thu của từng chi nhánh trong vòng 2 năm trở lại

1.2.5.3 Mô hình DOLAP

Ngoài ra còn có mô hình DOLAP: Lưu trữ dữ liệu trong các tệp trên máy trạm Trong

mô hình này, một phần nhỏ dữ liệu được lưu trữ trên các máy trạm Chúng có thể được phân bố từ các máy trạm từ trước hoặc được tạo ra theo yêu cầu từ các máy trạm ( có thể thông quan Internet) Giống như trường hợp trên, dữ liệu hoạt động có thể được lưu trữ trên đĩa cứng hoặc trong RAM Lưu trữ các tệp cho phép người sử dụng có thể làm việc gián tiếp không cần phải kết nối trực tiếp với máy phục vụ OLAP

1.2.5.4 HOLAP (Hybrid OLAP)

Là mô hình OLAP lai ( HOLAP) là sự kết hợp giữa MOLAP và ROLAP