3NF淺談BI領域的資料模型設計

/**********************************/

目錄：

第一部分：基礎概念

第二部分：設計方式

第三部分：銀行業資料模型基本概念介紹

第四部分：銀行業資料模型分主題介紹

第五部分：ODS和EDW

/**********************************/

第一部分：基礎概念

1.什麼是LDM(Logic Data Module)

LDM是一個業務組織的資訊表示方式

不是Database

平臺獨立

是對業務資料的邏輯表示

定義存在的資料實體和它們之間的關係

業務人員透過LDM就可以知道其業務問題能否被解決

2.LDM的特點

穩定性：

可以長期滿足業務需求

正確性：

對真實世界的業務one-to-one 的資料對映

共享性：

不是為特定部門或特定應用需求而設計

靈活性：

當業務環境變化後，只要進行最小的改動

3.LDM的行業特性

不同行業有不同的LDM參考模型

通訊(Communication) cLDM

金融(Financial) FISLDM

醫療(HealthCare)

零售(Retail)

交通(Transportation)

旅遊(Travel)

製造(Manufacture)

4.為什麼要使用LDM(實施端)

減少成本(cost savings)

降低風險(Reduce Risk)

1:1 Mapping(LDM->PDM)

低維護量(Low Maintenance)

溝通(Communication)

全企業級(Cross Functional)

客戶中心(Customer Centric)

5.為什麼要用LDM(客戶端)

生成一個精確(accurate)和一致(consistent)的業務資料檢視

對業務規則的清晰表達

可以超越當前資料的侷限,提供資料整合的路線圖

對各個層級的參與者提供溝通的手段

6.建模框架( Data Modeling Frame Work)

7.LDM(Logic Data Module)和PDM(Physical Data Module)

8.LDM和ERD

ERD (Entity Relationship Diagram)

ERD 是一個標準建模技術，對LDM進行圖形化的表達

ERD技術可以透過不同的產品進行體現：

Erwin

Power Designer

Visio

ERD 需要表達：

實體(Entity)。所有事物

關係(Relationship)。不同業務實體之間的關聯關係

屬性(Attribute)。實體或者關係的資料事實(data fact)，是最低層級的資訊，且業務含義不可拆分

主鍵(Primary Key)

關係描述符(Relationship Descriptor)

外來鍵(Foreign Key)

9.LDM和Table Layout (表樣式)

Table Layout 透過在LDM中加入樣例資料(sampling data)，使得業務人員可以更直觀的理解資料。

鍵屬性用藍色表示，非鍵屬性用紅色表示

第二部分：設計方式

建模方式：

第一步:定義業務需求與範圍(Requirement)

第二步:定義實體(Entity)

第三步:定義關係(Relationship/PK/FK)

第四步:定義屬性(No-key Attribute)

第五步:驗證模型(Verify)

第六步:正則化(Normalization)

第七步:歷史資料建模(History Modeling)

第一步:定義業務需求和範圍

LDM的構建是一個漸進的過程，也是隨著企業業務和管理模型不斷擴充套件而演進的。

LDM是對資訊的表示方式，資訊的分類就是主題，透過主題定義資訊的範圍

同一主題的內容也可能隨著業務進行擴充

第二步:定義實體

什麼是實體：

需要表達和維護的資訊就是實體，可以包括人、地點、產品等任何概念。實體是邏輯模型的概念，對應物理模型就是表。

實體的名稱：

在整個模型中是唯一的

一般是一個名詞(如客戶)，可以加上修飾詞(如VIP客戶)

實體定義時會發生的錯誤：

同義不同名(如員工worker和僱員employee)

同名不同義(如產品和促銷都定義為product)

實體中的主鍵(Primary Key)：

主鍵是實體中的每個例項(instance) 區別於其他例項的標誌。在物理模型中，主鍵是不同行(row)的區分標誌。

在定義實體時，一般要最先定義主鍵。在圖形表示的時候，一般放在最前面。

定義主鍵的一些原則：

每個實體(表)必須要有主鍵。即使表是multiset(可能出現重複記錄)也必須要有主鍵。

每個表只能有一個主鍵。

主鍵值必須唯一(ANSI標準允許不唯一，為了保證資料載入效能，可能主鍵值不唯一)

主鍵值不能為空

主鍵值不能被修改

主鍵值可以由多個值構成。

第三步:定義關係(Relationship)

什麼是關係(Relationship)：

關係是兩個不同實體互動方式的表達(如客戶購買產品，員工在那個部門)

直接關係與間接關係如下圖所示，在模型中，只要定義直接關係，而不用定義間接關係。

定義關係的原則：

關係是唯一的(由涉及的表唯一標示)

關係對與實體內的所有例項都是適用的(物理模型中對錶中的所有row都是適用的)

需要定義關係的集合表達方式(cardinality)。如1：1、1:M、M:M

定義關係的步驟：

Step1: 識別實體之間是否有關係

是否存在關係

是直接還是間接關係

定義關係的名稱

Step2: 識別實體之間的集合表達方式

1:1

1:M

M:M

Step3:用外來鍵(Foreign Key)將關係表達出來

外來鍵是表示兩個實體中的例項的互相的數量關係

外來鍵定義的原則：

一個實體可以有0/1/M個外來鍵

外來鍵的值可以不唯一(1:M/M:M)

外來鍵的值可以為空(客戶可以沒有賬戶)

外來鍵的值可以被更改(客戶的賬戶號可以被修改)

外來鍵可以由多個屬性構成

A表的外來鍵的屬性和值必須在B表中的PK中存在

定義M:M關係需要新建一個關係實體(Associative Entities)：

客戶與產品的關係是M:M關係，所以需要定義一個關係實體(訂購 subscription)

將A實體與B實體的主鍵放在一起，就構成了關係實體。

關係實體的主鍵是A實體主鍵+B實體主鍵

遞迴關係：

在實體內部存在的關係，實體的外來鍵是本實體的主鍵

如下圖所示

管理者本身也是一個員工

MgrEmp# 是Empolyee外來鍵，對應的主鍵是Empolyee的Emp#

第四步: 定義屬性( Attribute Modeling)

屬性是描述實體(entity)的相關的、細節的資料項

定義屬性的原則:

名稱在本實體內唯一

與本實體相關

不能夠被別的屬性所描述

有單一的值域空間

屬性應該是對實體內的所有例項都是有效的

屬性的型別:

鍵屬性(主鍵、外來鍵)

非鍵屬性

派生屬性，能夠從別的屬性中計算而得的屬性

第五步:驗證模型(Verify)

透過模型驗證發現上述4步的問題，不斷修正，多次迴圈。

與客戶討論，確認客戶的業務需求、業務問題和業務約束條件能否透過模型進行體現。

不要考慮任何有關物理模型的問題。

但客戶的業務需求能夠透過模型進行表達，就結束模型的最佳化。

第六步:正則化(Normalization)

正則化是設計實體的屬性的規則，使得實體-屬效能夠更加精確的反應客觀事實

正則化的作用:

減少資料冗餘(避免資料多處儲存)

減少由於資料修改導致的資料不一致(只修改了一處資料，而另一處忘了修改)

正則化的原則“一個事實，一處存放”(one fact ,one place)

1NF，2NF，3NF 解決非鍵屬性對主鍵的依賴性

4NF, 5NF 解決是鍵屬性互相之間的依賴關係。

一般LDM建模只要求到3NF

什麼是3NF:

1NF: The Key(有主鍵，且沒有重複的屬性)

2NF: The Whole Key (非鍵屬性對主鍵的依賴關係)

3NF: And Nothing But Key(屬性對主鍵依賴關係是直接的，而非間接的)

第七步:歷史資料建模(History Modeling)

業務人員不僅要對當前(current)的資料進行分析，而且要對資料的變化進行追蹤(track)，而且需要對歷史資料進行分析。

這就要求對資料的變化歷史進行建模，這就是歷史資料建模(History Modeling)

History Modeling的原則：

Current和History：

如果在模型中既存在當前實體(current entity)也存在歷史實體(history entity)，那麼當前實體的資訊必然是冗餘的。

在設計LDM中，只需保留歷史實體，在進行物理模型設計時，可以加上一個當前標誌(current flag)，表明哪些記錄是對應當前實體的資訊。

歷史資料建模：

將需要儲存歷史資訊的屬性放入到歷史實體(History Entity)中。

時間屬性作為主鍵的一部分。

歷史實體(History entity)的主鍵必然是一個符合主鍵(包括多個屬性)

First Normal Form (1NF)

First normal form (1NF) sets the very basic rules for an organized database:

· Eliminate duplicative columns from the same table.

· Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).

Second Normal Form (2NF)

Second normal form (2NF) further addresses the concept of removing duplicative data:

· Meet all the requirements of the first normal form.

· Remove subsets of data that apply to multiple rows of a table and place them in separate tables.

· Create relationships between these new tables and their predecessors through the use of foreign keys.

Third Normal Form (3NF)

Third normal form (3NF) goes one large step further:

· Meet all the requirements of the second normal form.

· Remove columns that are not dependent upon the primary key.