男德模范队数据库设计心得

男德模范队数据库设计心得

简介

项目名称：对联云小程序

项目组成：小程序+后台管理+服务器

项目指导老师：陆邵飞

项目小组名称：男德模范队

项目小组成员：刘顺（PM）、尚兴帆、肖宇、胡嘉宏、黄泽云

数据库设计过程

我们采用规范设计法结合数据库设计工具PowerDesigner来设计数据库。

流程图如下：

1. 需求分析阶段：

   需求分析是我们在数据库设计之前就已经完成的工作。需求分析的数据库设计的指引，在开始分析数据库之前，我们组就明确了一点，数据库设计必须围绕需求分析来实行。所以在开始设计数据库之前，我们在会议都回顾了我们分析的需求。

2. 概念设计阶段：

   概念设计阶段需要我们确定实体，属性，关键字，实体之间的关系等。我们根据对联云小程序的特征，将整体分为四个板块，帖子，用户，资料，对联四个模块，然后针对每一个模块分析了每个模块需要的实体，以及实体的属性，关键字，确定了实体，再确定实体之间的关系。这里我们使用了PowerDesigner工具绘制了CDM，每个模块先分别绘制出相应的CDM，然后再根据模块之间的关系整合。

3. 逻辑设计阶段：

   确定了概念模型以后，就需要进入逻辑设计阶段。概念模型只是确定了实体，实体关系等，并没有确定数据的存储模型。逻辑设计阶段就需要就概念模型转换成数据模型。我们现在使用的Mysql都是基于关系型数据库的DBMS，层次型和网状型已经很少使用。不管是E-R图也好，还是我们在Powerdesigner中设计绘制的CDM也好，都需要转换成关系模型。这里，我们直接使用PowerDesigner工具可以直接生成LDM，LDM中将每一个实体转换成了表，也就是关系模式，实体之间的关系，也发生了对应的转换。

4. 物理设计阶段：

   前几步只完成了数据库的理论设计，基于具体实现，也需要我们设计。基于实用性和便捷性考虑，我们使用的是开源的DBMS，MySQL；MySQL存储引擎使用的是最常见的Innodb，它直接我们需要的所有功能。然后我们规定了一下建表时的命名规范，避免出现冲突。还有就是字段的域的确定，这需要我们根据需求选取合适的域，像诸如datetime和date，需要区别使用。

5. 数据库实施阶段：

   在完成前面的工作以后，就由我们的后端人员，试着根据我们的设计去搭建环境并且建库。这里我们使用的PowderDesigner工具可以根据绘制的LDM图直接导出Sql语句，这给后台人员带来了许多便利。

6. 数据库运维阶段：

   在测试运行了数据库应用系统以后，就可以投入正式运行了。在这个阶段，我们要根据实际开发需求不断优化，调整数据库。在后续版本迭代中，我们可能会对小程序添加一些功能，这也有可能需要我们对数据库进行调整。

问题及解决

1. PowerDesigner工具的使用

   在使用PowerDesigner工具时，小组成员或多或少都出现了一些问题。例如在cdm转pdm时，出现了属性和实体转换失败，实体或属性的name和code编写不规范等问题。这些问题在组员一起探讨，很容易就得到了解决。

2. 三大范式

   在原版小程序的数据库设计中，由于添加了一些新的功能，有一些设计是不适用于我们当前版本的。例如帖子类型，本来是作为一个字段存放在帖子表中的，但是现版本新增了添加帖子类型的功能，这意味着需要存放更多关于帖子类型的信息，例如类型创建时间等，如果将这个类型创建时间等也作为帖子表的字段，会出现大量的数据冗余，这显然是违背了第三范式的，所以现版本将这些字段抽离出来，构成一个新的帖子类型表。

3. 反范式设计

   在具体实现的时候，还需要考虑后端开发人员编程的便捷程度，还有程序的高效性。在最初设计时，我们想消除所有冗余数据。实际上这是不合理的。这其实也是时间开销和空间开销的权衡问题，在表中添加部分冗余字段可以减少后端人员代码的复杂度，也可以减少联表查询数量，这是有利于程序运行效率的。

小组总结

​ 数据库设计的好坏直接影响到开发，小组成员基于需求分析，认真细心的花费大量时间讨论了数据库的设计。在数据库设计中，出现了一些典型的问题，这些问题在讨论之后都基本得到了解决。要设计出结构，性能都优秀的数据库，是不容易的事情。小组成员们从需求分析到最后运维，不断更新维护商议，这才得到了现在的数据库。即使这样，也难以保证数据库是最好的，在保证正确性的前提下，这更多的是一种维护平衡的问题，总而言之，适合的才是最好的，数据库仍然需要不断的评价，调整，维护。

小组成员各自总结

小组成员们对这次数据库设计有不同的总结以及心得体会，以下是小组成员的总结及心得：

刘顺

在分析了项目需求后，我们对项目有了一个全方位的理解和认识，在着手实现项目之前，首要的就是进行数据库设计。

库的设计：
虽然在需求分析时，我们决定重新实现对联云项目，给小程序一个全新的设计，但是考虑到服务器的部署等相关问题，还是决定重用原有的库的设计，分为四个微服务模块，也就是帖子微服务、楹联微服务、用户微服务和文件微服务，划分模块的设计方法有助于我们理清数据库设计的思路，让设计变得有条理起来。

表的设计：
针对表的设计，我们选择的方式是ER模型设计方法，首先从需求当中抽离出实体，然后小组讨论确定哪些实体是必须的，哪些实体是不需要的，最终得出了每个库的实体列表，这也就构成了我们的数据库的表的设计，然后再讨论表之间的联系，联系的分析有助于我们分析表的主键和外键的设计；库的设计选择沿用，这对我们进行表的设计有一定的局限性，由于我们需要进行扩展，有些新的功能的表的设计需要划分到那个微服务成为了问题，我们只能根据关联性进行大致的偏向性选择，这也是我们数据库设计的一点不太合理的地方；

属性的设计：
确定表的联系之后，就进行了具体的设计——属性的设计，这就需要根据需求细致的逐一确定，因为属性的设计不仅关乎到后续编写代码时前端的显示，也牵涉到后端与数据库交互时的操作，在分析过程中，不仅需要考虑表的字段的命名的规范和达意，也需要考虑实际情况中数据可能出现各种情况，需要给字段指定一个适应性良好但是又很贴切的域；在之后就是在设计的过程中一定要给字段添加注释，这样才能在后续使用时一目了然。

约束的设计：
仅仅设计表的属性是不够的，还需要根据实际情况，给表的字段设计约束。首先是主键和外键，主键的设计比较简单，再设计外键时，小组遇到的问题比较多，在满足一个需求的数据需求时，往往需要联表查询，一张表之间的哪些字段需要设置为外键，这边成为联表操作的关键；其次就是域约束，比如对于字符串类型的数据，设置多长是比较合理的；对于一些取值有限的属性，还需要对他的取值在设计时就做好约定；再次就是一般性约束，表与表之前是否有联系，比如项目中的点赞评论收藏等功能的实现，这必然牵涉到多张表的同时变化，我们就可以设计一般性约束，并发出发操作。

此外，在没有进行实际使用时，数据库的设计往往会存在缺陷，所以我们需要时刻关注数据库的设计的适用性，发现问题后，就及时和组员讨论，尽早修改，这样修改的成本才不会很大。

总之，自己作为组长，在数据库设计的过程中，承担起了带领组员进行讨论，开展设计工作的责任，让我体会到了数据库设计工作的重要性，也体会到了数据库设计的复杂和不易。和组员合作，一起成长，收获很多。

肖宇

做的好的地方：
1.团队协作
在数据库设计过程中，大家的参与度和积极性都很高。在数据库雏形设计完成后，都积极地参与了设计复查。我们的小程序是一个很复杂的系统，功能很多，一个人很难一次性做到面面俱到，所有团队合作可以让大家互相弥补，找出设计的遗漏之处。

2.紧贴需求分析
在设计数据库的时候，我们会根据需求分析中的功能和用例逐步地分析数据库，并且考虑数据库完整性以及实体之间的联系。比如在实现删除帖子等删除功能的时候，不能直接简单地将与帖子相关的数据都连表查询并删除，这显然是不合理的，我们就该功能得出需要一个字段用于标识帖子是否被删除，这样在实现删除功能的时候可以实现伪删除，不能影响实体之间的关系。

3.遵循设计流程
在数据库设计过程中，我们按照需求分析，概念设计，逻辑设计，物理设计，实施，运维的过程进行设计，每个环节环环相扣，减少了不必要的设计纰漏。在设计过程中，我们消除了冗余数据，消除了数据间的不一致性，保护了数据的完整性。并且全组成员一起仔细考虑了关系模式区分了诸如(0,1)和 (1,1)的关系。

出现的一些问题：
1.对于开发了解过少
由于缺乏后端开发经验，我在数据库设计的时候难以考虑到后端编程的困难程度。好的数据库设计应该要给予后端开发人员编程方面的便利。这一点是我难以做到的，但是组内有组员具有后端开发经验，可以根据自己的实际需求提出数据库设计的建议，所以这一点得以解决。

2.逻辑不够缜密
对联云小程序的表较多，实体之间的关系较为复杂。对有些表的操作会影响到众多其他的表，要把这些逻辑整理清楚，还是很麻烦的。在最初的设计中，我们难以将表之间逻辑关系全部理清，譬如如何解决删除异常的问题，即删除需要删除的数据，但不影响表之间的关系，因为比如帖子操作，和用户表之间就通过帖子表相联系，删除了某条帖子记录，但是不能删除这个间接的联系。这些问题我们通过后续审查才增加一个字段来实现伪删除的功能。

3.域的设计难以确定
对部分字段的域的设计，也是让我们比较头疼的点。因为微信小程序自带open_id，因此这个open_id作为用户表的主键是很合适的，但是这个open_id是varchar（32）的数据，在表中是无法自增的，而且其他表是否也用varchar（32）作为主键的域？还有诸如个人简介之类的文本长度，我们也经过长久的讨论才确定下来。

总结：
整个数据库设计的过程，在我看来，就是站在开发以及前后端交互的角度，对需求功能进行了更细致的分析。在设计数据库的时候，我们需要真正确定前后端分别需要什么。所以一旦数据库设计清晰了，开发也就提上日程了，自己的心里也有了一定的打算。所以说，不管对后端还是前端开发人员，数据库设计都是相当重要的。因此，前后端人员都应该参与并且规范地，认真地分析需求并设计数据库。

尚兴帆

​ 在设计数据库之前，首先要明确一个良好的数据库设计方案的重要性。首先，数据库的设计要从需求分析开始，只有明确每一个需求，我们才能开始设计数据库，如果从需求分析阶段就开始模糊分析，在项目开发过程中将经常面临修改增加数据表中的字段，甚至需要新加数据表和修改表结构的情况，会严重影响项目开发进程。所以我们一开始的时候就是把需求文档设计的比较详细，当然，仅仅做到这样还是不够的，我们需要考虑各方面的因素，因为数据库的设计关系到后端进行接口开发时实现的难度，数据库中数据的可维护性，一致性，以及是否会因为数据冗余太多导致系统性能较低等等。

​ 在设计数据库的时候，我们也是开线下会议，所有组员一起进行分析。首先，我们将项目分成四个模块，然后每个模块一个数据库，然后再往下设计具体的表。在设计字段的时候，我们还要考虑到外键，比如，我们设计作品表，这个表中肯定是要有作者表的作者的id，然后可以根据作者id，去作者表中找到对应的作者信息，作者id就是作品表的外键。

​ 在设计数据库和编写sql代码时，如果不借助工具的话，每个人设计的数据库和sql语句都是不尽相同，所以我们可以借助powerdesign，来设计数据库，然后在将sql语句导出，就可以确保规范性和统一性。

总的来说，通过这次的数据库设计，从开始设计，到完善设计，到CDM,PDM等，这巩固了我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高了我们综合运用所学知识的能力。

黄泽云

首先是关于数据库的设计步骤：

需求分析：数据是什么，数据有哪些属性，数据和属性各自的特点有哪些；

使用ER图对数据库进行逻辑建模（跟我们所选的具体的数据库管理系统是没有关系的），大部分的表关系也是在这一步完成的

物理设计：根据数据库自身的的特点把逻辑设计转换为物理设计；

维护优化：新的需求进行建表，索引优化，大表拆分。随着应用程序上线的时间越来越久，需求越来越多，数据结构也会越来越复杂，所以在维护优化的时候也要遵循以上几步，完了之后再进行页面的操作，这样保证数据结构永远是最优的。

其次在数据冗余和处理速度之间找到合适的平衡点。原则是相对的，不是绝对的。做表设计，读懂需求就对了。先不要管性能，先实现需求。表设计好了，写SQL的时候再考虑该合并，合并，该拆分，拆分。另外最关键的就是搞清楚一对一还是一对多。

对于每一个项目，数据库的设计都是至关重要的，它关系到后端进行接口开发时实现的难度，数据库中数据的可维护性，一致性，以及是否会因为数据冗余太多导致系统性能较低等等。总的来说，在数据库的设计过程中，我们需要考虑各方面的因素。而详细认真的需求分析是数据库的设计中至关重要的一个环节，如果从需求分析阶段就开始模糊分析，在项目开发过程中将经常面临修改增加数据表中的字段，甚至需要新加数据表和修改表结构的情况，会严重影响项目开发进程。好的设计能减少数据多余，避免数据维护异常，节约存储空间，高效的访问。

最后从各种文档的阅读到开始的需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。

胡嘉宏

1、 需求分析

在对联云小程序1.0版本的基础上，我们通过对其需求的分析，将数据抽象为四个微服务类别和其他的相关联的表，分别是file、user、couplet、post等，分别与资料文件、用户、对联、帖子的信息与操作行为有关，在互相关联的条件下保证其对于小程序功能的实现没有冲突矛盾。

而用户的数据方面我们保存了对于用户类别进行鉴别的方式，用于区别会员与普通用户。同时，对于资料和帖子，尽管两者的操作行为有很多的相同之处，但是由于资料与帖子的存储形式、调用场景不一样，我们建立了两个不同的表。除此之外，对于投稿、新闻、用户关系、通知的数据，也通过建表来存储表示。

在数据库设计前，我们对小程序的用户人群、用途、设计目的等做了详细的分析。在需求文档的基础上，对小程序的功能需要使用到的数据进行了分析，形成了数据库的设计框架，并且基于实际的情况，不断地完善，对于一些冲突、矛盾的地方，进行了调整（例如用户表、创作者表所表示的用户身份有重合的地方，所以仅保留一个表）。

2、 数据库设计分析

数据库的设计采用PowerDesigner进行，通过对需求对象的抽象设计，形成了实体表，再利用设计工具进行整合设计，与数据库模型结合起来。

在user-server微服务模块，我们建立了管理员、会员、通知、粉丝关注、用户这几个实体，涵盖了三个用户角色的基本信息；在通知实体内，为了实现对指定用户群发送通知的功能需求，我们对对其赋予了关联用户编号的属性，以此来将通知行为与用户绑定。而粉丝关注实体实质上是用于表现用户关系的，其属性包括两个交互的用户编号和关系类型。

在post-server微服务模块，我们建立了许多与帖子有关的实体（例如帖子点赞、收藏、评论、浏览等），还有比赛、获奖、投稿、投稿审核等实体。与帖子的信息有关的实体保存了帖子的基本信息（例如编号、标题、上联、下联等）；与帖子的操作有关的实体保存了用户对于帖子的操作数据（例如操作类型、操作记录等）。同时，比赛、获奖、投稿、投稿审核这四个实体满足了小程序的基本功能。

在couplet-server微服务模块，主要是对楹联的操作和信息实体，其内容设计逻辑与帖子有许多重合的地方，但是不同的是，本微服务模块的数据实体包含一个楹联家实体，主要包含了楹联家的个人信息、推荐日期等，用于实现首页推荐楹联家的功能。

在file-server微服务模块，基于对楹联和帖子设计逻辑，对资料的一些操作进行了抽象化，除此之外，还包含一个资料对应文件的实体，用于指向具体的文件。

3、 总结心得

即使在数据库设计完毕后，在对项目进行实际开发的过程中，仍然需要对照数据库的设计来进行开发，与此同时，也需要根据实际情况对数据库的设计进行改进、维护。数据库的设计不仅仅是对数据模型的分析与设计，更是一个将实际行为抽象为数据形式的任务，设计出的数据库不但需要完善具体，更需要符合实际运行的需要。