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

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

              图1 项目总的用例

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

            图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：视图和索引
我们认为视图和索引的创建是与具体的应用相结合的，因此这两个部分我们还在设计之中，并没有具体的实现。

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