给进行数据模型设计的同事的几点设计建议

前日下午过了下班时间，看同事A还没有回去。问A为什么还不回？A说正在整理下午的内部设计评审的内容。

接着又询问了下午他们内部设计评审，总有多少人参加并且提出了多少个问题（其实想通过这个问题了解到提出问题的效率以及能力）。从回答的数据上来看，我觉得对于项目的第一次技术评审，该数据还有很大提升的空间。

简单看了一下他们项目组的模型设计，我给A几点建议：

1. 美观上去改进，给人看起来舒服，特别不要出现斜线、斜线交叉、实体对齐以及大小自动调整；
2. 多用Note表达一些设计者的意图，特别是在一些不能按常规思维考虑的地方，即使在设计文档里有阐述，也必须在模型上使用Note来给读者一个钥匙或者“指路”；
3. 刚好打开某实体，其中有属性命名为“状态”，相信该状态肯定有状态迁移图，询问了说在设计文档中有描述，OK，但是在模型中没有该状态属性的缺省值，是正确吗？另外状态的属性用什么字符串来表达呢？是S代表开始，还是Start，还是直接存“开始”；
4. 刚好打开某实体，其中有属性命名为“次序”，询问了次序这个属性怎么记值，是1..n呢？还是10、20、30这么记？并且告诉同事，“次序”往往还跟你的UI实现有一些关系，是只提供提供Up/Down调整呢？还是支持Drag方式来调整次序？方式不一样，可能设计中要存储的实现方式也不一样。

虽然只是走马观花看了一下，我觉得有必要结合这几年给大家进行设计评审的经验，总结一些模型设计时大家经常忽略的问题，给大家参考，分几个方面进行论述：

模型中表达实体和实体的关系图，在全局、易懂、上手、美观上的考虑；

1. 全局性考虑，不要将系统的所有实体都组织在一张图上；根据系统的主题域进行切分，主题域是可以分层级关系，不一定只有一层；
2. 每个主题域的实体关系图，布局控制在一张A4纸以内，这样的好处在于一看就能看到该主题域的所有实体，而且当你打印出来也方便阅读；使用CASE工具，如PD或者Rose都缺省展现了一张纸张的大小；
3. 在实体关系图内，每个实体的大小缺省使用自动调整大小，除非你在以下两种情况刻意要将实体缩小：
• 实体属性太多
• 关注的是实体之间的关系；
4. 在实体关系图内，实体之间的关系，尽量不要用斜线来表达，表达成一个“斜线交叉网”的实体关系图是设计者的大忌；尽量用水平或者竖直线来表达；CASE工具都支持在一个图中出现允许一个实体多个实例，来更好地组织实体关系图；
5. 在实体关系图中，不要用模型缺省给你生产的名称或者代码，大家一般都能做到也一定能做到改缺省属性名称attribute_1，但是用缺省的relation1来表达关系或者用constraint1来表达约束，我却经常发现，请用有意义的名称来表达；
6. 在实体关系图中，注意给上描述表达一些实体、属性、关系的含义；在实体关系图中应当多用Note将自己一些思考过程、重点/关键点、容易混淆的地方标记出来，每个CASE Tools都提供了很好的Note功能，大家好像为了保证整洁，不像我在图上贴满了“膏药”；

从具体的设计方法上看，从业务的主题域开始入手去设计才是正确的方法，需要考虑如下：

1. 确认前期业务系统的主题域划分是否合理；并且使用Package来表达不同的主题域；
2. 确认整个业务系统需要用到的各种常用基础元数据，使用Domain来表达元数据，譬如：Address来表达地址、URL表达网址、PhoneNumber表达电话号码等、Available代表可不可用等；
3. 在主题域中，先进行实体设计，切切不要先进行实体属性设计；
4. 根据设计者的业务理解，先在图上放入一个实体，给实体起一个名称；从名称的角度，给他起一个没有二义性的名称；如果名称有二义，那么你就要考虑是否实体需要分拆了；
5. 有没有发现图中实体的某几个实体好像在表达相同的意思，有的话，需要合并吗？
6. 循环执行4－5步骤，不断思考实体是否合理呢，检验标准：从业务上去评判是否满足原子性、无二义性；
7. 考虑实体之间的关系如何？是组合、还是依赖，有递归关系吗？是继承关系吗？是两个实体的关联关系吗？
8. 考虑实体之间的基数关系如何？是1..n还是0..n？是1..0还是1..1？（能表达1..1吗？请读者回答）
9. 有没有发现实体在生命周期的前后关系，是先有鸡，还是先有蛋啊？
10. 有没有发现实体之间有互斥关系啊，有他没我啊？
11. 循环执行7－10步骤，确认实体之间的关系是否合理？检验标准：找个不了解业务的同事看是否能够快速理解你的意图；从业务上去评判。

截至到目前为止，总结了实体的初步设计，还没有详细进行实体属性设计，后面的还更加复杂。今天先总结到这里，设计不容易，想当设计师就得下功夫。

欢迎给我提意见！架构师就不要给我意见了，我都谈不上架构师。