<1+3班 知识雪豹组>基于动态水利模型的管网智能预警系统丨数据库设计心得
著作：<1+3班 知识雪豹组>
目录
一、ER图设计心得
二、实体表设计心得
三、数据库设计过程心得
四、数据库设计规范心得
五、数据库建立（实现）心得
er图是一个数据库设计的指导，对数据库的设计起着至关重要的作用。
首先，er图的设计原则是尽量减少实体集，能作为属性的不要作为实体集，属性”不能再具有需要描述的性质。“属性”必须是不可分割的数据项，不能包括其他属性。“属性”不能与其他实体具有联系。在E-R中所有的联系必须是实体间的联系，而不能有属性与实体之间的联系。针对特定用户的应用，确定实体、属性和实体间的联系，设计该用户视图的局部E-R图。综合局部E-R图，产生出总体E-R图。在综合过程中，同名实体只能出现一次，并去掉不必要的联系，以便消除冗余。一般来说，从总体E-R图必须能导出原来的所有局部视图，包括实体、属性和联系。
同时，在设计数据库时，我们采用了先局部后整体的方法，选择局部应用：根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图作为设计分E-R图的出发点 。逐一设计分E-R图：将数据字典中的数据抽取出来，参照数据流图，设计出E-R图，再作必要的调整。调整原则：为简化图的处置，现实世界中的事物能作为属性对待的，尽量作为属性对待。作为“属性”，不能再具有描述的性质，也不能与其他实体具有联系。具体分成三个部分，用户数据部分，数据显示部分，数据采集处理部分，尽量做到必要的前提下简化图的设计。然后在不同部分设计人员的沟通下，一次性集成三个分er图。
在完成了E-R图的设计后，变要设计具体的实体表了。那么ER图上的表就和实体表一模一样吗？
显然还是有所差异的，ER图的表仅仅定义了表的名称、字段名称、字段类型，但对于物理表而言还缺少了一些约束条件，比如是否可为空，是否需要自动递增。在创建物理表的时候，有两种方法可供选择，第一种就是使用SQL语句，使用Create table语句，另一种就是使用类似Navicat这样的数据库系统管理工具，我们选择的是后者。图形化的操作界面往往更吸引人，操作方便，避免了Sql语句的细微错误导致实体表创建差错，当然最好的方法是用Navicat创建之后，继续检查一遍。
实体表的设计总体就是参考ER图，至于实体表之间的关系，可以总结为“一对一”、“一对多”、“多对多”的关系，小组总结的心得是：“一对一”任意一方使用外键联系，“一对多”在多的一方使用外键绑定少（一）的一方，“多对多”则新增关系表，记录双方的关系。实则这个心得即第三范式的简化，为了将表的设计更合理，在设计之后还应检查是否满足第三范式。
我们的设计过程分为系统需求的分析、概念结构设计、逻辑结构设计、物理结构设计和数据库的实施等几个方面，其中特别需要参考我们的需求规格说明书。这部分我们需要调查用户的活动，明确系统边界需求、安全性、完整性等方面的问题。根据我们基于动态水利模型的管网智能预警系统项目的实际特点，我们将数据表分为存放业务实体的基本数据表，比如人员的基本信息、管线信息等。业务信息表用于存放用户、管理员的日志等业务调动信息。
我们要对表名、字段名、外键约束、索引、字段的属性等方面进行确定。其中表名可以直接使用小写的英文单词，这样较为直观，可以适当地添加一些前后缀，另外命名时要避开数据库的一些关键字，如datetime、password等等，建表时需要包含描述信息。日志表一般以Sys_开头，数据字典表一般以SD_开头，系统字典表一般以DT_开头。对于字段名，除了上述对表命名的几条规范外，还需要注意使用名词或动宾短语可以较好地显示字段的意思。对于外键的设定，我们需要通过分析数据完整性的要求来决定实际是否建立。设定索引时，我们要避免索引常用的小型表和大型字段。另外，对于触发器，选择触发器的BEFORE或AFTER事务属性的时候，对表操作的事务属性必须与应用程序事务属性保持一致，以避免死锁发生。在大量修改数据时，尽量避免使用触发器。在进行表的设计时，规范化与反规范化之间也应该有所权衡，数据库课程讲授的三范式的结构固然标准且规范，但其可能会在实际运用的过程中会面临大量的连表查询，在应用中可能会拖慢程序的运行速度，因此，减少或增加数据冗余，需要我们根据数据的类别进行组织，确定其规范化或非规范化。
数据库作为一个应用程序的核心部分，对项目有着至关重要的作用。因此数据库的建立和实现需要格外的谨慎和细心。
在宏观上，数据库的表的设计应尽量满足五个范式而进行设计。这样的设计可以减少数据的冗余性从而提高数据库检索的整体性能，并且满足了易维护、易扩充等的要求。尽管数据库能为我们提供很大的帮助，可以在数据库层面实现很多的依赖事务，但是在项目开发中我们应尽量减少对数据库的依赖。这样可以避免因数据库故障或迁移带来的代价。
从微观来说，数据库的字段也有很多细节需要注意。首先字段的名字不应该与系统保留关键词冲突，这在项目未来将会带来许多的困扰，是亲历的血的教训。为了减少错误和增加可读性，字段名应具有一定的意义。此外，字段的属性也需要谨慎的设计，例如varchar和char属性的不同可能会为数据库带来很大的性能不同。
数据库的建立是一项复杂的任务，并且对于项目的后续开发有着决定性作用。因此在数据库建立过程中，要参考已有的数据模型，在此基础上与项目成员进行讨论，得出一致通过的较合理的数据库。
数据库部署心得：
对于市面上较为常用的数据库例如MySQL数据库，很多博客网站均有资料。但是对于一些国产的开源数据库，可能相关资料不够详细。例如国产的开源数据库OpenGauss。但是我们要知道，每个数据库都有各自的优缺点，因此在实际项目开发中，一个项目可能使用多种数据库来存储数据，从而组合实现更好的性能。
MySQL的安装是比较简单的，按照某篇博客进行安装即可。但是对于OpenGauss而言，其需要繁多的配置和环境，并且官方的文档也有些前后不一。加上各种博客中内容与快速迭代产生的版本不同，出现了很多没有渠道解决的问题。在我们的项目中，我们分别对企业版和极简版进行了测试安装，并且使用的是OpenEuler20.03LTS版本。但是在多次的企业版安装中出现了同样的错误，初步判定是企业版对系统性能要求较高。而极简版的安装虽然也有多次失败，但极简版步骤较为简单，最终成功安装。与此同时，OpenGauss提供的使用手册也较少，通过较多的检索发现其命令与GaussDB较为相似。
所以对于一些较少使用者的数据库，很大情况下主流博客网站中对于该数据库的资料较少，这就需要开发者去仔细研究推敲官方文档或主动联系社区，并鼓励开发者将自己的经验分享，为国产数据库建立良好的生态。
六、总结
数据库的设计需要细心和耐心，严格遵守范式要求。正所谓“磨刀不误砍柴工”，花费时间设计实现一个合理的数据库是相当必要的，若数据库设计不合理，后续开发时出现问题，则会带来极大的返工开销。
浙公网安备 33010602011771号