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

浏览数：25 / 时间：2015年06月12日

摘要：

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

大纲：

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）数据冗余，容易出现不一致等等。如果我们能先进行业务建模，可以帮助我们避免这些问题。

下图是对上述需求的业务概念建模分析：

图7.2 选课系统的业务概念建模

我通常用UML的类图来整理业务概念模型，简介一下这个图的基本语法：

1）图中的一个个矩形就是类，这个图有四个类：学生、学院、课程、成绩；

2）学生与学院之间，学生与课程之间有实线相连，表示它们”有关系“；

3）学生与学院之间的关系是 ”* 对 1“，表示多个学生对应1个学院；

4）学生与课程之间的关系是 ”* 对 *“，表示多个学生对应多个学院；

5）成绩这个类有一条虚线连到学生与课程之间的实线，这个成绩类叫关联类，这可能是比较难以理解的，它表示的是学生与课程之间的关系的约束，这个”成绩“你可以理解为：每个学生在每个课程中的成绩。

补充说明一下，严格来说业务建模有两种：业务结构建模和业务行为建模。上述案例其实做的是“业务结构建模”，主要是对数据结构进行分析；“业务行为建模”主要是对流程、过程等进行分析，图7.1中“需求分析”的其中一个工作产品是“业务流程图”，这个“业务流程图”就是行为建模的产品。后续文章会为大家分享更多行为建模的内容。

根据这个业务概念建模，我们可以进行以下的数据库设计，我们将通过三个图来说明。