Download miễn phí Đồ án Xây dựnd kho chứa dữ liệu Data Warehouse



Xử lý phân tích trực tuyến (On-Line Analysis Processing - OLAP) là công cụ phân tích trực tuyến. Bản chất cốt lõi của OLAP là dữ liệu được lấy ra từ DW hay DM sau đó được chuyển thành mô hình đa chiều và được lưu trữ trong một kho dữ liệu đa chiều. Các công cụ OLAP lấy dữ liệu trong kho dữ liệu để thực hiện các công việc phân tích đặc biệt theo nhiều chiều và phức tạp hỗ trợ cho việc ra quyết định. Sơ đồ hình sao được dùng để thiết kế mô hình dữ liệu trong DW hay DM là mô hình dữ liệu quan hệ nhưng lại mang những thuộc tính nhiều chiều rất có nhiều thuận lợi cho việc cài đặt OLAP.


http://s1.liketly.com/flash/edoc/jh2i1fkjb33wa7b577g9lou48iyvfkz6-swf-2014-01-17-do_an_xay_dund_kho_chua_du_lieu_data_warehouse.rNAxL16vqc.swf /tai-lieu/de-tai-ung-dung-tren-liketly-54894/
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí

Tóm tắt nội dung tài liệu:

ụng sơ đồ bông tuyết. Trong sơ đồ loại này, các bảng Fact kết hợp được tạo ra một cách riêng biệt từ những bảng chứa dữ liệu chi tiết. Thêm vào với các bảng Fact chính, sơ đồ hình tuyết rơi còn chứa các bảng Fact riêng rẽ cho mỗi mức kết hợp, vì vậy không mắc lỗi trong việc lựa chọn các bản ghi chi tiết. Tuy nhiên sơ đồ hình tuyết rơi phức tạp hơn sơ đồ hình sao và thường đòi hỏi những câu lệnh SQL phức tạp hơn để nhận được câu trả lời.
5.1.3 Những vấn đề thiết kế lược đồ hình sao liên quan tới các phương tiện của hệ quản trị cơ sở dữ liệu quan hệ và kĩ thuật tối ưu.
a/ Vấn đề kết hợp từng cặp 2 bảng
Hệ quản trị cơ sở dữ liệu quan hệ không được thiết kế để dùng cho một tập lớn các câu truy vấn phức tạp có thể được đưa ra đối với một sơ đồ hình sao. Một cách cụ thể khả năng lấy được thông tin liên quan từ một số bảng trong một câu truy vấn đơn- được gọi là xử lí kết hợp - rất bị hạn chế.
Một số hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) chỉ có thể kết hợp 2 bảng tại một thời điểm. Nếu một sự kết hợp phức tạp liên quan tới nhiều hơn 2 bảng thì RDBMS cần tách câu truy vấn thành một chuỗi các cặp 2 bảng kết hợp với nhau. Đó không phải là hạn chế khắt khe nhất đối với những câu hỏi đơn giản được thực hiện bởi cơ sở dữ liệu OLTP tuy nhiên những kĩ thuật kết hợp như vậy không thể thực hiện một cách đầy đủ trong môi trường DW.
Yêu cầu là liệt kê phần đóng góp của tất cả số lượng hàng bán được theo mỗi sản phẩm trong các thị trường, các loại và các giai đoạn khác nhau. Như vậy chúng ta phải kết hợp dữ liệu từ 4 bảng: SalesFact, Priod, Market, Product.
Số lượng phép kết hợp được đánh giá là tăng theo hàm mũ so với số lượng các bảng được đem ra kết hợp nên trật tự kết hợp không còn là vấn đề quan trọng nhất, nó được tối ưu để có thể thực hiện trong một khoảng thời gian hợp lí. Sự kết hợp có nhiều thuật toán khác nhau. Mỗi thuật toán trong những thuật toán này cần được đánh giá cho mọi sự kết hợp. Chẳng hạn có 5 thuật toán kết hợp RDBMS, cần đánh giá 10!*5=18 triệu phép toán kết hợp cho một câu truy vấn liên quan tới 10 bảng. Con số này qua lớn khiến cho một số cơ sở dữ liệu không chạy những truy vấn cố gắng kết hợp quá nhiều bảng. Một RDBMS điển hình phải quyết định trật tự kết hợp từng cặp 2 bảng trước khi một truy vấn bắt đầu được thực hiện vì vậy việc thực hiện bị trễ đi một khoảng thời gian khá dài.
b/ Vấn đề kết hợp đối với sơ đồ hình sao
Vì số lượng các cặp bảng cần kết hợp với nhau thường quá lớn cho một sự đánh giá đầy đủ, rất nhiều RDBMS tối ưu hạn chế phép chọn dựa trên một tiêu chí cụ thể, thường là nhặt ra kết hợp các bảng liên quan trực tiếp với nhau. Đối với ví dụ trình bày ở trên thì việc kết hợp SalesFact với Perid thì tốt hơn là Product kết hợp với Market. Chiến lược này có vẻ có lí đối với sơ đồ OLTP truyền thống chứa một mạng phức tạp rất nhiều các bảng có quan hệ trực tiếp với nhau. Trong khi đó nó tỏ ra không hiệu quả lắm với DW vì trong sơ đồ hình sao chỉ có một bảng liên quan trực tiếp tới hầu hết các bảng còn lại đó là bảng Facts. Điều đó có nghĩa là bảng Facts là thành phần quan trọng nhất cho sự kết hợp đầu tiên. Nhưng kích thước của bảng Facts thường là lớn nhất nên chiến lược này tạo ra tập các bảng trung gian rất lớn. Điều này ảnh hưởng tới năng suất thực hiện truy vấn. Vấn đề công suất này là giả thiết rằng RDBMS có thể chọn được cặp 2 bảng kết hợp với nhau tốt nhất được đánh giá theo trật tự trong tập giới hạn các trật tự. Trong một RDBMS được tối ưu cho OLTP, truy vấn được phân tích và kế hoạch được lựa chọn dựa trên sự ước lượng độ lớn của bảng kết quả trung gian. Những ước lượng này dựa trên sự thống kê của bản thân dữ liệu và thường không được chính xác. Trong bất kì một môi trường tính toán nào, sự lan truyền về lỗi chỉ làm cho vấn đề trở nên tồi tệ thêm: nếu có một lỗi trong lần đánh giá đầu tiên thì lỗi này sẽ được nhân lên trong mỗi lần đánh giá mới tiếp theo vì vậy chỉ một lỗi nhỏ sẽ trở nên rất nghiêm trọng. Hiệu quả của mạng là ở chỗ RDBMS có thể gạt bỏ trật tự tối ưu nhất khi phải trả cái giá quá cao do lỗi xảy ra trong quá trình ước lượng chi phí.
5.2 Lược đồ bông tuyết - Snowflake
Lược đồ bông tuyết là một sự mở rộng của sơ đồ hình sao tại đó mỗi cánh sao không phải là một bảng chiều mà là nhiều bảng.
perKey
month
year
quarter
…
Period
SalesMonthly
perKey
prodKey
mktKey
dollars
weight
…
prodKey
product
color
model
size
…
Product
SalesWeekly
perKey
prodKey
mktKey
dollars
weight
…
SalesDaily
perKey
prodKey
mktKey
values
units
…
mktKey
city
state
region
…
Markets
countryKey
…
regionKey
…
Lược đồ bông tuyết
Trong dạng sơ đồ này, mỗi bảng theo chiều của sơ đồ hình sao được chuẩn hóa hơn. Sơ đồ bông tuyết cải thiện năng suất truy vấn, tối thiểu không gian đĩa cần thiết để lưu trữ dữ liệu và cải thiện năng suất nhờ việc chỉ phải kết hợp những bảng có kích thước nhỏ hơn thay vì phải kết hợp những bảng có kích thước lớn lại không chuẩn hóa. Nó cũng làm tăng tính linh hoạt của các ứng dụng bởi sự chuẩn hóa và ít mang bản chất theo chiều hơn. Nó làm tăng số lượng các bảng và làm tăng tính phúc tạp của một vài truy vấn cần có sự tham chiếu tới nhiều bảng.
Một vài công cụ đã che giấu người sử dụng đầu cuối sơ đồ cơ sở dữ liệu vật lí và cho phép họ có thể làm việc ở mức khái niệm. Những công cụ này đã ánh xạ những truy vấn của người sử dụng tới sơ đồ vật lí. Họ cần một bộ quản trị cơ sở dữ liệu để thực hiện công việc này một lần đầu tiên khi công cụ này được cài đặt.
5.3 Lược đồ kết hợp
Là kết hợp giữa sơ đồ hình sao dựa trên bảng Fact và những bảng chiều không chuẩn hóa theo các chuẩn 1, 2, 3 và sơ đồ hình tuyết rơi trong đó tất cả các bảng chiều đều đã được chuẩn hóa. Trong sơ đồ loại này chỉ những bảng chiều lớn là được chuẩn hóa còn những bảng khác chứa một khối lượng lớn các cột dữ liệu chưa được chuẩn hóa.
5.4 Giải pháp cho vấn đề hiệu suất thực hiện của mô hình dữ liệu
Tư tưởng cơ bản của việc tối ưu là chiến lược kết hợp các cặp bảng bằng cách lựa chọn chỉ các bảng có liên quan tới nhau ít nhất. Khi 2 bảng được kết hợp và không có cột nào liên kết 2 bảng đó với nhau sự kết hợp các hàng của 2 bảng được thực hiện.
RDBMS không bao giờ coi tích Đề các như một phép kết hợp tốt, nhưng đối với sơ đồ hình sao những tích đề các này đôi khi cải thiện công suất truy vấn. Bởi vì bảng Fact trong sơ đồ hình sao có kích thước lớn hơn rất nhiều các bảng chiều mà sự kết hợp các cặp bảng được thực hiện đầu tiên với bảng Fact. Sự lựa chọn này là không hợp lí vì như vậy sẽ tạo ra các bảng trung gian rất lớn. Một tích đề các được thực hiện đầu tiên với tất cả các bảng chiều (bằng cách kết hợp các cặp bảng liên tiếp...

---