五黑小队数据库设计文档心得得体-HNU-软件工程导论

 

                    数据库设计文档心得体会

一、概要

我们的数据库设计是一个由简单到复杂、由粗略到具体的过程。我们用的是power designer进行UML图设计。根据需求分析,我们设计了13张表,对应了3类用户的具体功能。我们按照原型的运行,将所有的操作流程过了一遍,从中分析我们可能需要用到的表并进行记录,对整个原型记录完成之后,通过列出这些表中所有的属性,我们对每张表的必要性进行了分析,并判断这些表之间的关系,思考怎么将其相互连接起来。

 

二、数据库设计应该遵循的原则

  1. 对需求的认知完全没有歧义。比如我们在设计久坐提醒表时,讨论课指导老师认为这张表并没有存在的必要,但是经过对需求的分析,我们发现,由于需要记录不同助理的不同时间设置,所以还是需要这样一张表,否则这个功能无法实现;

  2. 熟练而且正确的E-R图绘制,明确改图是表明实体和关系的图,实体表示要在数据库里保存的类,关系表示类与类之间的相互关系,关系主要有一对一,一对多,多对多。在绘制过程中,我们发现,继承关系通常可以用一对一表示,而一对多或者多对多通常表示类之间的使用关系;而根据指导老师的意见,当两张表为一对一关系时,我们没有必要把它们分开,可以直接合并为一张表。

  3. 在设计时要做到高度的抽象,对内容或者关系相类似的内容抽象为一类实体,在分类时可以抽象出一个“类”的实体,与要分类实体之间进行多对多关系映射,明确哪些是必须要进行存储的实体; 

 

三、设计过程详情

 

由于我们都是初学者,在这个数据库设计的过程中,我们前后经过了很多次讨论修改,即使是最终基本上定下来的时候,还是会对数据库进行修改,比如增加一些字段或者删掉一些字段,来适应我们的需求。当时我们是以编辑共享的Excel表的形式来完成这一步,当时针对一些表,组员几番争执不下,尤其是对医生信息表与患者信息表。最后,我们静下心来,综合各种条件,根据各自所提出的理由,互相说服,完成这些字段的确定。完成这些表后,我们与指导老师周老师进行了交流,老师首先指出,我们使用的工具不对,用Excel完全体现不出这些表之间的关系,用excel记录数据会有很大的模糊性和不确定性,数据的灵活性也会受到很大的限制。同时,我们既然已经下载了PowerDesigner,这个工具正好适合现阶段的设计,用excel太敷衍了,于是我们之后又根据excel表在powerdesigner里建立了CDM、PDM模型。

在数据库设计正式开始之前,小组成员各自根据对项目的理解进行了简单的设计,整理出了项目数据库中大概有哪些表,表中有哪些属性和约束;大家都认为有了大概的数据库设计,后面的任务进行的会很顺利,但是这个数据库设计框架只起到了一点点参考作用,紧接着我们又开了两次线下会议进行了长时间的完善和改动。在数据库设计时,我们和指导老师周老师,交流了很多次,给了我们很多宝贵的意见,比如,表的结构方面应该逻辑清晰,针对需求进行表的设计,要考虑需求点是否真的可行有效。这也很大程度上推进了我们数据库设计的进度以及设计方案的改良。

 

在数据库表初步设计后,我们进行了小班展示。胡老师给予了我们改进的意见,比如登录表的设计不够合理,应当将3张不同用户的登录表合并为一份。在此基础上,我们又对我们的数据库进行了一次小规模的改动。

五黑小队数据库设计文档心得得体-HNU-软件工程导论

因为数据库的设计会直接影响到页面数据的显示的操作难度,所以我们在设计时也是再三斟酌才得到了最终的成品。

五黑小队数据库设计文档心得得体-HNU-软件工程导论

针对我们开发的小程序的核心,即提供给3类用户的主要功能,我们也是十分慎重,花费了很多时间来考虑其构成。考虑到患者端的预约功能,我们设计了预约表;考虑到医生端查看预约的功能,我们设计了患者预约列表;考虑到助理端提供实时咨询的功能,我们设计了聊天记录表……

五黑小队数据库设计文档心得得体-HNU-软件工程导论

值得一提的是,我们在商讨助理端自我提醒的功能时,一直纠结要不要加一个自我提醒表。开始想的是系统自动提醒,就不需要在从数据库读取数据。但之后又考虑到会有不同的助理,那么如何判断是谁的自我提醒,这就不太好实现了。于是,最终还是将其设计为一张自我提醒表。

五黑小队数据库设计文档心得得体-HNU-软件工程导论

归根到底,我们在数据库设计上采取的方法是:

  针对某一页面进行思考:它实现的功能是什么?它需要呈现哪些数据?数据库中应该存储哪些数据?页面和数据库之间的操作逻辑是否简单和明确?

  在此基础之上,进行表的增删以及字段与数据类型的设定。

通过这些逻辑性,合理性的思考,我们在讨论中提高了自己思维的严谨性,更强化了我们对于自己的观点进行清晰表达的能力!我们相信,这次团队项目中获得的经验一定会让我们在当下收获,未来受益。

 

 

四、总结:

 

  

我们要根据原型界面判断数据库设计的是否完整,看看这个界面所需要的数据,是否能够从数据库取出。如果全部都能取出,那么数据库完整性就保证了,后面的就是考虑是否合理,如何提高效率,在设计数据库表中的具体字段时,我们需要考虑之后它们的用途,比如,对于宽度的设计,我们尽量留出一个剩余空间而不是刚好够。

而且表的结构方面应该逻辑清晰,针对需求进行表的设计,要考虑需求点是否真的可行有效。这也很大程度上推进了我们数据库设计的进度以及设计方案的改良。因为数据库的设计会直接影响到页面数据的显示的操作难度,所以我们在设计时也是再三斟酌。设计相关数据表时,我们允许有数据冗余,这样牺牲了空间换取了效率,但需要注意的是,一定不能有数据项之间的矛盾,当有多种方式进行数据处理时,应该综合多个方面进行考虑,选取最适合我们项目的解决方案。

数据库的设计是与需求紧密结合的,在设计数据库之前要对需求有完善的确立,将需求讨论明白了才能将数据库给设计好,如果需求没有确定,就设计了数据库,那么设计出来的数据库很可能是存在很大问题,需要大改的。

 

在使用power designer进行cdm转pdm的时候,如果两张表是一对一关系,那么在设计表的时候可以使用外键来联系两张表,但如果是一对多关系或多对多关系,并且需要在关系中新增属性来记录的话可以用association来设计。

 

在设计数据库的时候要注意对主键的把握,对于不同情况的表,主键应该有不同的设计方法。比如对于基本不会变动的表,如个人信息表,认证表,这些表在创建时就会把相应的数据导入并且这些数据在后续基本不会变动。那么这个时候我们就可以考虑使用逻辑主键。比如自增型主键,作为外键的话也很方便。例如要注册一个用户,如果把账户设置为自增型主键,通过主键索引可以一下就知道是否是重复。

 

在设计表的时候对于每个字段,要注意长度的设置,要尽量多的考虑各种情况,防止后续发生数据越界的情况。 

要明确数据库的功能与职责,虽然数据库的设置可以极大的方便我们,但是数据库不是万能的,它仅仅是被用来存储数据的的仓库,我们不应该让它来完成逻辑过于复杂的问题,对于这些逻辑复杂的问题,我们应该用代码来实现。

上一篇:近场通信技术


下一篇:Android近距离通信