Khung nhìn này là tập hợp của các khung nhìn 2D ở trên theo vị trí là các thành phố bán hàng trong bảng Thành phố. Để mô tả giống với khái niệm mơ hình dữ liệu đa
Hình 13: Hộp lập phương cho lược đồ dữ liệu 3 chiều
Giả xử tiếp chúng ta muốn xem xét dữ liệu bán hàng theo một chiều thứ 4 nữa ví dụ như chiều Nhà cung cấp. Việc biểu diễn mơ hình dữ liệu với 4 chiều như vậy là khó khăn nhưng ta có thể xem xét chúng như là tập hợp các mơ hình dữ liệu 3 chiều như ở bên dưới.
Hình 14: Hộp lập phương cho lược đồ dữ liệu 4 chiều
Theo cách mơ tả này, chúng ta có thể biểu diễn bất cứ một mơ hình dữ liệu n chiều như là một tập hợp các mơ hình dữ liệu (n-1) chiều.
Trong mơ hình dữ liệu đa chiều, mỗi một chiều thường được mô tả như là một đường xương trong hình hộp đa chiều. Nếu có nhiều chiều đưa ra, chúng ta có thể biểu diễn mỗi một chiều như là một đường xương và kết quả là tạo ra một mạng từ các đường xương đó. Mỗi chiều sẽ hiển thị dữ liệu theo theo các cấp độ tổng hợp dữ liệu khác nhau theo hàm nhóm. Hình vẽ bên dưới chỉ ra một mạng các đường xương hình thành lên mơ hình dữ liệu đa chiều với các chiều Thời gian, Sản phẩm, Thành phố, và Nhà cung cấp.
Hình 15: Mạng mơ tả dữ liệu đa chiều
Trong mơ hình mạng trên, mức độ tổng hợp dữ liệu thấp nhất được gọi là mức cơ bản (base cuboid) chính là mức xương mạng 4D với 4 chiều được đưa ra là Thời gian, Sản
phẩm, Thành phố, và Nhà cung cấp. Mức độ thấp hơn là mức xương mạng 3D với 3 chiều được đưa ra là Thời gian, Sản phẩm và Thành phố được tổng hợp cho tất cả các nhà cung cấp trong bảng Nhà cung cấp. Mức tổng hợp cao nhất là mức 0D với với dữ liệu tổng hợp cho tổng doanh số bán hàng của tất cả các chiều. Mức này thường được gọi là mức đỉnh (apex cuboid).
2.3.1. Lược đồ dữ liệu trong data warehouse
Trong thiết kế các cơ sở dữ liệu quan hệ, mơ hình dữ liệu quan hệ thực thể thường được sử dụng. Mơ hình này bao gồm một tập hợp các thực thể và các mối quan hệ giữa các thực thể đó. Mơ hình dữ liệu quan hệ thực thể thường thích hợp cho các giao dịch xử lý trực tuyến.
Trong môi trường data warehouse, yêu cầu căn bản là một lược đồ tạo ra phải đảm bảo các tính năng ngắn gọn, hướng chủ đề và thân thiện, phù hợp với phân tích dữ liệu trực tuyến.
Mơ hình dữ liệu phổ biến nhất cho mơi trường data warehouse chính là mơ hình dữ liệu đa chiều. Mơ hình này thường tồn tại dưới dạng lược đồ hình sao (star schema) hay lược đồ hình bơng tuyết (snowflake schema) hay lược đồ chòm sao (fact constellation schema).
thừa dữ liệu nằm ở trung tâm của mơ hình (bảng sự kiện) và tập hợp các bảng bao xung quanh (bảng chiều). Về mặt hình học, lược đồ này giống với hình các ngơi sao với các bảng chiều xuất hiện quay xung quanh bảng sự kiện trung tâm.
Mơ hình star giúp tối ưu hiệu quả của data warehouse nhờ câu lệnh truy vấn đơn giản và thời gian trả lời truy vấn nhanh.
Ví dụ là lược đồ mô tả bán hàng của công ty AllElectronics được chỉ ra như hình vẽ
bên dưới. Việc bán hàng được xem xét dưới 4 chiều được đặt tên như: time, item,
branch, và location. Lược đồ này có bảng sự kiện tên là sales nằm ở trung tâm. Bảng
sự kiện này có khố nối đến các bảng chiều cùng với 2 giá trị độ đo là dollars sold và
units sold. Để giảm thiểu kích cỡ của bảng sự kiện, các định danh khoá của bảng chiều
(time_key và item_key) thường là các số tuần tự được tạo ra bởi hệ thống.
Hình 16: Lược đồ hình sao
Chú ý rằng trong lược đồ hình sao, mỗi chiều chỉ được biểu diễn bởi một bảng và mỗi bảng chứa đựng một tập các thuộc tính. Ví dụ bảng chiều location chứa các thuộc tính như {flocation_key, street, city, province_or_state, country}. Ràng buộc này có thể tạo ra độ dư thừa dữ liệu. Ví dụ 2 thành phố là "Vancouver" và ”Victoria" thuộc tỉnh
Canadian, bang British Columbia của Canada. Hai thành phố này trong bảng chiều
location sẽ tạo ra độ dư thừa dữ liệu từ các thuộc tính province_or_state và country, cụ thể là, (..., Vancouver, British Columbia, Canada) và (..., Victoria, British Columbia,
Canada). Hơn nữa, độ dư thừa dữ liệu có thể nhiều hơn khi mà các bảng chiều có lưu
Lược đồ bông tuyết: Đây là biến thể của lược đồ hình sao khi mà một vài bảng chiều
được chuẩn hoá bằng cách tách dữ liệu thêm ra một vài bảng nữa để tránh độ dư thừa dữ liệu. Kết quả này hình thành nên một hình vẽ giống với hình bơng tuyết.
Sự khác nhau chính lược đồ hình sao và lược đồ hình bơng tuyết là bảng chiều của lược đồ hình bơng tuyết được lưu giữ ở dạng chuẩn hoá để giảm độ dư thừa dữ liệu. Các bảng chiều như vậy sẽ dễ dàng hơn trong việc bảo trì và giảm thiểu cho cấu trúc lưu trữ. Tuy nhiên việc tiết kiệm lưu trữ này là không đáng kể bởi dữ liệu lớn nhất trong môi trường data warehouse là ở bảng sự kiện. Hơn nữa, cấu trúc dữ liệu của lược đồ bông tuyết sẽ làm giảm hiệu năng của việc xem dữ liệu vì cần phải kết nối dữ liệu giữa các bảng khi thực hiện truy vấn. Vì vậy, hiệu năng của hệ thống sẽ bị ảnh hưởng. Do vậy, lược đồ bông tuyết mặc dù làm giảm độ dư thừa nhưng nó khơng được sử dụng phổ biến như lược đồ hình sao trong khi thiết kế data warehouse.
Ví dụ lược đồ bông tuyết mô tả việc bán hàng cho cơng ty AllElectronics được đưa ra như hình bên dưới. Bảng sự kiện sales giống hệt về vị trí và cấu trúc như trong lược đồ hình sao.
Hình 17: lược đồ bơng tuyết
Sự khác nhau chính giữa 2 lược đồ này là việc định nghĩa ra các bảng chiều. Bảng chiều item đứng độc lập trong lược đồ hình sao được chuẩn hố trong mơ hình bơng tuyết và kết quả tạo ra những bảng item mới và bảng supplier. Trong ví dụ này, chiều
item mới tạo ra chứng đựng các thuộc tính là item_key, item_name, brand, type, và
supplier_key với supplier_key là khố ngồi kết nối đến bảng chiều supplier là bảng
location trong lược đồ hình sao được chuẩn hố thành 2 bảng mới là location và city
với cột city_key là khố ngồi trong bảng location kết nối đến chiều city.
Lược đồ chịm sao (fact constellation): các ứng dụng phức tạp có thể có nhiều bảng sự
kiện và cùng chia sẻ các bảng chiều. Loại lược đồ này có thể xem như là tập hợp các lược đồ hình sao cho nên nó có tên là lược đồ chịm sao.
Ví dụ về lược đồ này được chỉ ra như hình vẽ bên dưới. Lược đồ này có 2 bảng sự kiện là sales và shipping. Bảng sales có định nghĩa giống hệt ở trong lược đồ hình sao.
Bảng shipping có 5 chiều với các khố tương ứng là: item_key, time_key, shipper_key,
from_location, and to_location, và 2 độ đo là: dollars_cost và units_shipped. Lược đồ
chòm sao này cho phép 2 bảng chiều là sales và shipping có thể chia sẻ các bảng chiều như trong mơ hình là time, item và location.
Hình 18: lược đồ chịm sao
Trong khi xây dựng data warehouse, cần phải chú ý phân biệt 2 khái niệm cơ bản là data warehouse và kho dữ liệu hướng chủ đề. Data warehouse là tập hợp các thông tin về các chủ để trong toàn bộ doanh nghiệp như là sản phẩm, khách hàng, phân phối bán hàng, nhân lực, con người. Nói chung là phạm vi của nó là là trải rộng cho tồn bộ doanh nghiệp. Khi xây dựng data warehouse, lược đồ chòm sao thường phổ biến được sử dụng vì nó có thể mơ hình hố được nhiều chủ đề. Kho dữ liệu hướng chủ đề thường phản ánh về một chủ đề nào đó của doanh nghiệp nên phạm vi của nó thường ở mức phịng ban. Việc xây dựng kho dữ liệu hướng chủ đề, các lược đồ hình sao hay lược đồ bơng tuyết thường được sử dụng vì cả 2 lược đồ này chỉ hướng đến một chủ đề đơn giản và lược đồ hình sao thường phổ biến và hiệu quả hơn.
2.3.2. Định nghĩa lược đồ
Data warehouse và kho dữ liệu hướng chủ đề có thể được định nghĩa bằng ngơn ngữ truy vấn khai phá dữ liệu (data mining query language) như mô tả bên dưới.
Định nghĩa lược đồ được miêu tả theo cú pháp sau:
define lược đồ (tên lược đồ) [<danh sách chiều>]: <danh sách độ đo>
Định nghĩa chiều được miêu tả theo cú pháp sau:
define dimension (tên chiều) as (<danh sách các thuộc tính>)
Bây giờ hãy xét ví dụ làm thế nào để định nghĩa lược đồ hình sao, lược đồ bơng tuyết và lược đồ chịm sao trong nội dung mơ tả ở phần trên.
Định nghĩa lược đồ hình sao:
define lược đồ 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)
Lệnh define lược đồ ở trên tạo ra một lược đồ gọi là sale_star tương ứng tới bảng sự
kiện sales ở trung tâm của lược đồ. Lệnh này chỉ ra các chiều và hai độ đo là dollars_sold và units_sold. Các chiều cụ thể là time, item, branch và location. Lệnh
define dimension được dùng để định nghĩa ra các chiều này.
Định nghĩa lược đồ bông tuyết:
define lược đồ 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 thì tương tự như định nghĩa của sale_star trong định nghĩa lược đồ
chiều item của lược đồ sale_star đã được chuẩn hoá trên lược đồ sales_snowflake
thành hai bảng chiều là item và supplier. Chú ý rằng định nghĩa chiều cho supplier thì được chỉ ra trong định nghĩa của chiều item. Định nghĩa chiều supplier theo cách này tạo ra một supplier_key trên định nghĩa chiều item. Tương tự như vậy, chiều location của lược đồ sale_star đã được chuẩn hoá trên lược đồ sale_sowflake thành hai bảng
chiều, location và city. Định nghĩa chiều city được chỉ ra trong cùng định nghĩa của
chiều location. Theo cách này, thuộc tính city_key được tao ra một cách tường minh
trong định nghĩa bảng chiều location. Định nghĩa lược đồ chòm sao thực:
Lược đồ chịm sao có thể được định nghĩa như là một tập hợp của các lược đồ liên kết lại. Dưới đây là một ví dụ định nghĩa lược đồ chịm sao ở trên:
define lược đồ 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 lược đồ shipping [time, item, shipper, from location, to location]:
dollars_cost = sum(cost_in_dollars), units shipped = count(*)
define dimension time as time in lược đồ sales define dimension item as item in lược đồ sales
define dimension shipper as (shipper_key, shipper_name, location as location in lược đồ sales, shipper_type)
define dimension from_location as location in lược đồ sales define dimension to_location as location in lược đồ sales
Lệnh define lược đồ được sử dụng để định nghĩa ra lược đồ dữ liệu là sales và shipping tương ứng với 2 bảng sự kiện của lược đồ chịm sao được mơ tả ở trên. Các
chiều time, item và location của lược đồ sales được chia sẻ với lược đồ shipping.
Trong ví dụ trên phần định nghĩa lược đồ shipping, chiều time được lấy lại định nghĩa từ từ chiều sales.
2.3.3. Độ phân cấp
Khái niệm phân cấp chỉ ra thứ tự ánh xạ dữ liệu từ một tập hợp ở mức thấp đến tập hợp ở mức cao. Để làm rõ hơn, ta xem xét mức độ phân cấp cho chiều location. Thuộc
tính city của chiều này bao gồm các giá trị là: Vancouver, Toronto, NewYork, và Chicago. Tuy nhiên mỗi thành phố này có thể được ánh xạ vào các tỉnh hoặc các nước
mà nó thuộc vào. Ví dụ là thành phố Vancouver được ánh xạ vào bang BritishColumbia, thành phố Chicago vào bang Illinois. Các tỉnh hay các bang này sẽ tiếp tục được ánh xạ vào đất nước mà nó thuộc vào như là Canada hay USA. Các ánh
xạ đó hình thành nên khái niệm phân cấp cho chiều location từ mức độ thấp đến mức độ cao. Khái niệm phân cấp này có thể được minh hoạ như hình vẽ bên dưới.
Hình 19: Các mức phân cấp dữ liệu
Đa số các khái niệm phân cấp được khai báo tường minh trong lược đồ cơ sở dữ liệu. Quay lại ví dụ trên với chiều location có các thuộc tính là number, street, city, province_or_state, zipcode, và country. Các thuộc tính này có mối quan hệ thứ tự với
nhau hình thành nên mức phân cấp: street < city < province_or_state < country. Mức độ phân cấp này chỉ ra trong hình vẽ bên dưới.
Hình 20: Mức phân cấp chiều thời gian
Do các bảng dimension có tính phân cấp nên có thể xuất hiện dư thừa dữ liệu. Điều này được chấp nhận trong data warehouse.
CHƯƠNG 3: OLAP VÀ DATA WAREHOUSE
3.1. Giới thiệu về OLAP
Người dùng cần khả năng thực hiện phân tích đa chiều với những tính tốn phức tạp nhưng với những công cụ truyền thống như lập báo cáo, truy vấn các sản phẩm trong cơ sở dữ liệu, bảng tính thì các ngơn ngữ thơng thường là rất khó khả thi bởi các cơng cụ được sử dụng trong hệ thống OLTP và môi trường data warehouse là hoàn toàn khác nhau. Chúng ta cần một tập các công cụ đặc biệt phục vụ cho mục đích phân tích dữ liệu. Đó chính là mơi trường OLAP (On-Line Analytical Processing ) trong data warehouse.
Thuật ngữ OLAP hay xử lý phân tích trực tuyến được giới thiệu E. F. Codd [9]- cha để của mơ hình cơ sở dữ liệu quan hệ hướng dẫn cho một hệ thống OLAP.
Định nghĩa: OLAP là loại kỹ thuật phần mềm cung cấp khả năng phân tích, quản lý
và thực thi để lấy dữ liệu với phương thức truy cập nhanh, nhất quán, khả năng tương tác trong các hệ thống thơng tin lớn phản ánh một cách nhìn đa chiều về doanh nghiệp. Như vậy, định nghĩa trên bao gồm tất cả các thành phần chính như: tấc độ, tính nhất qn, khă năng tương tác và khung nhìn đa chiều.
E. F. Codd [9] đề xuất ra 12 nguyên tắc hay hướng dẫn cho một hệ thống OLAP như sau:
Khung nhìn khái niệm đa chiều: Cung cấp mơ hình dữ liệu đa chiều nhằm hướng
đến mục đích phân tích và tính dễ sử dụng. Thơng thường cách nhìn của người dùng kinh doanh là đa chiều. Do đó, mơ hình dữ liệu đa chiều thích hợp cho người dùng giải quyết các vấn đề liên quan đến nghiệp vụ.
Tính trong suốt: Các khía cạnh về cơng nghệ, data warehouse, kiến trúc tính tốn...
tất cả đều trong suốt đến người sử dụng, giải quyết các vấn đề về nghiệp vụ của người dùng thông qua cơng cụ có giao diện đơn giản, dễ sử dụng.
Khả năng truy cập: Hệ thống OLAP phải ánh xạ được tới kênh logic của chính nó tới
data warehouse vật lý hỗn độn và thực hiện các chuyển đổi dữ liệu cần thiết để tạo ra một khung nhìn đơn giản, mạch lạc cho người sử dụng.
Khả năng tạo báo cáo thống nhất: Khi số lượng các chiều tăng thì năng suất tạo báo
cáo giảm đi.
Kiến trúc client/server: Thành phần server của các công cụ OLAP cần phải đủ thông
minh đến mức mà nhiều client có thể truy cập tới một cách dễ dàng và có thể lập trình tích hợp. Server thơng minh phải có đủ khả năng để ánh xạ và xây dựng dữ liệu từ những cơ sở dữ liệu vật lý và logic khác hẳn nhau. Điều đó rất cần thiết để đảm bảo tính trong suốt và xây dựng một lược đồ mức khái niệm, logic, vật lý chung.
Mơ hình chiều: Mỗi chiều của dữ liệu phải cân bằng giữa cấu trúc và khả năng thực
hiện của nó. Thường chỉ tồn tại một cấu trúc chung cho tất cả các chiều. Mọi chức năng được áp dụng cho một chiều cũng có thể áp dụng cho các chiều khác.