星型模式設計元件及分析

---

星型模式設計是一種用於資料倉庫的資料庫模式型別，旨在提高對大型資料集的查詢和分析效率。該模式包含一箇中心的事實表，其中包含要分析的資料，以及一個或多個維度表，這些維度表提供有關事實表中資料的其他資訊。

星型模式的元件

星型模式由四個主要元件組成。如下所示 -

• 事實表

• 維度表

• 屬性

• 屬性層次結構

讓我們逐一瞭解它們 -

事實

• 這些是貨幣值。

• 表示業務活動的績效指標。

• 例如，生產力、成本、銷售額、利潤、定價和數量。

• 事實也稱為度量。它們儲存在事實表中。

文字儲存在維度表中，數值儲存在事實表中。數值提供了公司績效的統計度量。在書面描述銷售時，銷售統計資料更容易理解，而用文字描述則較為繁瑣。事實有時也稱為度量，因為它們用於衡量公司的成功。

事實表到底是什麼？

• 事實表也稱為詳細表。

• 事實表是星型模式的中心點。

• 事實表提供主鍵以及事實或度量。

• 事實表由事實和鍵組成。這些是公司的最重要方面。事實表，也稱為詳細表，顯示了公司績效的概述。它始終位於星型模式的中心或中心位置。它周圍環繞著度量表。它還包含事實表的主鍵。

示例

假設我們有一家零售店向客戶銷售產品，並且我們希望在資料倉庫中跟蹤銷售資料。我們可以建立一個星型模式，其中包含一個名為“銷售”的事實表，用於跟蹤每次銷售的資訊 -

銷售事實表

列名	資料型別	描述
sale_id	整數	每次銷售的唯一識別符號
customer_id	整數	引用客戶維度表的外部索引鍵
product_id	整數	引用產品維度表的外部索引鍵
store_id	整數	引用商店維度表的外部索引鍵
sale_date	日期	銷售日期
quantity	整數	銷售數量
total_price	十進位制	銷售總價

在此示例中，“銷售”事實表包含每次銷售的唯一識別符號，以及引用客戶、產品和商店維度表的外部索引鍵。事實表還包含有關銷售日期、銷售產品數量和銷售總價的資訊。此表可用於按客戶、產品、商店和日期分析銷售資料，以及跨不同維度彙總銷售資料。

事實表特徵

• 事實表定期透過插入來自運營資料庫的聚合資料來重新整理。

• 度量是在查詢執行期間計算的事實。

• 每個事實表都包含維度表。

• 事實表有助於資料彙總。

• 至少包含一個事實或度量。

• 主鍵 - 所有維度表主鍵的並集。

• 維度表從不處於BCNF，但事實表處於。

• 事實表中的一行至少包含一個事實以及其維度表的主鍵。

• 度量有三種類型：可加性、半可加性和不可加性。

• 具有少量列和大量行，這些行相對較長且窄。

• 事實表中單個條目中資訊的量稱為事實表的粒度。

• 最有價值的事實是數值的、持續評估的和可加的。

事實表最常見的特徵之一是銷售額。因此，此值必須定期更新，例如每月或每季度更新一次。在星型模式中，維度表圍繞核心事實表。事實表必須始終至少包含一個事實；否則，它就不存在。它不包含代理鍵；而是由所有維度表的主鍵的並集形成事實表的主鍵。事實表始終處於規範化的BCNF形式。由於事實表包含主鍵並且只有少量事實，因此它具有較少的屬性但大量的行。如果銷售額每天更新一次，則事實表的粒度為一天。

維度表到底是什麼？

• 維度表提供主鍵以及僅在決策過程中使用的特徵。

• 例如，產品維度、位置維度和時間維度。

• 主鍵到外部索引鍵連線將維度表連線到事實表。

• 維度表提供過濾和分組。

• 維度通常是限定為事實的描述性資料。

顧名思義，維度表包含業務實體的支援特徵。每個維度表都具有主鍵和必需的屬性。客戶表是一種維度表。外部索引鍵連線將每個維度表連線到事實表。

示例

假設我們有一家零售店向客戶銷售產品，並且我們希望在資料倉庫中跟蹤有關產品的資訊。我們可以建立一個星型模式，其中包含一個名為“產品”的維度表，其中包含有關每個產品的資訊 -

產品維度表

列名	資料型別	描述
product_id	整數	每個產品的唯一識別符號
product_name	可變字元	產品名稱
category	可變字元	產品所屬的類別
price	十進位制	產品價格
supplier_id	整數	引用供應商維度表的外部索引鍵
brand_id	整數	引用品牌維度表的外部索引鍵

在此示例中，“產品”維度表包含每個產品的唯一識別符號，以及有關產品名稱、類別、價格以及引用供應商和品牌維度表的外部索引鍵的資訊。此表可用於按類別、價格範圍、供應商和品牌分析產品資訊，以及跨不同維度彙總產品資訊。

維度表特徵包括

• 維度表通常稱為查詢表或參考表。

• 維度表未被規範化。

• 包含一個主鍵，它是事實表主鍵的一部分。

• 維度不會隨著時間的推移而改變或變化非常緩慢。

• 它們具有少量行和大量列。

• 大多數星型模式都包含一個時間維度。

• 維度表不會相互連線；而是每個維度表都透過 PK-FK 聯接連線到事實表。

• 代理鍵通常是主鍵。

這些被稱為參考表，因為它們支援事實表中提供的資訊。事實表顯示了公司實體的摘要，而維度表則為事實表提供支援。維度表未被規範化，因為這樣做會導致維度表被拆分為多個表。這將增加模式中聯接的數量，使星型查詢變得更加困難，並且執行時間更長。維度表連線到事實表，但不會相互連線，因為這是不必要的。為每個維度表引入了代理鍵以唯一標識每個條目。

屬性是什麼？

• 這些是維度表的列。

• 客戶維度表示例包括客戶姓名、年齡、性別、婚姻狀況等。

• 這些大多是描述性值。

列名稱為屬性。在客戶表中，客戶特徵是將恰當定義客戶的詳細資訊。客戶特徵包括其姓名、性別、年齡和婚姻狀況。通常，它們是描述性資料，例如姓名和地址。

假設我們有一家零售店向客戶銷售產品，並且我們希望在資料倉庫中跟蹤有關客戶的資訊。我們可以建立一個星型模式，其中包含一個名為“客戶”的維度表，其中包含有關每個客戶的屬性 -

客戶維度表 -

列名	資料型別	描述
customer_id	整數	每個客戶的唯一識別符號
first_name	可變字元	客戶名
last_name	可變字元	客戶姓
gender	可變字元	客戶性別
date_of_birth	日期	客戶出生日期
email	可變字元	客戶電子郵件地址
address	可變字元	客戶街道地址
city	可變字元	客戶居住的城市
state	可變字元	客戶居住的州
country	可變字元	客戶居住的國家

在此示例中，“客戶”維度表包含每個客戶的唯一識別符號，以及客戶姓名、性別、出生日期、電子郵件地址和地址資訊等屬性。此表可用於按人口統計特徵、位置和購買歷史分析客戶資訊，以及跨不同維度彙總客戶資訊。

屬性層次結構到底是什麼？

• 屬性可以組織成層次結構。

• 層次結構級別具有 N:1 關係。

• 確定功能依賴序列。

• 示例 - 產品->產品型別，產品型別->行業

• 時間維度的層次結構 - 日期->周->月->季度->年。

• 位置的層次結構 - 城市->地區->州->國家->商店

• 屬性層次結構用於在多個聚合級別分析資料，通常從最高級別開始。

• 某些維度表列僅用於維度描述，並未用於屬性層次結構。

當我們需要更細粒度或更粗粒度的資訊時，屬性層次結構就派上用場了。我們可以找到特定季度的總銷售額。如果存在時間層次結構，我們可以檢索同一季度特定月份發生的銷售額。如果我們進一步深入層次結構，我們可以確定該月在特定一週的總銷售額。同樣，我們可以向上遍歷結構。並非所有維度表都需要屬性層次結構。

資料聚合的多種方法有哪些？

• 資料層次結構由屬性層次結構定義。

• 向上彙總 - 獲取更粗粒度或層次結構中更高級別的資料。

• 向下鑽取 - 獲取更細粒度的資料。

星型查詢到底是什麼？

• 星型查詢是事實表和多個維度表之間的連線。

• 這些問題確實很難。

• 完成需要很長時間。

星型查詢是在星型模式上執行的 SQL 查詢。星型查詢的名稱來源於我們是在星型模式上執行查詢的事實。因為星型模式在事實和維度列之間有多個連線，所以星型查詢很困難。由於多個連線關係，星型查詢的執行需要數小時。

結論

總之，星型模式設計是為資料倉庫中的分析建模資料的一種有效方法。該模式包含一箇中心事實表，其中包含要分析的定量資料，以及一個或多個維度表，這些表提供有關事實表中資料的其他上下文和描述性資料。事實表使用外部索引鍵連結到維度表，從而能夠跨不同維度和屬性執行查詢和分析。星型模式設計的分析涉及透過維度表中各種維度和屬性聚合和查詢事實表中的資料，以生成提供資料洞察的報表和視覺化。使用星型模式設計的優勢包括更快的查詢效能、簡化的資料建模以及易於終端使用者使用。