软件设计是怎样炼成的（6）——打造系统的底蕴（数据库设计）（下篇）

摘要：

数据库是系统的根基，若是需求变动致使你要常常修改数据库的字段，甚至须要修改表及表关系，相信多折腾几回谁都受不了！由于数据库结构的变化，不只仅是数据库自己的变动，实体类、数据操做层、逻辑层和表现层的代码都须要改。更麻烦的是数据库中若是已经存在大量的旧数据时，这些旧数据是不会“自动”适应新的数据库结构的，你须要想办法来“升级”这些旧数据。本文为你分享如何打造好系统的根基——作好数据库设计！文章太长，分红上下两篇了，此乃下篇。

 

大纲：

1.什么是优秀的设计？
2.优秀的设计能节省项目工做量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感受好才是真的好——用户体验设计
10.持续提高设计水平

 

本文章是系列文章之一，若是你尚未看过以前的文章，建议先看完前面的文章再看本篇，这样效果更好。

 

 

7.打造系统的底蕴——数据库设计

 

 

7.4 考勤系统的业务建模及数据库设计

 

学生选课系统这个案例比较简单，主要是帮助你们理解”业务概念模型驱动数据库设计“。接下来咱们继续用”考勤系统“这个例子为你分享，个人主要目的有：

1）对考勤系统进行行为建模；

2）经过另一个例子再次体会如何用类图分析业务概念模型；

3）根据业务概念模型，同时考虑到咱们的现实状况，咱们要作一个“老土”的数据库设计；

4）深挖业务概念模型，作一个“高端大气”的数据库设计。

本小节为你分享第一、二、3点。

 

这个考勤系统的需求请参考前面的文章，若是忘记了必定要从新看看噢！

你能够会发现，前面的文章没有详细描述请假（外出）的审批流程，下面咱们经过一个图来看看这个流程吧，这个图就是业务行为建模的其中一个结果。

 

图7.6 请假审批流程活动图

 

了解这个流程后，咱们将会对业务概念模型有更加清晰的认识，下面直接上两个业务建模的图：

 

图7.7 考勤系统的业务概念建模1

 

图7.8 考勤系统的业务概念建模2

 

上面两个图结合一块儿看才是完整的业务建模，由于一张图太大可能会显示不下，或者显示出来很差看，因此才拆分红两张图。

 

根据上述业务建模，如何来设计数据库呢？若是照搬学生考勤系统的作法，那么一个类至少要对应一个数据表，这样设计的话彷佛有点麻烦，后续写起代码来也可能挺麻烦的。咱们要思考这个系统的主要需求是什么？这个系统主要是围绕请假（外出）的审批流程进行的，其实就是一个简单的工做流，咱们要解决提出申请以及多个层次的审批问题。现实项目中进度压力是很大的，也会受制于各类限制条件，因此能解决须要当中主要矛盾的设计就是一个好设计，因此我有这样的一个老土的设计，能知足需求，实现起来也比较简单。请看下面的两个图，节选了部分的数据库设计。

 

图7.9 考勤系统的数据库设计1

 

图7.10 考勤系统的数据库设计2

 

这个设计至关老土，原本应该拆分为多张表的所有弄到一张表去：

1）当提出请假申请时，请假申请表就多了一条记录，这条记录审批相关的字段所有都是空的；

2）当去到某个审批环节时，该申请记录只须要更新相应的字段就好了。

 

这个程序的代码写起来也比较简单，例如：表现层不须要针对不一样的流程环节设计不一样的界面，直接能够经过一个界面搞定，固然还要写一堆 If Else 或 Switch Case。表现层的代码思路以下图：

7.11 考勤系统的表现层代码思路

 

当员工提出请假申请时，他只能看到1这部分的内容，二、三、4部分隐藏；当部门经理审批申请时，1部分只读，2部分可编辑，三、4部分隐藏，副总和总经理审批时也进行相似的处理。

 

数据库设计不能单纯仅仅从数据库的角度来考虑，还须要总体平衡这个项目的工做量，通常来讲能解决需求当中的主要矛盾，能让整个开发工做量降下来，而且是项目团队有能力作到的设计，这样的数据库设计及软件设计才是好的设计。

 

考勤系统的业务建模及数据库设计，也说明了这样的最佳实践：

1）业务结构建模和行为建模是颇有必要的，业务建模这一步能够多深刻一些，不要由于项目进度紧而压缩你的时间，这里的时间投入所带来的回报是超值的；

2）业务建模让咱们对需求的理解更深，让咱们的数据库设计及软件设计”进可攻退可守“；

3）遇到进度压力及各类限制条件时，你不必定非要照这个业务模型来设计你的数据库和代码，你能够退一步，用一个”老土“的数据库设计及程序设计来解决问题；

4）你也能够采起更加进取的设计策略，这点下一小节为你分享。

 

 

7.5 业务建模更上一层楼，打造更具弹性的数据库设计

 

本小节为你分享前文提到的第 4 个目标：深挖业务概念模型，作一个“高端大气”的数据库设计。但这个目标实在太“伟大”了，这里能仅为你分享开始的一部分，后续有机会我再发文章分享更多内容。

 

咱们有更多的思考：若是请假（外出）审批流程改变了，例如增长了审批环节，怎么办？按照前面的“老土”设计的话就麻烦了，咱们须要增长“请假申请表”的字段，而表现层的代码也须要修改，须要更多的If Else。

固然咱们可能还有一个更好的处理办法，就是认为这是需求变动，对客户说：no money no talk（没有钱没商量）。只要前期咱们的业务分析足够到位，将流程图、业务概念图等所有画出来，而且跟客户确认好了，客户就不能赖帐了，增长审批环节，这明显就是需求变动嘛，是须要工做量，须要付钱滴！可是咱们为何不能将程序作得更有弹性呢？为何不能作一个“全活”的工做流呢？这样咱们的软件将会更有竞争力，帮助咱们赚到更多的钱。

 

前文的文章提到的工做流，分为三种层次：

1）死的工做流：就是代码写死的（hard code），数据库设计也是死的，流程或表单有任何变化，均可能须要改代码和数据库设计。

2）半死不活的工做流：部分地方写死，部分地方是灵活的，能适应部分需求变化。

3）全活的工做流：代码和数据库设计等都是灵活的，能基本适应流程及表单的变化，不须要修改代码或数据库设计，只要配置一下就能够搞定。

前面这个老土的设计，是属于那种一种层次呢？

我都很差意思说了了，这是“死的工做流”，弹性最差的！流程稍微改变，就要处处修改，包括修改数据库设计和代码。

 

下面咱们尝试一下作“活的工做流”，咱们须要再进一步分析业务模型，找出流程的规律，针对规律来设计数据库和软件！

 

图7.12 考勤系统业务概念模型的深刻挖掘

上图红色虚线框框里面的内容就是规律，并且其余部分能够当作是这种规律的一个“实例”。

这个图揭示了这样的规律：

1）从提出申请开始，后续的审批其实就是一个”审批链”；

2）“申请”对应一个“首次审批”，“首次审批”后续是“下一个审批”；

3）对应某一个“审批”来讲，若是它不是“首次审批”，它对应一个“上一个审批”。

若是数据库及程序能针对这样的规律进行设计，那么只要是符合这个规律的状况，系统均可以适应，这样就不怕审批流程的变化了！

 

图7.12 可能有点难度，若是没有应用类图分析业务的经验，会更加难理解此图，但这仅仅是挑战的开始！当咱们须要打造更具弹性的系统的时候，咱们面临两大挑战：

1）透视需求发现需求本质的能力，创建更深层次的业务模型；

2）根据第1）点的业务模型，设计出相应的数据库设计及软件设计。

这两大挑战都是难度很高的，图 7.12 仅仅是业务模型进一步深挖的开始，打造“活的工做流”难度是很大的，未来有机会再分享更多文章。

 

 

7.6 数据库设计小结

 

数据库设计的好坏决定了系统的底蕴，不管是“老土”的设计仍是“高端大气”的设计，都是为项目的目标服务的。

通常来讲咱们应该达到如下基本要求：

1）意识上要重视数据库设计，数据库设计上的时间投资是超值的；

2）良好的业务建模（包括结构建模和行为建模）是良好数据库设计的基础，而且可让你在后续工做中“进可攻退可守”；

3）在业务概念模型的基础上搭建数据库，你能够采用相似学生选课系统的数据库设计方法（业务实体类与数据表一一对应），也能够采用考勤系统的“老土”设计方法（合并业务实体类到一个表中）。

当条件成熟时，咱们能够考虑进一步提高咱们的业务深挖能力及弹性设计的能力，让咱们的软件更好卖，让咱们能够赚取更高的薪金！

 

 

本文是系列文章的其中一篇，要作软件设计师一点都不简单啊，请留意后续文章！

 

若是本文对你有帮助，麻烦点一下“推荐”啦，谢谢！

 

 

做者：张传波

创新工场创业课堂（敏捷课程）讲师

软件研发管理资深顾问

CMMI首席专家

《火球——UML大战需求分析》做者

软件知识原创基地创办人