因为我们的项目是算法类，所以项目本身的需求不太明确。设计数据库的过程其实本身也是在进一步明确需求的过程。
这是我们画出的用例图：
以下是我们小组成员的数据库设计心得：
JJ:
通过本次数据库设计的过程，我经历了很多也学会了很多。
首先因为课程组的要求是设计出至少15张表，而我们想要达到15张表是很困难的。我们的设计想法是先根据我们之前设计的原型先设计出一些表，根据登陆、注册、历史记录等设计了几张表。但是这些表也基本是基于用户而设计的，后来我们也寻求了指导老师的帮助，指导老师帮忙想了一个损失函数表。但是表的数量仍然是不够的。之后我们去寻求了尹庚老师的帮助，在尹老师的帮助下我们简直像是打开了新世界。
之前一直在想办法增添合适功能的我们终于找到了方法，我们决定不仅写一个算法。而是进行多个算法的比较，这样可以增加算法表，同时算法的训练也可以建表。通过增加这个表，我们项目的功能也进一步丰富了。至于实在建不出表的情况，我们可以增加一些额外的小辅助功能。比如说主题更换，友情链接等等。其实表是依赖于功能的，功能丰富了，表自然也就可以写出来了。
根据功能建完表后，我们对于表的主键及类型、长度和其是否符合三大基本范式等都进行了探讨。最后一步步确定了表的基本形态。这里不同人的命名方式也可能存在差异，需要统一。在数据库小班课上也很感谢老师给出的建议，提出了一些我们没有想到的方面，对我们的数据库设计表进行了完善。
依据软件工程课上学到的知识和内容，我们将其应用到了实际设计过程中，做到了“做中学”。数据库的设计就是要让其能满足后面开发的需要，并且尽量的好用，在数据类型、域约束、主键外键等的设置上要考虑实际情况更加小心。
LYX：
我们小组，做的是手势识别项目的数据库，因为是纯算法型的，最开始的时候表又少作用又不大，然后我们加入了用户，和与之相关的几个功能，这样我们的表终于多了一点，最后我们通过向老师求助，老师提供了较好的想法，终于把数据库大体定下来。
然后我们开始完善，发现好多问题，比如未遵守范式，变量命名方式不统一等等。通过制定标准，进行讨论，解决了问题。
数据库设计部分，我认为首先需要弄清楚的是实体（或者表）之间的联系，其次是必须弄清楚表中字段的数据类型，是char、varchar、int、date&time型等等，还有是几个字符长度。还有的就是它的值是否可以为空的，这也是需要考虑的。设置主键相对而言就比较容易了，我最大的体会是对于表中每列的数据类型的分析必须谨慎细心，否则很容易出错。
我们虽然学习了数据库，但是我们还是缺少经验。现在我们利用自己学到的知识设计一个数据库，这本身就是一个知识转化为生产力的过程，所以大家都很兴奋，都不同程度的投入了很高的热情与努力。
GM:
对于一个项目，数据库的设计是非常重要的，数据库设计决定了以后的数据好不好维护，需求有没有得到较好的的满足，后期需求更改好不好展开，同时也决定了系统的性能。一个不够好的数据库设计对于一个功能点的改动可能会涉及多张表的改动，一不小心可能就会引起数据的不一致。为了避免这些不必要的麻烦，在数据库设计之初就要考虑这些问题，从而减少后期的系统维护量。说了这么多数据库设计的重要性，那么我对数据库设计有以下的思考。
关于范式与反范式，范式设计的目的是为了减少数据冗余从而节约存储空间提高查询效率，同时也使得数据一致性容易得到维护。而反范式的设计主要考录历史数据要反应历史问题，需要将数据冗余到表中。具体采用什么方式就要分析我们的业务是属于哪种情况视具体情况而定采用哪种方式。像涉及到财务方面，涉及到以后财务对账，历史变更就有很大的用处，所以数据冗余相当重要，就会考虑到反范式。针对我们的项目，主要需要减少数据冗余，也不存在历史变更问题，出于提高查询效率的目的，我们选择了范式设计
至于扩展性设计，项目初期业务场景的数据模型是一对一，但我们对未来的项目进行了一定程度的设想，并且分析后期会变成一对多。这种情况不要为了前期方便设计成一对一数据模型，如果这样做到后期可能得不尝失。这就是数据拓展性设计需要考虑，不要为了一时的便捷忽略了设计的扩展性。
YDY：
在原型项目设计设计完毕后，我们进行了数据库的设计。数据库是要根据需求来进行设计，这也是我们数据库设计实验中要求我们需要掌握的。
设计数据库时，我们首先进行功能的罗列，然后根据我们要实现的功能来进行设计数据库中含有那些表，每个表中各自含有什么字段，字段的类型、约束等等。比较重要的就是在进行设计时，要考虑到功能，把每一项功能的实现需要用到数据表和字段都要仔细地设计和审查，同时也需要考虑实现的复杂程度。
课程要求每个项目需要至少设计出一定数量的数据表，所以我们针对此也和指导老师进行了沟通，进行需求的讨论并最后进行了一些功能的添加，使得整个项目的功能得到了很好的充实。在这里我们一开始因为对于数据库表的个数有要求，所以在起初对表的设计时制作了很多个数据表。但是在后来小组内整合和审查的时候，发现在设计时已经把一些可以合在一起的数据表分离开了，所以之后又对表进行了重新整理。
对于每张表的主键外键等的确定，我们组内意见没有什么分歧。同时对设计出来的表都注意到了满足范式的问题，符合了数据表设计的规范。设计出来的数据库也只有符合规范以及考虑到所有的功能的实现才能算是一个好的数据库。
QMX:
在完成了需求分析后我们紧接着完成了项目数据库的设计。上一次的心得体会中有提到，我们小组项目的功能不算太多，主要是集中在用户注册登录和图片识别这里。因此，在设计数据库时，还是出现了跟上次分析需求时类似的问题达不到课程组要求的数据库表的个数。一开始，能够想到的表的个数才不到10个。后来去问了指导老师，才想到原来可以从别的方向来增添数据表，比如神经网络模型的训练过程、不同类型的图片集存储等等。虽然在小班课评审时老师对表的细节上指出了一些不足之处，但大体上还是过关了的。我们小组讨论数据库设计时，是按照项目的功能需求来一个个分析的，例如用户登录功能可能会用到哪些表等，这样子既能提高效率，也保证了不会有漏掉的表或字段。这种讨论方式在其他实验课的数据库设计中也可以借鉴使用。