每種資料存儲都有一種模式，所有列、主鍵和外鍵形成了這樣一個模式。例如，網絡内容管理的資料庫包括像CUSTOMER、CUSTOMER_ORDER和DVD_RELEASE這樣表的定義。
某些特定的模式流行起來以至于它們被命名。我們在整本書中都提到的最有名的4個模式是：
标準化模式
非标準化模式
星形模式
雪花模式
本節可以看作一個模式形式的進階課程，更詳細的描述見文獻［27］和文獻［25］。此外，對于模式形式，并沒有一個完全的清單。例如，其他模式形式如電子資料室（見文獻［28］）是值得一說的，但是我們把它們寫在了更專業化的書中。
标準化模式是4個模式中最古老的。第一篇關于标準化模式的文章寫于20世紀70年代（例如，見文獻［29］和文獻［30］）。标準狀态下，每個商務執行個體中隻存儲一次，或者換句話說，一個表格應該不包括複制的資料，表格的每一列是以這樣方式組織的。William Kent曾經這樣概括：在一個标準化表格中，每一列如果不是主鍵的一部分，那麼這一列就應該依賴于主鍵，并且是主鍵的全部，并且隻依賴于主鍵（見文獻［31］）。在非正式的情況下，這意味着在兩個非主鍵之間，不存在一對一或者一對多的關系。
标準化模式的目的是避免存儲重複的資料使得被存儲的資料變得不一緻。因為标準化模式的表格不包含重複的資料，它們與資料插入、更新和删除的事務高度适應。原因是沒有重複的資料，每次插入、更新和删除隻涉及一行。是以，它在很長的一段時間裡是開發生産資料庫的首選模式形式。
顧名思義，非标準化模式是标準化模式的反義詞。當表不遵循以上規則，包含着複制的資料，它就是非标準化模式。例如，WEBSITE_TITLE這一列也可以添加到CUSTOMER表中，CUSTOMER表中可能包含了複制的資料。下面這個表是擴充版本的CUSTOMER表的一些行與列的子集：
可以清楚地看到，對于每個使用者，都有網站ID和網站标題兩列。不過，因為使用者共享網站，是以導緻一個特定的網站ID屬于一個特定的網站标題這樣的情況不停地重複出現。這個表将這個現象展現得非常清楚。例如，網站ID号為1并且該網站标題為世界一流電影這個組合，在這個非标準化的CUSTOMER表中被存儲了58 014次。這個現象出現的原因是非主鍵列WEBSITE_ID和WEBSITE_TITLE有一對一的關系，是以它就包括了重複的資料。或者用William Kent的話來說，WEBSITE_TITLE這一列是依賴着不是非主鍵的列WEBSITE_ID。
在很長的一段時間裡，标準化模式是設計資料庫表的首選模式。随着資料倉庫和資料集市的到來，另外的一些模式變得流行起來。星形模式和雪花模式是其中兩個最有名的模式。Ralph Kimball對于這些較新的模式形式貢獻較大。
圖2-10展示了一個用星形模式設計的資料庫。它代表了一些資料來自樣本資料庫（見圖1-13）。在星形模式中，表分為次元表和事實表。在這裡，CUSTOMER、DVD_RELEASE和DATE構成了次元表，TRANSACTION構成了事實表。星形模式名字的由來是因為其構圖特征，事實表在中間，次元表像射線那樣從中間發射出來，共同構成了一個星形的圖案。
每一個次元表都有一個主鍵和一系列的特征屬性來描述這個次元。CUSTOMER表就是次元表中一個典型的例子。在次元表中的每一行都代表着一些業務對象，在CUSTOMER表中，每一行代表着一個使用者。在次元表中，非主鍵列的資料是用來描述業務的。次元表與次元表之間沒有關系，隻與事實表有關系。
事實表是星形模式的中心表，每個事實表都有一個主鍵包含着它引用的所有次元表中的主鍵。事實表中的一行往往代表着一個業務事件。潛在的事實表的例子是從銀行賬戶取錢，一次航班的預定以及在櫃台前的一次支付。
在圖2-10中，TRANSACTION是事實表。它指的是其他三個事實表—CUSTOMER表、DVD_RELEASE表和DATE表，并且它的主鍵由那三個表的主鍵組成。這就暗示了在TRANSACTION表中，一行代表了一個客戶在具體日期購買或者租用一個具體的DVD版本支付了多少。一個事實表非主鍵的列是所有的量。通常，量是數值，是可加的數字，像租金、購買價格以及運費。事實表彼此之間沒有關系，隻是和次元表有關系（通常不隻一個）。
因為這個特殊的主鍵結構，事實表和每個次元表之間的關系總是一對多。并且，在TRANSACTION表中的每一行屬于且僅屬于一個客戶、一個DVD版本和一個日期。對每個客戶、每個DVD版本和每個日期，一定有許多交易。
星形模式中次元表和事實表中的主鍵由代理鍵值填充滿，這些主鍵對企業使用者是沒有意義的。是以，它們有時被叫作無意義鍵值。在大多數情況下，這些隻是普通數字。所有CUSTOMER、DVD_RELEASE和DATE表的主鍵包含代理、無意義的鍵。一個有意義的鍵（相反的）的例子是如果日期/時間值用作DATE表的主鍵值。代理鍵被用于獲得永不改變的、永遠代表業務對象（次元）或者業務事件（事實）的關鍵值。這些用于代表特定對象和事件的鍵值是必要的，因為它們是不變的常量。
值得注意的是，事實表有标準化模式，而次元表是非标準的。例如，在CUSTOMER表中，WEBSITE_TITLE和COUNTRY_NAME是不标準的，因為它們都是非主鍵并且它們之間存在着一對多的關系。當有很多客戶住在同一個國家的時候，他們都有同一個國家名字和相同的ISO3166國家代碼，這是重複資料，是以這個表是不标準的。
幾乎每個星形模式都包含一個日期次元。這并不驚奇，因為一個事實表記錄了一些業務事件。由于這樣一個業務發生在時間的某個角落，事件的發生時刻是描述它的一個必要部分。在這個表中大多數的資料，像月份、周是衍生的資料。這些列是被增添用于提高查詢性能，但是也有一些列不包含衍生資料，如假日。
以星形模式安排表的主要目标是限制做連接配接查詢的時候必須參與的表的數目。經常提及的改善查詢性能方式是避免表之間的連接配接查詢。另一個優點是書寫查詢和為最終使用者提供一套能從工具中生成查詢的選項變得更容易。事實上，重複資料增加的存儲空間不是主要因素。另外，重複資料造成的資料不一緻性被認為是不嚴重的問題。它在一個資料倉庫的環境裡，所有插入和更新都被執行在控制模式下是有意義的。
一個資料存儲可以包含許多事實表和諸多星形模式。如果事實表共享了相同的次元表，這些次元表被叫作一緻性次元表。隻有事實表被相同的次元表通路這樣一個方式設計，上述情況才可能發生。
從某種意義上來說，雪花模式和星形模式很像，都是由中心的事實表連接配接多個表并使用了代理主鍵。最重要的不同是雪花模式中的次元表是标準化的（如圖2-11所示）。如圖2-11所展現的，一些列從CUSTOMER表删除了，并且放在了三張外加的表中。
雪花模式中的事實表隻和次元表有關，這一點和星形模式一樣。而另一方面，次元表可以和其他的表存在一對多的關系。例如，每個區域可以有很多顧客，但是每個顧客隻能屬于一個區。從某種程度上講，這些次元表構成了層次。例如，在圖2-11中，CUSTOMER表是在REGION表的下一層，而REGION表在COUNTRY表的下一層。換句話說，REGION表中的資料粒度級别比CUSTOMER表中的低。事實上，雪花模型和星形模型都不存在多對多的關系。
雪花模式的優點在于，與等價的星形模式相比減少備援資料存儲。除此之外，雪花模式還可支援次元表中更低級别的查詢。就查詢而言，為了擷取一個網站标題的URL，隻需查詢一個小表即可。至于雪花模式的事實表和次元表中的關鍵字，和星形模式中的一樣，它們都包含了代理鍵值。