医生智能提醒小程序数据库设计心得——Legends Never Die

数据库设计心得
根据咱们小组数据库设计的整个流程，咱们将整个数据库设计划分为两个具体的阶段，在每一个阶段须要进行不一样的准备，有不一样的注意事项，接下来咱们将结合在数据库设计过程当中遇到的一些问题和困难，提出本身的一些观点，但愿能对你们有所启发。若有异议，欢迎指正。
1、准备阶段：
在数据库设计前，须要准备如下几样东西：
1：设计工具
数据库设计过程当中会用到一些软件，例如powerdesigner（实际上不只仅是用于数据库设计）。想要设计好数据库，熟练运用软件是必不可少的。至于如何学习使用其进行数据库设计，主要的方法仍是利用其自带的文档/网上找资料。
在使用该软件以前，最好先从E-R图开始入手，同时数据库的基本知识也要有，这些都是数据库设计的基础。
2：用例图
用例图可以帮助咱们理清各种用户，以及他们所须要功能。有这些数据，咱们能够划分不一样的功能模块，而后再对每一个功能模块设计其对应数据库。这样作就不会出现不知道从哪张表开始设计的状况。不一样功能模块相对独立，这样作就能够将设计任务分红若干部分。至于不一样的用户则是这些功能模块的全部者，并起到桥梁的做用。
以咱们的项目为例：用户只有两类，医生和患者，医生功能有查看并处理预定，自我提醒，积分，提醒患者，上传资料等，患者功能主要有预定而且及时查看提醒并回复。
实际设计步骤中也是按照模块一个一个设计的。

图1 项目总的用例

3：需求文档
需求文档中主要提供了对各类功能以及相关数据的详细描述。相关数据的主要来源是咱们设计的表中的属性。除此以外，需求文档还能够揭示一部分的关系，例如实体和实体之间的联系（一对一，一对多，多对多等）。

图2 预定用例说明

图2 展现的只是预定功能中一部分，咱们能够从中知道患者预定时须要选择（业务和时间），其中业务显然是医生方提供的。除此以外，不容许患者重复预定（对预定的约束）。
详细的需求说明在设计数据库的过程当中是十分重要的，须要弄清楚总体需求以后才能开始设计。固然，需求说明并非万能的，有些说明中提供的数据可能不完善，或者是描述不清。此时能够选择和相关人员交流，或者经过参考已有案例来填充这部分。

2、设计
概念数据模型（CDM）是咱们的本次设计的重点。具体的任务有如下几个
1：实体的创建
创建一个实体并不容易，既要考虑实体所具备的属性，以及属性的数据类型，属性的默认值，一些简单的约束，是否为空，还要考虑主键，候选key（标识符）。
其中一个比较常规的作法是为每一张表添加一个标号属性（并不必定有用），并做为主键，以此做为惟一识别的标识符，同时也做为多表关系中的外键。
固然，这么作比联合主键这类利用其余属性做为主键的作法要简单，可是在数据的约束上可能会有更高要求。由于原来做为主键可让其不重复，可是不做为主键能够必须使用unique约束来完成这一点。
下图3中就是使用编号做为主键，可是编号自己没有意义，所以实际过程当中可能须要患者姓名+电话号码或者单纯的电话号码做为标识符。

图3 患者基本信息实体

2：关系的肯定
关系是实体和实体之间的桥梁，不管是一对一，一对多，仍是多对多关系，都是如此。值得注意的是，一对一实际上是指在A表中的一条对应B表中的一条记录。关系之间还有强相关，弱相关，弱相关（只对与一方来讲，可能另一方是强相关）是指A表中的一条记录不必定在B表中有对应记录。具体能够在关系的描述中看到。
至于带属性的关系其实能够转换成实体，这里就再也不阐述了。
图4中只是一种实现方式，在当前业务，帐户和用户是一对一的关系，即一个用户只有一个帐号，一个帐号对应一个用户。（至于那种相同的注册两个帐号，看做是两个不一样的人）

图4 帐号和患者基本信息

3：PDM
PDM主要由CDM转换而成。值得注意的是，PDM是最终参考的依据，外键可以显示在PDM中，所以具备很强的参考价值。可是要注意由CDM直接生成的PDM有时候并不彻底知足咱们的要求，所以，在生成PDM以后，必需要进行检查。
4：视图和索引
咱们认为视图和索引的建立是与具体的应用相结合的，所以这两个部分咱们还在设计之中，并无具体的实现。

3、总结：
数据库设计有必定难度，咱们组是一边探索一边设计的，而且在过程当中积极讨论，询问老师获取意见，修改了不少次才有如今的这个版本，由于需求不是一成不变的。在此后的开发过程当中，咱们还会根据需求的变更与实际状况对数据库进行调整，使其更加符合项目的功能需求与生活应用，而且要积极在组内，小组之间，以及和老师，就设计中出现的问题展开讨论，寻求解决方案。同时但愿小组成员能在此次数据库设计中掌握基本的设计原理与概要。
咱们在数据库设计上花费了不少时间和精力，在后续开发过程当中咱们会充分利用咱们设计出来的数据库。
祝各位开发顺利！