搜索
一、流程概括数据库设计大致可分为5个阶段：1.规划阶段包括论证必要性、可行性、根据项目情况进行数据库选型。2.需求阶段调研业务，明确需求，撰写文档。3.概念阶段设计数据流图、数据字典4.逻辑阶段设计ER图，从整体的角度把握数据库模型5.物理阶段根据ER图+数据字典，设计物理模型图6.开发阶段根据物理模型生成基础代码，根据默认的功能验证模型。开发过程中，根据业务变更，反复完善模型。二、规划阶段论证必要性是否需要使用数据库做持久化处理？是否使用关系数据库？比如对于工作流引擎，使用xml来持久化流程的设计，反而更加灵活。另外，在处理大数据量，高并发的时候，用NoSql会更加理想。所以，开展一个项目之前，需要论证，使用什么方式的持久化技术更加合适。可行性看项目的部署方式、运行环境是否支持关系数据库。数据库选型根据项目规模、历史原因、和其它系统集成需求、经费等，考虑选择那种数据库产品。三、需求阶段通过充分调查现实世界的业务对象，明确用户的各种需求，确定系统的各项功能。需求阶段不单止要考虑系统当前的业务需求，还要充分考虑到以后系统可能的扩充和改变。四、概念结构设计阶段这个阶段主要是完成数据字典和数据流图，这是从业务的角度挖掘系统涉及的数据流转方式、实体和属性成分说明。数据字典数据字典最重要的作用是作为分析阶段的工具。任何字典最重要的用途都是供人查询对不了解的条目的解释。在结构化分析中，数据字典的作用是给数据流图上每个成分加以定义和说明。换句话说，数据流图上所有的成分的定义和解释的文字集合就是数据字典，而且在数据字典中建立的一组严密一致的定义很有助于改进分析员和用户的通信。数据流图数据流是一组数据。在数据流图中数据流用带箭头的线表示，在其线旁标注数据流名。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。数据流图的加工（处理）方式在数据流图中加工用圆圈表示，在圆圈内写上加工名。一个处理框可以代表一系列程序、单个程序或者程序的一个模块。五、逻辑结构设计阶段这个阶段最重要的任务就是根据数据流图的分析设计出E-R图。E=EntityR=RelationshipER图即实体关联图笔者的使用习惯是在设计E-R图时，注重整体考虑，主要分析系统涉及哪些实体、实体负责的业务逻辑，实体之间的关系（如1对1，1对多，多对多等）是怎么处理的。而不会在E-R图中描画实体的具体属性。因为两者关注的粒度是完全不同的。对于一些核心的关键属性，如果有利于说明实体业务和关系的，可以加入，但是注意一定要严格控制。即类似这样的E-R图（在网络收集），笔者是不推荐的：因为这个图内容太多，虽然通过矩形、菱形和圆形区分各种元素，但是还是会被属性（圆形）干扰了注意力。笔者认为，概念阶段，主要关注点是实体和关联，属性在数据字典环节已经做了初步的分析，这也足够了。所以，笔者推荐的是类似这样的E-R图：这个图主要关注的就是实体和关联，以及实体和外部模块的联系情况。至于属性，则只列出一些关键的属性，如果没有这类关键属性，则不列出属性也是合适的。六、物理结构设计阶段这个阶段就是基于E-R图+数据字典+数据流图进行数据库设计，由于设计E-R图已经主要参考了数据流图，所以这个阶段主要参考前面两项。通过E-R图中的实体，确定有哪些数据表，通过关联确定数据表之间的外键关系（根据设计习惯和项目情况，有些实体关联并不一定通过外键处理，不同模块之间的表可以通过业务键进行业务上的关联，而不是物理结构上的外键关联。通过数据字典确定数据表的字段和字段的数据类型、域和业务描述（字段备注Comment）等。笔者一般使用Powerdesigner完成物理模型的设计。七、开发、迭代和优化阶段数据表设计好后，如果企业的软件开发架构有代码生成组件，则可以基于这些数据表生成基础代码，生成的基础代码一般有基础的CRUD功能，通过这些功能初步验证一下数据表，没有问题就可以往下开发了。然后在开发过程中，如果涉及数据表的更改，则通过代码生成组件局部的更新相关的配置文件（如ORM的映射文件和映射类）。在运营过程中，如果数据量、访问量增大，则存在在数据库层面的优化，比如冗余数据、索引、表分割、维度方式的数据表设计等。数据库物理模型的设计一般很难一步到位，在开发和维护阶段均存在调整的可能性，调整有微调，也有大调整。微调可以是增加、修改或减少一些字段；大调整，则可能业务发生很大的变化，或者原先的分析阶段，在需求、数据流图上理解有误，导致数据表的重新设计。大调整对整个项目影响很大，可能会导致项目因此失败。所以我们在分析和设计阶段务必准确的理解业务，从根本上保证方向的准确。并且对系统的发展有一定的扩充预留，为以后的调整、优化做些预留，避免大幅调整的出现。