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

摘要:

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


大纲:

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


本文章是系列文章之一,如果你还没有看过之前的文章,建议先看完前面的文章再看本篇,这样效果更好。



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



7.1 数据库结构变更可大可小

数据库字段的微调,比方说增加一个字段、修改一个字段等等,是很常见的事情。当然这样的事情经常发生的话,也是挺让人厌烦的,所以我们可能会在数据库中增加一些保留字段。
以前参考前辈的数据库设计时,经常会发现一些“保留字段”,于是自己也去模仿一下,后来发现好像没有什么用。比方说:当需要增加一个字符型的字段时,我会去找一个字符型的保留字段,将原来字段的名字由“保留1”改为合适的名字;当需要增加一个数字型的字段时,去找一个数字型的保留字段,将原来字段的名字由“保留X”改为“XXX”。这样的做法,和增加一个字段有什么区别呢?还不如取消保留字段,需要时再添加字段就是了。
数据库字段的变更还算是小变化,虽然会带来数据操作层、业务层、表现层代码的修改,也可能需要“升级”旧数据,但这些都算是“小动作”,还不算“很可怕”,“最可怕”的可能是数据表或表关系上的变化,例如:原来的表设计不合理,需要将一个表拆分为两个或以上的表;需求发生变化,需要增加更多表格;原来的表关系不对需要修改等等,这些变化将会导致程序的大范围修改。
正因为数据库的结构变化可大可小,可能遇到相关问题的时候我们会采取“将就”的策略,仅仅是对数据库进行修修补补,不太敢从根本上改造数据库,以致雪球越滚越大,最终有一天会发现数据库结构实在无法适应需求了,但工期压力又超级巨大,这时只能祝你好运了!


7.2 数据库结构变更的源头是什么?

数据库变更的原因可能有:
1)客户的需求并没有发生什么变化,而是我们前期的需求分析不到位,或者是我们前期对数据库设计不重视,导致数据库设计不合理。
2)客户的业务发生变化,以致数据库也需要调整设计。
无论是哪种情况,其实都是业务概念驱动数据库设计!请看前文出现过的一个图:
软件设计是怎样炼成的(6)——打造系统的底蕴(数据库设计)(上篇)

图7.1 业务概念驱动数据库设计

此图是前文说明“由底而上”的设计思路时的一个图,现在我们再重新理解一下:
1)“需求分析”活动有三种工作产物:业务概念图、业务流程图和用例/用户故事。
2)“业务概念图”是“设计数据库”活动的“输入”,也就是“业务概念图”是数据库设计的重要依据。

那什么是“业务概念”呢?下面我们通过实例来理解“业务概念模型驱动数据库设计”。


7.3 案例:学生选课系统——业务概念模型驱动数据库设计

案例:学生选课系统的业务建模
某学生选课系统部分需求如下:
1)学生基本信息:学号、姓名、年龄、所在学院、学院地址、学院联系电话。
2)课程基本信息:名称、学分、类别(必修、限选、任选)。
3)学生可以读多门课程,每门课程都有相应的成绩。
你觉得仅根据上述信息,是不是可以进行数据库设计了?建议你先根据上述信息思考一下数据库设计,完成后再继续阅读后文,这样效果更好。

实际工作中因为工期压力大,我们可能不会稍微停留一下思考一下这些需求,而是直接就是数据库设计。这样做有相当大的风险,很可能会导致数据库设计不符合“三大范式”的要求的,导致一些问题,例如:1)该拆分的表没有拆分,表关系不合适;2)字段设计不合适;3)数据冗余,容易出现不一致等等。如果我们能先进行业务建模,可以帮助我们避免这些问题。

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

软件设计是怎样炼成的(6)——打造系统的底蕴(数据库设计)(上篇)
图7.2 选课系统的业务概念建模

我通常用UML的类图来整理业务概念模型,简介一下这个图的基本语法:
1)图中的一个个矩形就是类,这个图有四个类:学生、学院、课程、成绩;
2)学生与学院之间,学生与课程之间有实线相连,表示它们”有关系“;
3)学生与学院之间的关系是 ”* 对 1“,表示多个学生对应1个学院;
4)学生与课程之间的关系是 ”* 对 *“,表示多个学生对应多个学院;
5)成绩这个类有一条虚线连到学生与课程之间的实线,这个成绩类叫关联类,这可能是比较难以理解的,它表示的是学生与课程之间的关系的约束,这个”成绩“你可以理解为:每个学生在每个课程中的成绩。

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

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

软件设计是怎样炼成的(6)——打造系统的底蕴(数据库设计)(上篇)
图7.3 选课系统的数据库设计1
右上方是业务建模的小图,方便大家对照来看,图7.3 展示了”学生类“与”学院类“对应的数据库设计。

软件设计是怎样炼成的(6)——打造系统的底蕴(数据库设计)(上篇)
图7.4 选课系统的数据库设计2
此图展示了”课程类“和”成绩类“所对应的数据库设计,请重点看”成绩类“的数据库设计。

下图是上述两个图的汇总:
软件设计是怎样炼成的(6)——打造系统的底蕴(数据库设计)(上篇)
图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 数据库设计小结

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



广告:

软件设计是怎样炼成的这个系列的文章当中出现了很多UML图,而且文章一直很强调需求驱动设计,如果你对这些话题感兴趣,欢迎你考虑我即将在深圳举办的一个活动:敏捷遇上UML

详情请猛点这个链接:http://blog.csdn.net/fireball1975/article/details/19550771

本活动已经在CSDN社区活动发布,详见:http://huiyi.csdn.net/module/meeting/meeting/info/706/community




作者:张传波

创新工场创业课堂(敏捷课程)讲师

软件研发管理资深顾问

CMMI首席专家

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

www.umlonline.org创办人


软件设计是怎样炼成的(6)——打造系统的底蕴(数据库设计)(上篇),布布扣,bubuko.com

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

上一篇:MySQL必知必会之1-4


下一篇:fstab文件中挂载/dev/mtdblock设备不行!