业务数据库设计流程

需求分析

开发流程的流程是附属在项目开发之中的，首先是需求分析阶段，根据用户提出的需求，我们要分析出记录的数据，比如说我们要给一个学校做一套在线教学系统，那么我们需要分析教学系统，都要保存什么样的数据，比如说有学生数据、教师数据、课程数据、出勤数据、考试数据等等。

概要设计

接下来就要做一下概要设计了，把上一个步骤采集下来的数据需求抽象成实体的模型，绘制出er图，那么这个er图是比较抽象的，那么在这个图里边只说明了每个实体应该具备什么样的属性，比如说学生实体应该具有学号和姓名这样的属性，那么将来在创建数据表的时候，字段应该用什么名字？数据类型是什么？有没有约束?，有没有索引？所以等等一系列的问题在er图上都没有反馈出来，

ER图转数据表

所以我们还需要第三个阶段要把 er图转换成数据库的模型图，那么这个数据库模型图里面就包含了字段的名字，包括数据类型等等，所以它的信息表达出来比概要设计阶段设计的er图还要详细。那么根据数据库模型图，我们就可以创建出数据表了，就是这么一个环节，那么创建出数据表之后，我们还要插入一些初始化的数据，所以第三阶段被称作详细设计阶段。以上就是业务数据库设计流程的三个阶段了。

瀑布模型还是螺旋模型？

数据库设计流程跟程序开发里边的瀑布模型很像，既然说数据库设计的流程采用的是瀑布模型，那么能不能给它转换成螺旋开发模型？

瀑布模型是没有迭代回溯的，属于一次性的开发模型，从图形上你也能看得出来，比如说做完需求分析之后不会再回到这个阶段了，而是进入到下一个阶段，也就是甘油设计这个阶段，如果说瀑布模型的后半程某一个阶段出现了设计问题，或者说在这个阶段用户提出要修改需求，这就意味着我们之前的工作很有可能就都白做了，于是项目代码可能就要推倒重来了，可见使用瀑布模型每一个环节都要精心的设计，不能出现纰漏，否则代价实在是太大了。

• 瀑布模型的前提是要有非常明确的需求，而且用户不会在中途去修改需求。

模型里边螺旋线是从原点开始，一次经过了4个象限，那么循环下来一次以后继续进入到下一次循环，那么还是要经历需求分析、概要设计、详细设计这三个象限，因此说螺旋模型是属于有回溯的多次开发模型，那么在创业公司里边面对现有明确的需求，我们采用螺旋模型中第一次迭代来开发项目核心，等将来有新的需求，我们再做下一次迭代开发，每一次这种迭代开发仅仅完成少量的功能，这种小步快跑的开发方式就是螺旋模型，就算这一次迭代开发失败了，我们只需要推翻这次迭代的项目就可以了，不必推翻之前所有的迭代开发产生的代码和项目，所以说失败的成本还是很低的，这一点比突破模型要好很多。

案例

你的客户是一个公司的老板，他在南方考察发现了某一个公司，他有一个管理系统非常的好，所以说老板自己也想有一套，于是就找到了你，让你的团队帮他也做一套系统，因为这个老板并不了解业务系统模块的划分和业务流程，所以在需求方面说不出什么，反正就是让你模仿做一套系统就行了。

如果说你贸然采用了瀑布模型，很可能经历大半年的开发，你拿着半成品找到客户让他去体验，这个时候老板发现根本不是他想要的那种效果，于是他很不满意，让你再重新做一遍，那么你说这样的后果是不是特别严重，所以说项目开发用什么模型是要看人下菜碟的，如果说客户对业务非常了解，能说出详细的需求，这个时候你可以用瀑布模型是没有问题的，但是客户对业务不了解，你就应该使用螺旋模型提炼他最想要的核心功能，然后你的团队花费两周的时间完成第一次小的迭代开发，拿着这种成果跟老板去确认，如果没有问题，那么再进入到下一次迭代开发。

如果说老板不满意，那么咱们就重新迭代重新来做这个项目，成本也不是很高，毕竟是两周迭代下来的一个小项目，因此说用什么开发模型，关键啊还是要看需求清不清晰。

总结

最后我来回答同学们的问题，数据库的设计流程能不能使用螺旋模型，答案是否定的，必须要采用瀑布模型，因为数据库改动之后产生的连带效应是很大的，比如说我们修改了数据表的某一个字段的名字和数据类型，看似一个很小的操作，但是后台的Java项目要修改pojo Deo service， 控制器，甚至还要去修改后台的验证规则，那么前端项目要修改HTML还要修改前端的验证，以及表单的提交或者AJAX，你看数据库改动一丁点，程序员就得累趴下，因此说数据库不适合做螺旋模型的开发，必须要使用瀑布模型，提前设计好完整见状的数据库，这才是我们要做的，而不是迭代开发，一点一点网上加砝码加功能，这不适合数据库的开发