摘要：
数据库是系统的根基，如果需求变更导致你要经常修改数据库的字段，甚至需要修改表及表关系，相信多折腾几次谁都受不了！因为数据库结构的变化，不仅仅是数据库本身的变更，实体类、数据操作层、逻辑层和表现层的代码都需要改。更麻烦的是数据库中如果已经存在大量的旧数据时，这些旧数据是不会“自动”适应新的数据库结构的，你需要想办法来“升级”这些旧数据。本文为你分享如何打造好系统的根基——做好数据库设计！文章太长，分成上下两篇了，此乃上篇。
大纲：
1.什么是优秀的设计？
2.优秀的设计能节省项目工作量
3.优秀设计从分析需求开始
4.软件系统不是木桶型的
5.软件设计的“大道理”
6.规划系统骨架——架构设计
7.打造系统的底蕴——数据库设计
8.细节决定成败——详细设计
9.用户感觉好才是真的好——用户体验设计
10.持续提升设计水平
本文章是系列文章之一，如果你还没有看过之前的文章，建议先看完前面的文章再看本篇，这样效果更好。
7.打造系统的底蕴——数据库设计
7.1 数据库结构变更可大可小
数据库字段的微调，比方说增加一个字段、修改一个字段等等，是很常见的事情。当然这样的事情经常发生的话，也是挺让人厌烦的，所以我们可能会在数据库中增加一些保留字段。
以前参考前辈的数据库设计时，经常会发现一些“保留字段”，于是自己也去模仿一下，后来发现好像没有什么用。比方说：当需要增加一个字符型的字段时，我会去找一个字符型的保留字段，将原来字段的名字由“保留1”改为合适的名字；当需要增加一个数字型的字段时，去找一个数字型的保留字段，将原来字段的名字由“保留X”改为“XXX”。这样的做法，和增加一个字段有什么区别呢？还不如取消保留字段，需要时再添加字段就是了。
数据库字段的变更还算是小变化，虽然会带来数据操作层、业务层、表现层代码的修改，也可能需要“升级”旧数据，但这些都算是“小动作”，还不算“很可怕”，“最可怕”的可能是数据表或表关系上的变化，例如：原来的表设计不合理，需要将一个表拆分为两个或以上的表；需求发生变化，需要增加更多表格；原来的表关系不对需要修改等等，这些变化将会导致程序的大范围修改。
正因为数据库的结构变化可大可小，可能遇到相关问题的时候我们会采取“将就”的策略，仅仅是对数据库进行修修补补，不太敢从根本上改造数据库，以致雪球越滚越大，最终有一天会发现数据库结构实在无法适应需求了，但工期压力又超级巨大，这时只能祝你好运了！
7.2 数据库结构变更的源头是什么？
数据库变更的原因可能有：
1）客户的需求并没有发生什么变化，而是我们前期的需求分析不到位，或者是我们前期对数据库设计不重视，导致数据库设计不合理。
2）客户的业务发生变化，以致数据库也需要调整设计。
无论是哪种情况，其实都是业务概念驱动数据库设计！请看前文出现过的一个图：
图7.1 业务概念驱动数据库设计
此图是前文说明“由底而上”的设计思路时的一个图，现在我们再重新理解一下：
1）“需求分析”活动有三种工作产物：业务概念图、业务流程图和用例/用户故事。
2）“业务概念图”是“设计数据库”活动的“输入”，也就是“业务概念图”是数据库设计的重要依据。
那什么是“业务概念”呢？下面我们通过实例来理解“业务概念模型驱动数据库设计”。
7.3 案例：学生选课系统——业务概念模型驱动数据库设计
案例：学生选课系统的业务建模
某学生选课系统部分需求如下：
1）学生基本信息：学号、姓名、年龄、所在学院、学院地址、学院联系电话。
2）课程基本信息：名称、学分、类别（必修、限选、任选）。
3）学生可以读多门课程，每门课程都有相应的成绩。
某学生选课系统部分需求如下：
1）学生基本信息：学号、姓名、年龄、所在学院、学院地址、学院联系电话。
2）课程基本信息：名称、学分、类别（必修、限选、任选）。
3）学生可以读多门课程，每门课程都有相应的成绩。
你觉得仅根据上述信息，是不是可以进行数据库设计了？建议你先根据上述信息思考一下数据库设计，完成后再继续阅读后文，这样效果更好。
实际工作中因为工期压力大，我们可能不会稍微停留一下思考一下这些需求，而是直接就是数据库设计。这样做有相当大的风险，很可能会导致数据库设计不符合“三大范式”的要求的，导致一些问题，例如：1）该拆分的表没有拆分，表关系不合适；2）字段设计不合适；3）数据冗余，容易出现不一致等等。如果我们能先进行业务建模，可以帮助我们避免这些问题。
下图是对上述需求的业务概念建模分析：
图7.2 选课系统的业务概念建模
我通常用UML的类图来整理业务概念模型，简介一下这个图的基本语法：
1）图中的一个个矩形就是类，这个图有四个类：学生、学院、课程、成绩；
2）学生与学院之间，学生与课程之间有实线相连，表示它们”有关系“；
3）学生与学院之间的关系是 ”* 对 1“，表示多个学生对应1个学院；
4）学生与课程之间的关系是 ”* 对 *“，表示多个学生对应多个学院；
5）成绩这个类有一条虚线连到学生与课程之间的实线，这个成绩类叫关联类，这可能是比较难以理解的，它表示的是学生与课程之间的关系的约束，这个”成绩“你可以理解为：每个学生在每个课程中的成绩。
补充说明一下，严格来说业务建模有两种：业务结构建模和业务行为建模。上述案例其实做的是“业务结构建模”，主要是对数据结构进行分析；“业务行为建模”主要是对流程、过程等进行分析，图7.1中“需求分析”的其中一个工作产品是“业务流程图”，这个“业务流程图”就是行为建模的产品。后续文章会为大家分享更多行为建模的内容。
根据这个业务概念建模，我们可以进行以下的数据库设计，我们将通过三个图来说明。
图7.3 选课系统的数据库设计1
右上方是业务建模的小图，方便大家对照来看，图7.3 展示了”学生类“与”学院类“对应的数据库设计。
图7.4 选课系统的数据库设计2
此图展示了”课程类“和”成绩类“所对应的数据库设计，请重点看”成绩类“的数据库设计。
下图是上述两个图的汇总：
图7.5 选课系统的数据库设计3
这个数据库设计一共有4个数据表，请对照图7.2来思考一下，业务概念建模是如何驱动数据库设计的。
如果忽略了”业务概念建模“这一步，我们的数据库设计可能会：
1）没有能拆分出学生表、学院表、课程表；
2）没有能拆分及设计出合适的成绩表。
如果你曾经用过E-R图（实体关系图），或者用过 Power Design 软件设计过数据库，你会发现上述文章的内容也就是那么一回事！
用类图分析业务概念，确实与E-R图很类似，道理也是共通的，但是还是有一些区别的：
1）E-R 图一般是直接面向数据库设计的，实体之间的关系一般就是1对1、1对多，而多对多的关系通过两个1对多来间接实现；
2）类图也能表示上述关系，但类图可以表达更丰富的内容，比如：继承（泛华）、包含（聚合、组合）、依赖、关联类等等。
也就是说用类图分析业务概念模型，能达到更广和更深的效果，当然这是我个人的体会，仅供参考。
如果你一直用 E-R 图用得好好，也没有必要非要转成类图来分析。无论是类图、 E-R 图，还是其他的什么图或工具，我们的目的都是为了更好的理解需求，梳理业务和整理出合适的业务概念模型，为数据库设计打好基础。
本想一篇文章写完，但不知不觉越写越长，又舍不得删减内容，所以分成上下两篇了，下篇为你分享：
7.4 考勤系统的业务建模及数据库设计
7.5 业务建模更上一层楼，打造更具弹性的数据库设计
7.6 数据库设计小结
7.5 业务建模更上一层楼，打造更具弹性的数据库设计
7.6 数据库设计小结
本文是系列文章的其中一篇，要做软件设计师一点都不简单啊，请留意后续文章！
广告：
“软件设计是怎样炼成的”这个系列的文章当中出现了很多UML图，而且文章一直很强调需求驱动设计，如果你对这些话题感兴趣，欢迎你考虑我即将在深圳举办的一个活动：敏捷遇上UML
详情请猛点这个链接：http://blog.csdn.net/fireball1975/article/details/19550771
本活动已经在CSDN社区活动发布，详见：http://huiyi.csdn.net/module/meeting/meeting/info/706/community
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者