1.项目简介与背景
当今时代智能手机的多功能化与便携性，使许多智能机用户习惯于将重要个人隐私信息储存于智能手机内。然而现代智能手机的密保系统较为简陋，在某些特殊情况下，个人手机的解锁密码很容易被窃取导致手机内存储的隐私信息泄露，对个人信息安全与财产安全造成损伤。因此，为了保护智能手机内部信息，希望开发一个基于个人生物信息的手机密保系统，并且此系统使用的生物信息较难被窃取，且能够有效的分辨解锁对象是否为本手机用户。
本项目研究的目的是为用户提供更为安全的生物识别认证方式。
2.团队介绍
项目名称：智能手机防窃取密码认证系统
指导老师：刘代波
小组名称：树脂666队
小组成员：曾坤，曾佳宝，邵聪，李校，颜豪辰，周成杰
3.数据库设计过程
我们根据项目需求，设计如如下表格
4.ER图设计
在本系统中,数据库的设计采用PowerDesigner进行,并且采用面向对象的设计方法,首先进行对象实体的设计,最后将对象持久化到数据库中,所有的表和表之间的关联(ER图)都采用标准的PowerDesigner设计工具进行,这样能够将整个系统的设计和数据库设计有机的结合起来。
4.1CDM设计
数据库设计的第一步应该就是CDM设计了，我认为这也是相当关键的一步。我们首先从需求文档出发，结合原型图所展现的功能和流程抽象出所需要的数据，经过讨论修改，共确定了14个数据库表，又经过老师的指导，完善了数据库表的备份字段和预留空白字段。然后，我们便开始用PowerDesigner创建实体，分析实体之间的联系，实现CDM设计：
4.2PDM设计
当我们完成CDM设计之后，使用PowerDesigner可以直接生成PDM。但是生成PDM之后我们发现，有些实体中出现了原本没有的多余字段，这是因为，在CDM设计的过程中，我们创建实体时不需要设置外键，而在创建了实体和实体之间的关系之后，实体之间的外键会自动生成，如果我们在CDM中设置了本应该是外键的字段，那么在生成PDM之后就会产生多余的字段。生成PDM之后，还可以利用PDM导出数据字典和SQL文件，SQL文件可用来数据库建表。
5.数据库设计心得
曾坤：
我主要负责用powerdesign设计数据库的过程，在设计过程中掌握有简单的表到编程整个数据库的设计方法。去思考表和表之间的关系，去考虑企业设计过程中的设计规范，表名规范，一些必要属性等，去考虑范式要求。这些问题都是在亲手设计的时候慢慢思考出来的。同学也碰到了外键重复设置的问题等等。总之这次数据库设计让我们学会了如何抽象出数据，并设计出合格的数据库，收获满满。
曾佳宝：
经常听老师们说一个优秀的数据库设计不仅会满足用户的需求，还会对程序开发有很大的作用。通过这一次数据库设计和文档撰写，让我对上述观点深有体会。在这一次数据库设计中，大家积极讨论协商，对数据库的设计反复修改，总结出以下心得体会：
1、为每个表定义一个主键，并且主键选择要尽量选择自增或者数字类型。主键的名字不能直接叫id，可能会使得后期开发容易混乱，特别是做两张表连接查询，而他们都有一个叫做id的主键的时候显得尤为重要。并且名字尽量突出表特征，例如用户表可以直接叫user_id。
2、尽量让每张表满足范式规范，对此我们小组分别对每张表进行了审核，演算是否满足三范式要求。但在实际开发过程中，需要我们具体需求具体对待，不能一味的去追求范式建立数据库。
3、考虑到该项目涉及到的技术路线，我们积极讨论了关于模型参数的存储方式，认为可以针对每个模型保存在一个文件中，然后保存其路径在数据库中，为数据库后续存储更多数据奠定基础。
4、在数据库最开始设计阶段，小组成员的命名习惯各不相同，导致后续讨论整合时候出现看不懂字段名称含义等问题。通过查找网上关于数据库的命名规范，我们发现数据库所有对象名称均使用小写字母，并且单词之间通过下划线分开；并且所有业务表的前缀均使用项目名称或者模块首字母缩写；锁有存储相同数据的列名和列类型必须保持一致。
最后，在本次数据库设计中，我不仅更加深入地掌握了数据库相关理论知识，并将其应用于实践，我还发现一个优秀的项目并不在于项目成员有多么优秀，更重要的是项目成员之间的配合。如果一个项目的项目成员彼此不了解，那么在项目开发过程中沟通将成为最大的问题；如果项目成员能够协调配合各项工作，互相信任，那么这个项目一定能够圆满完成。
邵聪：
本次设计中我主要负责的是数据库对象的实际创建，虽然通过powerdisigner中物理模型和逻辑模型的创建能导出数据库中各种表的创建语句，但实际创建表对象时会遇到在数据库逻辑模型和物理模型设计过程中没有考虑到的内容：
- 外键对象的外键约束
a) RESTRICT:若子表中有父表对应的关联数据,删除父表对应数据，会阻止删除。默认项
b) NO ACTION:在MySQL中，同RESTRICT.
c) CASCADE:级联删除。(常用)
d) SET NULL:父表对应数据被删除，子表对应数据项会设置为NULL。(常用) - 不允许为空对象的默认值设置
需要根据实际需求确定外键的约束，以保证数据库能满足实际的需求。非空对象需提供好默认值。
在数据库对象创建时使用的是Flask-SQLAlchemy，Flask-SQLAlchemy是一个简化了 SQLAlchemy 操作的flask扩展，SQLAlchemy是一个关系型数据库框架，它提供了高层的 ORM 和底层的原生数据库的操作，让开发者不用直接和 SQL 语句打交道，而是通过 Python 对象来操作数据库，在舍弃一些性能开销的同时，换来的是开发效率的较大提升
李校：
在本项目数据库进行设计的时候，我们首先根据需求文档、用例文档，讨论出需要存储的数据，以及数据存储的具体方式。如对于用户头像，我们选择存储用户头像路径，对于生成的模型，我们也选择存储对应路径。通过合作讨论这些数据的存储方式，我们组最终用powerdesigner设计出了数据库。之后为了检查数据库设计是否满足范式要求，我们小组共同温习了数据库设计的第一范式、第三范式，共同讨论当前数据库是否合理、合规。除此之外，还要确保数据库的每一个对象确实有其业务含义存在，也不能单纯为了满足范式要求而违背业务逻辑。在开数据库评审会议时，边老师提到数据库的表名设计可以更加符合自然语言的规范，这一点我们组内讨论时并没有想到。数据库的表名确实应该能够让人一目了然，而不能使用一些复杂的、难以理解的名字。在实现数据库的时候，还要注意外键的外键约束，以及该对象是否允许未空这些细节。在实际编写代码的时候，这些细节需要注意。
颜豪辰：
在学习数据库和数据表创建和修改时，了解到表是建立关系数据库的基本结构，用来存储数据具有已定义的属性，在表的操作过程中，有查看表信息、查看表属性、修改表中的数据、删除表中的数据及修改表和删除表的操作。表是数据最重要的一个数据对象，表的创建好坏直接关系到数数据库的成败，表的内容是越具体越好，但是也不能太繁琐，以后在实际应用中多使用表，对表的规划和理解就会越深刻。基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。通过这次设计，我还学习了，sql管理、数据的导入、导出、备份和还原。有sql server 安全访问控制；登录账户的管理；数据库角色的管理；用户权限管理。维护数据库的安全是确保数据库正常运行的重要工作。数据的备份是对sql server数据事务日志进行拷贝，数据库备份记录了在进行备份操作的数据库中所有数据的状态。而数据的备份还分为数据库完整备份、差异备份、事务日志备份、文件及文件组备份。做数据备份就是为了以后的数据库恢复用。也了解到中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键（数据仓库除外）。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。我做的是用户数据的数据库设计，其中的要求包含了许多数据库的对象，综合了我所学的许多知识。总而言之，通过这次数据库设计学会了很多，很是还需要继续深入学习。
周成杰：
在本项目的α版本开发前，我们基于各个模块的数据需求，具体化数据结构作为实体，根据实体间的相关关系与内容，通过powerdesigner，进行了概念模型CDM和物理模型PDM的初步设计。对于user表，我们没有使用个人部分信息作为主键，，而是设置了user_id作为主键，同时我们的user实体与其他两个实体间的关系都是一对多，一个用户有多条记录，有多条反馈。通过以user_id作为外键可以操作多个相互关联的实体。同时由于我们项目中涉及到音视频文件以及深度学习的网络模型，为了解决此类数据的存储，我们将这类数据在数据库中存储为文件路径以方便查询使用。
标签：范式,数据,666,数据库,外键,设计,心得,备份 From： https://www.cnblogs.com/kunny199/p/kunny115.html