Rate this post

Khi dữ liệu được nhóm hoặc kết hợp trong ma trận nhiều chiều được gọi là Data Cubes. Phương thức Data Cube có một vài tên thay thế hoặc một vài biến thể, chẳng hạn như “Cơ sở dữ liệu đa chiều”, “chế độ xem cụ thể hóa” và “OLAP (Xử lý phân tích trực tuyến).”

Ý tưởng chung của phương pháp này là thực hiện một số phép tính đắt tiền thường được yêu cầu.

Các bài viết liên quan:

    Ví dụ: mối quan hệ với doanh số bán hàng trong lược đồ (bộ phận, nhà cung cấp, khách hàng và giá bán) có thể được cụ thể hóa thành một tập hợp tám chế độ xem như được hiển thị trong hình, trong đó psc chỉ ra một chế độ xem bao gồm giá trị hàm tổng hợp (chẳng hạn như tổng- bán hàng) được tính bằng cách nhóm ba phần thuộc tính, nhà cung cấp và khách hàng, p chỉ ra một chế độ xem bao gồm các giá trị hàm tổng hợp tương ứng được tính bằng cách nhóm riêng phần, v.v.

    Một Data Cube được tạo từ một tập hợp con các thuộc tính trong cơ sở dữ liệu. Các thuộc tính cụ thể được chọn làm thuộc tính đo lường, tức là các thuộc tính có giá trị được quan tâm. Các thuộc tính khác được chọn làm thứ nguyên hoặc thuộc tính chức năng. Các thuộc tính đo lường được tổng hợp theo các kích thước.

    Ví dụ: XYZ có thể tạo một kho dữ liệu bán hàng để lưu giữ hồ sơ về doanh số của cửa hàng cho các thứ nguyên về thời gian, mặt hàng, chi nhánh và địa điểm. Những thứ nguyên này cho phép cửa hàng theo dõi những thứ như doanh thu bán hàng hàng tháng của các mặt hàng cũng như các chi nhánh và địa điểm mà tại đó các mặt hàng đã được bán. Mỗi thứ nguyên có thể có một bảng đồng nhất với nó, được gọi là bảng thứ nguyên, mô tả các thứ nguyên. Ví dụ: bảng thứ nguyên cho các mặt hàng có thể chứa các thuộc tính item_name, brand và type.

    Phương pháp Data Cube là một kỹ thuật thú vị với nhiều ứng dụng. Các Data Cube có thể thưa thớt trong nhiều trường hợp vì không phải mọi ô trong mỗi chiều đều có thể có dữ liệu tương ứng trong cơ sở dữ liệu.

    Các kỹ thuật nên được phát triển để xử lý các hình khối thưa thớt một cách hiệu quả.

    Nếu một truy vấn chứa các hằng số ở cấp độ thậm chí thấp hơn những hằng số được cung cấp trong Data Cube, thì không rõ làm thế nào để sử dụng tốt nhất các kết quả được tính toán trước được lưu trữ trong Data Cube.

    Mô hình xem dữ liệu dưới dạng một Data Cube. Các công cụ OLAP dựa trên mô hình dữ liệu đa chiều. Các Data Cube thường mô hình hóa dữ liệu n chiều.

    Một Data Cube cho phép dữ liệu được mô hình hóa và xem theo nhiều chiều. Mô hình dữ liệu đa chiều được tổ chức xung quanh chủ đề trung tâm, như bán hàng và giao dịch. Một bảng thông tin đại diện cho chủ đề này. Dữ kiện là các thước đo bằng số. Do đó, bảng dữ kiện chứa số đo (chẳng hạn như Rs_sold) và các khóa cho mỗi bảng chiều liên quan.

    Kích thước là một thực tế xác định một Data Cube. Dữ kiện nói chung là các đại lượng, được sử dụng để phân tích mối quan hệ giữa các thứ nguyên.

    Ví dụ: Trong biểu diễn 2-D, chúng tôi sẽ xem xét dữ liệu bán hàng của Tất cả các thiết bị điện tử cho các mặt hàng được bán mỗi quý ở thành phố Vancouver. Màn hình được đo bằng đô la đã bán (hàng nghìn).

    3-Dimensional

    Giả sử chúng ta muốn xem dữ liệu bán hàng bằng thứ nguyên thứ ba. Ví dụ: giả sử chúng tôi muốn xem dữ liệu theo thời gian, mục cũng như vị trí cho các thành phố Chicago, New York, Toronto và Vancouver. Màn hình được đo bằng đô la đã bán (hàng nghìn). Dữ liệu 3-D này được hiển thị trong bảng. Dữ liệu 3-D của bảng được biểu diễn dưới dạng một chuỗi các bảng 2-D.

    Về mặt khái niệm, chúng ta có thể biểu diễn cùng một dữ liệu dưới dạng các Data Cube 3-D, như thể hiện trong hình:

    Giả sử rằng chúng tôi muốn xem dữ liệu bán hàng của mình với một chiều thứ tư bổ sung, chẳng hạn như nhà cung cấp.

    Trong kho dữ liệu, các Data Cube là n chiều. Hình khối chứa mức tổng hợp thấp nhất được gọi là hình khối cơ sở.

    Ví dụ: hình khối 4-D trong hình là hình khối cơ sở cho các kích thước thời gian, mặt hàng, vị trí và nhà cung cấp đã cho.

    Hình được hiển thị là Data Cube 4-D đại diện cho dữ liệu bán hàng, theo kích thước thời gian, mặt hàng, địa điểm và nhà cung cấp. Số đo được hiển thị là đô la được bán (tính theo hàng nghìn).

    Hình khối 0-D trên cùng, có mức tổng hợp cao nhất, được gọi là hình khối đỉnh. Trong ví dụ này, đây là tổng doanh số hoặc đô la đã bán, được tóm tắt trên cả bốn thứ nguyên.

    Mạng tinh thể của hình khối tạo thành một Data Cube. Hình bên cho thấy mạng lưới các khối lập phương tạo ra các Data Cube 4-D cho thứ nguyên thời gian, mặt hàng, vị trí và nhà cung cấp. Mỗi hình khối đại diện cho một mức độ tóm tắt khác nhau.

    Xem thêm Hướng dẫn Data mining- kiến thức về data mining

    Tính toán khối Cube dữ liệu hiệu quả

    Cốt lõi của phân tích dữ liệu đa chiều là tính toán hiệu quả các tổng hợp trên nhiều tập hợp kích thước. Theo thuật ngữ SQL, những tập hợp này được gọi là từng nhóm một. Mỗi nhóm nhỏ có thể được biểu diễn bằng một Cube, trong đó tập hợp các nhóm nhỏ tạo thành một mạng hình khối xác định một khối dữ liệu. Trong tiểu mục này, chúng tôi khám phá các vấn đề liên quan đến việc tính toán hiệu quả các khối dữ liệu.

    Toán tử Cube tính toán và Lời nguyền của chiều không gian

    Một cách tiếp cận đối với tính toán Cube mở rộng SQL để bao gồm một công cụ tính toán Cube. Toán tử Cube tính toán tổng hợp trên tất cả các tập hợp con của các kích thước được chỉ định trong phép toán. Điều này có thể yêu cầu quá nhiều không gian lưu trữ, đặc biệt là đối với số lượng kích thước lớn. Chúng tôi bắt đầu với một cái nhìn trực quan về những gì liên quan đến việc tính toán hiệu quả các khối dữ liệu.

    Một khối dữ liệu là một mạng lưới các Cube. Giả sử rằng bạn muốn tạo một khối dữ liệu cho doanh số bán hàng chứa các thông tin sau: thành phố, mặt hàng, năm và doanh số tính bằng đô la. Bạn muốn có thể phân tích dữ liệu, với các truy vấn như sau:

    “Tính tổng doanh số, phân nhóm theo thành phố và mặt hàng.” “Tính tổng doanh số, phân nhóm theo thành phố.” “Tính tổng doanh số, phân nhóm theo mặt hàng.”

    Tổng số Cube, hoặc theo từng nhóm, có thể được tính cho khối dữ liệu này là bao nhiêu? Lấy ba thuộc tính, thành phố, mặt hàng và năm, làm thứ nguyên cho khối dữ liệu và doanh số tính bằng đô la làm thước đo, tổng số Cube hoặc theo từng nhóm, có thể được tính cho khối dữ liệu này là 23 8 . Các nhóm có thể có như sau: (thành phố, mặt hàng, năm), (thành phố, mặt hàng), (thành phố, năm), (mặt hàng, năm), (thành phố), (mặt hàng), (năm), () , trong đó () có nghĩa là từng nhóm trống (tức là các thứ nguyên không được nhóm lại).

    Hình trên: Mạng Cube, tạo nên khối dữ liệu 3-D. Mỗi hình khối đại diện cho một nhóm khác nhau. Hình khối cơ sở chứa các kích thước thành phố, mục và năm.

    Hình khối cơ sở chứa cả ba thứ nguyên, thành phố, mục và năm. Nó có thể trả về tổng doanh số cho bất kỳ sự kết hợp nào của ba thứ nguyên. Cube đỉnh, hoặc Cube 0-D, đề cập đến trường hợp từng nhóm là trống. Nó chứa tổng cộng của tất cả các lần bán hàng.

    Hình khối cơ sở là hình khối ít khái quát nhất (cụ thể nhất) trong số các hình khối. Hình khối đỉnh là hình khối có tính khái quát cao nhất (ít cụ thể nhất) trong số các hình khối và thường được ký hiệu là tất cả. Nếu chúng ta bắt đầu từ khối chóp và khám phá xuống dưới trong mạng tinh thể, điều này tương đương với việc đi sâu vào bên trong khối dữ liệu. Nếu chúng ta bắt đầu từ hình khối cơ sở và khám phá hướng lên trên, điều này giống như cuộn lên.

    Truy vấn SQL không chứa từng nhóm (ví dụ: “tính tổng doanh số bán hàng”) là một phép toán không chiều. Truy vấn SQL chứa từng nhóm một (ví dụ: “tính tổng doanh số, từng nhóm theo thành phố”) là một hoạt động một chiều. Một toán tử Cube trên n kích thước tương đương với một tập hợp các câu lệnh theo nhóm, một cho mỗi tập con của n dimen. Do đó, toán tử Cube là tổng quát hóa n chiều của toán tử từng nhóm.

    Vật liệu hóa từng phần: Tính toán được chọn lọc của các hình khối

    Có ba lựa chọn để thực hiện hóa khối dữ liệu với một khối cơ sở:

    1. No materialization: Không tính toán trước bất kỳ hình khối “nonbase” nào. Điều này dẫn đến việc tính toán các tổng hợp đa chiều đắt tiền khi đang di chuyển, có thể cực kỳ chậm.
    2. Full materialization: Tính toán trước tất cả các hình khối. Mạng tinh thể kết quả của các hình lập phương hợp thành được gọi là hình lập phương đầy đủ. Lựa chọn này thường yêu cầu một lượng lớn không gian bộ nhớ để lưu trữ tất cả các hình khối được tính toán trước.
    3. Partial materialization: Tính toán một cách có chọn lọc một tập hợp con thích hợp của toàn bộ tập hợp các hình khối có thể xác định. Ngoài ra, chúng tôi có thể tính toán một tập hợp con của Cube, chỉ chứa những ô đáp ứng một số tiêu chí do người dùng chỉ định, chẳng hạn như trong đó số lượng bộ của mỗi ô cao hơn một số ngưỡng. Chúng ta sẽ sử dụng thuật ngữ hình lập phương con để chỉ trường hợp thứ hai, trong đó chỉ một số ô có thể được tính toán trước cho các hình khối khác nhau. Việc vật chất hóa từng phần thể hiện sự cân bằng thú vị giữa không gian lưu trữ và thời gian phản hồi.

    Việc hiện thực hóa một phần hình khối hoặc ống con cần xem xét ba yếu tố:

    1. Xác định tập hợp con của hình khối hoặc ống con để hiện thực hóa;
    2. Khai thác các hình khối hoặc ống con cụ thể hóa trong quá trình xử lý truy vấn; và
    3. Cập nhật hiệu quả các hình khối hoặc ống con được vật liệu hóa trong quá trình tải và làm mới.

    Việc lựa chọn tập hợp con các hình khối hoặc ống con để hiện thực hóa cần tính đến các truy vấn trong khối lượng công việc, tần suất của chúng và chi phí truy cập của chúng. Ngoài ra, cần xem xét các đặc điểm khối lượng công việc, chi phí cho các bản cập nhật gia tăng và tổng yêu cầu lưu trữ.

    Việc lựa chọn cũng phải xem xét bối cảnh rộng lớn của thiết kế cơ sở dữ liệu vật lý như việc tạo và lựa chọn các chỉ số. Một số sản phẩm OLAP đã áp dụng các phương pháp tiếp cận heuristic để lựa chọn hình khối và hình khối con. Một cách tiếp cận popular là hiện thực hóa tập hợp các Cube mà các Cube thường được tham chiếu khác dựa trên đó. Ngoài ra, chúng ta có thể tính toán khối tảng băng trôi, là khối dữ liệu chỉ lưu trữ các ô khối đó có giá trị tổng hợp (ví dụ: số lượng) cao hơn một số ngưỡng hỗ trợ tối thiểu.

    Một chiến lược phổ biến khác là hiện thực hóa một khối vỏ. Điều này liên quan đến việc tính toán trước các Cube chỉ cho một số kích thước nhỏ (ví dụ: ba đến năm) của khối dữ liệu. Các truy vấn về các kết hợp bổ sung của các thứ nguyên có thể được tính toán nhanh chóng. Bởi vì mục tiêu của chúng tôi trong chương này là cung cấp một giới thiệu vững chắc và tổng quan về Data Warehouse để khai thác dữ liệu, chúng tôi hoãn thảo luận chi tiết về lựa chọn và tính toán Cube sang Chương 5, chương này nghiên cứu sâu hơn các phương pháp tính toán khối dữ liệu khác nhau.

    Bài viết khác:

    Khi các hình khối được chọn đã được hiện thực hóa, điều quan trọng là phải tận dụng chúng trong quá trình xử lý truy vấn. Điều này liên quan đến một số vấn đề, chẳng hạn như cách xác định (các) Cube có liên quan trong số các Cube ứng viên, cách sử dụng các cấu trúc chỉ mục có sẵn trên các Cube được vật chất hóa và cách chuyển đổi các toán hạng OLAP thành (các) Cube đã chọn .

    Cuối cùng, trong quá trình tải và làm mới, các hình khối cụ thể hóa sẽ được cập nhật một cách hiệu quả. Cần khám phá kỹ thuật song song và cập nhật gia tăng cho hoạt động này.

    Lập chỉ mục Dữ liệu OLAP: Chỉ mục Bitmap và Join index

    Để tạo điều kiện truy cập dữ liệu hiệu quả, hầu hết các hệ thống Data Warehouse đều hỗ trợ cấu trúc chỉ mục và các khung nhìn cụ thể hóa (sử dụng hình khối). Trong mục này, chúng tôi kiểm tra cách lập chỉ mục dữ liệu OLAP bằng cách lập chỉ mục bitmap và lập chỉ mục tham gia.

    Phương pháp lập chỉ mục bitmap phổ biến trong các sản phẩm OLAP vì nó cho phép tìm kiếm nhanh trong các khối dữ liệu. Chỉ mục bitmap là một đại diện thay thế của danh sách ID bản ghi (RID). Trong chỉ mục bitmap cho một thuộc tính nhất định, có một vectơ bit riêng biệt, Bv, cho mỗi giá trị v trong miền của thuộc tính. Nếu miền của thuộc tính nhất định chứa n giá trị thì cần n bit cho mỗi mục nhập trong chỉ mục bitmap (tức là có n vectơ bit). Nếu thuộc tính có giá trị v cho một hàng nhất định trong bảng dữ liệu, thì bit đại diện cho giá trị đó được đặt thành 1 trong hàng tương ứng của chỉ mục bitmap. Tất cả các bit khác cho hàng đó được đặt thành 0.

    Indexing OLAP Data

    Ví dụ: Trong Data Warehouse, giả sử mục thứ nguyên ở cấp cao nhất có bốn giá trị (đại diện cho các loại mục): “giải trí gia đình”, “computer”, “điện thoại” và “bảo mật”. Mỗi giá trị (ví dụ: “máy tính”) được biểu thị bằng một vectơ bit trong bảng chỉ mục bitmap mục.

    Giả sử rằng Cube được lưu trữ dưới dạng một bảng quan hệ với 100.000 hàng. Bởi vì miền của mục bao gồm bốn giá trị, bảng chỉ mục bitmap yêu cầu bốn vectơ bit (hoặc danh sách), mỗi vectơ có 100.000 bit.

    Hình dưới cho thấy một bảng cơ sở (dữ liệu) chứa mục kích thước và thành phố, và ánh xạ của nó tới các bảng chỉ mục bitmap cho từng thứ nguyên.

    Lập chỉ mục dữ liệu OLAP bằng chỉ số bitmap.

    Lập chỉ mục bitmap có lợi thế hơn so với chỉ số băm và chỉ số cây. Nó đặc biệt hữu ích cho các miền có thẻ số thấp vì các toán hạng so sánh, nối và tổng hợp sau đó được giảm xuống số học bit, điều này làm giảm đáng kể thời gian xử lý. Lập chỉ mục bitmap dẫn đến giảm đáng kể không gian và đầu vào / đầu ra (I / O) vì một chuỗi ký tự có thể được biểu diễn bằng một bit duy nhất. Đối với các miền có bản số cao hơn, phương pháp này có thể được điều chỉnh bằng cách sử dụng các kỹ thuật nén.

    Phương pháp lập chỉ mục nối đã trở nên phổ biến từ việc sử dụng nó trong xử lý truy vấn cơ sở dữ liệu quan hệ. Lập chỉ mục truyền thống ánh xạ giá trị trong một cột nhất định vào danh sách các hàng có giá trị đó. Ngược lại, tham gia lập chỉ mục đăng ký các hàng có thể nối của hai quan hệ từ một cơ sở dữ liệu quan hệ. Ví dụ: nếu hai quan hệ R (RID, A) và S (B, SID) tham gia vào các thuộc tính A và B, thì bản ghi chỉ mục kết hợp chứa cặp (RID, SID), trong đó RID và SID là các định danh bản ghi từ Các quan hệ R và S, tương ứng. Do đó, các bản ghi chỉ mục nối có thể xác định các bộ giá trị có thể nối mà không cần thực hiện các thao tác nối tốn kém. Lập chỉ mục tham gia đặc biệt hữu ích để duy trì mối quan hệ giữa khóa ngoại và các khóa chính phù hợp của nó, từ quan hệ có thể nối.

    Mô hình giản đồ hình sao của Data Warehouse làm cho việc lập chỉ mục liên kết trở nên hấp dẫn đối với tìm kiếm trên nhiều bảng, vì liên kết giữa bảng dữ kiện và các bảng thứ nguyên tương ứng của nó bao gồm khóa ngoại của bảng dữ liệu và khóa chính của bảng thứ nguyên. Kết hợp lập chỉ mục duy trì mối quan hệ giữa các giá trị thuộc tính của một thứ nguyên (ví dụ: trong bảng thứ nguyên) và các hàng tương ứng trong bảng dữ kiện. Các chỉ số tham gia có thể trải dài nhiều thứ nguyên để tạo thành các chỉ số kết hợp tổng hợp. Chúng tôi có thể sử dụng các chỉ số tham gia để xác định các ống con được quan tâm.

    Join index

    Chúng tôi đã xác định giản đồ hình sao cho AllElectronics có dạng “sao bán hàng [thời gian, mặt hàng, chi nhánh, địa điểm]: tổng số tiền bán được (doanh thu tính bằng đô la)”. Kiểm tra mối quan hệ chỉ số kết hợp giữa bảng dữ kiện bán hàng với các bảng kích thước vị trí và mặt hàng được thể hiện trong Hình 4.16. Ví dụ: giá trị “Main Street” trong bảng thứ nguyên vị trí kết hợp với các bộ T57, T238 và T884 của bảng thông số bán hàng. Tương tự, giá trị “Sony-TV” trong bảng kích thước mặt hàng kết hợp với các bộ giá trị T57 và T459 của bảng thông số bán hàng.

    Tham gia các bảng chỉ mục dựa trên các liên kết giữa bảng thông tin bán hàng với vị trí và mặt hàng.

    Giả sử rằng có 360 giá trị thời gian, 100 mặt hàng, 50 chi nhánh, 30 địa điểm và 10 triệu bộ giá trị bán hàng trong khối dữ liệu sao bán hàng. Nếu bảng thực tế bán hàng chỉ ghi nhận doanh số bán hàng cho 30 mặt hàng, 70 mặt hàng còn lại rõ ràng sẽ không tham gia vào các lần tham gia. Nếu chỉ số kết hợp không được sử dụng, I / O bổ sung phải được thực hiện để kết hợp các phần tham gia của bảng dữ kiện và bảng thứ nguyên lại với nhau.

    Để tăng tốc hơn nữa việc xử lý truy vấn, lập chỉ mục liên kết và các phương pháp lập chỉ mục bitmap có thể được tích hợp để tạo thành các chỉ số liên kết được ánh xạ bit.

    Xử lý hiệu quả các truy vấn OLAP

    Mục đích của việc hiện thực hóa hình khối và xây dựng cấu trúc chỉ mục OLAP là để tăng tốc độ xử lý truy vấn trong khối dữ liệu. Với các chế độ xem cụ thể hóa, quá trình xử lý truy vấn sẽ được tiến hành như sau:

    1. Xác định thao tác nào nên được thực hiện trên các cube có sẵn: Điều này liên quan đến việc chuyển đổi bất kỳ thao tác chọn, chiếu, cuộn lên (từng nhóm) và chi tiết được chỉ định trong truy vấn thành các thao tác SQL và / hoặc OLAP tương ứng. Ví dụ, cắt và cắt một khối dữ liệu có thể tương ứng với các thao tác lựa chọn và / hoặc chiếu trên một Cube được vật chất hóa.

    2. Xác định xem nên áp dụng (các) Cube nào mà các hoạt động liên quan sẽ được áp dụng: Điều này liên quan đến việc xác định tất cả các Cube cụ thể hóa có thể được sử dụng để trả lời truy vấn, lược bỏ tập hợp bằng cách sử dụng kiến thức về các mối quan hệ “thống nhất” giữa các các hình khối, ước tính chi phí sử dụng các hình khối được vật liệu hóa còn lại và chọn hình khối có chi phí thấp nhất.

    “Nên chọn khối nào trong số bốn Cube này để xử lý truy vấn?” Không thể tạo dữ liệu chi tiết hơn từ dữ liệu thô hơn. Do đó, không thể sử dụng hình khối 2 vì quốc gia là một khái niệm chung chung hơn là tỉnh hoặc tiểu bang. Các khối vuông 1, 3 và 4 có thể được sử dụng để xử lý truy vấn vì (1) chúng có cùng một tập hợp hoặc một tập hợp lớn của các thứ nguyên trong truy vấn, (2) mệnh đề lựa chọn trong truy vấn có thể ngụ ý lựa chọn trong Cube, và (3) các cấp độ trừu tượng cho kích thước mục và vị trí trong các hình khối này ở cấp độ tốt hơn so với nhãn hiệu và tỉnh hoặc tiểu bang, tương ứng.

    “Chi phí của mỗi Cube sẽ so sánh như thế nào nếu được sử dụng để xử lý truy vấn?” Có khả năng sử dụng hình khối 1 sẽ tốn kém nhất vì cả tên mục và thành phố đều ở cấp thấp hơn so với khái niệm thương hiệu và tỉnh hoặc tiểu bang được chỉ định trong truy vấn. Nếu không có nhiều giá trị năm được liên kết với các mục trong Cube, nhưng có một số tên mục cho mỗi thương hiệu, thì khối 3 sẽ nhỏ hơn khối 4 và do đó khối 3 nên được chọn để xử lý truy vấn. Tuy nhiên, nếu các chỉ số hiệu quả có sẵn cho hình khối 4, thì hình khối 4 có thể là lựa chọn tốt hơn. Do đó, cần có một số ước tính dựa trên chi phí để quyết định bộ hình khối nào nên được chọn để xử lý truy vấn.

    Kiến trúc máy chủ OLAP: ROLAP so với MOLAP so với HOLAP

    Về mặt logic, máy chủ OLAP cung cấp cho người dùng doanh nghiệp dữ liệu đa chiều từ Data Warehouse hoặc Data Warehouse mà không cần quan tâm đến cách thức hoặc vị trí dữ liệu được lưu trữ. Tuy nhiên, kiến ​​trúc vật lý và việc triển khai các máy chủ OLAP phải xem xét các vấn đề về lưu trữ dữ liệu. Việc triển khai máy chủ kho để xử lý OLAP bao gồm:

    Máy chủ OLAP quan hệ (ROLAP): Đây là những máy chủ trung gian nằm giữa máy chủ back-end quan hệ và các công cụ front-end của máy khách. Họ sử dụng DBMS quan hệ mở rộng hoặc quan hệ mở rộng để lưu trữ và quản lý dữ liệu kho, và phần mềm trung gian OLAP để hỗ trợ các phần còn thiếu. Các máy chủ ROLAP bao gồm tối ưu hóa cho mỗi mặt sau DBMS, triển khai logic điều hướng tổng hợp, các công cụ và dịch vụ bổ sung. Công nghệ ROLAP có xu hướng có khả năng mở rộng lớn hơn công nghệ MOLAP. Ví dụ, máy chủ DSS của Microstrategy áp dụng phương pháp ROLAP.

    Máy chủ OLAP đa chiều (MOLAP): Các máy chủ này hỗ trợ chế độ xem dữ liệu đa chiều thông qua các công cụ lưu trữ đa chiều dựa trên mảng. Chúng ánh xạ các khung nhìn đa chiều trực tiếp tới các cấu trúc mảng Cube dữ liệu. Ưu điểm của việc sử dụng khối dữ liệu là nó cho phép lập chỉ mục nhanh chóng đến dữ liệu tóm tắt được tính toán trước. Lưu ý rằng với Data Warehouse đa chiều, việc sử dụng lưu trữ có thể thấp nếu tập dữ liệu thưa thớt. Trong những trường hợp như vậy, nên tìm hiểu kỹ thuật nén ma trận thưa.

    Nhiều máy chủ MOLAP áp dụng biểu diễn lưu trữ hai cấp để xử lý các tập dữ liệu dày đặc và thưa thớt: Các ống con dày đặc hơn được xác định và lưu trữ dưới dạng cấu trúc mảng, trong khi các ống con thưa thớt sử dụng công nghệ nén để sử dụng hiệu quả lưu trữ.

    Máy chủ OLAP kết hợp (HOLAP): Phương pháp OLAP kết hợp kết hợp công nghệ ROLAP và MOLAP, được hưởng lợi từ khả năng mở rộng lớn hơn của ROLAP và tính toán nhanh hơn của MOLAP.

    Ví dụ: một máy chủ HOLAP có thể cho phép lưu trữ khối lượng lớn dữ liệu chi tiết trong cơ sở dữ liệu quan hệ, trong khi các tập hợp được lưu giữ trong một kho MOLAP riêng biệt. Microsoft SQL Server 2000 hỗ trợ máy chủ OLAP kết hợp.

    Máy chủ SQL chuyên dụng: Để đáp ứng nhu cầu ngày càng tăng của việc xử lý OLAP trong cơ sở dữ liệu tương đối, một số nhà cung cấp hệ thống cơ sở dữ liệu triển khai các máy chủ SQL chuyên biệt cung cấp ngôn ngữ truy vấn nâng cao và hỗ trợ xử lý truy vấn cho các truy vấn SQL trên lược đồ hình sao và bông tuyết trong môi trường chỉ đọc.

    “Dữ liệu thực sự được lưu trữ như thế nào trong kiến ​​trúc ROLAP và MOLAP?” Đầu tiên chúng ta hãy xem xét ROLAP. Như tên gọi của nó, ROLAP sử dụng các bảng quan hệ để lưu trữ dữ liệu cho quá trình xử lý phân tích trực tuyến. Nhớ lại rằng bảng dữ kiện được kết hợp với một hình khối cơ sở được gọi là bảng dữ kiện cơ sở.

    Bảng dữ kiện cơ sở lưu trữ dữ liệu ở mức trừu tượng được chỉ ra bởi các khóa nối trong lược đồ cho khối dữ liệu đã cho. Dữ liệu tổng hợp cũng có thể được lưu trữ trong các bảng dữ kiện, được gọi là bảng dữ liệu tóm tắt. Một số bảng dữ kiện tóm tắt lưu trữ cả dữ liệu bảng dữ kiện cơ sở và dữ liệu tổng hợp Ngoài ra, các bảng dữ kiện tóm tắt riêng biệt có thể được sử dụng cho mỗi cấp độ trừu tượng để chỉ lưu trữ dữ liệu tổng hợp.

    MOLAP sử dụng cấu trúc mảng đa chiều để lưu trữ dữ liệu cho quá trình xử lý phân tích trực tuyến. Cấu trúc này được thảo luận chi tiết hơn trong.

    Hầu hết các hệ thống Data Warehouse đều áp dụng kiến ​​trúc máy khách-máy chủ. Một kho lưu trữ dữ liệu quan hệ luôn nằm tại trang web của máy chủ Data Warehouse / data mart. Một Data Warehouse đa chiều có thể nằm ở trang máy chủ cơ sở dữ liệu hoặc trang máy khách.

    Trả lời

    Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

    Contact Me on Zalo
    Call now