維度表

本文提供一些資料表基本概念。

在維度模型中，維度表描述與業務和分析要求相關的實體。 大致而言，維度表代表你建模的內容。 內容可以是產品、人員、地點或任何其他概念，包括日期和時間。 若要輕鬆識別維度表，通常要為其名稱加上前綴 d_ 或 Dim_。

範例給出一個銷售人員維度表，如下圖所示：

代理鍵

定義： 代理鍵是一種由資料倉儲系統自動生成的唯一識別符號，用於識別維度表中的每一行記錄。

作用：

穩定性： 代理鍵的值是由系統分配的，不受業務變化的影響，因此更為穩定。

效能優勢： 由於代理鍵是增量或隨機生成的數字，對於資料庫索引的效能有積極影響，提高了查詢效率。

優勢：

靈活性： 允許系統獨立管理唯一標識，降低了與業務變化相關的複雜性。

易維護性： 由於代理鍵不受外部業務資料的影響，維護起來更加簡便。

適用場景：

維度表： 通常在維度表中使用代理鍵，用於唯一標識每個維度記錄。

聯動： 在與事實表建立聯動時，作為連結點，提供更高效的聯動操作。

範例中的 Salesperson_SK 表示代理鍵。

自然鍵

自然鍵是維度模型中的一個關鍵概念，與代理鍵相對。自然鍵使用資料本身的業務屬性作為識別符號，其在維度表中用於唯一地標識記錄。以下是自然鍵的主要特點：

定義：自然鍵是由維度表中現有的業務資料屬性構成的識別符號，用於唯一標識每個維度記錄。

作用：

業務聯動： 自然鍵直接反映真實業務世界中的關係，與業務實體的屬性相對應。

可讀性： 自然鍵通常具有業務含義，使得資料更易理解，有助於業務使用者的可讀性。

優勢：

業務可理解性： 由於自然鍵基於現有資料，更容易為業務人員理解和使用。

反映真實業務： 自然鍵直接映射到業務實體，提供了更直覺的資料模型。

限制：

不穩定性： 部分情況下，自然鍵可能受到業務變化的影響，導致不穩定性。

複雜性： 在處理變化、合併或分割等業務操作時，自然鍵可能引入複雜性。

適用場景：

業務明確： 當業務實體有清晰的、穩定的業務標識時，自然鍵是一個合適的選擇。

使用者可理解： 當使用者更容易透過業務屬性識別記錄時，自然鍵有助於提高可理解性。

範例中的 EmployeeID 表示自然鍵。

外鍵

其他維度表可以引用外鍵，並且它們存在於維度表中是一種特殊情況。 它表示該表與另一個維度表相關。

範例中的 SalesRegion_FK 表示外鍵。

維度屬性

範例維度表還具有維度屬性，如 FirstName 列。 維度屬性為儲存在相關事實資料表中的數值資料提供上下文。 它們通常是分析查詢中使用的正文列，用於篩選和分組，但不能自行合併。 一些維度表包含少數幾個屬性，而另一些則包含許多屬性。

歷史磁軌屬性

歷史磁軌屬性是可選的，取決於磁軌源系統中發生的特定更改的需要。 它們使儲存值能夠支援資料倉儲的主要角色，即準確描述過去。 具體而言，當 ETL 進程將新的或更改的資料載入到維度時，這些屬性將儲存歷史上下文。

審核屬性

審核屬性是可選的，但建議使用。 它們使你能夠磁軌建立或修改維度記錄的時間和方式，並且可以包括 ETL 進程中產生的診斷或故障排除資訊。 例如，將要磁軌誰（或哪些進程）更新了行，以及何時進行的更新。 審核屬性還可以幫助診斷具有挑戰性的問題，例如 ETL 進程何時意外停止。

通常，維度模型中最有用且最通用的維度是大而寬的維度。維度支援對事實資料進行所需的篩選、分組和準確的歷史分析。

大維度可能源自多個源系統。 在這種情況下，維度處理需要組合、合併、刪除重複資料並標準化資料：以及分配代理鍵。

相比之下有些維度很小。 可能表示只包含幾個記錄和屬性的尋找表。 通常這些小維度儲存與事實資料表中的交易相關的類別值，以具有代理鍵的維度形式實現，以與事實記錄相關。

層次結構

通常，維度列會生成層次結構。 層次結構允許在不同的匯總級別瀏覽資料。 例如，初始檢視表可能顯示年銷售額，報表使用者可以選擇鑽取以顯示季度和每月銷售額。

可透過三種方法將層次結構儲存在維度中。 可用工具如下：

• 來自單個非規範化維度的列。

• Snowflake 維度，其中包含多個相關表。

• 維度中的父-子關係（自引用）。

均衡層次結構

均衡層次結構是最常見的層次結構類型。 均衡層次結構具有相同的級別數。 均衡層次結構的一個常見範例是日期維度中的日曆層次結構，該層次結構包含年份、季度、月和日期的級別。

例如門店區域的均衡層次結構可以包括兩個級別，即省份、城市。

均衡層次結構的級別基於來自單個非規範化維度的列，或基於構成 Snowflake 維度的表。 當基於單個非規範化維度時，表示較進階別的列包含冗餘資料。

對於均衡層次結構，事實資料始終與層次結構的單個級別相關，這通常是最低級別。 事實資料就可以合併（匯總）到最進階別的層次結構。 事實資料可以與任何級別相關，這由事實資料表的粒度決定。 例如，銷售事實資料表可能以日期級別儲存，而銷售目標事實資料表可能以季度級別儲存。

非均衡層次結構

非均衡層次結構是一種不太常見的層次結構類型。 非均衡層次結構具有基於父-子關係的級別。 非均衡層次結構中的級別數由維度行決定，而不是特定的維度表列。

非均衡層次結構的一個常見範例是員工層次結構，其中員工維度中的每一行都與同一表中的報表管理器行相關。 在這種情況下，任何員工都可以成為具有報表員工的經理。 當然，層次結構的一些分支將比其他分支具有更多的級別。

下圖描繪了一個非均衡層次結構。 它包括四個級別，層次結構中的每個成員都是銷售員。 請注意，銷售員在層次結構中的上級數不同，具體取決於他們向誰報表。

非均衡層次結構的其他常見範例包括物料清單、公司所有權模型和總帳。

對於非均衡層次結構，事實資料始終與維度粒度相關。 例如，銷售事實資料與具有不同報表結構的不同銷售員相關。 維度表將具有代理鍵（命名為 Salesperson_SK）和 ReportsTo_Salesperson_FK 外鍵列，其引用了主鍵列。 每個沒有人要管理的銷售員不一定在層次結構任何分支的最底層。 當他們不處於最低級別時，銷售員可能會銷售產品，並且還會具有也在銷售產品的報表銷售員。 因此，事實資料的匯總必須考慮各個銷售員及其所有下級。

查詢父-子層次結構可能很複雜和緩慢，尤其是對於大維度。 雖然源系統可能會將關係儲存為父-子級，但建議將層次結構自然化。 在此實體中，自然化意味着將層次結構級別轉換和儲存到維度中作為列。

不規則層次結構

有時層次結構是不規則的，因為層次結構中的成員的父級存在於不緊隨其上方的級別。 在這些情況下，缺失的級別值會重複父級的值。

請考慮均衡的地理層次結構的範例。 當國家/地區沒有州或省時，存在不規則分級結構。 例如，新西蘭既沒有州也沒有省。 因此，插入新西蘭行時，還應將國家/地區值儲存在 StateProvince 列中。

日曆和時間

事實資料表幾乎無一例外地儲存特定時間點的度量值。 若要支援按日期（可能是時間）進行分析，必須有日曆（日期和時間）維度。

源系統具有日曆維度資料並不常見，因此必須在資料倉儲中生成它。 通常，它只生成一次，如果它是日曆維度，則在需要時可以使用將來日期對其進行擴展。

日期維度

日期（或日曆）維度是用於分析的最常見維度。 它為每個日期儲存一個行，並支援按特定日期週期（如年份、季度或月份）進行篩選或分組的常見要求。

日期維度不應該包含擴展到一天中的時間的粒度。 如果需要一天中的具體時間分析，則應同時具有日期維度和時間維度。 儲存一天中的具體時間事實資料的事實資料表應有兩個外鍵，每個外鍵對應一個維度。

日期維度的自然鍵應使用日期資料類型。 代理鍵應使用 YYYYMMDD 格式和 int 資料類型來儲存日期。 當代理鍵值具有意義且人工可讀時，此接受的做法應該是唯一的例外（與時間維度一起）。 以 YYYYMMDD 資料類型儲存。

當維度用於與更高粒度的事實資料聯動時，事實資料表可以使用日期週期的第一個日期。 例如，儲存季度銷售員目標的銷售目標事實資料表會將季度的第一個日期儲存在日期維度中。 另一種方法是在日期表中建立鍵列。 

維度應該用所有事實資料表使用的已知日期範圍填充。 它還應包括資料倉儲儲存有關目標、預算或預測的事實資料時的將來日期。 與其他維度一樣的是，可以包含表示缺失、未知、N/A 或錯誤情況的行。

時間維度

事實資料需要儲存在某個時間點（如一天中的具體時間）。 在這種情況下，建立時間（或時鐘）維度。 它可以有分鐘（24 x 60 = 1,440 行）甚至是秒（24 x 60 x 60 = 86,400 行）的粒度。 其他可能的粒度包括半小時或一小時。

時間維度的自然鍵應使用時間資料類型。 代理鍵可以使用適當的格式，並儲存具有意義且人工可讀的值，例如，透過使用 HHMM 或 HHMMSS 格式。

多值維度

當某個維度屬性必須儲存多個值時，需要設計多值維度。 透過建立網橋表（有時稱為聯接表）來實現多值維度。 網橋表儲存實體之間的多對多關係。

假設有一個銷售員維度，並且每個銷售員都分配給一個或多個銷售區域。 在這種情況下，建立銷售區域維度是有意義的。 該維度只將每個銷售區域儲存一次。 一個單獨的表（稱為網橋表）為每個銷售員和銷售區域關係儲存一行。 從物理上看，銷售員維度到網橋表之間存在一對多關係，銷售區域維度與網橋表之間存在另一個一對多關係。 從邏輯上看，銷售員與銷售區域之間存在多對多關係。

退化維度

當維度與相關事實資料的粒度相同時，可能會發生退化維度。 退化維度的常見範例是與銷售事實資料表相關的銷售訂單號維度。 不復制此資料來建立單獨的維度表是可接受的做法。

下面的關係圖描繪了 Sales_Order 維度，它是基於銷售事實資料表中的 SalesOrderNumber 列的退化維度。 

角色扮演維度

在當一個維度在事實資料表中被多次引用時，稱為角色扮演維度。

例如，當銷售事實資料表具有訂單日期、裝運日期和交付日期維度鍵時，日期維度以三種方式聯動。 每個方式都表示不同的角色，但只有一個實際日期維度。

下面的關係圖描繪了事實資料表。 銷售維度是角色扮演維度，因為它作為機會銷售維度和簽單銷售維度與事實資料表有兩次聯動。