1. Họ tên: Trần Thanh Long - MSSV: CH20401027
Kính thưa thầy và các bạn thân mến.
Khái niệm data cube rất mới lạ với bản thân. Nên rất muốn tìm hiểu sâu về
nó. Qua quá trình tìm hiểu thêm em xin nêu ra đây một số kiến thức để chia xẻ
với các bạn
- Cách chọn lựa của tác giả bài báo trong một datacube cell nào nên được
tính trước.
- Giới thiệu khái niệm dàn
- Các thuộc tính phân cấp và
- Gộp các chiều có thuộc tính phân cấp trong dàn.
- Thuật toán tham lam làm việc với dàn này để xác định một tập hợp các
view tốt nên được tính toán trước nó.
Rất mong sự góp ý của thầy và các bạn
Kính chào.
CÀI ĐẶT DATACUBE MỘT CÁCH HIỆU QUẢ
Trích từ nguồn “Implementing Data Cubes Efficiently” của các tác giả
Venky Harinarayan – Anand Rajaraman – Jeffrey D. Ullman

2. Họ tên: Trần Thanh Long - MSSV: CH20401027
Mở đầu:
Các ứng dụng hỗ trợ ra quyết định liên quan đến các câu truy vấn phức tạp
trên các cơ sở dữ liệu lớn. Vì thời gian hồi đáp yêu cầu phải nhỏ, việc tối ưu câu
truy vấn là quan trọng. Người sử dụng view dữ liệu như là các data cube nhiều
chiều. Mỗi cell của data cube đó như là 1 view bao gồm 1 phép gộp đáng quan
tâm chẳng hạn như tổng doanh thu bán hàng. Các giá trị của nhiều cell này thì
phụ thuộc vào các giá trị của các cell khác trong data cube. Một kỹ thuật tối ưu
hoá thường làm là phải tính toán trước một vài cell hay tất cả các cell trong data
cube hơn là mỗi lần cần tính toán thì lại truy xuất dữ liệu thô để tính toán. Chúng
ta tìm hiểu xem các cell nào (view) nên được tính toán trước trong khi nếu tính
toán hết tất cả các view thì quá là tốn kém.
Một cấu trúc dàn lattice được sử dụng để diễn tả sự phụ thuộc của các view
và một thuật toán tham lam làm việc với dàn này để xác định một tập hợp các
view tốt nên được tính toán trước nó.
Phần I
I. Giới thiệu:
Hệ thống hỗ trợ ra quyết định (DSS) nhanh chóng trở thành chìa khoá để thu
được nhiều thuận lợi đến việc cạnh tranh trong kinh doanh. DSS cho phép các
nhà kinh doanh nhận được thông tin hữu ích đã được chốt lại từ các cơ sở dữ
liệu giao tác. Nhiều công ty đã và đang xây dựng các cơ sở dữ liệu DSS thống
nhất mới được gọi là nhà kho dữ liệu ( data warehouse) qua đó người sử dụng
có thể thực hiện các phân tích của họ.
Trong khi các cơ sở dữ liệu giao tác duy trì thông tin trạng thái đang hoạt
động còn nhà kho dữ liệu lưu trữ thông tin quá khứ. Do đó các nhà kho dữ liệu
có khuynh hướng rất lớn và tăng trưởng theo thời gian.
Người sử dụng của DSS quan tâm đến việc chỉ ra xu hướng hơn là nhìn vào
các mẫu tin rời rạc.
Các câu truy vấn DSS thường sử dụng nhiều phép gộp phức tạp hơn các câu
truy vấn OLTP.
Kích thước của nhà kho dữ liệu và sự phức tạp của các câu truy vấn có thể
khiến các câu truy vấn tốn thời gian rất lâu để hoàn thành. Độ trễ này là không
thể chấp nhận trong phần lớn môi trường DSS. Yêu cầu thường là thời gian thực
thi truy vấn khoảng vài giây đến vài phút là nhiều nhất.
Có nhiều cách để đạt mục tiêu thi hành như vậy. Một kỹ thuật thường được
sử dụng là tính trước các câu truy vấn thường được hỏi . Ví dụ nhà kho dữ liệu
của dãy các cửa hàng kinh doanh của Mervyn có tổng cộng 2400 bảng được
tính trước để cải thiện việc thi hành các câu truy vấn.
Việc chọn đúng tập hợp các câu truy vấn cần tính trước là một công việc
không tầm thường vì rằng việc chọn lựa một query nào để tính trước có thể giúp
chúng ta trả lời các câu truy vấn khác một cách nhanh chóng mặc dù các câu
truy vấn khác đó chưa được tính trước.
Ví dụ Một query thường ít được hỏi nhưng nếu nó lại giúp ta trả lời nhiều câu
truy vấn khác một cách nhanh chóng thì ta nên tính trước query đó.
 Điều ta cần quan tâm ở đây là thứ tự những query cần được tính trước đó.
1.1 Data cube:

3. Họ tên: Trần Thanh Long - MSSV: CH20401027
Người sử dụng của nhà kho dữ liệu làm việc trong môi trường đồ hoạ và dữ
liệu thường được trình bày dưới dạng data cube nhiều chiều trong đó các data
cube con 2-D hay 3-D dùng để khám phá các thông tin đáng chú ý. Các giá trị
trong mỗi cell của data cube này là đáng quan tâm.
Ví dụ 1: Mô hình nhà kho dữ liệu của hệ thống cửa hàng của Mervyn gồm các
cửa hàng p mua từ các nhà cung cấp s và sau đó bán cho khách hàng với giá
sp. 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 bộ phận p bán các sản
phẩm được mua từ nhà cung cấp s và được bán cho khách hàng c.
Người dùng cần quan tâm đến việc kinh doanh có chắc chắn không ? Do đó
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 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.
=> Vì thế điều quan trọng là chúng ta phải chọn lựa đúng các cell cần tính trước.
Hướng tiếp cận của chúng ta rất linh hoạt và có thể xử lý tốt với data cube lớn.
Bất kỳ cell nào có giá trị ALL như là một thành phần địa chỉ của nó là cell phụ
thuộc. Giá trị của cell này có thể tính từ các cell khác trong data cube. Nếu một
cell không có “ALL” trong thành phần của nó, thì giá trị của nó không thể tính từ
các cell khác, chúng ta phải truy xuất dữ liệu thô để tính giá trị của nó. Số lượng

4. Họ tên: Trần Thanh Long - MSSV: CH20401027
các cell có thành phần “ALL” thường là phần lớn trong tổng số các cell trong
data cube đó. Trong cơ sở dữ liệu TPC-D với các chiều như trong ví dụ 1 ở trên
khoảng 70% tổng số các cell trong data cube là phụ thuộc.
Bài toán cell nào của data cube đó cần được tính trước là một bài toán thực
tế. Có nhiều hệ thống thương mại khác nhau chọn một trong các hướng tiếp cận
trên. Hiển nhiên mỗi chiến lược có những thuận lợi của nó.
Các cell của data cube được tổ chức thành các tập hợp khác nhau dựa vào
vị trí của “ALL” trong địa chỉ của chúng. Vì thế, ví dụ, tất cả các cell mà địa chỉ
của nó hợp với cell ( -,ALL,-) được đặt trong cùng tập hợp. Ở đây “-“ thay thế
cho giá trị bất kỳ. Mỗi một tập hợp này tương ứng với một câu truy vấn SQL
khác nhau: Giá trị trong tập hợp các cell (-,ALL,-) được xuất ra từ câu truy vấn
sau:
SELECT Part, Customer, Sum(SP) AS TotalSales
From
Group by Part, Customer;
Ở đây, R tương ứng quan hệ dữ liệu thô. Các câu truy vấn tương ứng với tập
hợp các cell khác nhau chỉ khác trong mệnh đề GROUP-BY. Tổng quát, các
thuộc tính với giá trị “ALL” trong sự mô tả tập hợp các cell sẽ không xuất hiện
trong mệnh đề group-by của câu truy vấn SQL.
Ví dụ thuộc tính Supplier không xuất hiện trong mệnh đề group-by trong câu
truy vấn SQL ở trên.
Vì các câu query khác nhau cho ra các tập hợp khác nhau chỉ khác nhau duy
nhất trong nhóm các thuộc tính được gộp trong mệnh đề group-by nên chúng ta
sử dụng các thuộc tính được nhóm như là sự nhận diện duy nhất các query đó.
Do đó việc chọn lựa tập các cell được tính trước tương ứng với việc quyết
định query nào hay view nào cần được tính trước.
Cơ sở dữ liệu mà chúng ta xem xét có 3 thuộc tính: Part, Supplier, Customer.
Vì thế chúng ta có 8 nhóm các thuộc tính được liệt kê trong mệnh đề group by.
Tất cả các query(view) có thể có ở dưới đây với tổng số các dòng dữ liệu trong
kết quả của chúng.
1. Part, Supplier, Customer ( 6M tương ứng 6 triệu dòng)
2. Part, Customer (6M)
3. Part, Supplier (0.8 M)
4. Supplier, Customer (6M)
5. Part (0.2 M)
6. Supplier (0.01 M)
7. Customer (0.1M)
8. none
Chú ý: none ở đây cho biết không có thuộc tính nào trong mệnh đề group by.
Hình 1 ở dưới trình bày 8 view được tổ chức như một dàn các query. Trong việc
đặt tên các view trong sơ đồ này, chúng ta sử dụng p cho part, s cho Supplier và
c cho Customer.

5. Họ tên: Trần Thanh Long - MSSV: CH20401027
psc(6M) sc(6M)
Hình 1: 8 view được xây
s(0.01M)
ps(0.8M) dựng bằng cách nhóm
pc(6M) một vài thuộc tính trong
c(0.1M) các thuộc tính Part,
Customer, Supplier.
p(0.2M) non
e
Người dùng có thể hỏi doanh thu được nhóm bởi Part, Nếu chúng ta đã tính
view số 5 chúng ta chỉ cần quét view đó một lần và xuất ra câu trả lời ngay.
Chúng ta cũng có thể trả lời cho hỏi trên bằng cách sử dụng view số 2 được
nhóm bởi (Part,Customer). Trong trường hợp này, vì chúng ta đã có tổng doanh
thu của từng khách hàng do đó mỗi bộ phận part chúng ta cần tính tổng doanh
thu đối với tất cả các khách hàng cũng nhận được kết quả như trong view số 5.
Chúng ta giả sử chi phí để trả lời cho câu truy vấn thì tỷ lệ với số dòng dữ liệu
được xem xét .
Do đó chi phí tìm tổng doanh thu được nhóm bởi Part (View 5) =chi phí xử lý
0.2 triệu dòng dữ liệu ( kích thước của view này).
Trong khi để trả lời cho cùng câu hỏi đó bằng cách nhóm bởi Part,Customer
(view 2 ) chúng ta cần xử lý 6 triệu dòng dữ liệu.
Một loại câu hỏi khác chỉ yêu cầu tính doanh thu cho 1 bộ phận cụ thể. Nếu
view chưa có chỉ mục, thì khi đó phải quét toàn thể view cho cả 2 view số 2 và số
5. Tuy nhiên, nếu trong cả 2 view đã có chỉ mục thì việc tìm doanh thu chỉ truy
xuất 1 dòng ( đối với View 5) trong khi đối với view 2 thì phải truy xuất trung bình
6M/0.2M=30 dòng.
Có một vài câu hỏi đáng quan tâm:
1) Cần bao nhiêu view phải được tính trước để có thể đạt được thời gian thi
hành có thể chấp nhận được.
2) Biết rằng với vùng không gian S đã cho, các view nào chúng ta cần tính
trước sao cho chi phí truy vấn trung bình thấp nhất .
Bây giờ chúng ta để ý rằng để tránh phải truy xuất dữ liệu thô chúng ta cần
tính trước view 1 được nhóm bởi (Part,Supplier,Customer), vì rằng view đó
không thể tính từ bất kỳ view nào khác.
Đối với view 2 và view 4 để trả lời cho bất cứ câu truy vấn sử dụng view 2
hoặc view 4 đòi hỏi chúng ta phải xử lý 6 triệu dòng. Thay vì phải sử dụng view 2
hoặc view 4 để trả lời ta có thể sử dụng view 1 cũng cho ra cùng 1 câu trả lời.
=> Không cần hiện thực view 2 và view 4. Do đó chi phí truy vấn trung bình chỉ
khoảng 7 triệu dòng. Một sự cải thiện hơn 60% vùng không gian lưu trữ và cũng
vì thế cải thiện chi phí tạo data cube đó.
Vì thế bằng cách chọn một cách thông minh phần nào của data cube cần tính
trước, chúng ta có thể thu được nhiều lợi ích.

6. Họ tên: Trần Thanh Long - MSSV: CH20401027
PHẦN 2: Cấu trúc dàn
Chúng ta phát triển ký hiệu để mô tả khi nào một truy vấn data cube có thể
trả kết quả từ kết quả của một câu truy vấn khác.
Chúng ta thấy rằng các câu truy vấn trả về kết quả mong muốn đưa các
thuộc tính cần thiết trong mệnh đề group by của chúng. Chúng ta ký hiệu các
thuộc tính nằm trong mệnh đề group by bằng cách đặt chúng trong dấu ngoặc
đơn.
Ví dụ: Query có các thuộc tính được gom nhóm Part và Customer được ký
hiệu bởi (Part,Customer).
2.1 Quan hệ phụ thuộc trên các câu truy vấn:
Xét 2 query Q1 và Q2. Ta nói rằng Q1 và Q2 có quan hệ ≤ nếu và chỉ nếu Q1
có thể trả về kết quả bằng cách sử dụng kết quả của query Q2. Khi đó ta nói
rằng Q1 là phụ thuộc vào Q2.
Ví dụ: Query truy vấn (Part) trong phần 1 có thể được trả lời bằng cách chỉ sử
dụng kết quả của query (Part,Customer). Vì thế (Part) ≤ (Part,Customer). Có
những query không có quan hệ ≤ với query khác. Ví dụ (Part) ≤ (Customer) và
(Customer) (Part).
≤
Quan hệ ≤ đưa ra một thứ tự từng phần trên các query .
Để là 1 dàn, bất cứ 2 phần tử nào (view hay query) phải có ít nhất một biên
trên và một biên dưới tuỳ thuộc vào quan hệ thứ tự ≤. Tuy nhiên trong thực tế,
chúng ta chỉ cần giả định rằng :
1. ≤ là 1 quan hệ thứ tự từng phần và
2. có một phần tử trên (top element), đó là view mà mọi view khác đều phụ
thuộc.
2.2 Ký hiệu dàn:
Chúng ta ký hiệu 1 dàn bằng tập các phần tử ( query hay view) L và một
quan hệ phụ thuộc ≤ bởi (L,≤ ).
Đối với các phần tử a và b của một dàn (L,≤ ),a <b khi và chỉ khi a ≤ b và a ≠b
Tổ tiên và con cháu của một phần tử trong một dàn (L,≤ ) được định nghĩa
như sau:
ancestor(a) = {b / a ≤ b}
descendant(a) = {b / b ≤ a}
Chú ý rằng mọi phần tử của dàn là tổ tiên và là con cháu của chính nó.
Các tổ tiên trực tiếp của một phần tử a đã cho trong một dàn,ký hiệu là
next(a) được định nghĩa như sau:
next(a) = { b / a <b ∧ ∃ c , a ≤ c, c ≤ b}
2.3 Các sơ đồ dàn:
Thương biểu diễn một dàn bằng 1 đồ thị trong đó các phần tử thuộc dàn là các
node và có 1 cạnh từ phần tử a dưới đến phần tử b trên nếu và chỉ nếu b ∈ next(a)

7. Họ tên: Trần Thanh Long - MSSV: CH20401027
Vì thế đối với 2 phần tử x, y bất kỳ có 1 đường đi xuống từ y đến x nếu và chỉ
nếu x ≤ y.
Ví dụ: Siêu cube trong hình 1 là một sơ đồ dàn của tập hợp các view.
2.4 Sự phân cấp:
Trong phần lớn các ứng dụng thực tế, các chiều của một data cube bao gồm
nhiều hơn một thuộc tính và các chiều được tổ chức như là sự phân cấp các
thuộc tính. Một ví dụ đơn giản chiều thời gian được tổ chức phân cấp như sau:
day, month và year. Sự phân cấp rất quan trọng khi chúng tạo thành hai phép
toán truy vấn cơ bản rất thường được sử dụng nhất : “drill-down” và “roll-up”.
- Drill-down là quá trình view dữ liệu ở các cấp độ càng ngày càng chi tiết
hơn.
Ví dụ: người dùng đầu tiên muốn biết tổng doanh thu cả năm và rồi tổng
doanh thu mỗi tháng và cuối cùng doanh thu của một ngày đã cho.
- Roll-up: là phép toán ngược lại, đó là quá trình view dữ liệu ở cấp độ càng
ngày càng tổng quát hơn.
Ví du: người dùng muốn biết doanh thu vào một ngày đã cho, rồi tổng doanh
thu trong tháng đó và cuối cùng tổng doanh thu trong năm đó.
Trong sự hiện diện của sự phân cấp, dàn phụ thuộc (L,≤ ) thì phức tạp hơn
một dàn siêu cube (hypercube lattice) ví dụ, xét một query nhóm theo chiều thời
gian và không có chiều khác.
Khi đó chúng ta có 3 query sau đây: (day), (month), (year).
Hơn thế nữa ta có quan hệ thứ tự sau: (year) ≤ (month) ≤ (day).
Mặt khác, nếu chúng ta có tổng doanh thu được nhóm theo month, chúng ta
có thể sử dụng các kết quả đó để tính tổng doanh thu được nhóm theo year. Sự
phân cấp trình bày những sự phụ thuộc query mà những sự phụ thuộc đó phải
tính đến khi xác định những query nào cần được tính trước.
Sự phân cấp thường không là thứ tự toàn phần tuy nhiên chỉ là thứ tự riêng
phần trên các thuộc tính tạo thành một chiều. Xét chiều thời gian với sự phân
cấp day, week, month và year. Vì month và year không thể được chia nhỏ thành
week. Nếu chúng ta nhóm theo week thì chúng ta không thể group theo month
và year được.
Mặt khác (month) ≤ (week) , (week) ≤ (month) tương tự đối với week và year.
Khi chúng ta gộp cả none view ( tương ứng với không có thuộc tính time
trong group-by), chúng ta nhận được một dàn đối với chiều thời gian time được
trình bày trong hình 2:
Day
Month
week
year
none Hình 2

8. Họ tên: Trần Thanh Long - MSSV: CH20401027
2.5 Gộp nhiều dàn có sự phân cấp theo từng chiều:
Chúng ta gặp sự phụ thuộc query theo 2 dạng sau đây:
1- Sự phụ thuộc query gây ra bởi sự tương tác của các chiều khác nhau với
một query khác .
2- Sự phụ thuộc query trong phạm vi một chiều gây ra bởi những sự phân
cấp thuộc tính.
Ví dụ: Chúng ta xét sự phân cấp theo các chiều Part và customer. Mỗi một dàn
phân cấp theo từng chiều trên( Part/ Customer) được bổ xung phần tử none
như là phần tử thấp nhất.
Đối với chiều Customer được tổ chức thành cây phân cấp như sau: Các
khách hàng cụ thể được ký hiệu là c, những khách hàng này được nhóm trong
cùng một quốc gia nơi họ thường trú được ký hiệu là n. Phần tử thấp nhất của
sự phân cấp được ký hiệu là none.
Đối với chiều Part, mỗi sản phẩm cụ thể được ký hiệu bằng thuộc tính p,
những sản phẩm cụ thể được nhóm theo kích thước của chúng được ký hiệu bởi
thuộc tính s. Chúng cũng được nhóm theo sự phân loại được ký hiệu bằng thuộc
tính t.
Chú ý rằng giữa s và t không có quan hệ nào nghĩa là (s) ≤ (t) , (t) ≤ (s)
Sơ đồ các dàn phân cấp theo các chiều Part và Customer được cho trong hình 3
p
c
s t
n
non
non
a) Customer Hình 3 b) Part
Dàn kết hợp các chiều phân cấp được cho trong hình 4:
cp ct
cs c
np
nt
ns n
p
t
s
none
Hình 4: Kết hợp hai chiều Part và Customer có các thuộc
tính phân cấp.

9. Họ tên: Trần Thanh Long - MSSV: CH20401027
Cấu trúc dàn mà tác giả bài báo trình bày có những thuận lợi như:
1- Nó cung cấp một cấu trúc rõ ràng với sự phân cấp các chiều để lập luận.
Sự phân cấp này rất quan trọng trong việc quyết định những view nào cần
được tính trước để việc thực thi query là tốt nhất.
2- Chúng ta có thể mô hình các query thường được hỏi bời người dùng tốt
hơn bằng cách sử dụng cấu trúc dàn. Người dùng không thể nhảy giữa
các phần tử không được kết nối trong dàn này, chúng phải di chuyển dọc
theo các cạnh của dàn. Trong thực tế, drill-down thường đi lên theo một
đường từ cấp độ thấp tới cấp độ cao hơn, trong khi roll-up thì đi xuống
theo một đường từ cấp độ cao xuống cấp độ thấp hơn.
3- Hướng tiếp cận theo dàn cũng chỉ ta thứ tự để thực thi các view.
Ví dụ chúng ta quyết định thực thi một view S= {Q1,Q2,…, Qn} có thể có
một vài query trong S phụ thuộc vào các query khác, do đó chúng ta
không cần quét dữ liệu thô để tính toán cho mỗi query đó mà chỉ cần sử
dụng kết quả các query đã được tính toán rồi để tính tiếp cho các query
phụ thuộc khác trong S. Do đó chúng ta có thể giảm thời gian cần để thi
hành view S dẫn đến việc giảm thời gian tạo data cube đó.
Xét dàn (L,≤ ) trong đó tất cả các view trong S là các phần tử. Thực hiện việc
sắp xếp thứ tự các phần tử trong S theo thứ tự giảm dần tương ứng với quan hệ
≤ . Kết quả chúng ta có thứ tự các view như sau: QS1, QS2,… Qsn. Chúng ta thi
hành các view theo thứ tự đó. Một vài phần tử đầu tiên không có các phần tử tổ
tiên trực tiếp trong S. Để truy xuất các view này chúng ta phải truy xuất dữ liệu
thô. Sau đó tất cả các view có thể được thực hiện thông qua các view đã được
tính toán trước đó. Trong việc tính toán một view QSi chúng ta sử dụng các view
tổ tiên trực tiếp của nó trong S, QSj , j < I với số dòng nhỏ nhất.
3. Tối ưu các dàn Datacube:
Mục tiêu quan trọng nhất của chúng ta là phải phát triển kỹ thuật để tối ưu
vùng không gian- thời gian khi cài đặt một dàn các view.
Một bài toán tối ưu đơn giản như sau:
Giả sử cần cài đặt trước k view, bất kể vùng không gian cần lưu trữ các view
đó. Làm thế nào để chọn k view trong tập hợp các view của một datacube
sao cho đối với các view còn lại ta có thể tính toán từ k view đã được tính
trước với một chi phí thấp nhất.
Sự chọn lựa heuristic ở đây là thuật toán là thuật toán tham lam, trong đó
chúng ta chọn 1 dãy các view mà mỗi view là một sự chọn lựa tốt nhất. Hướng
tiếp cận này rất gần với tối ưu.
3.1 Thuật toán tham lam:
Giả sử chúng ta có một dàn datacube với chi phí vùng không gian lưu trữ cho
mỗi view. Chi phí vùng không gian ở đây là số dòng trong view đó. Đặt C(v) là
chi phí của view v. Giả sử rằng k là giới hạn số view cần cài đặt trước cùng với
top view. Sau khi chọn lựa một số tập S các view ( kể cả top view là view mà tất
cả các view khác đều phụ thuộc nó), độ lợi của view v liên quan đến S, được ký
hiệu B(v,S) được định nghĩa như sau:

10. Họ tên: Trần Thanh Long - MSSV: CH20401027
1- Đối với mỗi w ≤ v định nghĩa độ lợi Bw bởi:
a) Gọi u là view có chi phí thấp nhất trong S sao cho w ≤ u. Chú ý
rằng top view trong S nên phải có ít nhất một view như thế trong S.
b) Nếu C(v) <C(u) thì Bw=C(u)-C(v) ngược lại Bw=0
2- Định nghĩa B(v,S)= Σ Bw = Σ (C(u)-C(v))
w≤v w≤v
Chúng ta tính độ lợi cho view v bằng cách xét làm thế nào để cải thiện chi
phí tính toán các view con khác kể cả chính view v. Đối với mỗi view w mà v bao
phủ (w ≤ v), chúng ta so sánh chi phí để tính w bằng cách sử dụng bất cứ view
nào trong S đưa ra chi phí tính toán rẻ nhất cho w. Nếu sử dụng v, nghĩa là chi
phí của v thì nhỏ hơn hoặc bằng chi phí của các phần tử cạnh tranh của nó. Khi
đó tổng cộng độ lợi B(v,S) là tổng tất cả độ lợi của các view w có sử dụng v để
tính w.
Thuật toán được trình bày như sau:
S={top view}
For i=1 to k do begin
Select view v not in S such that B(v,S) is maximized;
S= S union {v};
End;
Resulting S is the greedy selection;
Minh hoạ bằng hình vẽ sau: S s2 Sk-1
+ Giả sử trong tập S đã có các view s1,s2,… sk-1 s1
+ v , w1 , w2 ,w3 là các view thoả v
w1 ≤ v ; w2 ≤ v ; w3 ≤ v và w3
w1 w2
w1 ≤ s1 ; w2 ≤ s2
khi đó độ lợi B(v,S)= Bv + Bw1 + Bw2 + Bw3 = 2*[C(v)-C(s2)] + [C(v)-C(s1)] + [C(v)-C(sk-1)]
( vì Bv = Bw2 =[C(v)-C(s2)] )
Do đó Nếu độ lợi B(v,S) lớn nhất ∀ v ∉ S thì S= S ∪ {v}
Ví dụ: Xét dàn được cho trong hình 7. 8 view được đặt tên từ a đến h có chi phí
vùng không gian lưu trữ được chỉ trên hình. Top view là a, với chi phí 100, được
chọn đầu tiên. Giả sử chúng ta muốn chọn 3 view nữa sao cho có thể tính chi
phí thấp nhất cho các view khác trong dàn.
a 100
75
c
50 b
30
20 f 40
e
d
1 h
g
10
Hình 7:Ví dụ về dàn với chi phí vùng không gian lưu trữ

11. Họ tên: Trần Thanh Long - MSSV: CH20401027
để thực hiện thuật toán tham lam trên dàn này , chúng ta phải thực hiện liên tiếp
3 sự chọn lựa các view để tính toán trước. Cột đầu tiên trong hình 8 cho chúng
ta độ lợi của mỗi view ngoài view a. Khi tính toán độ lợi, chúng ta bắt đầu với giả
sử sau mỗi view con a khi tính toán có sử dụng a sẽ có chi phí là 100.
a) Chọn lựa lần 1:
Nếu chúng ta chọn b để thực hiện trước thì khi đó chúng ta sẽ giảm bớt chi
phí của nó đi 50 (=C(a)-C(b)=100-50) và cũng giảm bớt chi phí của các view con
d,e,g và h dưới b đi 50  B(b,S)=50*5=250.
Tương tự nếu ta chọn e đầu tiên và các view dưới nó g và h mỗi view có chi
phí giảm đi 70( =C(a)-C(e)=100-30). Do đó B(e,S)=70*3=210.
So sánh độ lợi giảm đi của các view trong cột đầu tiên.
Kết quả: view được chọn lần 1 là view b.
b) Chọn lựa lần II:
Tiếp tục chúng ta phải tính lại độ lợi của mỗi view v, biết rằng view v được
tạo từ b với chi phí 50 nếu v là con b
hoặc từ a với chi phi 100 nếu v không là con b. Độ lợi được trình bày trong cột 2
của hình 8.
+ Nếu chọn c sinh ra độ lợi 25 cho chính nó(=C(a)-C(c)=100-75)và
f con c sinh ra độ lợi 25 (=C(a)-C(c)=100-75).
Việc chọn c không còn cải thiện chi phí của e,g,h, vì thế chúng ta không
tính độ lợi cho các view đó  B(c,S)=25+25=50
+ Nếu chọn f nó sinh ra độ lợi 60 cho chính nó (=C(a)-C(f)=100-40) và
h con f sinh ra độ lợi là 10 (=C(b)-C(f)=50-40)  B(f,S)=60+10=70
Kết quả: View được chọn lần thứ 2 là view f.
c) Chọn lựa lần III:
Tính toán lại độ lợi cho các view được tóm tắt trong cột cuối cùng của hình 8.
+ Nếu chọn e thì độ lợi của e là 20(=C(b)-C(e)=50-30)
View g con e có độ lợi là 20(=C(b)-C(e)=50-30)
View h con e có độ lợi là 10(=C(f)-C(e)=40-30)
 B(e,S)=20+20+10=50
Tương tự cho các view còn lại
Kết quả: View đươc chọn lần thứ 3 là view d
Sự chọn lựa S={a,b,d,f} sẽ làm giảm tổng chi phí tính toán cho tất cả các view từ
800 nếu chỉ có a được tính toán trước xuống còn 420. Chi phí đó thật sự là tối ưu.
First choice Second choice Third choice
b 50*5=250
c 25*5=125 25*2=50 25*1=25
d 80*2=160 30*2=60 30*2=60
e 70*3=210 20*3=60 20+20+10=50

12. Họ tên: Trần Thanh Long - MSSV: CH20401027
f 60*2=120 60+10=70
g 99*1=99 49*1=49 49*1=49
h 99*1=99 40*1=40 30*1=30