数据库设计心得

对于最开始数据库的设计，我们小组是一无所知的，不过根据软件工程创新课程的老师授课内容，我们也有了大致的思路，首先我们应该按照之前做的需求分析文档，对着需求一个个的思考，数据库应该存什么数据才能完成这些需求，应该怎么去存这些数据。随着我们一个个需求分析完，不仅数据库的要存放什么数据明白了，整个程序大体上的设计思路也清晰了。

一开始我们是从尽可能减少冗余的角度来设计数据库的，把一些可有可无的属性新建一个表和主表关联起来。我们的大体思路是按照四个主体的增删改查，超管，终端用户，平台管理人员，现场运维人员，按照现实中的逻辑将他们串联起来，按照分区的方式管理直饮机，将每片区域绑定好运维人员，为每台直饮机绑定水表，这样就建立了运维人员与终端用户的连接，而且在维修的过程中，需要运维人员进行工单生成，工单下发，工单追踪。所有的管理人员都是通过超管进行增删改查，终端用户可以通过扫描二维码的方式查询当前的水质状态。因此，具体我们就设计了十几张表，人员表包括：超管，平台管理人员，终端用户，运维人员。直饮机总表单个直饮机运行状态（主要是水质监测）、水表表、直饮机设备表包括三个部件，分别监控维修记录表和工单表。

经历了千辛万苦设计的数据库，本来以为可以满足需求，但是“贪得无厌“的甲方的需求是无穷无尽的，我们深刻的体验到了什么叫需求的变化性。不断的更新需求，数据库也需要不断地更新。在与甲方进行第二次约谈之后，又增添了很多需求，但是才疏学浅的我们认为，对于现在的我们的能力还难以实现，因此我们选择了简化版的数据库设计。

我们好不容易搞完的数据库，有了信心，但没想到，却输得这么彻底。小班课上被指导老师一阵见血的指出了问题，管理的实体又新增了“老板“身份，数据库的设计不符合第三范式，表与表之间的依赖设计的不够真实，数据冗余，我们小组在这次小班课后，痛定思痛，决定立即起草第二版。老师建议我们，将是体现抽象出来，根据实体之间的关系，设计关系模式，尤其是多对多的关系，要抽出来专门设计。于是我们在第二版的设计新增了区域管理，加入了新的身份：老板。虽然数据库的设计更加复杂了，但是我们认为只有把数据库设计好，才能更好地处理前后端，更好的对数据进行操作。

我觉得我们组1.0版本的数据库设计并没有遇到什么大阻碍和分歧。在肖老师的帮助下，我们对总体的需求还是比较明确的，根据需求来设计数据库也就顺理成章。而且我们的物联网对应到净水器的应用，这其中涉及到数据库的部分是很清晰的，没有什么难度。就是净水器、各个耗材，还有用户的基本信息以及权限，所以我们1.0版本的很快就讨论出结果并达到一致。但是经过今天的小班讨论数据库评审。我们还是存在了一些自己没注意到的细节的地方，而且因为我们之前计划好的α版本迭代计划我们设计的数据库并没有更新。老师说我们要把整个完整的数据库设计好，然后才能基于数据库进行前后端的开发。而且可以基于一个完整全面的数据库来提取一部分到α迭代中实现，这比我们想的先设计α部分的数据库之后再更新数据库的想法要好得多。所以我们还有很多要学习的地方，更是要和老师多沟通，最近也是缺乏了与老师的沟通，导致我们的各项进度都很滞后并且出现了大大小小的问题。作为PM这是我的失职，我应该深刻反思。