bảng Fact với nhiều sự kiện

Question

Tôi có một kích thước (SiteItem) có hai sự kiện quan trọng:

perUserClicks 
perBrowserClicks 

Tuy nhiên, trong không gian này, tôi có nhóm các giá trị dựa trên một cột thuộc tính (chúng ta hãy gọi các nhóm AboveFoldItems, LeftNavItems, OnTheFlyItems, vv) từng có nhiều những sự kiện mà cụ thể vào nhóm rằng:

AboveFoldItems: eyeTime, loadTime 
LeftNavItems: mouseOverTime 
OnTheFlyItems: doesn't have any extra, but may in the future 

là schema bảng thực tế sau ok?

DateKey 
SessionKey 
SiteItemKey 
perUserClicks 
perBrowserClicks 
eyeTime 
loadTime 
mouseOverTime 

Có vẻ như một chút lãng phí vì chỉ một số cột liên quan đến một số khóa thứ nguyên (các thông tin không liên quan được để lại NULL). Nhưng ... điều này có vẻ như nó sẽ là một vấn đề phổ biến, vì vậy cần có một giải pháp chung cho việc này, đúng không?

Answer 1

Tôi thường đồng ý với câu trả lời của Damir về điều này, nhưng vì bảng thực tế rất hẹp trong trường hợp cụ thể của bạn, vẫn còn công đức cho lời đề nghị của Aaron về việc giữ các NULL.

Chúng tôi có một số lược đồ sao trong các lĩnh vực chủ đề cụ thể với nhiều bảng thực tế chia sẻ nhiều nhất (nếu không phải tất cả) các tham số (tuân thủ và nội bộ). Các thứ nguyên phạm vi giới hạn không được coi là "được tuân thủ" trên toàn doanh nghiệp, nhưng chúng là thứ chúng tôi gọi là thứ nguyên "chia sẻ nội bộ". Thông thường, nếu dữ liệu được tải cùng lúc để kích thước không thay đổi, bạn có thể tham gia cả hai bảng thực tế trên các khóa, nhưng nói chung, tất nhiên, bạn không thể tham gia hai lược đồ sao khác nhau trên các khóa thứ nguyên nếu họ là người thay thế trong các chiều không gian thay đổi từ từ truyền thống. Nói chung, bạn phải tham gia các ngôi sao riêng biệt trên khóa tự nhiên hoặc "khóa doanh nghiệp" trong thứ nguyên chứ không phải thay thế (ngoại trừ trường hợp đặc biệt của thứ nguyên ngày không thay đổi và chỉ có khóa tự nhiên). Lưu ý rằng khi bạn tham gia hai ngôi sao, bạn phải sử dụng LEFT JOIN, trong trường hợp này bạn sẽ tạo ra NULL mà bạn vẫn có thể phải tính đến - vì vậy bạn thực sự quay trở lại với bản gốc mô hình bạn đã có với NULLs!;-)

Lợi ích của bảng thực tế là rõ ràng hơn khi bảng của bạn rộng với một bộ khóa nhỏ hơn và phân vùng dọc của dữ liệu tiết kiệm không gian cũng như mô hình hợp lý sạch hơn - điều này đặc biệt đúng khi các phím chỉ thực sự được chia sẻ tới một điểm - có một khóa giả hoặc phím NULL chắc chắn không phải là một ý tưởng hay - điều này thường chỉ ra một vấn đề mô hình hóa chiều. Tuy nhiên, như Aaron nói, nếu bạn đẩy nó đến cực, bạn có thể có một cột thực tế trong mỗi bảng thực tế với các khóa chia sẻ, có nghĩa là chi phí quan trọng làm giảm chi phí thực tế và bạn thực sự kết thúc trong một ngụy trang. Mô hình EAV.

Tôi cũng sẽ xem xét liệu bạn có đang ở trong tình trạng "quá ít kích thước" của Kimball hay không. Có vẻ như bạn phải có thuộc tính chiều tốt được gộp vào SessionKey và SiteItemKey - nhưng không nhìn thấy toàn bộ mô hình và yêu cầu của bạn, thật khó để nói, nhưng tôi nghĩ bạn sẽ có một số nhân khẩu học người dùng trong một cardinality thấp hoặc thậm chí kích thước bông tuyết mà không cần toàn bộ phiên hoặc thứ nguyên trang web.

Answer 2

Không có giải pháp thanh lịch thực sự, bạn có cột trống hoặc bạn sử dụng giải pháp EAV. Tôi đăng về EAV trước (và tạo ra rất nhiều nhận xét có thể đọc giá trị):

http://sqlblog.com/blogs/aaron_bertrand/archive/2009/11/19/what-is-so-bad-about-eav-anyway.aspx

Tôi là một fan hâm mộ của mô hình trong một số tình huống, nhưng nếu kích thước của bạn/thuộc tính không thay đổi thường xuyên, nó có thể là rất nhiều công việc phụ cho không có gì. NULL giá trị trong một cột không thực sự làm cho chất thải miễn là mã xung quanh có thể đối phó với chúng một cách thích hợp.

Answer 3

Bạn có thể có nhiều hơn một bảng thực tế: factperUserClicks, factperBroWserClicks, factEyeTime, vv ...

Mỗi trong số này sẽ có DateKey, SessionKey, SiteItemKey. Bằng cách này, chỉ các khóa kích thước "có ý nghĩa" mới xuất hiện với mỗi sự kiện.

Lý tưởng nhất, không nên có NULLS trong DW - nếu bạn giữ chúng trong cùng một bảng thực tế, sử dụng số 0 có thể phù hợp hơn.

Theo như tiết kiệm dung lượng ổ đĩa, tôi không thấy giải pháp lý tưởng - nhưng, trong DW một là nghĩa vụ phải giao dịch không gian cho tốc độ và (truy vấn) đơn giản anyway.