Tiểu luận Mô hình hóa dữ liệu đa chiều

lập tương ứng có liên quan các khối. Cho FS một tập của các khối quan hệ và QS là tập của các truy vấn trên các khối trong FS. Cho tập các view cụ thể trên các khối trong FS và PS là tập của đặc tả các mô hình trong các view VS. Định nghĩa 2.5. Cho khối chúng ta phân chia Meas(f) bên trong các tập con lớn nhất của các dữ kiện xuất hiện tất cả cùng với nhau trong tối thiểu một truy vấn QS và không xuất hiện một cách riêng biệt khác trong truy vấn QS: Chúng ta gọi mỗi tập con một minterm của f, và biểu thị với MS(f) tập của tất cả các minterm của f. Ví dụ: Trên khối LineItem cho QS ={q1, q2} trong đó Meas(q1) = {Price, Qty, ExtPrice, Discount} và Meas(q2) = {Price, Qty, DiscPrice, SumCharge}, nó là MS(LineItem) = {{Price, Qty}, {ExtPrice, Discount}, {DiscPrice, SumCharge}}. Định nghĩa 2.6. Cho tập các khối quan hệ FS, chúng ta định nghĩa một term như là một tập của dữ kiện có thể là một minterm của một khối trong FS hoặc hội của các minterm thậm chí từ các khối khác trong FS bên trong tập như vậy . Chứng tỏ với TS tập của các term cho FS. Ví dụ ở trên nó là Cho FS, môt sự giải quyết vấn đề phân mảnh là được giải mã bởi một mảng phân mảnh, …một mảng nhị phân C có ba chiều tương ứng, tương ứng các truy vấn qi QS, các mô hình Pj PS và các term tập của các mảnh được định nghĩa bởi C là: Trong đó mảnh vjk là được đặc trưng bởi Meas(vjk) = Tk và Patt(vjk) = Pj. Một mảng phân mảnh không chỉ biểu diễn một phân mảnh của các view trong VS đồng thời nó xác định rõ mảnh(s) mỗi truy vấn là giả định được thực thi. Trong thực tế một ô Cijk biểu diễn điều đó khi trả lời truy vấn qi, dữ kiện trong sẽ thu được từ vjk. Sự phân mảnh giải mả được bởi C là khả thi nếu đều sau là thỏa: Mỗi truy vấn, mọi dữ kiện yêu cầu phải thu được chính xác một mảnh (sự thực thi truy vấn không nhập nhằng) Mỗi mô hình, mỗi dữ kiện phải thuộc tối đa một mảnh (không có phân mảnh dư thừa) Mỗi mảnh trong VS’ phải được một mảnh của một hoặc hơn các view trong VS(kiên định với các view cụ thể): Mặc dù theo(constraint) (3) nói rằng mỗi mảnh phải lấy được từ một view trong VS, không bảo đảm rằng mọi dữ kiện trong mỗi view là được bao gồm trong một mảnh. Trong thực tế, các mảnh sẽ được sản xuất chỉ cho các minterm, trong những nguồn gốc này từ mỗi view, thực sự được sử dụng để trả lời ít nhất một trong những yêu cầu truy vấn. Cho một view, chúng tôi sẽ gọi cho các minterm bị mất không có trong bất kỳ term tạo ra một mảnh. Sự phân mảnh của các view chính nhất thiết phải không được mất, vì vậy, mỗi minterm chính mất phải được xét lại một posteriori, hoặc bằng cách tạo ra một mảnh tách biệt hoặc thống nhất của nó với một trong các quyết định các mảnh. Mặt khác, như để các minterm mất từ view thứ cấp, nó không được rõ ràng cho dù các mảnh là tạo ra những thuận lợi hay không, trên thực tế, các không gian lưu có thể có được nhiều hơn lợi ích làm việc hay chỉ để lưu bổ sung các view. Trong phần sau đây chúng tôi xem xét một ví dụ nhỏ trên FS = {LineItem, Shipment}. Cho QS = {q1, q2, q3, q4, q5}; q1, q2, q3 là được định nghĩa trên LineItem, q4 trên Shipment và q5 là một truy vấn drill-across: Meas(q1) = {Price, Qty, Discount}; Patt(q1) = {ShipDate} Meas(q2) = {ExtPrice, DiscPrice}; Patt(q2) = {Part, Customer} Meas(q3) = {SumCharge, Tax}; Patt(q3) = {Part, CNation} Meas(q4) = {QtyShipped, ShippingCost}; Patt(q4) = {CNation, MFGR, ShipDate} Meas(q5) = {ExtPrice, DiscPrice, ShippingCost}; Patt(q5) = {Brand, CNation} Chúng ta giả sử rằng, bên cạnh các view chính v1 và v2, hai view thứ cấp v3 và v4 cụ thể hóa trên LineItem, một view thứ cấp v5 trên Shipment: Patt(v3) = {Part, Customer}; Patt(v4) = Patt(v5) = {Part, CNation} (với mỗi view, các dữ kiện là của khối những tương ứng). Hình 2.3 hiển mảng sự phân mảnh đại diện cho giải pháp khả thi của vấn đề phân mảnh này, tiêu biểu 5 phân mảnh: Meas(v’1) = {Price, Qty, Discount}; Patt(v’1) = Patt(LineItem) Meas(v’2) = {QtyShipped, ShippingCost}; Patt(v’2) = Patt(Shipment) Meas(v’3) = {ExtPrice, DiscPrice}; Patt(v’3) = Patt(v3) Meas(v’4) = {SumCharge, Tax}; Patt(v’4) = Patt(v4) Meas(v’5) = {ExtPrice, DiscPrice, ShippingCost}; Patt(v’5) = Patt(v4) = Patt(v5) Bốn mảnh đầu thu bởi việc phân chia, mảnh cuối một phối hợp phân chia và hợp nhất. Mảng cũng biểu hiện đó, ví dụ truy vấn q1 là thực thi trên v’1 Hình 2.3 Mảng sự phân mảnh đại diện một giải pháp khả thi 2.3.2 Hàm chi phí (Cost Function) Trong số các giải pháp khả thi tới vấn đề sự phân mảnh chúng ta quan tâm cực tiểu hóa chi phí cho thực thi khối lượng công việc. Chúng tôi tin nó thuận lợi quản lý phân tách thiết kế logic từ mức vật lý để cả hai cung cấp giải pháp tổng quát giảm phức tạp; vì vậy hàm chi phí đưa ra có ý định trước trừu tượng từ bất kỳ giả định trên truy cấp các đường dẫn, dựa trên số trang đĩa các bộ ta quan tâm cho một truy vấn là được lưu trữ. Cụ thể chi phí của truy vấn qi trong sự phân mảnh C là được định nghĩa: Trong đó: ns(Pj) số yếu tố trong tập hợp cho view trên mô hình Pj (ước lượng ví dụ như trình bày trong [8]). sel(qi) là lựa chọn của qi; vì vậy sel(qi).ns(Pj) số của các bộ của view trong mô hình Pj phải được truy cập để mà trả lời qi là số các bộ trên trang đĩa cho mảnh vjk mô tả đặc điểm Pj và Tk Vì vậy là số của các trang đĩa vjk chứa đựng là mong đợi của số các trang trong các bộ cần thiết cho qi là được lưu trữ, ước lượng với công thức . Vì vậy cost(qi, C) biểu diễn tổng số của các trang đĩa phải được truy cập để mà giải quyết qi. Mặc dù trên thực tế số của các trang đọc khi thực thi truy vấn có lẽ phụ thuộc cao hơn truy cập đường dẫn theo sau, chúng tôi tin rằng hàm này trình bày một cân bằng tốt giữa tổng quát và đúng đắn. Cần lưu ý rằng bất kỳ hai truy vấn là hợp nhất, kết quả phân mảnh có lẽ sử dụng trả lời không chỉ các truy vấn drill-across mà còn các truy vấn trên các khối đơn; vì vậy nó phải chứa hợp của các bộ. Cho f’ và f” là hai khối, cho P là chung mô hình đến f’ và f”, và cho ns’(P) và ns”(P) là các yếu tố của các view v’ trên f’ và v” trên f” riêng biệt. Yếu tố của view hợp nhất hợp nhất v’ và v” có thể ước lượng như: Trong đó cs(P) là kết quả của các yếu tố miền cho các thuộc tính trong P 2.3.3. Tiếp cận nhánh và cận (Branch-and-Bound) Bài toán của phân mảnh dọc (VFP-Vertical Fragmentation Probelem) có thể được tính theo sau: Tìm kiếm cho mảng quyết định nhị phân C, giá trị của hàm cực tiểu hóa Chủ thể đưa ra đoạn 2.3.1 mục (1), (2), (3). VFP là một bài toán lập trình tuyến tính số nguyên 0-1 giống tập bao phủ với các ràng buộc thêm vào (addition constraints), và được biết NP khó. Vì vậy một phương pháp nhánh và cận (branh – and –bound) có thể được thông qua để giải quyết nó tối ưu. Thành phần của thủ tục nhánh và cận cho một bài toán tối ưu rời rạc như VFP là [1] Luật phân nhánh cho phân chia bài toán vào trong các bài toán con. Cho là bài toán của việc chọn, cho một giải pháp bộ phận tới VFP đại diện một mảng chưa hoàn chỉnh(incomplete) C(), các phần tử duy trì Cijk đặt 1 trong giải pháp hoàn chỉnh (complete). Chúng ta biểu diễn SUB() tập các bài toán con trong là được phân chia (broken up); mỗi định nghĩa bởi việc chọn một phân tử Cijk đặt 1 trong giải pháp bộ phận, nghĩa là thêm vào giải pháp hiện hành một phân mảnh trên mô hình Pj sử dụng khôi phục vài dữ kiện Tk giải quyết truy vấn qi; Luật chọn lọc một bài toán con cho việc chọn lựa bài toán con kết tiếp(hứa hẹn nhất most promising) được xử lý. Phần tử Cijk chọn là một cho ns(Pj) là cực tiểu và có nhân tố cực đại. Một sự mở rộng của bài toán dễ dàng hơn, giải pháp của tạo thành biên của . Chúng ta mở rộng bằng việc di chuyển theo (2): trong vài dữ kiện có lẽ được thay thế trong hai hay nhiều mảnh định nghĩa trên mô hình tương tự. Một thủ tục biên dưới tính toán chi phí của sự mở rộng. bao gồm một tập bài toán bao phủ cho mỗi qi, nó có thể được giải quyết theo một trong số thuật toán của bài [4]. Vì vậy trong giải quyết số các mảnh thích hợp là cao hơn so với , chi phí của sẽ thấp hơn hoặc bằng của . 2.4 . Test thử nghiệm Trong phần này chúng tôi hỗ trợ phương pháp phân mảnh dọc của các view trong cơ sở dữ liệu đa chiều. Kết quả thử nghiệm chúng tôi trình bày trong thừa nhận ích lợi của phương pháp trong các term của giảm chi phí cho việc thực thi khối lượng công việc mong đợi. Test thực thi dựa trên chuẩn TPC-D nổi tiếng[18], chúng đặc trưng hai khối LineItem và PartSupplier với các đề cử 6.000.000 và 8.000.000 riêng biệt; tổng số lượng của dữ liệu là khoảng 1 Gbyte. Chúng ta test trên Informix DBMS với một khối lượng công việc dựa trên các truy vấn 17 TPC-D (tất cả tần số xuất hiện là giống nhau). Các view bị phân mảnh được lựa chọn bởi phương tiện tiếp cận heuristic của 2 GB( 1GB cho các view chính + 1 GB cho các view thứ cấp); cụ thể hổ trợ trong [3] bằng việc xem xét không gian toàn cục; như kết quả 11 view thứ cấp được tạo ra, bên cạnh hai view chính. Thuật toán sự phân mảnh xác định 14 mảnh(3 từ các view chính) và 9 miniterm mất. Các chỉ mục trên tất cả thuộc tính thuộc về các khóa trong thực tế cả hai chiều và bản được tạo ra. Hình 2.4 với mỗi truy vấn tỉ lệ giữa số của các trang đĩa không được đọc và với sự phân mảnh; trên mỗi cột số của các trang đĩa đọc không có sự phân mảnh. Toàn bộ sự phân mảnh giảm chi phí khối lượng công việc từ 265.904 còn 59.986 trang (hơn 4 lần). Hình 2.4. Tỉ lệ giữa số trang đĩa đọc không có với sự phân mảnh Hình 2.5 sự phân mảnh ảnh hưởng như thế nào đến tổng không gian lưu trữ; trên mỗi cột, không gian lưu trữ không có sự phân mảnh. Tất cả view không phân mảnh yêu cầu 368.840 trang; trong khi cụ thể chỉ các mảnh(không mất các miniterm) giảm yêu cầu không giam xuống 306.042 trang(-17%), cụ thể cũng mất minterm tăng yêu cầu không gian đến 442.097 trang(+19,8%). Nên chú ý rằng view kế tiếp vượt trội 2 GB sẽ tốn 126.460 trang đĩa và giảm chi phí khối lượng công việc 1%; sự phân mảnh là thuận lợi hơn chỉ tốn 73.257 trang mở rộng và giảm chi phí 77%. Trong thực tế trong khi cụ thể hơn một view tiêu biểu ích lợi vài truy vấn. Vài truy vấn có lẽ là thuận lợi từ việc sử dụng cùng không gian đĩa cho sự phân mảnh. Hơn thế trong khi phân mảnh không yêu cầu mở rộng không gian cho chiều các bảng, mỗi một view mới có lẽ yêu cầu thêm các bộ vào các chiều các bảng được tham chiếu bởi kết tập các bộ trong view. Hình 2.5 Tỉ lệ giữa không gian lưu trữ có và không có sự phân mảnh Để mà đánh giá thuật toán phức tạp, chúng tôi có định nghĩa thêm bốn khối lượng công việc, mỗi tiến trình mở rộng TPC-D; kết quả hiển thị trong bảng I. Việc tính toán thời gian không phụ thuộc chặt chẽ kích thước khối lượng công việc, tất nhiên nó cũng xác định mối quan hệ giữa các truy vấn. Bảng I Các kết quả kiểm tra phức tạp n. truy vấn trong khối lượng công việc n.subproblems generated(vấn đề con phát sinh) Thời gian tính toán 17 2775 Khoảng 1 phút 25 4439 Khoảng 2 phút 30 348925 Khoảng 30 phút 35 51099 Khoảng 12 phút 40 403420 Khoảng 75 phút 3. Một trong hai phương pháp mới cho mô hình ROLAP Tóm tắt: Thiết kế lược đồ là một nguyên tắc cơ bản trong lý thuyết cơ sở dữ liệu cũng như trong thực tiễn. Trong bài báo này, chúng tôi thảo luận về vấn đề giá trị cục bộ các thuộc tính chiều trong hệ thống phân cấp của một kịch bản OLAP đặc trưng. Bước đầu, chúng tôi thấy rằng phương pháp lược đồ hình sao và bông tuyết truyền thống không thể thực thi trong trường hợp rất tự nhiên của hệ thống cấp bậc. Bởi vậy, chúng tôi phác thảo hai phương pháp mô hình có thể thay thế trong việc giải quyết vấn đề thực tế và sự mở rộng của phương pháp lược đồ hình sao và bông tuyết truyền thống. Trong phương pháp quan hệ thuần túy, chúng ta thay thế mỗi bảng chiều của lược đồ hình sao/bông tuyết bởi một tập các khung nhìn phân cấp tương ứng trực tiếp. Phương pháp thứ hai lợi dụng sự mở rộng của quan hệ đối tượng. Sử dụng các kĩ thuật của phương pháp object-relational trong ngữ cảnh về sự điển hình thường thấy của phương pháp kịch bản OLAP đa chiều là phương pháp mới lạ và đảm bảo thiết kế được lược đồ đúng đắn, linh hoạt. 3.1. Giới thiệu: Trong những năm qua, xử lý phân tích trực tuyến(OLAP) đã trở thành lĩnh vực nghiên cứu chủ yếu trong cộng đồng làm cơ sở dữ liệu(mô hình dữ liệu đặc biệt, SQL mở rộng). Một kết quả của cơn sốt OLAP là “làm trẻ lại” mô hình dữ liệu đa chiều. Phương pháp ROLAP (“Relational OLAP”) mô phỏng sự đa chiều và cho phép truy cập dữ liệu trên phương tiện cơ sở dữ liệu quan hệ. Theo cách đó sử dụng kĩ thuật của cơ sở dữ liệu quan hệ phức tạp để thao tác, tức là lưu trữ và phân tích các số lượng dữ liệu lớn của các kho dữ liệu cơ sở. Tuy nhiên phương pháp này cần một biểu diễn thường thấy phù hợp mà nó là một sự suy biến điển hình của lược đồ hình sao hoặc bông tuyết. Dựa trên cơ sở các kinh nghiệm từ các dự án công nghiệp, chúng tôi thấy rằng các kĩ thuật mô hình truyền thống cho giải pháp cơ sở dữ liệu quan hệ như lược đồ hình sao và bông tuyết, không luôn luôn phù hợp. Thậm chí khi xem xét những biến đổi phức tạp có liên quan tới những chiều thay đổi chậm , bảng thực tế,v.v..Trong ([Inmo96]), chúng tôi đã giải thích vấn đề còn tồn tại mà nó không được nói rõ trong tài liệu này. Trong bài báo này cân nhắc những vấn đề thiết kế lược đồ của chúng tôi với các kỹ thuật truyền thống và đề xuất hai phương pháp khái quát hơn đó là các phương pháp mô hình thay thế. Hình 3.1 Ví dụ sự phân loại cấp bậc Ý tưởng chính của mô hình đa chiều là mỗi chiều của khối dữ liệu đa chiều ví dụ như các sản phẩm, các cửa hàng, hoặc thời gian có thể được xem như là phần của khóa chính, tìm ra tích Đề các sản phẩm của các phần tử trong các chiều. Kết quả, sự kết hợp của khóa chính đa hợp xác định chính xác một đơn vị cơ bản đơn lẻ trong khối. Mỗi đơn vị cơ bản có thể nắm giữ một giá trị thực tế hoặc rỗng nếu nó không tồn tại. Như minh họa ở hình 3.1, trên cơ sở các phần tử của chiều, ví dụ như các hàng hóa đơn lẻ trong chiều sản phẩm, các sự phân loại có thể được định nghĩa để xác định các lớp C khác nhau như các product families, groups, hoặc các product areas, mỗi nút của sự phân loại ở mức phân loại cụ thể có thể được xem như một thể hiện của thuộc tính phân loại tương ứng(CAi) Hình 3.2: Ví dụ các thuộc tính chiều Thêm vào đó, các thuộc tính (DAk) của chiều như brand, color, shoptype, ..có thể được sử dụng để làm phức tạp thêm quá trình phân tích đa chiều. Như miêu tả ở hình 3.2, những thuộc tính này, đặc tả các phần tử mỗi chiều, là chuẩn có liên quan tới phân loại cấp bậc, phân loại các phần tử của chiều. Vì vậy, một câu hỏi tiêu biểu theo kịch bản mô hình đa chiều có thể được cho như sau: Cho tôi tổng mức tiêu thụ của người tiêu dùng hàng điện tử ở Châu Âu trong quý đầu của năm 1997 theo các nhãn hiệu khác nhau và các cửa hàng khác nhau. Một điều rất có giá trị ở đây là một cấu trúc với các thuộc tính chiều đặc biệt (tốt hơn:giá trị cục bộ) cho các lớp khác nhau trong sự phân loại phân cấp phản ảnh ý tưởng cơ bản của phân lớp. Ngoài ra còn có gì khác là lý do để phân loại? Các phân lớp thường sử đặc tính ẩn của các lớp con và thực hiện một quá trình trừu tượng đi từ các lớp con tới Siêu lớp(super-class). Chúng ta nghĩ rằng ý tưởng này nên được phản ánh thõa đáng trong thiết kế các lược đồ quan hệ của một kịch bản đa chiều. 3.2. Phương pháp ROLAP truyền thống: Để minh họa tình trạng không thích hợp của phương pháp ROLAP truyền thống và thúc đẩy phương pháp thay thế của chúng ta, chúng tôi đề cập đến một kịch bản ví dụ tiêu biểu , bắt nguồn từ một dự án nghiên cứu trên toàn thế giới của một công ty nghiên cứu hoạt động bán lẻ. Trong việc kinh doanh của họ, các thực thể như hàng bán được(sales) , hàng tồn kho(stock) hoặc giá trị doanh thu(turnover values)của các mặt hàng lẻ trong các cửa hàng lẻ ở một thời kỳ cụ thể của thời gian là được quản lý và thu thập tới mẫu cơ sở dữ liệu thô. Ví dụ như: Facts(ArticleID, ShopID, Period, SALES, STOCK, TURNOVER) TR-75 203 05/97 121 78 33 TS-78 203 05/97 112 63 121 ....... Nói chung, các cơ sở dữ liệu thô này thường có tên là bảng thực thể (fact table) và bao gồm hai thành phần chính: một tập của các chiều, chúng ta kí hiệu như thuộc tính chính ‘primary attributes’ PAi (1<=i<=n) tạo thành khóa chính hợp thành của bảng và một tập các dữ liệu {f1 ,…., fk} kí hiệu hình đang được phân tích. số lượng của các thuộc tính chính(n) xác định chiều của bài toán Facts(PA1,...,PAn,f1,..., fk) Ở mức khái quát hơn của mặt nghiên cứu đánh giá bán lẻ, các cơ sở dữ liệu thô được phân tích theo hai hướng: Theo hướng thứ nhất , dữ liệu được kết hợp lại theo sự phân loại cấp bậc được xác định trước(như trong hình 3.1). Theo hướng khác , dữ liệu được chia nhỏ theo các đặc điểm đặc trưng của các hàng hóa đơn lẻ hoặc các cửa hàng đơn lẻ. Ví dụ, mỗi cữa hàng nắm giữ thông tin cụ thể về các loại lợi nhuận hoặc kiểu cửa hàng của nó (“cash&carry”, “retail”, “hyper-market”). Theo chiều sản phẩm, mỗi hàng hóa của 250000 sản phẩm được quản lý thuộc 400 dòng sản phẩm. Hơn nữa mỗi sản phẩm được đặc tả bởi 5 giá trị thuộc tính cho tất cả các sản phẩm(nhãn-‘brand’, kiểu đóng gói-‘package type’,…) và khoảng 15 thuộc tính trong mỗi dòng hoặc nhóm sản phẩm(ví dụ chỉ có hệ thống video-‘video system’; mới thuộc nhóm công cụ video, ‘water’ sử dụng cho dòng sản phẩm máy giặt-‘Washer’). 3.2.1. Lược đồ hình sao: Cách truyền thống đơn giản nhất để mô hình bộ khung thông tin cần kiểm tra này được sử dụng trong suốt quá trình phân tích là sử dụng một bảng chiều đơn lẻ Di(1<=i<=n) cho mỗi chiều để giải quyết các mục mức cao trong hệ thống phân loại cấp và biểu diễn các thuộc tính chiều. Khi mỗi chiều được kết nối tới tương ứng khóa chính của bảng thực thể, kết quả của chúng trông như một hình sao. Hình 3.3 sẽ mô tả lược đồ hình sao cho ví dụ. Chính lược đồ của bảng chiều cho chiều i nó chứa thuộc tính chính PAi, tất cả các thuộc tính sự phân lớp CAj(1<=j<=p) và tập hoàn chỉnh của các thuộc tính chiều DAk(1<=k<=m). Di(PAi, DA1,….,DAm,CA1,….,CAp) Thật quan trọng để chú ý rằng sự phân loại theo cấp bậc được mô hình hóa như là một tập các thuộc tính phụ thuộc hàm(CAJ ->CAJ+1 (1<=J<=p)). Hơn nữa sự khác biệt của các phần tử chiều đã tổ chức trong hệ thống phân cấp và sự phân định đặc tính của các phần tử chiều một cách rõ ràng đã qui định trong mô hình đa chiều bị bỏ phí. Hình 3.4 biểu diễn bảng chiều sản phẩm cho ví dụ nghiên cứu thị trường. 3.2.2. Lược đồ bông tuyết: Hình 3.4 Ví dụ bảng chiều lược đồ hình sao cho chiều sản phẩm Sự loại bỏ các phụ thuộc hàm trong các bảng chiều đơn lẻ, nghĩa là lược đồ bông tuyết bình thường, dẫn tới các bảng vệ tinh nhỏ biểu diến lại dạng cấp bậc chiều. Do đó tập các bảng chiều cho một chiều đơn lẻ được mô hình hóa theo dạng sau: Nhắc lại PAi(1<=i<=n) kí hiệu thuộc tính chính cho chiều thứ i cho liên kết bảng thực thể. Thuộc tính phân lớp CAJ hình thành hệ thống cấp bậc hoạt động như một khóa ngoài trong trong phân lớp mức j-1 và như một khóa chính ở mức j. Hơn nữa tất cả các thuộc tính chiều DAK ở mức j là phụ thuộc hoàn toàn vào CAJ. Thông qua bảng chiều trên ví dụ, các thuộc tính phân lớp, ‘Group’ và ‘Area’ được đưa lên hai quan hệ mới. Lược độ quan hệ cho chiều sản phẩm của ví dụ này được mô tả ở hình 3.5: Hình 3.5: Ví dụ các bảng chiểu của lược đồ bông tuyết cho chiều sản phẩm. 3.2.3. Tóm tắt và kết luận: Phương pháp lược đồ hình sao/bông tuyết cho phép mô hình một phạm vi rộng các kịch bản đa chiều đơn lẻ. Từ việc biểu diễn View lược đồ hình sao đã tránh được các kết nối tìm kiếm ở các bảng vệ tinh nhưng nó có thể bị chỉ trích khi thiết kế lược đồ của View. Tuy nhiên cả hai phương pháp truyền thống đều không thành công với việc cài đặt và thiết kế lược đồ cho View nếu tồn tại các thuộc tính chiều phụ thuộc vào các giá trị các phần tử chiều trong hệ thống phân loại phân cấp. Như chúng ta thấy trong kịch bản nghiên cứu về thị trường, vấn đề này trở nên tồi tệ hơn, chẳng hạn chiều thuộc tính ‘Water’ và ‘Load’ chỉ nằm trong “washers” và không trong video equipment. Nên có thể lựa chọn thay phương pháp Relational OLAP. Với cách giải quyết của chúng tôi, chúng tôi thông qua ý tưởng đưa ra một lớp đặc biệt của các thuộc tính, được gọi là các thuộc tính chính(có suy xét). Những loại thuộc tính này nắm giữ các tên của quan hệ cũng như các giá trị thuộc tính của chúng, mà nó cho phép biểu diễn sự phân cấp thực của vấn đề ánh xạ thành hình chóp của các khái niệm (tức là sự phân cấp các lớp) cho mô hình dữ liệu quan hệ. Trong bước đầu, chúng tôi có thể mô hình mỗi nhóm sản phẩm, tức là nút lá của cây phân lớp, trong một quan hệ tồn tại riêng biệt với các thuộc tính chiều cụ thể của tất cả các nút. Ví dụ bốn dòng sản phẩm tiêu biểu từ hình 1 được mô hình như sau: Lược đồ của nút phân loại C ở mức thấp nhất, tức là mức phân loại 1 với thuộc tính CA1 được kí hiệu bởi: C(PA,DA1,…..,DAm) Thông thường, PA là thuộc tính chính cho liên kết với bảng thực thể và tập DAk(1<=k<=m) kí hiệu các thuộc tính chiều mà chúng được áp dụng ở nút C. Cách xây dựng hệ thống phân cấp được tạo theo kiểu từ dưới lên, tức là các tập của các nút được nhóm vào một mục ở mức mới cao hơn, tức là một nút phân cấp mới. Giả sử, trong bước thứ j, các nút {C1,…,Cq} với tập các thuộc tính chiều hợp lệ cục bộ {DA1i,……,DAmii} cho mỗi Ci tương ứng với thuộc tính phân loại CAJ-1 được xếp vào nút C ở mức cao hơn tương ứng với thuộc tính phân loại CAJ . Tập các thuộc tính chiều hợp lệ được hoàn thành bởi sự giao nhau của tất cả thuộc tính các tập của các nút gộp vào: Ví dụ, Camcorders và HomeVCR được phân vào lớp Video, Washers và Dryers được gộp vào bởi nút nút phân cấp cao hơn Home Appliances. Hơn nữa, chỉ các thuộc tính chiều đó truyền lại cho các nút cha mới, mà nó vẫn hợp lệ ở đó. Từ đó, các thuộc tính chiều riêng biệt ‘BLT’(cho Camcorder) và ‘RC’(cho HomeVCD)bị đánh mất, nhưng trái lại các thuộc tính ‘VSys’ và ‘Brand’ được truyền lại lớp Video. Nói chung, lược đồ của một nút phân loại mới C cho thuộc tính phân loại CAJ(1<j≤p) được làm rõ bởi công thức: C(PA,DA1,…,DAm, CA1,….,CAj-1,CAj)= Điểm then chốt của kỹ thuật này là mỗi nút phân cấp Ci được thêm như một giá trị hằng cho thuộc tính phân loại mới CAJ của nút phân loại mới C. Trong xây dựng các lớp ở mức cao hơn, chúng ta sử dụng cơ chế View của hệ thống cơ sở dữ liệu quan hệ ở vị trí cài đặt. Sau đây, các định nghĩa View của các nhóm sản phẩm Video và Home Appliances được miêu tả. Tương tự như mô tả hình thức, mỗi tên của quan hệ xuất hiện như một giá trị hằng trong View mới: Mỗi View nắm giữ thuộc tính chính, các thuộc tính chiều có thể ứng dụng và (tương tự như trong lược đồ hình sao)tất cả các thuộc tính phân loại. Hơn nữa, mỗi View xây dựng các nền tảng cho việc định nghĩa các nút phân loại ở cấp cao hơn. Việc định nghĩa một cách đệ quy này được minh họa như sau cho hệ thống phân loại phân cấp được mô tả trong hình sau: So sánh với phương pháp mô hình cổ điển(hình 3.4), chỉ những thuộc tính có giá trị trong bảng chiều mà nó được ứng dụng cho tất cả các phần tử chiều.Để địa chỉ chính xác các nét đặc trưng, các bảng chiều con tương ứng được sử dụng, mà các tên của chúng được cụ thể như các thể hiện của các thuộc tính phân loại. Hình 3.6 tóm tắt mô hình của sự phân loại phân cấp sử dụng cách hành động, được mô tả trong bài này. Tương tự hình 3.5(lược đồ bông tuyết), phương pháp của này cũng có thể được đơn giản hóa sự phức tạp. Hình 3.6: Bảng chiều tiêu biểu cho chiều sản phẩm (phương pháp thay thế) Để đặt nó vào bảng tóm tắt, trong trường hợp phương pháp cổ điển, câu truy vấn (vô nghĩa) như tìm tổng doanh thu của Home Appliances bởi ‘video system’ sẽ dẫn đến một sự tìm kiếm hết trên bảng chiều. Dẫn đến phần liên kết cho các bảng thực thể rỗng và cuối cùng là số 0. Trong phương pháp thay thế của chúng tôi, câu truy vấn trên sẽ bị loại bỏ vì Home Appliances không chứa trong chiều thuộc tính ‘video system’. 3.3. Cách thiết kế Object-Relational: Sự lựa chọn khác và cách tiếp cận mới để khắc phục hạn chế của lược đồ hình sao/ bông tuyết truyền thống là sử dụng kỹ thuật Object-relational. Từ khi các khái niệm Object-relational được hỗ trợ về nội dung và cài đặt theo cách rất cụ thể-hệ thống, chúng tôi đưa ra cách thiết kế một lược đồ Object-relational trên cơ sở khả năng của hệ thống cơ sở dữ liệu DB2/UDB của IBM. Thiết kế một lược đồ Object-relational trong DB2 được chia thành hai giai đoạn. Bước thứ nhất, chúng tôi phải xác định phân loại kiểu và những tham chiếu dựa trên các kiểu. Dựa theo những kiểu này, chúng tôi có thể tạo đối tượng các bảng đầy đủ(cũng có thể xem là: Bảng Types). Ngoài ra, đối lập với phương pháp đưa ra trong phần trước, chúng tôi phải theo tiến trình từ trên xuống khi định nghĩa lược đồ object-relational của các cấu trúc chiều. 3.3.1. Định nghĩa kiểu: Siêu kiểu của một chiều chỉ nắm giữ các thuộc tính chiều chung nhất và tất cả các thuộc tính phân loại có thể. Cho ví dụ vào của chiều sản phẩm, câu lệnh DDL sau khai báo kiểu chung của Articles_T, mà ở đó các hàng hóa đơn lẻ được xác định bởi thuộc tính ArticleID. Create type Articles_T as (brand varchar(30)), Area varchar(30), Group varchar(30), Family varchar(30)); Tương tự như k