當所有尺寸值具有100％重要性時，處理多對多尺寸

假設我們正在追蹤賬戶餘額。因此，我們的事實表將擁有如...

賬戶餘額事實表

（FK）ACCOUNTID
（FK）DateID
...
餘額列
...

Obviou狡猾的你有一個帳戶維度表和日期維度表。因此，現在我們可以輕鬆過濾帳戶或日期（或日期範圍等）。

但這裏是踢球者...賬戶可以屬於組 - 任何數量的組在給定的日期。團體只是邏輯抽象，除報告之外，他們沒有實際的意義。處於0,1或17組的賬戶不會以任何方式影響其餘額。例如，帳戶ID 1可以在組38,76,104和159中。帳戶2可以在組1中（其具有「未分組」的組描述。帳戶3可以在十七組中（實例）

作爲一個額外的好處，我們的用戶完全不是技術人員，他們不知道SQL，他們沒有關係數據庫的經驗，並且歷史上他們在一個複雜的Excel解決方案中完成了他們所有的工作。他們可以使用PowerPivot進行切片和過濾的尺寸模型，儘管這些帳戶組正在威脅要將其他無情簡單的星型模式變成足夠複雜的事物，以至於用戶會拒絕並返回到其當前的意大利麪條解決方案。我們的選擇...

布爾方法 布爾方法不可行。我們擁有約570,000個不同的賬戶，但更重要的是，有26,000個不同的賬戶。這對最終用戶來說也是一個惡魔，因爲他們是非技術性的，並且依靠非常簡單的工具來完成。

多列方法 理論上這可以工作，但是，我們確實有一些屬於17組的帳戶。再一次，這些團體實際上只是合乎邏輯的團體 - 他們沒有意義，但他們是業務部門要求報告的目的。讓最終用戶過濾出17個不同列的組在用戶接受中不會很好地完成，並且可能會導致用戶拒絕使用該解決方案（我不會責怪他們）。

橋表這個計數工作，但我們有26,000個不同的組。我不覺得這是用戶友好的。

由於我不喜歡我的選擇，我只能假設除了雪花之外還有更好的方法......除非雪花是唯一的方法。如果有人可以伸出援助之手並解釋他們的理由，那會很感激。

UPDATE：爲了說明，一個例子，我想每個人都可以在這裏涉及到是想象你可以在簡歷上列出的關鍵字的技巧。他們都涉及同一個人，但你可以擁有任何數量的技能。這些技能並不影響簡歷中的任何單項措施 - 即「C++」並不比「C＃」更有價值 - 您無法將所有簡歷/技能組合放入事實表中，或者您將結束雙重計數（或者超過一倍））。

我認爲我能做的最好的事情就是爲團體創建一個支腿表。我不是它的粉絲，但我認爲這是我唯一的選擇。

所以現在我們有...

賬戶餘額事實表

（FK）ACCOUNTID
（FK）DateID
...
平衡
...

科目維度

（PK）ACCOUNTID
帳戶名稱
...
（FK）賬戶組密鑰

帳戶組支腿

（PK）AccountGroupID
（PK）的AccountID）
帳戶組名稱

來源

2011-03-31 Jibba Jones

：這是否意味着您還想存儲有關帳戶的歷史信息？ I. e。帳戶5屬於A組和B組，直到3月3日，它在3月3日以後屬於A組和C組？ – jing 2011-03-31 05:23:44

這些真實的羣體或只是用於過濾的標籤？如果一個賬戶可以同時屬於幾個組，那麼'acc_group'的和（餘額）組沒有多大意義，這是雙重計數？ – 2011-03-31 12:14:01

關於@jing，有一個類型2緩慢變化的維度，這應該由支腿表處理得很好。該業務不需要它，但它將在那裏不管。關於@Damir，這些確實只是爲了過濾，所以如果您將所有組/賬戶組合放入事實表中，重複計算就成了一個問題。 – 2011-03-31 13:06:31

我會說你得從界面開始。用戶如何在理想世界中進行過濾？

我想我最終會選擇一個橋樑或無事實的事實表或類似的東西。也許事實表上的代理鍵和從組到成員資格的許多鏈接表。

這絕對是艱難的 - 接口和使用案例必須可行，所以我會從那裏開始。也許某些事情會擺脫他們如何進行這種報告 - 就像羣體中的等價類或他們分配帳戶空間的方式一樣。也許有一個組織的層次或組織，使其更易於管理，並可以通知更簡單的設計。

來源

2011-03-31 05:00:05

按帳戶和分組這就是他們目前的解決方案（需要16小時加載的Excel工作表）的工作方式，以及他們需要如何能夠在將來繼續過濾（其他維度比較簡單）。賬戶處於一個扁平的層次結構 - 團隊只是爲了過濾而完成的，原因是相當隨意的（相信我，爲期兩週的會議，試圖消除它們）。現有的解決方案迫使他們複製粘貼公式（我稱之爲_electronic handcrafting_），這是公開的，我不希望他們在同一條路上。 – 2011-03-31 12:34:33

@Jibba Jones評論Kimball Design Tip＃50和尚未發佈（但通過電子郵件發送）的設計提示＃133。 http://www.kimballgroup.com/html/designtipsPDF/DesignTips2003/KimballDT50FactlessFact.pdf – 2011-04-05 14:43:12

如果我理解正確你的問題，這應該是好的：「帳戶可以屬於組 - 在給定日期任意數量的組」

CREATE TABLE IF NOT EXISTS `accounts` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ; 

CREATE TABLE IF NOT EXISTS `accounts_groups` (
    `account_id` int(11) NOT NULL, 
    `group_id` int(11) NOT NULL, 
    `start_date` date NOT NULL, 
    `end_date` date DEFAULT NULL, 
    UNIQUE KEY `account_group` (`account_id`,`group_id`,`start_date`), 
    KEY `group_id` (`group_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

CREATE TABLE IF NOT EXISTS `account_balances` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `account_id` int(11) NOT NULL, 
    `date` date NOT NULL, 
    `balance` decimal(11,2) NOT NULL, 
    PRIMARY KEY (`id`), 
    KEY `account_id` (`account_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ; 

CREATE TABLE IF NOT EXISTS `groups` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ; 

ALTER TABLE `accounts_groups` 
    ADD CONSTRAINT `accounts_groups_ibfk_1` FOREIGN KEY (`account_id`) REFERENCES `accounts` (`id`), 
    ADD CONSTRAINT `accounts_groups_ibfk_2` FOREIGN KEY (`group_id`) REFERENCES `groups` (`id`); 

ALTER TABLE `account_balances` 
    ADD CONSTRAINT `account_balances_ibfk_1` FOREIGN KEY (`account_id`) REFERENCES `accounts` (`id`);

來源

2011-03-31 22:22:41 bancer

當所有尺寸值具有100％重要性時，處理多對多尺寸

回答

相關問題