數據架構是業務和應用系統建設的橋梁，貫穿了業務、應用及技術架構，成為鏈接彼此的橋梁。本文就數據架構之數據建模展開分析，一起來看看吧。

數據架構是業務與應用系統建設的橋梁，數據架構基于業務架構（業務模式、流程、規則等）識別出業務數據需求，統一數據語言及操作手段，作為應用架構（系統功能、組建、接口等）和技術架構（技術指標、技術選型等）設計和開發的依據。

簡單說就是——數據架構貫穿了業務、應用及技術架構，成為鏈接彼此的橋梁。

因為筆者不是技術人員，在技術這塊知識不是很足，所以不會往技術的部分深入，而是通過梳理數據架構的內容，去反哺因為及應用部分。

完整的設計數據架構的步驟如下所述:

A、數據模型——通過各層級的建模得出整個系統的數據模型

B、數據來源——數據的類型、采集方式及來源

C、數據的處理——數據清洗及轉化、集成、存儲

D、數據分析——如何分析數據

E、數據展示——以什么樣的方式來展示數據

F、數據應用——將數據應用在哪些方面

一、數據建模

整個企業架構的建模過程如下，從業務到應用、再到數據架構。每一個架構又從上而下、從粗顆粒到細顆粒度逐步拆解。數據架構也不例外，我們就來看看，如何搭建一個業務的數據架構。

數據建模，采用分層建模的方式，可以有如下幾個層級：

• 數據主題域——將頂級業務映射為數據，比如財務、倉儲等；
• 概念數據模型——梳理數據實體之間的關聯關系，比如采購合同、采購計劃等；
• 邏輯數據模型——梳理邏輯實體之間的關系，比如訂單表與其支付子表、優惠券子表的關系；
• 物理數據模型——數據表單對應的字段的類型、長度等。

二、數據主題域

1. 模型

我們從業務的整個價值鏈來看，一個價值鏈條就是一個業務，一個業務與對應一個數據主題域，比如以上可以得到這個制造系統的核心數據主題域：研發、采購、制造、倉儲、營銷、運輸。

我們選擇采購來進行分析：

2. 關系圖

單個業務域的數據主題域關系圖，與應用系統的比較類似，如應用系統中的采購管理系統下包含：

a、供應商管理；

b、采購計劃管理；

c、采購合同管理；

d、貨品庫存管理；

e、配送調度管理。

如果是多個系統的數據主題域關系圖則概略如下所示示意圖。

三、概念數據模型

概念數據模型就是梳理主題域中各數據主題中的業務對象，并將業務對象之間的關系梳理出來，這樣概念數據模型就搭建好了。

如下圖，用戶采購，1個采購會對應多個訂單，1個訂單又會對應多個商品。則其概念數據模型簡單說明如下：

我們進一步詳細的說一下，首先是要挑選出數據主題域中的業務對象，那什么是業務對象呢，有什么選擇標準，怎么樣來篩選呢？

A、業務對象包含：是業務領域中的人、事、物、地等，承載了業務運作及管理的重要信息，比如說書店管理系統中的：圖書、職工、會員、售貨員等。

I、人員角色——比如用戶、配送員、供應商、商家等

Ii、客觀存在的事物——比如商品、配件

Iii、一種行為、規則、過程概念——比如調度規則、賬戶

Iv、事件——比如訂單

以上簡單總結就是，找關鍵路徑上的人事物規則等。

B、業務對象具有唯一的標識信息，比如供應商有供應商編號

C、相對獨立，比如訂單和商品，本身互相是彼此獨立的

D、一般為主數據（各系統中共享的數據，比如商品、訂單等）及事務數據

建模方法1：DDD的四色建模法

1）首先以滿足管理和運營的需要為前提，尋找需要追溯的事件，或者叫關鍵業務時刻。

2）根據這些需要追溯，尋找足跡以及相應的Moment-interval（關鍵業務時刻）對象。

3）尋找“關鍵業務時刻”對象周圍的Party，Place or thing（人-事-物）對象。

4）從“人-事-物”中抽象出Role（角色）。5）把一些描述信息（Description）用對象補足。

舉例：

我們以一個線上書店的業務來說明，核心鏈條是：用戶瀏覽之后下訂單，支付成功之后，根據用戶的下單地址，給快遞公司下單，快遞公司根據快遞單進行運輸，最終送到用戶的手上。我們就得到一個主干的E-R圖，如下：

得到骨干之后，我們需要豐富這個模型，使它可以更好的描述業務概念。這時候，我們需要補充一些實體對象。通常實體對象有三類：人-事-物（Party,Place, or Thing）。如圖所示：

在這個基礎上，我們可以進一步抽象這些實體事如果參與到各種不同的流程中去的，這時候，我們就需要用到角色（role），如圖所示：

最后再把一些需要描述的信息放入描述對象（description）。如圖所示：

建模方法2

A、首先是根據業務梳理數據域得到了數據主題域

B、按照業務流程順序，梳理數據主題中的關鍵時刻

C、梳理關鍵時刻對應的主要人事物角色，

D、進一步細化、補充分支對象

E、并建立關聯關系

舉例：

我們將數據主題域中的業務對象找出來，并按照業務流程發生的先后順序，得到如下的圖：

我們再按照之前說明的如何找業務對象，將其中的主要人事物梳理出來，并進一步的細化，簡單示意圖如下：

以上是采購管理的部分，如果我們把其它的部分加上，比如財務結算，運輸環節，則會有各部分的示意圖如下。此圖形則一方面能夠展示各業務對象之間的關系，另外也能展示數據的流向，比如采購中是先有采購計劃，然后是有采購合同，所以也是一個數據流圖，同時也能展示數據的分布，可以算是一個數據分布圖。

最終的整體效果如下圖。能夠顯示整個應用系統中數據主題、業務對象之間的關系及數據在其中的流向，有一個宏觀而清晰的認知。

四、邏輯數據模型

1. 建模

邏輯數據模型是干什么呢？

是將業務對象及屬性結合，也就是將一個業務對象描述清楚。

比如訂單下會有：訂單支付、訂單配送、訂單購買用戶、訂單商品等多個子項，則我們進一步梳理清楚。

看起來感覺和概念數據模型差不多，有什么不同呢？

概念數據模型是梳理業務對象之間的關系，業務對象是彼此獨立的，而邏輯數據模型是作用于實體，彼此之間有層級關系，從屬關系，也就是說明一個業務對象及其下屬的關系。這個層級就需要細化到一個表單及子表的層級。

比如一個訂單的邏輯數據模型如下圖所示：

2. CRUD分析

當我們梳理了邏輯數據模型，也就是細化到數據表單的層級的時候，我們就能夠將主題域中的所有數據表單整理出來，我們將表單的控制權做關聯，比如哪些系統中需要操作對應的表單做清晰的展示，則得到如下的更細化的數據表單分布控制圖。

這個能夠清晰的看到各系統對相應數據是否有控制權，控制權是否超出本身權限范圍外，哪些系統沒有拿到應得的數據控制權限，都可以通過表單級別的數據分布圖做自我檢查和校驗。

五、物理數據模型

物理數據模型就細化到表單中的具體字段、字段的具體屬性值類型、范圍、大小等。如下圖為發票的物理數據模型示例。

六、數據標準

在建模過程中，我們會用到很多術語（業務術語是公司內部業務對象統一的定義）。

流程、IT系統界面會統一引用業務術語，以方便業務人員之間交流、IT系統之間信息的集成。一般來說，容易出現歧義的業務對象需發布業務術語以消除歧義提高溝通效率。

數據標準用于描述公司層面需共同遵守的屬性層數據含義和業務規則。其描述了公司層面對某個數據的共同理解，這些理解一旦確定下來，就應做為企業層面的標準在企業內被共同遵守。

• 在業務方面，業務相關對象、規則、定義等都需要明確。
• 在IT方面，也需要簡歷數據字典、對數據的類型、長短、類型、格式都要做限制。

最終達到：統一語言、消除歧義、調高溝通效率、減少錯誤、降低成本、調高客戶滿意度的目的。

簡單說明如下：

A、統一業務規則——業務上需要首先明晰

B、統一定義——達成一致，消除歧義

C、明確責任人——可以找到責任主體

D、嚴格執行——對標準的使用，引用已經定義好的內容，對于新的內容需要先明確定義，達成共識再使用。

總結

通過以上內容，我們了解到數據建模的整個過程。通過商業模式中的價值鏈，我們能夠映射出數據主題域。

按照業務流程的順序，去梳理出業務對象，并將業務對象之間的數據關系處理之后，就能夠得到概念數據模型。

我們在講業務對象進一步拆分，能夠得到業務對象及附屬項目的關系，這就是邏輯數據模型，相當于主表和子表的整體關系。

描述業務對象的子項目就是一張張的數據表，也就是產品中的表單，那么我們進一步梳理表單中的字段及字段的屬性值、大小、類型等，就能夠得到一張表的模型，這個模型就是物理數據模型。

通過鏈接各業務對象，并表明數據的流向，我們能夠知道業務中數據是如何流轉的

通過梳理數據表單在各系統之間的控制權限，我們能夠得到數據的分布圖，這能夠看到數據是否被合理的使用控制。

另外在建模中，我們要注意數據的標準，是的數據的定義等需要標準、明確、清晰。

到此，我們對整個業務的數據建模就完成了。