一、流程概括

数据库设计大致可分为5个阶段：

1. 规划阶段

   包括论证必要性、可行性、根据项目情况进行数据库选型。
   

2. 需求阶段

   调研业务，明确需求，撰写文档。

3. 概念阶段

   设计数据流图、数据字典

4. 逻辑阶段
   

   设计ER图，从整体的角度把握数据库模型

5. 物理阶段

   根据ER图 + 数据字典，设计物理模型图

6. 开发阶段
   

   根据物理模型生成基础代码，根据默认的功能验证模型。开发过程中，根据业务变更，反复完善模型。

二、规划阶段

• 论证必要性
  

  是否需要使用数据库做持久化处理？是否使用关系数据库？

  比如对于工作流引擎，使用xml来持久化流程的设计，反而更加灵活。
  另外，在处理大数据量，高并发的时候，用NoSql会更加理想。
  所以，开展一个项目之前，需要论证，使用什么方式的持久化技术更加合适。

• 可行性
  

  看项目的部署方式、运行环境是否支持关系数据库。
  

• 数据库选型

  根据项目规模、历史原因、和其它系统集成需求、经费等，考虑选择那种数据库产品。

三、需求阶段

    通过充分调查现实世界的业务对象，明确用户的各种需求，确定系统的各项功能。

    需求阶段不单止要考虑系统当前的业务需求，还要充分考虑到以后系统可能的扩充和改变。

四、概念结构设计阶段

    这个阶段主要是完成数据字典和数据流图，这是从业务的角度挖掘系统涉及的

数据流转方式、实体和属性成分说明。

• 数据字典

      数据字典最重要的作用是作为分析阶段的工具。

      任何字典最重要的用途都是供人查询对不了解的条目的解释。

      在结构化分析中，数据字典的作用是给数据流图上每个成分加以定义和说明。

      换句话说，数据流图上所有的成分的定义和解释的文字集合就是数据字典，而且在数据字典中

  建立的一组严密一致的定义很有助于改进分析员和用户的通信。     

  
  

• 数据流图

      数据流是一组数据。在数据流图中数据流用带箭头的线表示，在其线旁标注数据流名。

      在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。

     

• 数据流图的加工（处理）方式

      在数据流图中加工用圆圈表示，在圆圈内写上加工名。一个处理框可以代表一系列程序、单个程序或者程序的一个模块。

五、逻辑结构设计阶段

     这个阶段最重要的任务就是根据数据流图的分析设计出E-R图。

     E=Entity

     R=Relationship

     ER图即实体关联图

     笔者的使用习惯是在设计E-R图时，注重整体考虑，主要分析系统涉及哪些实体、实体负责的业务逻辑，

实体之间的关系（如1对1，1对多，多对多等）是怎么处理的。而不会在 E-R图中描画实体的具体属性。因为

两者关注的粒度是完全不同的。

    对于一些核心的关键属性，如果有利于说明实体业务和关系的，可以加入，但是注意一定要严格控制。

     即类似这样的E-R图（在网络收集），笔者是不推荐的：

    因为这个图内容太多，虽然通过矩形、菱形和圆形区分各种元素，但是还是会被属性（圆形）干扰了
注意力。笔者认为，概念阶段，主要关注点是实体和关联，属性在数据字典环节已经做了初步的分析，这也足够了。

    所以，笔者推荐的是类似这样的E-R图：

     这个图主要关注的就是实体和关联，以及实体和外部模块的联系情况。

     至于属性，则只列出一些关键的属性，如果没有这类关键属性，则不列出属性也是合适的。

六、物理结构设计阶段

    这个阶段就是基于E-R图 + 数据字典 + 数据流图进行数据库设计，由于设计E-R图已经主要参考了数据流图，

所以这个阶段主要参考前面两项。

    通过E-R图中的实体，确定有哪些数据表，通过关联确定数据表之间的外键关系（根据设计习惯和项目情况，

有些实体关联并不一定通过外键处理，不同模块之间的表可以通过业务键进行业务上的关联，而不是物理结构上的

外键关联。

    通过数据字典确定数据表的字段和字段的数据类型、域和业务描述（字段备注Comment）等。

    笔者一般使用Powerdesigner完成物理模型的设计。

七、开发、迭代和优化阶段

    数据表设计好后，如果企业的软件开发架构有代码生成组件，则可以基于这些数据表生成基础代码，生成的

基础代码一般有基础的CRUD功能，通过这些功能初步验证一下数据表，没有问题就可以往下开发了。

    然后在开发过程中，如果涉及数据表的更改，则通过代码生成组件局部的更新相关的配置文件（如ORM的映射文件

和映射类）。

    在运营过程中，如果数据量、访问量增大，则存在在数据库层面的优化，比如冗余数据、索引、表分割、维度方式

的数据表设计等。

    数据库物理模型的设计一般很难一步到位，在开发和维护阶段均存在调整的可能性，调整有微调，也有大调整。

微调可以是增加、修改或减少一些字段；大调整，则可能业务发生很大的变化，或者原先的分析阶段，在需求、

数据流图上理解有误，导致数据表的重新设计。大调整对整个项目影响很大，可能会导致项目因此失败。

    所以我们在分析和设计阶段务必准确的理解业务，从根本上保证方向的准确。并且对系统的发展有一定的扩充预留，

为以后的调整、优化做些预留，避免大幅调整的出现。