数据建模与存储

在业务需求分析过程中，概念模型描述了业务对象之间的关系，但概念模型毕竟只是业务侧的一种表述方式，为了支持系统功能的实现，还需要对其进一步的设计。

当前，为了对数据进行有效管理，形成了多种类型的数据库，比如以关系代数为理论基础的关系型数据库、以面向对象为理论基础的面向对象数据库以及面向文档管理的文档数据库（例如IBM的Lotus数据库）等。由于每一种数据库都有其适用的范围，同时每一类数据库都有不同的数据库实现产品，为了使得数据模型能够适应这些情况，保持数据模型的稳定性以及对不同数据库产品的适应性，通常将数据模型分为逻辑模型和物理模型两种类型。

逻辑模型侧重从业务角度来考虑实体/对象之间的关系，不同于概念模型，逻辑模型更加具体和细化，对于关系型数据库，通常采用范式设计方法，根据业务需求的不同采用不同的范式。为了更好地理解逻辑模型，我们下面举例说明。电信运营商的三户逻辑模型如图1-6-1所示：

 

图1-6-1 电信运营商三户逻辑模型

从图1-6-1可以看出，一个客户可以购买企业的多个产品，每购买一个产品就意味着形成一个订购实例，因此客户和订购实例之间是一对多的关系，同样，由于客户即包含了购买者，也包括使用者，这就意味着一个订购实例对应多个客户，因此，客户与订购实例之间为多对多关系。通过引入第三范式消除数据冗余，在客户和订购实例逻辑模型之间增加客户订购实例关系逻辑模型，从而将逻辑模型之间的关系变为一对多的关系。

顾名思义，物理模型就是那个最终要填充数据的模型。由于某个具体的数据库会有不同于其它数据库的特性，物理模型需要与具体的某个数据库产品对应，比数据项类型、长度等在不同的数据库产品之间不一定完全相同，比如整型在SQL Server数据库中以int表示，而Oracle数据库中则以number表示。

除了不同数据库产品在数据类型的定义方面存在差异之外，其它方面也可能存在很多区别，比如数据定义和数据操作语言SQL，通常是在标准SQL的基础上做了扩展，因此在考虑采用用哪一种数据库时，一定要综合数据库产品的价格、特性、售后服务等方面，选择适合的数据库产品。

与业务过程经历了从业务过程=>能力蓝图=>技术实现的逐步落地过渡过程类似，数据模型同样也经历了从概念模型=>逻辑模型=>物理模型的逐步落地的过渡过程，如图1-6-2所示：

 

 图1-6-2 业务过程侧与数据模型侧从业务到实现的过渡过程对比

从图1-6-2可以看出，业务过程与数据模型都是从业务需求逐步过渡到具体实现，但都不是一次到位的，都经历了中间一个过渡阶段。之所以这样做的原因是由于专业化分工不同，各参与方的背景知识不同，业务和技术人员对于同一个事物的理解也不一样的，为了消除这种差异以及更好地做好各自擅长的工作，需要通过一个中间媒介来促进共识。对于业务过程来说，需要通过能力蓝图来达成业务人员与技术人员的共识，对于数据模型来说，需要通过逻辑模型达成业务人员与技术人员的共识。