数据架构是业务和应用系统建设的桥梁，贯穿了业务、应用及技术架构，成为链接彼此的桥梁。本文就数据架构之数据建模展开分析，一起来看看吧。

数据架构是业务与应用系统建设的桥梁，数据架构基于业务架构（业务模式、流程、规则等）识别出业务数据需求，统一数据语言及操作手段，作为应用架构（系统功能、组建、接口等）和技术架构（技术指标、技术选型等）设计和开发的依据。

简单说就是——数据架构贯穿了业务、应用及技术架构，成为链接彼此的桥梁。

因为笔者不是技术人员，在技术这块知识不是很足，所以不会往技术的部分深入，而是通过梳理数据架构的内容，去反哺因为及应用部分。

完整的设计数据架构的步骤如下所述:

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、严格执行——对标准的使用，引用已经定义好的内容，对于新的内容需要先明确定义，达成共识再使用。

总结

通过以上内容，我们了解到数据建模的整个过程。通过商业模式中的价值链，我们能够映射出数据主题域。

按照业务流程的顺序，去梳理出业务对象，并将业务对象之间的数据关系处理之后，就能够得到概念数据模型。

我们在讲业务对象进一步拆分，能够得到业务对象及附属项目的关系，这就是逻辑数据模型，相当于主表和子表的整体关系。

描述业务对象的子项目就是一张张的数据表，也就是产品中的表单，那么我们进一步梳理表单中的字段及字段的属性值、大小、类型等，就能够得到一张表的模型，这个模型就是物理数据模型。

通过链接各业务对象，并表明数据的流向，我们能够知道业务中数据是如何流转的

通过梳理数据表单在各系统之间的控制权限，我们能够得到数据的分布图，这能够看到数据是否被合理的使用控制。

另外在建模中，我们要注意数据的标准，是的数据的定义等需要标准、明确、清晰。

到此，我们对整个业务的数据建模就完成了。