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.