Phương pháp mô hình ROLAP mới

MỘT PHƯƠNG PHÁP MÔ HÌNH ROLAP MỚI 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. 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 đx 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 2.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 2.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 2.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 2.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. 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 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ửa hàng đơn lẻ. Ví dụ, mỗi cữa hàng nắm giữ thông tin của địa bàn riêng về lợi nhuận hàng năm hoặc loại cửa hàng(“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’). 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 2.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) Hình 2.3: Ví dụ lược đồ hình sao Thật có ý nghĩa để 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 được sắp xếp trong hệ thống phân cấp và các thuộc tính chiều phân định đặc tính của phần tử được mô tả một cách rõ ràng trong mô hình đa chiều đánh mất hoàn toàn. Hình 2.4 biểu diễn bảng chiều sản phẩm cho ví dụ nghiên cứu thị trường. Hình 2.4 Ví dụ bảng chiều lược đồ hình sao cho chiều sản phẩm 2.2. Lược đồ bông tuyết: 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 2.5: Hình 2.5: Ví dụ các bảng chiểu của lược đồ bông tuyết cho chiều sản phẩm. 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à discriminating attributes. 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 một biểu diễn phân cấp thực của bài toán đã ánh xạ thành hình chóp của các khái niệm (tức là sự phân loại phân cấp) tới 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 một nút phân C ở thấp nhất, tức là mức 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 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, sự 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ình1: So sánh với phương pháp mô hình cổ điển(hình 2.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 2.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 2.5(lược đồ bông tuyết), phương pháp của chúng tôi cũng có thể được bình thường hóa sự phức tạp. Hình 2.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. 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 cấp bậc kiểu và những tham chiếu dựa trên các kiểu. Tiếp 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 quá 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.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 (brandvarchar(30)), Area varchar(30), Group varchar(30), Family varchar(30)); Tương tự như khái niệm cổ điển của kết thừa, các lớp cụ thể của các sản phẩm được suy ra từ các lớp khái quát hơn của các sản phẩm và các thuộc tính cụ thể của chiều được thêm vào kiểu được suy ra. Sau đây là các lệnh SQL để định nghĩa các kiểu con cần thiết của sản phẩm trong hệ thống phân cấp. Đối với mỗi kiểu con, từ khóa UNDER kí hiệu Siêu kiểu tương ứng. create type ConsElectr_T under Articles_T as ( ... ); create type WhiteGoods_T under Articles_T as ( ... ); create type Video_T under ConsElectr_T as(vidsysvarchar(30) ); create type HomeAppl_T under WhiteGoods_T as(loadvarchar(30) ); create type HomeVCR_T under Video_T as (RC char(1) ); create type Camcorder_T under Video_T as (BLT varchar(5) ); create type Washer_T under HomeAppl_T as (Water varchar(5) ); create type Dryer_T under HomeAppl_T as (Temp short) ; Một khi chúng tôi định nghĩa các kiểu của cấu trúc chiều, ví dụ cho chiều Products và chiều Shops, chúng tôi có thể tạo một kiểu cho bản thực thể. Mặc dù điều này không là bắt buộc để thiết kế lược đồ của bảng thực thể sử dụng công nghệ của Object-relational, nhưng chúng ta có thể đạt được các lợi ích khi truy vấn cớ sở dữ liệu sau này. Do đó kiểu của bảng thực thể chứa hai tham chiếu tới các Siêu kiểu của các chiều tham gia. create type Facts_T as ( ArticleID REF(Articles_T), ShopID REF(Shops_T), Period date, Sales integer, Stock integer, Price integer); Sự xây dựng bảng này rất có giá trị vì nó tạo ra được các tiện ích sau: Xem xét vị trí mà chúng ta cài đặt chợ dữ liệu cho một nhóm sản phẩm cụ thể, ví dụ video equipment. Bây giờ chúng ta có thể tạo một kiểu của một bảng thực thể tùy ý cho phép chỉ tham chiếu tới các hàng hóa thuộc lớp video. Do đó chúng ta sẽ thay thế tham chiếu tới kiểu các hàng hóa khái quát bằng một tham chiếu tới kiểu cụ thể của Video_T (... ArticleID REF(Video_T), ...). Cách thiết kế này chắc chắn ở mức lược đồ đã có rằng bảng thực thể cho chợ dữ liệu này sẽ không bao giờ chứa sản phẩm khác hàng hóa Video. 3.2 Các định nghĩa Bảng Typed: Một khi chúng tôi định nghĩa đươc phân cấp kiểu cho lược đồ phân loại, chúng tôi ở thế tạo đối tượng, các kiểu này cũng cho kết quả đươc gọi là bảng Typed. Tương tự như định nghĩa kiểu, chúng tôi theo quá trình từ trên xuống. Để minh họa về Siêu kiểu, chúng ta cần đưa ra một thuộc tính định danh đối tượng. Ví dụ tiếp theo, chúng ta sử dụng ArticleID như thuộc tính tham chiếu (hoặc thuộc tính khóa chính trong thuật ngữ quan hệ), mà nội dung của nó được cho như người sử dụng đã phát sinh(trái ngược với hệ thống phát sinh). Tất cả các bảng con phụ thuộc được tạo ra theo kiểu của chúng và tham chiếu tới Siêu khóa trực tiếp của chúng. create table Articles of Articles_T (REF IS ArticleID user generated); create table ConsElectr of ConsElectr_T under Articles inherit select privileges; create table WhiteGoods of WhiteGoods_T under Articles inherit select privileges; create table Video of Video_T under ConsElectr inherit select privileges; create table HomeAppl of HomeAppl_T under WhiteGoods inherit select privileges; create table HomeVCR of HomeVCRF_T under Video inherit select privileges; create table Camcorder of Camcorder_T under Video inherit select privileges; create table Washer of Washer_T under HomeAppl inherit select privileges; create table Dryer of Dryer_T under HomeAppl inherit select privileges; Một lần nữa ta có thể thấy sự xây dựng này rất có giá trị vì nó cung cấp thuận lợi to lớn cho việc giải quyết các chiều thay đổi. Xem xét lại chiều sản phẩm. Các hàng hóa mới có thể được thêm, một số hàng hóa có thể bị phân loại lại và các sản phẩm khác có thể bị xóa bởi vì chúng không còn được bán nữa hoặc việc bán của chúng không còn được theo dõi. Tuy nhiên vì tất cả các hàng hóa của cùng kiểu, chúng ta có thể đơn giản tạo đối tượng một kiểu cụ thể nhiều lần. Mỗi bảng kết quả phản ánh trạng thái phù hợp của một hệ thống phân cấp và có thể được sử dụng để phân tích dữ liều thực thể theo chiều thời gian phù hợp nào đó. Sau khi tạo ra các phân cấp chiều, chúng tôi tạo đối tượng bảng thực thể từ kiểu Facts_T. Hai khía cạnh phải được xem xét một cách rõ ràng. Trước hết mỗi thực thể nhận một định danh đối tượng phát sinh của một hệ thống. Mỗi tham chiếu được trỏ tới một bảng thích hợp, ví dụ như: ArticleID thì tham chiếu bảng Articles,không còn kiểu Articles_T nữa. create table Facts of Facts_T (ref is FactID system generated, ArticleID with options scope Articles, ShopID with options scope Shops); 3.3 Thao tác dữ liệu: Thiết kế theo mô hình OR của kho dữ liệu cơ sở dữ liệu cũng có một số tác động đến thao tác dữ liệu. Xét một câu lệnh chèn đơn giản vào chiều sản phẩm. Sự khác nhau duy nhất với thao tác chèn của quan hệ thuần túy là gộp vào của chứng thực hàng hóa tới bộ phận xác định chứng thực đối tượng cụ thể. Sau đây là một ví dụ về một hàng hóa camcorder và một Dryer. insert into Camcorders ( ArticleID, brand, vidsys, blt, family, group, area) values (Camcorders_T(’TR-75’), ’Sony’, ’HI8’, ’2h’, ’Camcorder’, ’Video’, ’ConsElectr’); insert into Dryers ( ArticleID, brand, load, temp, family, group, area) values (Dryers_T(’Duett’), ’Miele’, ’6kg’, ’37oC’, ’Dryer’, ’HomeAppl’, ’WhiteGoods’); Để đảm bảo sự ổn định của các tham chiếu, bây giờ chúng tôi có thể chèn các thực thể vào bảng thực thể. Một lần nữa chúng ta phải gộp các giá trị của các tham chiếu tới kiểu các bảng chiều tương ứng của chúng, nghĩa là các chứng thực hàng hóa được gộp vào Articles_T , các tên cửa hàng được gộp vào Shops_T. insert into Facts (FactID, ArticleID, ShopID, Period, Sales, Stock, Price) values (Facts_T(’1’), Article_T(’TR-75’), Shops_T(’TeVi’), ’1999-12-02’, 45, 22, 998); Khi truy vấn cơ sở dữ liệu chúng ta có thể tận dụng các tham chiếu mà chúng có thể được hình dung như các đường dẫn liên kết cài đặt sẵn. Cho ví dụ, nhóm dữ liệu thực thể theo khu vực(từ bảng các Shop) và các nhóm các sản phẩm (từ bảng các Article) có thể được sử dụng cụ thể kí hiệu ’->’ mà không có bất cứ một liên kết rõ ràng nào. select f.ShopID->region, f.ArticleID->group, SUM(sales) from Facts f group by f.ShopID->region, f.ArticleID->group Tuy nhiên, chúng tôi không khôi phục lại các thuộc tính cụ thể sử dụng thiết lập này. Nhóm theo Video Systems cho tất cả video equipment sẽ được biểu diễn với ’Video’ như bảng chiều chính xác như sau: select f.ShopID->region, a.vidsys, SUM(sales) from Facts f, Articles a where f.ArticleID = a.ArticleID group by f.ShopID->region, a.vidsys Trong bản tóm tắt, kỹ thuật object-relational cung cấp một công cụ mạnh mẽ cho việc thiết kế lược đồ trong các môi trường kho dữ liệu. Đặc biệt là thiết kế một hệ thống phân cấp thực với các thuộc tính chiều và sự phân loại tìm ra một miêu tả phù hợp sử dụng các kỹ thuật thừa kế các kiểu và các bảng kiểu. Mở rộng sự biểu diễn object-relational cho bảng thực thể cho phép người thiết kế xác định một số loại cấu trúc khó khăn ở cấp độ lược đồ. 4. Tóm tắt và kết luận: Bài báo này nói về vấn đề các thuộc tính chiều hợp lệ trong hệ thống phân cấp trong bối cảnh thiết kế lược đồ đa chiều. Chúng tôi chứng tỏ rằng phương pháp truyền thống của một mô hình quan hệ là không khả thi và đưa ra hai phương pháp khả thi cho vấn đề này. Ý tưởng chính của kỹ thuật được đề xuất thứ nhất là dựa trên the article of [SmSm77] . Xây dựng một hình tháp các khái niệm theo cách từ dưới lên sử dụng thường xuyên các khung nhìn(Views) quan hệ có thể được xem như sự mở rộng hoàn hảo của phương pháp lược đồ hình sao hoặc bông tuyết. Phương pháp thứ hai kiểu từ trên xuống được dựa trên các kỹ thuật object-relational . Chúng tôi giải thích vấn đề này bằng cách sử dụng các khái niệm của object- relational như: Các kiểu, các typed subtable, kế thừa trên các kiểu và các bảng, và các tham chiếu. Nhắc lại phương pháp này cho phép thiết kế một lược đồ linh hoạt.