2009-09-09 29 views
1

考慮具有事實表一維模型像(fk_dim1value, fk_dim2value, ..., value)其中fk_X列是外鍵成對應瑣碎維度表dim1value (id, value), dim2value (id, value),合併相同的表,但保持獨立的參照完整性

這些事實和維表被自動地從收集不同的來源,所以它們有很多......並且它們是多餘的:所有維值表在結構上是相同的,它們表示文本值的簡單集合,沒有其他語義(唯一的區別是引用它們的不同外鍵各種事實表)。較不重要的維度類型可能稍後會出現,但不同類型的維度集合將保持較小。

所以我想合併維度表到一個表dimvalue (fk_dim, dimvalue_id, value)其中fk_dim引用表dimension (dim_id, name)dimvalue_id只在每個維度內是唯一的。然後自然主鍵是合成的:(fk_dim, dimvalue_id)

事實表外鍵列現在全都引用同一個表dimvalue (fk_dim, dimvalue_id, value) ......但是當然每列都與特定的維相關聯,因此應該仍然限於特定地引用該維的值(水平分區統一表dimvalue)。

有沒有一個(明智的)方法來做到這一點?

我的意思是像「半複合」外鍵,即對組合PK的「切片」的單列引用,對於其他列有固定值。 「完全複合」FK將爲FOREIGN KEY (col1, col2) REFERENCES dimvalue (fk_dim, dimvalue_id),但這裏的fk_dim是固定的,因此密鑰的「主」側只是一列,引用dimvalue主鍵的第二列;像FOREIGN KEY (fk_dim7value) REFERENCES dimvalue (fk_dim=7, dimvalue_id)

是這樣的可能嗎?或者我在這最後一段中迷失了方向?我應該放棄,只是外鍵到整個dimvalue表,然後添加檢查約束來限制維度?還是參考完整性要求我放棄更多,只是接受所有單獨的相同表?

(上寫入性能限制的影響並不重要;讀取性能是設計目標。)

回答

1

你說這些關鍵因素

  • 數據來自不同系統的收集,因此我斷定這是「報告」表而不是「操作」或「交易型」系統
  • 每個事實表包含每行一條業務數據,即「值」列
  • 您的事實表似乎只包含上e「測量」或「事實」
  • 寫入性能無關緊要,只有讀取性能是目標。這證實了我的結論,即這是一個「報告」表

考慮到你在快速閱讀表現後,我會去「大桌子」設計。授予交易系統的大桌子設計是可怕的,但這不是一個。大表我的意思是 表(DIM1VALUE,DIM2VALUE,DIM3VALUE,DIM4VALUE .... DIMNVALUE,FACTVALUE)

無論如何,您的維度表只有1列的業務數據,因此跳過查找。對每一列進行索引(事實值除外),然後測試查詢的性能。

當您加載大表時,您可以檢查數據質量的值並標記/解決預期範圍之外的值。

現在,如果維度表的數量過多,則可以將大表拆分成組,其中分組基於邏輯用法,例如,如果維度中的10個屬性總是一起使用,那麼將它們放在BIGTABLE1中, 等等。

+0

謝謝;你是對的,這是一個「報告」模式,但我不喜歡「大桌子」的方法。它會炸開事實表的寬度(尺寸值可能很寬),導致查詢I/O很重。它不會爲我節省很多,因爲我經常可以避免加入維度表。而且這將使我與這個唯一平凡的價值觀模型並不一致(我不清楚這一點,對不起,我已經修改了這個問題)。 – 2009-09-14 14:08:19