Rational Data Architect 中的邏輯數據建模
表規范化和反規范化
表規范化是指將實體劃分為多個物理表的過程。規范化通常是一種邏輯數據建模應用。規范化的目標包括：
消除冗余數據。
使用有效的數據依賴性。
最大化系統靈活性，以適應數據結構的未來增長。
第三規范形式（3NF）將第一規范形式和第二規范形式的規則組合在一起，並結合了 3NF 的獨特需求。簡單來說，3NF 的規則如下所示：
消除重復的組 – 為每一組相關屬性生成一個單獨的表，並為每個表提供一個主鍵。
消除同一表中的重復的列。
為每一組相關數據生成一個單獨的表，並使用一個惟一的列或列集合（主鍵）識別每一行。
消除冗余數據 – 如果某個屬性只依賴一個多值鍵的一部分，那麼將其移動到一個單獨的表中。
移除被應用到表的多個行的列數據，並將它們移到單獨的表中。
通過使用外鍵在表與表之間生成有效的關系。
刪除不依賴主鍵的列
如果屬性沒有用於描述鍵，應當將它們移動到一個單獨的表中。
在創建邏輯數據模型時，模型應當位於第三規范形式（3NF）。這種設計方法為用戶提供了靈活的模型，可以隨著業務需求的發展和變化進行增長和擴展。盡管建議對邏輯模型使用第三規范形式，但是當以第三規范形式部署模型時，它們常常不能有效地運行。
規范化示例
下面的示例旨在幫助您理解規范化的過程。有許多種方法可以建模問題解決方案，但是本節的目的是提供對規范化的理解。
例如，某些人也許會認為您永遠都不應該規范化表中的名稱，而另一些人則認為應該對名稱進行規范化，因為如果創建了一個存儲中間名的列，那麼您會遇到這樣一種情況：許多人實際上並沒有中間名。因此，您將得到許多值為 null 的記錄。正如此例展示的一樣，數據建模是一種經常無法給出確切解決方案的技能。
對於這個規范化示例的其余部分，假設規范化發生在一個邏輯數據模型中。相同的原則可以應用於一個物理數據模型，但是術語替換是必須的，其中術語實體被替換為表，而屬性被替換為列。
在本例中，在檢查完某些基本需求後創建了一個反規范化實體：
反規范化模型：
遵循第一規范形式
要遵循第一規范形式（1NF），從實體中去除所有重復的組。要移除這些重復的組，需要為每個重復組創建一個新實體並為每個實體創建一個主鍵。為了維護被移入到單獨實體的數據之間的關系，需要定義外鍵關系。
重復組的一個例子就是具有多個雇員的經理，這些雇員向經理遞交報告。向每一位經理遞交報告的雇員的數量可以是不同的。例如，某名經理擁有兩名向其遞交報告的雇員，而另一名經理擁有十名向其遞交報告的雇員。如果經理實體為每一位向其遞交報告的雇員包含一個屬性，那麼經理實體需要十個雇員屬性來容納第二個經理。第二個經理將用一個值填充所有十個屬性，而第一個只擁有兩名雇員的經理將有 8 個屬性會包含一個 null 值。這導致存儲空間的使用效率變低。
使用我們前面的反規范化模型，通過去除以下重復組來實現第一規范形式：
Address Line I、Address Line 2 和 Address Line 3
Customer First name，Customer Last Name
第一規范形式：
要使反規范化模型遵守 1NF，重復的數據元素組將被規范化為單獨的實體。
客戶名被規范化，因為如果將來需要用到表示中間名的字段時，那麼因為許多人並不使用中間名，因此會導致出現大量的冗余數據。並且，對名字進行規范化可以避免將其他與名稱有關的屬性添加到實體，比如名稱後綴（例如 Jr.、Sr. 或 III）或名稱前綴（例如 Mr.、Mrs. 或 Ms.）。
遵循第二規范形式
要遵循第二規范形式（2NF），模型必須位於第一規范形式，並且您必須將應用到實體的多個行的列數據移動到單獨的實體中。
這將導致創建新的實體，其中每個新實體必須定義一個主鍵。要維護被移動到單獨實體的數據之間的關系，必須定義一個外鍵關系。
數據子集的例子包括始終擁有相同郵政編碼的城市和州。如果一個地址實體包含一個城市屬性、一個州屬性和一個郵政編碼屬性，那麼在城市、州和郵政編碼之間始終存在一種模式。對於任何使用相同郵編的地址，這三個屬性的數據都將全部重復使用。這導致存儲空間的無效使用。
因此，城市、州和郵編這三個屬性都可以從實體中移出並放到一個單獨的實體中，其中郵編將作為主鍵使用。通過使用郵編列作為外鍵，可以在郵編實體和當前地址實體之間建立關系。
要實現 2NF，使用我們前面的反規范化模型，刪除以下潛在的數據冗余
Customer Names
Customer Addresses
第二規范形式：
要遵循第二規范形式，必須遵守第一規范形式，並且任何屬性都必須完全依賴於復合鍵的任意一部分。
遵循第三規范形式
要遵循第三規范形式（3NF），模型必須位於第二規范形式（來自第一規范形式），並且您必須移除任何沒有完全依賴單獨實體的鍵的屬性。當某個屬性依賴於另一個屬性，而後一個屬性並非主鍵的一部分，那麼這就是一種臨時的依賴關系。這將導致創建新的實體，其中每個實體必須定義一個主鍵。為維護被移出到單獨實體的數據之間的關系，必須定義一個外鍵關系。
第三規范形式：
要遵循 3NF，必須刪除任何臨時性的依賴關系。當非關鍵字段的值由另一個非關鍵字段的值確定時（即不屬於候選鍵的一部分），那麼此時將出現臨時性依賴關系。
反規范化
對於反規范化的其余部分，假設反規范化發生在一個物理數據模型中，因為反規范化通常是一種物理數據建模應用。相同的原則可以應用於邏輯數據模型，但是必須進行術語替換。
星型模式和雪花型（snowflake）設計在數據倉庫（商業智能）系統中變得十分流行。星型模式的主要概念就是將系統的“事實”與“維度”分離。
維度被定義為數據的屬性，比如位置、客戶或部件，而系統的事實指的是特定於時間的數據事件。例如，部件描述通常不會隨時間而變化，因此可以將其設計為維度。相反，每天售出的部件的數量是隨時間變化的，因此被設計為事實。
由此生成的模式被稱為星型模式，因為它的典型特征就是具有一個很大的中央事實表，其中保存隨時間變化的事件，而在理論上圍繞這個表的是一組維度表，其中保存事實表中引用的內容項的元屬性。
雪花型設計實際上是對星型模式的一個擴展。在雪花型設計中，低基數的列常常被從星型模式的維度表中移動到另一個維度表，然後在兩個維度之間建立一種關系。
反規范化是一種將表重疊在一起的過程，因此很可能會增加數據庫中的數據冗余。反規范化對於降低數據庫復雜性或減少連接數（用於獲得所需數據）是有用的。數據庫復雜度可以通過減少表的數量而降低。反規范化的主要目標是最大化系統性能並減少系統管理的復雜度。
雖然某些用戶可能會在其邏輯數據模型中使用反規范化，但通常不建議這樣做。反規范化會降低數據模型的靈活性，而這正是邏輯數據模型設計的目標之一。反規范化應當是一種物理數據建模任務，用來滿足性能需求或降低針對特定數據庫環境管理和開發系統的復雜性。
邏輯數據模型規范化最佳實踐
邏輯數據模型應當始終遵循第三規范形式（3NF）。
一般化關系
一般化關系指父實體與子實體之間的特殊關系，可以幫助在查看邏輯數據模型時發現更多的含義。父實體被稱為超類型，而子實體被稱為子類型。子類型是父類型的一種，因此一般化關系也因此被稱為超類型 - 子類型關系。
例如，關閉的帳戶就是帳戶的一種類型。打開的帳戶是另一種帳戶類型。它們各自可能擁有自己的獨特屬性，但是父類型具有通用的屬性。因此打開的帳戶可能具有一個余額，而關閉的帳戶可能有一個關閉日期。父類型可能有一個帳戶打開日期，因為所有帳戶，不管是打開的還是關閉的，都需要一個打開日期。通過給出前面描述的一般化關系，用戶可以從邏輯圖表中獲得更多含義。如果所有這些屬性都包含在一個單一帳戶實體中，那麼對於為什麼每個帳戶都需要有一個關閉日期這一點會產生誤解，即使它們永遠也不會關閉。下圖中的實體看上去不是很明白：
不具備一般化關系的帳戶實體
具有一般化關系的帳戶實體
第二個圖表提供了更多價值，因為它更清楚地解釋了哪些屬性屬於特定類型的帳戶。
一般化關系是一些特殊的關系，不僅是因為它們通過更好地表示數據模型而提供了額外的價值，還因為您可以在創建物理模型時選擇如何轉換它們。適合邏輯模型的設計並不一定是適合物理模型設計。
例如，在物理模型中，您出於性能考慮而希望使用一個單獨的帳戶表。您可以輕松地在父表中實現子類型。另一個選擇是將父表下推到子表中。來自父表的相同列（來自邏輯模型的屬性）將存在於每一個子表中。第三個選擇是僅僅將表保持原樣。為了提供更好的理解，這些類型的轉換的結果如下所示：
一般化向上轉換
一般化向下轉換
一般化獨立表轉換
一般化關系最佳實踐
使用一般化和子類型關系為業務分析師提供更有意義的邏輯數據模型。
團隊共享
團隊共享
團隊共享在數據模型設計中是一個重要的概念。如果數據模型無法廣泛應用於由相關用戶組成的社區，那麼它對於組織就沒有多大價值。Rational Data Architect 合並了一些能夠使團隊共享變得簡單而又有效的概念。
使用包分離邏輯實體
將邏輯實體分離到包中可以幫助降低大型模型的復雜性，使它變得易於理解。這對於域模型和邏輯數據模型都非常有用。
從包中創建子模型
從包中創建子模型的能力是非常強大的概念，因為它可以極大地減少您將多處更改合並到一個團隊共享庫所花的時間。在使用團隊共享庫時，您通常需要簽入和簽出模型。
在 Rational Data Architect 中，將對一個完整的模型執行簽入和簽出。因此，即使對實體做了很小的一處更改，也必須將整個模型簽入。
如果兩名用戶簽出同一個模型並在作出修改後將模型簽入，那麼這時就會出現問題。第一名用戶可以順利地保存他做出的更改。當第二名用戶簽入所做的更改時，他們必須在團隊共享庫中將自己的更改與來自第一名用戶的更新後的版本進行比較，然後選擇希望將哪些更改遷移到庫中。隨著模型的不斷壯大，這將成為一項非常費時的任務。
一種解決方案就是使用支持分支的庫。通過進行分支，您可以在庫中擁有自己的分支，您在其中可以只簽入和簽出正在處理的模型。當您完成了自己的修改後，這些修改隨後必須被合並到庫中的項目的集成（或主）流中。因此您不再需要處理模型合並問題，集成或項目管理器現在負責將各種分支合並到主流中。這是一個強大的概念，但是許多組織並不願意投入資源來建立這樣一種庫。
另一種解決方案是使用 Rational Data Architect 內的子模型功能處理這種情況。子模型使您能夠將一個大的模型分解為一些更小的模型。訪問大模型的任何人都可以訪問這些更小的模型。如果您希望對其中一個小模型（或子模型）做出更改，您只需要簽出這個小模型。當您完成更改後，需要將這個小模型簽入。
這可以幫助減少涉及模型合並的模型簽入沖突，因為如果兩個人各自處理一個單獨的子模型，他們可以同時簽入自己做出的更改，並且不會影響到另一個人。如果較大的模型沒有被劃分為子模型，第二個用戶如果要簽入自己做出的更改，他們必須使用比較特性手動將更改合並回庫中。
通過使用子模型，用戶不需要手動將更改合並到庫，從而節省了 時間。當沖突發生時，與合並完整模型相比，使用更小的子模型可以更輕松、更快速地實現合並。
如何從包創建子模型
要從包中創建子模型，您必須已經具有一個現有的子包。子模型無法從模型的主（根）包中創建。當您擁有至少一個包時，您可以從其中創建一個子模型。
要創建子模型，執行以下步驟：
1. 在 Data Project Explorer 中，右鍵單擊現有包並選擇 Create Submodel from package。
團隊共享最佳實踐
使用包分離邏輯實體。
從包中創建子模型，最小化團隊共享的影響。
Rational Data Architect 中的物理數據建模
物理數據建模是指創建特定於數據庫的數據模型以滿足應用程序性能需求的過程。這是一項艱巨的任務，因為通常很難對數據庫系統的增長做出規劃，在商業智能環境中工作時尤其如此，在這種環境下，初始部署獲得成功後，對更多數據源的請求將被包括到數據存儲中。
在設計適合大多數數據庫的物理數據庫時，可以遵循一些最佳實踐。IBM 已經發布了有關針對 DB2 數據庫設計物理數據庫的最佳實踐文檔，但是 Rational Data Architect 是一款支持眾多數據庫的企業信息建模工具，因此其中一些最佳實踐通常也可以應用於數據庫設計。
規范化和反規范化
盡管在討論邏輯設計模型設計的小節中討論了規范化和反規范化，但是物理模型設計則遵循一些不同的原則。與維護適應未來增長的靈活設計相比，滿足 SLA（服務水平協議）的要求通常更重要。因此，在進行物理建模時，有一些方法非常適合用於特定的情況：
將 3NF 應用於大多數 OLTP 和通用的數據庫設計。只要能夠維護系統設計的靈活性時，通常會使用 3NF。
對於需要極高性能的數據倉庫和數據集市，星型模式或雪花型模型通常適合用於維度查詢處理。然而，任何星型模式模型應當進行檢驗，從而遵循在規范化邏輯數據模型中設計的關系。
對於多種用途的廣泛數據倉庫操作，比如操作數據存儲、報告、OLAP 和多維數據集（cube），IBM 建議使用一種分層數據架構，如下頁的圖表所示。這種分層數據架構是一種強大的范例，它涵蓋了豐富的內容，因此無法在此詳盡介紹。請參見本文檔末尾的 進一步閱讀小節，獲得更多有關這種針對數據倉庫的方法的信息。並非所有數據庫都支持這種方法，如果它們缺乏分層數據架構在構建性能級別（圖表的第三層）時所需的某些特性的話。
考慮對非常窄的表進行反規范化。數據庫中的額外的表會增加查詢復雜度並使管理復雜化。查找那些非常窄的表（每條記錄小於或等於 30 字節），作為反規范化對象。
IBM 分層數據架構
圖字（自上而下）：第五層， 指示板靜態報告，固定期限
第四層，維度、數據集市、多維數據集、持續時間：年
第三層，摘要數據，性能和上滾數據，持續時間：年
第二層，接近第三規范形式，主題曲與，代碼和引用表，持續時間：年
第一層，准備、細節、反規范化、原始來源，持續時間：60，120，180 ……（天）
規范化和反規范化最佳實踐
對於大多數通用數據庫，需要將表規范化為第三規范形式（3NF）；使用星型模式或雪花型模型處理維度查詢；使用 IBM 分層數據架構處理使用廣泛的數據倉庫在線分析處理（OLAP）和商業智能（BI）。
索引設計
索引提供了對存儲在數據庫中的數據的快速查找，它們對性能起到絕對關鍵的作用。
它們在數據庫中的應用包括：
應用謂詞，特別是作為開始或停止鍵
進行排序（例如 ORDER BY、GROUP BY 或連接）
提供只針對索引的訪問（不用訪問數據頁面）
實現惟一性
然而，索引也存在一些缺點：
索引增加了執行 UPDATE、INSERT、DELETE 和 LOAD 操作的成本
索引增加了編譯成本（優化器有更多的選擇）
索引會占用大量存儲
考慮以下針對索引設計的最佳實踐：
在數據庫中對所有主鍵和大部分外鍵使用索引。
大多數連接發生在主鍵（PK）和外鍵（FK）之間，因此應當盡可能在所有 PK 和 FK 之間構建索引。
考慮對 SQL WHERE 子句中頻繁引用的屬性進行索引。
這一規則的一個例外就是謂詞為一個不等式的情況，比如 "WHERE cost <> 4"。索引在不等式中沒有什麼用處，因為不等式涉及到很多選擇。
對等式和范圍查詢使用索引。
