数据模型的探讨与分析-CDA数据分析师官网

数据模型的探讨与分析

2017-11-09

数据模型的探讨与分析

在工作中，关于概念模型、逻辑模型和物理模型三个数据模型的探讨中，发现大家都有自己的见解，但是却没有一个人能真正的说清楚这三个模型的涵义与差异。

虽说由于这三个模型在软件开发的过程中，由于其功能与作用的差异，结合项目规模等实际情况，不一定会全部使用以节省项目时间（有时候直接设计物理模型），但我认为不应该被冠以“大家对这个概念的理解不同”不同之名而歪曲数据模型的定义。事实上，这三个模型的概念是清晰的、标准化的。

1.2约定

本文中讨论的概念模型、逻辑模型和物理模型，主要是针对数据模型而言，也就是概念数据模型、逻辑数据模型和物理数据模型，而不是系统分析与设计中泛义的概念模型、逻辑模型和物理模型。

2数据模型的定义与分析

2.1概念模型

2.1.1定义

概念模型，是面向数据库用户的真实世界的模型，主要用来描述真实世界中的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的数据管理系统（Database Management System，简称DBMS）无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。——百度百科

概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。——Jerome's BI BLOG

我简单化归纳一下：概念模型，就是利用自然语言对真实世界的业务数据的抽象化描述，是面向终端用户的数据架构。

2.1.2作用

概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。

2.1.3实例分析

下面举两个例子来说。

例一：

先进行一番业务描述：我们的项目计划，一般包括年计划和月计划，年计划可分解为月计划。

我们来理解一下这句业务上的描述，可以把它分解为两部分：“计划包括年计划和月计划”和“年计划可分解为月计划”。我们从业务层面上，可以抽象出两个数据对象：年计划和月计划。

再用概念模型E-R图表示如下：

概念数据模型一：

概念数据模型二：

概念数据模型一是不完整的概念模型，概念数据模型二就是完整的概念模型。

原因：从概念数据模型一里面无法判断其中有多少隐藏的信息，当然你可以在另一个地方描述存在年计划或月计划这种业务情景，但是在这里你没有描述出来，所以至少在这里它是不完整的？我想问：此时不说，更待何时？

例二：

对于概念模型有一种典型的情况。例如，下面是一组关于财务审计系统中的概念数据模型：

姑且勿论这个概念模型是否正确，至少它是粒度很粗很不完整的。

对于“财务数据”来说，它并不能做为一个实体，而是其中包含了多个实体（包括账套，凭证，科目等相关实体），把它们（财务数据、审计数据与结果数据）定义为数据域（财务数据域、审计数据域与结果数据域）也许更加准确，而不是把它定义为一个数据（实体）。

“财务数据”域完整的概念模型，应该如下图：

（这里我假设这个概念模型里的实体是完整的，实际的财务系统当然不止这三个实体。）

这里也许有个疑问：这没问题啊，先系统性，再结构化嘛。

在此，我也真的很纠结，想想还是先不对这一句话解释太多，我们先进入概念模型的设计原则的讨论。完了之后，希望大家能找到“先系统性，再结构化”这句话的真谛。

2.1.4设计原则

我们先来引用一下数据库设计范式里面第三范式的描述：第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

在系统分析中对于数据架构的分析，一般原则是以数据实体为基本元素，即每个实体不可再分解为止。这也正符合数据库设计三范式里面第三范式的定义。

如果在分析阶段数据对象没有细化到最小粒度的数据实体，那么相当于把系统分析的工作留给了下一阶段的设计人员，从某种角度上来讲，这是不符合系统分析与设计的原则的。因为系统设计人员的工作是根据分析结果进行设计，而不是还要进行系统分析。

一：分析阶段要清楚问题的所有内容，即系统做什么。也就是：What to do.

二：设计阶段的设计工作是根据系统分析的结果而进行的，不完整的系统分析结果无法得到一个完整的系统设计结果。I don't know what to do, I don't know how to do.

对于结构化的分析我们一般的原则是：

一、使用一个总体结构图来描述各个数据域之间的关系，然后对数据域里面的所有数据实体进行结构化的分析与设计。

二、对于同一个数据域的结构化层次最多不超过三层结构，最好不超过两层；对于不同数据域由于系统规模较大，如果在同一个篇幅里面无法完全描述出来，则可以切片分章节对不同的数据域进行结构化的描述。

2.1.5小结

概念模型设计阶段，主要处于系统分析的阶段，属性可以不完全描述，但也可以描述一些主要的属性。如果你在E-R图上不给出属性，可以选择一个专门的表格来描述。另一方面，同一个实体的详细信息，在一个地方描述就好了，不要每一个涉及该实体的地方都描述一番。因为如果实体有变化的时候，我想有些实体会在几百上千个点上，你也不会每一个地方都去维护一次。

下面引用Jerome's BI BLOG里面的一句，这一句话很重要，也是理解概念模型与逻辑模型之间的区别的关键。

概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。——Jerome's BI BLOG

2.2逻辑模型

2.2.1定义

逻辑模型，是用户从数据库所看到的模型，是具体的DBMS所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系统，主要用于数据库管理系统（DBMS）的实现。——百度百科

2.2.2作用

逻辑模型是概念模型从真实世界向计算机世界的转换，加入了系统设计的相关内容。

逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。

2.2.3实例分析

例如：接着上面“计划表”的设计，“计划表”的逻辑结构，如下图所示。

其中：

1.计划标识：这是由于系统设计的需要而加进来的，与业务无关的属性。

2.计划类型：0：年计划；1：月计划；2：季度计划。（这里使用整型表示，当然可以是字符、字符串或其他自定义类型，这完全是设计上的事，一般不要在系统分析阶段啰嗦这些，客户不关心的事儿。）

虽然计划在业务概念上来讲，存在年计划、月计划，甚至于季度计划，但是在计算机世界中，计划的类型除了在概念上不一样之外，其他属性都是一样的，那么逻辑模型设计的时候可以把计划数据定义为一个实体，而使用其中的一个字段来标识某一份计划是年计划、月计划，还是季度计划。

2.2.4设计原则

逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。

逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。

例如，在“计划表”逻辑模型中可能加入了由于系统设计需要的一些字段（属性），这些字段可能是在业务概念上不存在或不需要的。

2.2.5小结

逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。——这一句话很重要，也是理解逻辑模型与物理模型之间区别性的关键。

2.3物理模型

2.3.1定义

物理模型，是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有起对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构。 ——百度百科

2.3.2作用

物理数据模型的目标是指定如何用具体的数据库模式来实现逻辑数据模型，以及真正的保存数据。

2.3.3实例分析

例如：对于计划表，基于SQL Server数据库管理系统为存储介质的物理模型结构。如下图所示：