星型模式

在計算領域，星型模式是最簡單的數據集市模式，也是最廣泛用於開發數據倉庫和維度數據集市的方法。 星型模式由一個或多個事實表組成，這些事實表引用任意數量的維表。星型模式是雪花型模式的一個重要特例，對於處理更簡單的查詢更有效。

星型模式的名稱來源於物理模型與星形的相似性。事實表位於中心，維表周圍代表星形的點。

模型

星型模式將業務流程數據分為事實和維度，事實保存有關業務的可測量的定量數據，維度是與事實數據相關的描述性屬性。事實數據的示例包括銷售價格、銷售數量以及時間、距離、速度和重量測量。相關維度屬性示例包括產品型號、產品顏色、產品尺寸、地理位置和銷售人員姓名。

具有多個維度的星型模式有時稱為蜈蚣模式。 維度僅包含幾個屬性，雖然更易於維護，但會導致查詢中包含許多表連接，並使星型模式不太易於使用。

事實表

事實表記錄特定事件的測量或指標。事實表通常由數值和保存描述性信息的維度數據的外鍵組成。 事實表被設計為低水平的統一細節（稱為「粒度」或「粒度」），這意味着事實可以在非常原子的級別上記錄事件。隨着時間的推移，這可能會導致事實表中積累大量記錄。事實表定義為以下三種類型之一：

• 交易事實表記錄有關特定事件（例如銷售事件）的事實
• 快照事實表記錄給定時間點的事實（例如，月底的帳戶詳細信息）
• 累積快照表記錄給定時間點的聚合事實（例如，產品本月至今的總銷售額）

事實表通常分配一個代理鍵以確保每一行都可以唯一標識。該鍵是一個簡單的主鍵。

維表

與事實表相比，維表通常具有相對較少數量的記錄，但每條記錄可能具有大量屬性來描述事實數據。維度可以定義多種特徵，但維表定義的一些最常見的屬性包括：

• 時間維度表描述了星型模式中記錄事件的最低時間粒度級別的時間
• 地理維度表描述位置數據，例如國家、州或城市
• 產品尺寸表描述產品
• 員工維度表描述員工，例如銷售人員
• 範圍維度表描述時間、美元價值或其他可測量數量的範圍，以簡化報告

維表通常分配一個代理主鍵，通常是單列整數數據類型，映射到形成自然鍵的維度屬性的組合。

好處

星型模式是非規範化的，這意味着在星型模式設計和實現期間，放寬了應用於事務關係數據庫的典型規範化規則。星型模式非規範化的好處是：

• 更簡單的查詢 - 星型模式連接邏輯通常比從高度規範化的事務模式檢索數據所需的連接邏輯更簡單。
• 簡化的業務報告邏輯——與高度規範化的模式相比，星型模式簡化了常見的業務報告邏輯，例如同期報告和當前報告。
• 查詢性能提升——與高度標準化的模式相比，星型模式可以為只讀報告應用程式提供性能增強。
• 快速聚合——針對星型模式的更簡單的查詢可以提高聚合操作的性能。
• 提供多維數據集——所有OLAP系統都使用星型模式來高效構建專有的OLAP 多維數據集；事實上，大多數主要的 OLAP 系統都提供ROLAP操作模式，可以直接使用星型模式作為源，而無需構建專有的多維數據集結構。

例子

示例查詢使用的星型模式。

比如一個來自連鎖店的銷售數據庫，按日期、商店和產品分類。右側的架構圖像是雪花模式文章中提供的示例架構的星型架構版本。

Fact_Sales是事實表，有三個維度表Dim_Date 、 Dim_Store和Dim_Product 。

每個維表的Id列上都有一個主鍵，與Fact_Sales表的三列（複合）主鍵（ Date_Id 、 Store_Id 、 Product_Id ）的列之一（在示例架構中視為行）相關。本示例中事實表的非主鍵Units_Sold列表示可用於計算和分析的度量或指標。維表的非主鍵列表示維度的附加屬性（例如Dim_Date維度的Year ）。

例如，以下查詢回答 1997 年每個品牌和國家/地區銷售了多少台電視機：

SELECT
	P.Brand,
	S.Country AS Countries,
	SUM(F.Units_Sold)

FROM Fact_Sales F
INNER JOIN Dim_Date D    ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S   ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)

WHERE D.Year = 1997 AND  P.Product_Category = 'tv'

GROUP BY
	P.Brand,
	S.Country

相關資料

• 數據倉庫
• 在線分析處理
• 反向星型模式
• 雪花模式
• 事實星座
• 活動圖式

外部連結

• 星星：查詢優化模式的模式語言 （頁面存檔備份，存於互聯網檔案館）
• 事實星座圖 （頁面存檔備份，存於互聯網檔案館）