Hiện nay trên thị trường có nhiều công cụ OLAP do các nhà phát triển khác nhau phát hành. Theo hiệp hội OLAP www.olap.org 1995, E.F. Codd đưa ra 12 tiêu chuẩn để đánh giá các công cụ OLAP:
1. Khung nhìn khái niệm đa chiều: mô hình đa chiều tương ứng với các vấn đề kinh doanh Geography Product Item Type Category All City State Country All Time Month Year Day Week All Quarter 200 100 30 time city product LA NY Jan Feb Mar Apr 1 3 2 50 100 time product city 1 2 Jan Feb Mar Apr LA NY 3
2. Trong suốt: hệ quản trị CSDL, sự hỗn tạp của dữ liệu nguồn, và kiến trúc trong suốt tới người dùng
3. Có thể truy cập: chỉ có dữ liệu được yêu cầu cho phân tích được truy cập Thiết lập báo cáo phù hợp: việc tăng dung lượng CSDL hoặc chiều không làm giảm hiệu suất
4. Kiến trúc khách chủ: Hệ thống OLAP phải tuân theo các nguyên tắc cơ bản để có sự linh động, điều hành liên kết
5. Chiều chung: các chiều dữ liệu phải tương đương về cấu trúc và các khả năng xử lí 6. Điều khiển ma trận rời rạc
7. Hỗ trợ nhiều người dùng
8. Các toán tử qua các chiều không bị giới hạn: nhận dạng các phân cấp của chiều và tiến hành tính toán trong các chiều giao nhau.
9. Thao tác dữ liệu trực quan
10. Lập báo cáo linh động, tương tác được với người dùng 11. Không giới hạn số chiều và mức độ tổng hợp
Tổng hợp
• Các hướng lưu trữ:
ROLAP: (Relational Online Analytical Processing) Xử lý phân tích trực tuyến quan hệ
MOLAP: (Multi dimensional Online Analytical Processing) Xử lý phân tích trực tuyến đa chiều
HOLAP: (Hybric Online Analytical Processing) Xử lý phân tích trực tuyến kết hợp
DOLAP: (Database Online Analytical Processing) Xử lý phân tích trực tuyến CSDL
4 Các mô hình lƣu trữ hỗ trợ OLAP
Dịch vụ OLAP hỗ trợ nhiều mô hình lưu trữ dữ liệu khác nhau, mỗi mô hình có các ưu và khuyết điểm riêng, chúng được sử dụng tuỳ theo mục đích khai thác. Việc lựa chọn mô hình nào là sự thỏa hiệp giữa hai yếu tố: kích thước lưu trữ và tốc độ đáp ứng truy vấn.
4.1 Mô hình Multidimensional OLAP (MOLAP)
Mô hình OLAP đa chiều (MOLAP) lưu trữ dữ liệu cơ sở (là dữ liệu từ các bảng của kho dữ liệu hoặc trung tâm dữ liệu chủ đề) và thông tin tổng hợp (là các độ đo được tính toán từ các bảng) trong các cấu trúc đa chiều gọi là các khối (cube). Các cấu trúc này được lưu bên ngoài cơ sở dữ liệu data mart hoặc kho dữ liệu.
Mô hình dữ liệu MOLAP
Lưu trữ các khối (cube) trong cấu trúc MOLAP là tốt nhất cho các truy vấn tổng hợp dữ liệu thường xuyên mà cần thời gian hồi đáp nhanh. Ví dụ, tổng sản phẩm bán được của tất cả các vùng theo quý.
Mô hình MOLAP cho phép thực hiện các truy vấn phân tích dữ liệu tốt nhất vì các đặc điểm sau:
- Thông tin tổng hợp và dữ liệu cơ sở được lưu trữ trong cấu trúc đa chiều.
- Các thao tác kết (join), là một trong những thao tác tốn chi phí nhất của mô hình quan hệ, thì không cần thiết.
- MOLAP sử dụng các thuật toán nén dữ liệu cho phép lưu trữ với ít không gian hơn. - MOLAP sử dụng chỉ mục bitmap cho hiệu quả thực thi tốt hơn.
- MOLAP lấy dữ liệu trong khối (cube) rất nhanh bằng cách sử dụng các xử lý truy vấn tốc độ cao và cache dữ liệu (data cache). Thông tin nhận được từ khối (cube) và các bảng OLAP cơ sở chỉ được truy xuất thông tin chi tiết.
- MOLAP không xử dụng cơ chế khoá vì dữ liệu là chỉ đọc. - MOLAP có thể được nạp trước vào bộ nhớ cache.
4.1.1 Mô hình Relational OLAP (ROLAP)
Mô hình OLAP quan hệ (ROLAP) lưu trữ dữ liệu cơ sở và thông tin tổng hợp trong các bảng quan hệ. Các bảng này được lưu trữ trong cùng cơ sở dữ liệu như là các bảng của data mart hoặc kho dữ liệu.
Mô hình dữ liệu ROLAP
Lưu trữ các khối trong cấu trúc ROLAP là tốt nhất cho các truy vấn dữ liệu không thường xuyên. Ví dụ như nếu 80% người dùng truy vấn chỉ dữ liệu trong vòng một năm trở lại đây, các dữ liệu cũ hơn một năm sẽ được đưa vào một cấu trúc ROLAP để giảm không gian đĩa bị chiếm dụng, hơn nữa còn để loại trừ dữ liệu trùng lắp. Lưu trữ dữ liệu trong cấu trúc ROLAP cung cấp các lợi ích sau:
- ROLAP cho phép Cube Builder tự động tạo chỉ mục.
- ROLAP ánh xạ các tổng hợp có sẵn từ data mart hoặc kho dữ liệu. OLAP Manager được phép xử dụng các tổng hợp có sẵn để tổng hợp mà không cần tính toán lại cho mỗi truy vấn.
- ROLAP tạo đòn bẩy cho hệ quản trị cơ sở dữ liệu quan hệ nhằm cho các nhà quản trị hệ thống duy trì nó hiệu quả hơn.
- ROLAP hỗ trợ Microsoft SQL Server, Oracle, Access và Open Database Connectivity (ODBC).
4.1.2 Mô hình Hybird OLAP (HOLAP)
Mô hình OLAP lai (HOLAP) là sự kết hợp giữa MOLAP và ROLAP.
Mô hình dữ liệu HOLAP
Lưu trữ các khối (cube) trong cấu trúc HOLAP là tốt nhất cho các truy vấn tổng hợp dữ liệu thường xuyên dựa trên một lượng lớn dữ liệu cơ sở. Ví dụ, chúng ta sẽ lưu trữ dữ liệu bán
hàng theo hàng quý, hàng năm trong cấu trong MOLAP và dữ liệu hàng tháng, hàng tuần và hàng ngày trong cấu trúc ROLAP.
Lợi ích của việc lưu trữ trong cấu trúc HOLAP là:
- Lấy dữ liệu trong khối (cube) nhanh hơn bằng cách sử dụng xử lý truy vấn tốc độ cao của MOLAP.
- Tiêu thụ ít không gian lưu trữ hơn MOLAP. - Tránh trùng lắp dữ liệu.
4.1.3 So sách các mô hình
Bảng sau so sánh tổng hợp ba mô hình lưu trữ hỗ trợ OLAP:
MOLAP ROLAP HOLAP
Lưu trữ dữ liệu cơ sở Khối Bảng quan hệ Bảng quan hệ
Lưu trữ thông tin tổng hợp Khối Bảng quan hệ Khối Hiệu suất thực hiện truy vấn Nhanh nhất Chậm nhất Nhanh
Tiêu thụ không gian lưu trữ Nhiều Thấp Trung bình
Chi phí bảo trì Cao Thấp Trung bình
5 Mô hình kiến trúc dịch vụ OLAP
Kiến trúc dịch vụ OLAP gồm 2 thành phần: Server và Client. Phần server (được đại diện bởi OLAP server) và phần client (là dịch vụ PivotTable).
Cả dịch vụ OLAP và dịch vụ PivotTable đều cho phép thiết kế, tạo mới và quản lý các khối (cube) từ kho dữ liệu (data warehouse) và cho phép các client truy xuất đến dữ liệu OLAP. Có thể hiểu rằng OLAP server quản lý dữ liệu còn dịch vụ PivotTable làm việc với server để cho client truy xuất dữ liệu.
5.1.1 Kiến trúc thành phần Server:
Dịch vụ OLAP của SQL Server cung cấp thành phần Server có khả năng tạo và quản lý dữ liệu OLAP đa chiều, đồng thời cung cấp dữ liệu cho client qua dịch vụ PivotTable (PivotTable Service).
Các thao tác (operation) của thành phần Server bao gồm việc tạo các khối dữ liệu đa chiều từ kho cơ sở dữ liệu quan hệ và lưu trữ chúng trong các cấu trúc khối đa chiều (MOLAP), trong cơ sở dữ liệu quan hệ (ROLAP) hoặc kết hợp cả hai (HOLAP). Siêu dữ liệu (metadata) của các cấu trúc khối đa chiều được lưu trữ trong một kho (repository) trong cơ sở dữ liệu quan hệ.
5.1.2 Kiến trúc thành phần Client
Kiến trúc thành phần Client
Thành phần client là dịch vụ PivotTable giao tiếp với OLAP server và cung cấp giao diện cho các ứng dụng client sử dụng truy cập dữ liệu OLAP trên server. Các ứng dụng client kết nối đến dịch vụ PivotTable bằng cách sử dụng giao diện OLE DB hoặc mô hình ADO (Microsoft ActiveX Data Objects).
Các ứng dụng client có thể sử dụng dịch vụ PivotTable để lấy dữ liệu từ cơ sở dữ liệu OLAP. Dịch vụ PivotTable có thể tạo các khối cục bộ mà đó là các tập con của các khối cư trú trên server. Các khối cục bộ có thể được sử dụng để làm tăng hiệu quả thực hiện và sử dụng để thực hiện các phân tích không trực tuyến (off-line).
Dịch vụ PivotTable là một công cụ lưu trữ, duyệt và phân tích khối (cube). PivotTable là một OLAP Server xử lý tại chỗ với cả các đặc tính phân tích trực tuyến (on-line) và không trực tuyến (off-line) mà:
- Cung cấp truy cập trực tuyến đến dữ liệu OLAP như một client của dịch vụ OLAP. - Bao gồm các đặc tính phân tích dữ liệu, xây dựng khối và quản lý cache.
Cho phép các khối (cube) lưu trữ cục bộ để phân tích không trực tuyến (off-line) như là kết nối đến dữ liệu dịch vụ OLAP trực tuyến.
6 Kỹ thuật để xử lý truy vấn hiệu quả trên OLAP
Tính hiệu quả xử lý truy vấn của một hệ thống OLAP thể hiện ở 2 điểm: - Thời gian đáp ứng
- Không gian nhớ cần thiết để thực hiện
Các truy vấn thống kê trên OLAP là các truy vấn mang tính tổng hợp (tổng, trung bình, ..). Ví dụ:
“Tìm tổng doanh số bán hàng của mỗi nhóm hàng trên các kho nằm ở Châu Âu”
Câu truy vấn thực hiện là:
SELECT PRODUCT.category, SUM(SALES.amount) FROM SALES, PRODUCT,LOCATION
WHERE SALES.product_key = PRODUCT.product_key AND SALES.location_key = LOCATION.location_key AND LOCATION.region=“Europe”
GROUP BY PRODUCT.category
Các câu truy vấn kiểu này thường thực hiện các phép join giữa bảng sự kiện và bảng chiều. Hệ thống xử lý truy vấn trên dữ liệu lớn đòi hỏi các kỹ thuật hỗ trợ thực hiện để đáp ứng về mặt tốc độ cho người sử dụng. Các kỹ thuật thường dùng bao gồm
- Bitmap – index: Lợi dụng tính chất : Số lượng không đáng kể các giá trị chiều so với số các bản ghi của bảng sự kiện
- Tính toán trước truy vấn trên lưới khối
6.1 Bitmap Index
Hình vẽ 1. Bitmap index
Bitmap Index (Index theo kiểu ánh xạ bits) là một kiểu index hay được sử dụng trong một số trường hợp sau:
Khi table có nhiều rows và các cột khoá có giá trị khác nhau rất ít. Điều đó có nghĩa là có rất ít sự khác nhau trong giá trị của các cột. Ví dụ Bitmap Index thích hợp hơn đối với các cột giới tính (Nam hay Nữ).
Khi truy vấn có kết hợp sử dụng nhiều mệnh đề trong phần điều kiện WHERE. Mệnh đề truy vấn sử dụng các phép toán logic OR.
Khi các cột khoá là read-only (chỉ đọc) hay có rât ít hoạt động cập nhật các cột khoá.
Cấu trúc của Bitmap Index
Một Bitmap index cũng được tổ chức như là B-TREE index, nhưng phần lá của mỗi node lưu một dãy các bit cho mỗi khoá thay vì danh sách các ROWID. Mỗi bit trong danh sách Bitmap đó tương ứng với một ROWID, và nếu giá trị bit đó được khởi tạo, điều đó có nghĩa là hàng có ROWID tương ứng sẽ chứa giá trị khoá.
Sử dụng Bitmap index
Bitmap-TREE index sử dụng để thiết lập phần lá của các node, phần này sẽ chứa đoạn bitmap được sử dụng để xác định hàng chứa giá trị khoá.
Khi có thay đổi trên các cột khoá trong table, các chuỗi bitmap cần được thay đổi theo. Kết quả là sẽ sinh ra các khoá trên các bitmap segment liên quan do quá trình phân đoạn các khoá này đòi hỏi thực hiện trên toàn bộ bitmap segment. Một row quản lý bởi bitmap sẽ không thể cập nhật bởi các transaction khác đến khi transaction đầu kết thúc.
Với chiều sản phẩm có 3 giá trị là TV, PC, Phone ta có Bitmap – index là
rid mục hàng thành phố Tháng TV Doanh số 1001 LA Jan 100 PC 1002 LA Jan 200 PC 1003 NY Jan 150 PC 1004 NY Feb 100 Phone 1005 NY Jan 175 TV 1006 NY Feb 200 Phone 1007 LA Jan 300 Phone 1008 LA Feb 120
6.2 Sử dụng kỹ thuật tính toán trƣớc khối dữ liệu [4]
6.2.1 Điểm khởi đầu
Kỹ thuật này sử dụng sơ đồ lưới khối của dữ liệu. Như chúng ta đã biết các phép toán thống kê sẽ được yêu cầu dựa trên một tập các chiều. Có thể là điều kiện trên một chiều, có thể điều kiện với 2 hay 3 chiều,…
Ví dụ: một khối 3 chiều là cha của 3 khối 2 chiều, mỗi khối được tạo thành từ 2 chiều khác nhau của khối cha. Rõ ràng là chúng ta không cần thiết phải tính toán một cách độc lập trên 4 view.
Kỹ thuật này thực chất là tính toán trước các truy vấn cơ sở thường được yêu cầu bởi người sử dụng. Từ kết quả của các truy vấn tính trước này có thể làm cơ sở thu được kết quả các truy vấn khác. Dựa trên lưới các khối để chọn lựa vác view được tính trước.
Ví dụ: Mô hình nhà kho dữ liệu của hệ thống cửa hàng trong đó các nhà cung cấp (supplier – s) bán các sản phẩm (Part –p) cho khách hàng (Customer –c). Cơ sở dữ liệu có chứa thông tin về mỗi giao tác bán hàng trong vòng 6 năm. Có 3 chiều đáng quan tâm : chiều p- Part , chiều s- Supplier và chiều c – Customer và độ đo đáng quan tâm là tổng doanh thu. Vì thế đối với mỗi cell (p,s,c) trong data cube 3-D sẽ lưu trữ doanh thu của sản phẩm p do nhà cung cấp s bán cho khách hàng c.
Người dùng cần quan tâm đến tổng doanh thu từng bộ phận p bán các sản phẩm cho 1 khách hàng c đối với tất cả các nhà cung cấp bằng cách thêm vào 1 giá trị “ALL” vào chiều nhà cung cấp từ đó để trả lời cho câu truy vấn đó ta chỉ cần nhìn vào cell (p,ALL,c). Tương tự thêm các giá trị “ALL” cho các chiều khác.
Chúng ta có thể chọn lựa một trong các cách cài đặt sau:
- Cách 1: Cài đặt vật lý toàn thể data cube. Hướng này cho thời gian hồi đáp câu truy vấn tốt nhất. Tuy nhiên, việc tính toán trước và lưu trữ mỗi cell không là một sự chọn lựa khả thi đối với các data cube lớn. Khi đó vùng không gian lưu trữ tiêu tốn quá mức. Chú ý rằng vùng không gian lưu trữ bởi data cube cũng là một tiêu chí để đánh
1 0 0 0 0 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 1 0 1 1 PC Phone TV
giá về thời gian tạo data cube đó. Vùng không gian tiêu thụ cũng ảnh hưởng đến việc tạo chỉ mục và vì thế gia tăng thêm tổng chi phí.
- Cách 2: Không tính trước một query nào. Trong trường hợp này, chúng ta cần phải truy xuất dữ liệu thô để tính toán mỗi cell khi có yêu cầu. Hướng tiếp cận này gây ra vấn đề về thời gian chờ để truy vấn đến hệ thống. Hướng này không thêm vùng vùng không gian ngoại trừ vùng vùng không gian dành cho dữ liệu thô được yêu cầu.
- Cách 3: Tính trước chỉ một phần data cube. Đây là hướng tiếp cận nên được chọn lựa. Trong data cube, có nhiều cell mà giá trị của nó có thể tính từ các cell khác trong data cube đó. Sự phụ thuộc này tương tự với bảng tính trong excel, trong đó giá trị của các cell có thể được biểu diễn như là một hàm của các giá trị của các cell khác. Chúng ta gọi các cell đó là các cell phụ thuộc.
Ví dụ: Chúng ta có thể tính giá trị cho cell (p,ALL,c) như là tổng các giá trị của các cell (p,s1,c), (p,s2,c),… , (p,sn,c) trong đó n là số các nhà cung cấp. Càng nhiều cell được tính trước thì việc thi hành query càng tốt. Tuy nhiên, đối với data cube lớn thì chúng ta chỉ có thể tính trước chỉ một phần nhỏ của các cell của data cube đó mà thôi. Vì vùng không gian lưu trữ có giới hạn và các ràng buộc khác.
Một view (hay query) trên Khối dữ liệu là một câu lệnh SQL trong đó mệnh Group by thực hiện trên 1 tập xác định thuộc tính. Có thể đại diện cho một truy vấn S bằng tập (D1, D2, .., Di) với Di là thuộc tính có trong Khối dữ liệu.
Từ ví dụ trên ta có lưới các view như sau:
Trong đó mỗi node trên lưới là 1 view, đường nối biểu thị quan hệ phụ thuộc truy vấn. Số hàng trong kết quả truy vấn (tính theo triệu) được ghi chú ở bên. Truy vấn (p,c) có thể được suy ra từ truy vấn (p,s,c), hay truy vấn p có thể suy ra từ truy vấn (p,s). Chi phí mỗi truy vấn được xác định bằng số bản ghi kết quả.
psc 6M
pc 6M ps 0.8M sc 6M
p 0.2M s 0.01M c 0.1M