基本但却重要，看似简单但却容易流于形式：做实数据模型设计的一些初级实践

前言

从事应用系统的开发，就离不开数据模型的设计。数据模型设计能力是我们开发和架构都是重要的基本功。

我们还是儿童的时候就接触到各种各样的表格，报名表、成绩单、个人信息表；在没有excel之前，人们就在本子上印上表格记录各种数据。所以，表格对我们来说，一点都不陌生，这种表达信息的形式、整理数据的方式，已经存在在我们的潜意识里，我们大脑在处理这种结构化整理后的信息的时候，也非常非常快。所以，当我们接触到关系型数据库的时候，会感觉一切都是那么的自然好理解。不管是不是科班出生的，不管有没有经过理论的训练，好像看看也就会了（人类太善于模仿了、抽象、总结了）。

所以，对大部分人来说，设计一套模型，支撑业务功能正确的跑出来，一点都不难。但是，很多事情，做出来容易，做好的话，就还要一些火候。做软件的开发，做一个能跑的不难；做一个性能好、易于维护、让后面的开发人员更好接手的系统，就需要我们捅破那一层从有到精的纸，利用一些套路了。

这篇实践，属于初级水平，主要是使用模型设计工具、基本的模型设计的概念、常见的一些问题。

1，使用模型设计工具

不用工具，也能设计出模型；用不用设计工具，就像我们是否交通工具一样，我走路，能到地铁站，我骑个共享单车，也能到，那我该怎么办，就看我的目的是什么。如果目的是考验自己的记忆力，对繁杂信息的快速理解能力，那么就不用使用设计工具。但如果我们是在做一个商业化的应用系统，以靠他吃饭为目的的，那我们就需要使用设计工具。图形化给人的信息传递非常快，使用设计工具确实来带来好处，有这样几个感受：

A，图形化的设计界面，可以更好地梳理设计思路

在软件开发过程中，设计数据模型的过程是对业务、对功能、对流程的理解的梳理和落地的过程。由于我们人脑天生对图形化有更快的处理速度，更直观的领悟能力，使用图形化的界面能降低我们在模型设计过程中的脑力消耗，让我们有更多地精力在理解业务、理解需求，从而更好地梳理我们的设计思路、设计出更好的模型；

B，开发过程中，能更快的帮我们知道、理解数据库结构

人的记忆力是有限的，如果涉及的表格、字段多了， 在开发过程中，不可避免地要回头来看数据表怎么设计的。这时，设计工具会加快这个过程，从而提高我们的开发效率。

C，方便日后的维护，系统升级，其他人接手，延长软件资产的生命

设计工具让人更快了解数据模型，通过设计工具看数据模型，显然，要比到数据库去看字段更快，理解了数据模型，对整个系统的理解就能更快。软件系统就是软件公司的产品，就是软件公司的资产，一个公司，往往一年就开发不少产品，使用工具，可以让其他人更好地接手，从而帮助资产保值。

模型设计工具，有一些，国内用得比较多的应该是powerdesigner，以前用12.5，现在应该是16.5了。我只用过powerdesigner。

2，基本的模型设计的概念

A，逻辑模型和物理模型

powerdesigner里面，逻辑模型生成的ldm，物理模型生成的是pdm（还有概念模型，这里先不表）。逻辑模型，就是不针对具体的数据库进行模型设计。为什么有这回事？因为不同的数据库系统支持的东西不一样，比如：ms access， ms sql server有自动增长，我们一些表格的主键id会使用这种类型；oracle有blob数据类型；mysql有tinytext类型等等。假如，我们设计的目标系统，是要支持不同的数据库的，那么，就需要逻辑模型，逻辑模型有自己的一套字段类型的定义，可以针对不同的目标数据库，生成不同的物理模型。如果，我们设计的系统，就是跑在某个具体的数据库上的，就不需要逻辑模型，物理模型就可以了。所以在设计物理模型的时候，工具会要求先选数据库，不然工具也不知道该提供什么数据类型让我们选择了。

B，关系的表达：reference， traceabilitylink

场景1：一个营业工号属于一个组织机构；组织机构本身是一个树，这里面就用到reference。工号表中的字段所属机构ID，引用组织机构中的机构ID，如果组织机构中没有10这个id，那么工号表中的所属机构ID也不应该存在10；

场景2，一个工号可能属于多个机构，这时就多了中间表了。

3，场景3：工号是某个角色； 权限授权给角色或者工号； 比如权限授权给某几个角色，和其他某几个特殊的工号；这时授权信息表有两种方式， 一种方式是：两个表，权限和角色的对应关系表+权限和工号的对应关系表；另外一种方式，是一个表，如下图；如果是一个表，那么就需要加一个字段：对象类型，表达授权给角色还是授权给工号？如果授权对象是角色，那么对象ID就是角色表的角色ID，如果对象是工号，那么对象ID就是工号表的工号ID；这时，就用到了traceabilitylink了。这个对象ID不是reference关系，用traceabilitylink表达

3，常见的问题

A，reference和traceabilitylink混淆。

如前面所说，reference是引用，A表的外键引用B表的主键，那么A表的该字段的值一定是B表中存在的（可空的话，或者为NULL）；traceabilitylink更弱的一点关系；

B，reference方向搞反

箭头指向的是主键（pk）；也可以从对应数量来看，通常两个表是1对N的关系，箭头指向1的那个；

C，原本有关系的表，都画成光秃秃的表，彼此之间没有reference关系

这就失去了准确性了，本来图上一看就知道谁和谁有关系，不画出来的话只能靠去看字段理解了。

D，忘记了为什么要用工具

见过像集成电路的pdm图；本来画图就是为了更快地传递信息，为了好懂；搞成了像集成电路一样，图上就是方块和看起来排列整齐其实烟花缭乱的线，这样的图的意义就减弱太多了。

那，怎样才能让图更加易懂呢，通常几种表达技巧：

场景1：表多； 

这时可以考虑多个diagram，每个diagram上画一组关系密切的表格，不同的diagram不同的组；

场景2：表太多；

这时可以考虑分不同的package；

场景3：一个表关联的表太多

如果图上就这一个表的话，那么必然出现很多交叉的线，这时可以考虑copy，在其他地方paste as shortcut，这样表还是一个，但是在图上可以有多个对应的图形，每个图形关联的表就可以不那么多了。

结语

这些东西都比较初级，但万丈高楼平地起，基本功做好了，我们就能更加得心应手。