我的事實表中可以混合使用非度量代碼嗎？

Question

我們正在做一些復雜的數據累積。 我們的客戶向我們發送了一些東西，其中包括兩個維度（時間和業務單位）。 時間主要是一年中的一個月。 業務單位維度僅具有一些屬性：名稱和BU可以用於報告和分析目的的一些類別。

他們發送給我們的內容包括一些當前狀態信息（日期和代碼）。 這些看起來像事實。 他們還發送一些表征與業務部門之間關系的信息（主要是附加代碼）。 同樣，這些對於業務部門和時間段是唯一的。

最后，他們向我們發送顯然是加法事實的東西。 它包括貨幣和具有適當單位的計數。

我是否應該將這些定性信息與單個事實表混合在一個事實表中？ 還是應該將定性材料（只能用於計數）與定量材料（可以用於總和）分開？

Answer 1

如果數據都直接與加法事實相關，並且不是要分組/排序/搜索的數據，則可以將其放入事實表中。

但是請注意，事實表中的非累加數據將防止匯總，或者將成為有損操作。

Answer 2

僅當事物退化時才將其放入事實表中（在維中導致維數高/唯一性問題，因為維將事實表與維關系成1-1關系）。 Kimball建議避免除事實之外（例如唯一的訂單號）使尺寸退化的任何誘惑。

您總是可以將它們放在Kimball所謂的“垃圾”維度中。 所有這些代碼都可以簡單地歸入垃圾內容。 大多數日期將作為特定角色中日期維度的鍵進入事實表（通常使用YYYYMMDD形式的自然int鍵-我們僅有的幾次不使用非身份無意義的替代鍵）

我喜歡天真地將星星視為所有事實，然后方便地簡單確定哪一列進入哪個維度。 不必一定認為它們對應於特定的業務實體-請記住，星號不是ERD樣式的標准化OLTP數據庫。

Answer 3

布拉德·威爾遜（Brad Wilson）准確地描述了將它們添加到事實表中的風險。 過去，我在事實表中添加了垃圾屬性，只是以后需要重構。

他們發送給我們的內容包括一些當前狀態信息（日期和代碼）。 這些看起來像事實。 他們還發送一些表征與業務部門之間關系的信息（主要是附加代碼）。 同樣，這些對於業務部門和時間段是唯一的。

日期有什么商業目的？ 副手，我建議將它們設置為自己的尺寸並准確地描述它們。

多余的代碼有多不穩定？ 如果事實表的詳細信息是日期和BU，為什么不能將它們包含在BU維中並視為緩慢變化的屬性？

沒有更多細節，我無法提出明確的建議，但這將是我首先要問自己的問題。