資料倉儲的物理模型較常見的操作型資料庫的物理模型有很大不同。最明顯的區別是：操作型資料庫主要是用來支撐即時操作，對資料庫的效能和質量要求都比較高，為了防止「garbage in，garbage out」，通常設計操作型資料庫的都要遵循幾個正規化的約束，除非少數情況下為了效能進行妥協，才可能出現冗餘。而資料倉儲的建立並不上為了支撐即時操作，或者說，資料倉儲的資料是**於即時操作產生的資料，而不是直接**於即時操作。所以它的資料質量是由操作性系統來保證的，而不是由幾個正規化來保證的。而且為了更好的跟蹤歷史資訊，以及更快的產生報表，資料倉儲的物理模型中存在著大量冗餘字段。
資料倉儲的物理模型分為星型和雪花型兩種。所謂星型，就是將模型中只有乙個主題，其他的表中儲存的都是主題的一些特徵。比如貨物銷量的主題倉庫中，每次**記錄是事實表，而時間，售貨員，商品是維度，都和事實表有聯絡，組織起來就是星型。而如果更細化來看，商品是有種類，產地，**等特徵的，從這個角度來看，有兩個主題，乙個是商品**，乙個是商品本身。組織起來就是雪花型。實際專案中，由於操作型系統業務的複雜性導致本身產生了大量的資料，所以，組織起來也以雪花型居多。
那麼圍繞著主題，該如何設計事實表和維度表呢？也是有規律可循的。
事實表和維度表的分界線
事實表是用來儲存主題的主幹內容的。以日常的工作量為例，工作量可能具有如下屬性：工作日期，人員，上班時長，加班時長，工作性質，是否外勤，工作內容，審核人。那麼什麼才是主幹內容？很容易看出上班時長，加班時長是主幹，也就是工作量主題的基本內容，那麼工作日期，人員，工作性質，是否外勤，工作內容是否為主幹資訊呢？認真分析特徵會發現，日期，人員，性質，是否外勤都是可以被分類的，例如日期有年-月-日的層次，人員也有上下級關係，外勤和正常上班也是兩類上班考勤記錄，而上班時長和加班時長則不具有此類意義。所以一般把能夠分類的屬性單獨列出來，成為維度表，在事實表中維護事實與維度的引用關係。
在上述例子中，事實表可以設計成如下
workdate employeeid，worktypeid，islegwork，content，
而時間，員工，工作型別，是否外勤則歸為維度表。
總的來看，和其他建立主外來鍵關係的表也都一樣。但是維度表的建立是需要有層次的（雖然不是必須，但是也是典型特徵），而事實表的建立是針對已經發生的事實的，是歷史資料的存檔，也就是說是不應該修改的。以測試部測試軟體的bug為例。每個bug都是乙個事實。這個bug的狀態在資料字典裡可能設計成新建，轉派，修復，拒絕等等。那麼在事實表中bug表中有乙個欄位為status。當測試員或者開發人員改變了這個狀態的值，事實表中該如何更新呢？是直接更新status還是什麼其他的方式？顯然，為了能夠追蹤這個bug的歷史資訊，應該是重新插入一條新的記錄。那麼這和以往的資料庫設計有什麼區別呢？可以看出對於原始記錄和新插入的記錄，其他字段全部是相同的，也就是全部冗餘的。如果以bugid作為主鍵，這時候會發現主鍵都是冗餘的（當然，插入之前只能刪除主鍵）。所以可以看出，事實表一般是沒有主鍵的。資料的質量完全由業務系統來把握。
可以看出，維度表一般是有主鍵的。代表該類物質的乙個單一個體，其他的字段一般都是有層次關係的，例如2023年2月19日是主鍵，那麼它會有年--月--日這樣的層次，為了方便統計，年月日不會在做聚合的時候才計算出來，而是在維護記錄時已經計算出來。那麼這些欄位的冗餘是否值得呢？可以這樣解釋：維度表的資料一般是比較少的，這個少是指相對事實表來講的。因為事實表是與日俱增，而維度表則增長緩慢，所以絕對數字也不會太大。在事實表和維度表做連線查詢的時候，會產生與事實表一樣大的資料量，如果還需要group by year（timekey）的話，其一是會增加計算，其二是由於引入了計算，索引會失效。這個代價比引入冗餘欄位要大的多。以adventureworks為例，它總共引入了日曆年-月-日，財年-月-日，還有日曆年-周-日，財年-周-日等等多個層次。那麼它在每個層次不同級別上做聚合都是不需要引入函式來做year（timekey），month（timekey）這樣的運算。
總的說來，事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。
資料倉儲建設快速入門 事實表和維度表的設計
原文 資料倉儲的物理模型較常見的操作型資料庫的物理模型有很大不同。最明顯的區別是 操作型資料庫主要是用來支撐即時操作，對資料庫的效能和質量要求都比較高，為了防止 garbage in，garbage out 通常設計操作型資料庫的都要遵循幾個正規化的約束，除非少數情況下為了效能進行妥協，才可能出現冗...
資料倉儲 事實表
事實表分成三種 事務事實表 週期快照事實表 累計快照事實表 官方定義是 發生在某個時間點上的乙個事件。比如以訂單為例 下單是乙個事實 付款是乙個事實 退款是乙個事實，所有事實的累計就是事務事實表 如果需要對某一天或者某個月的資料進行分析，那麼可以使用週期快照事實表，比如 以天舉例，財務報表一般都是週...
資料倉儲 維度表
維度建模將業務抽象成事實和維度兩個概念。維度建模的核心是對齊維度。所以維度表的一致性是很重要的！維度表是如何進行處理的呢？穩定的維度表。比如 時間維度表 這種維度表的屬性是穩定的，不需要做天的全量快照資料，直接匯入一次即可 緩慢漸變維 維度會隨著時間發生緩慢的變化。比如 使用者維度表 資料量很大，但...