噪声收集系统——数据库设计心得

数据库设计心得

在需求分析阶段，其实数据库的设计就已经初具雏形，组内初步分析了需要哪些表来存放哪类数据，并探讨了各个表中的关键字段。但在需求分析阶段的数据库设计并不完整，只描述了部分实体，表中的属性也不能完全描述需求，数据库表间的关系没有体现，这就需要进入详细的数据库设计阶段来完善。

在数据库设计的第一阶段，还是围绕用户需求来展开工作。用户的需求在设计过程中扮演着中心角色，如果一开始对需求的分析就出现偏差，那数据库设计就很容易出现问题，好在需求分析阶段结束后我们的需求是十分明确的，项目组内根据项目的需求刻画了用户的各种数据需求。

接下来，就进入将这些数据需求转化成数据模型的概念设计阶段。采用实体-联系的模型，我先列出了实体集并尽可能找出了这些实体集之间的关系，使用POWERDESIGNER工具画出了E-R图，当然这和最后的设计有所偏差，要知道，大部分事情一开始都不是最好的，甚至是不正确的，所以我们仍需要对这个模型进行改善。实体设计中，我最初本着在能实现的需求的前提下，将实体集的属性设计的尽量精简，表现在对于很多实体的主码上，我不希望添加ID字段，而是使用能唯一标识实体的属性组合。例如所用的噪声数据实体集，我将实体主属性设计为<时间+地点>，省去了ID字段，在数据库审查过程中，还是被边老师建议添加ID字段，我在修改数据库时思考得出的结论是，应该添加ID字段，原因有二，在区分不同实体时，使用ID更为清晰，另一个原因在于，在引入外键时，使用ID更为简便。在数据库设计过程中，我时刻注意数据的完整性和冗余发生的可能性，但是，过分的追求精简也会带来问题，数据库的设计还是为了方便数据的存储和操作。

ID的添加是可选的，是否使用ID是一种决策，应该说，数据库设计不是一般的选择题，没有一个标准答案，有时候两种设计方案都能够满足数据库设计的需求，这时设计者就会面临各种各样的决策。举几个我所面临的数据库设计决策的例子，用户需求中有一项是获取自己上传噪声记录的历史。一个方法是在噪声数据实体中添加关于该噪声数据上传的信息，如上传的时间，上传的用户等。这一设计的一个问题是，某个用户可能某一次上传中，上传了多条数据，结果造成了在噪声数据表中，这些同时上传的数据在上传时间和上传用户等字段上是相同的，并不是一个很好的设计。另一个实现的方法是创建一个用户实体和噪声数据实体之间的上传记录关系集，上传记录关系集联系了某个用户和该用户所上传的噪声数据关系，添加了上传的时间和协议等信息，一个用户可以上传多条噪声数据，所以关系的映射是一对多的。这个设计已经较为合格了，但还面临另一个决策，那就是是否可以将上传记录作为一个新的实体，得到一个用户-上传记录-噪声数据的实体-联系局部。最后我们采取了这样的设计方式，在一次上传中，单个的上传记录实体联系了多个噪声数据实体，这样这些噪声数据就不存在数据上的重复，并且，也很容易分条得到用户的上传记录历史，虽然不如前一种方法紧凑，但是这一方案使得数据库得组织更为得体，也更易于扩展。

另一个面临的决策是关于噪声数据组织成噪声地图的，噪声地图实际上是由噪声数据统计得出的。最初脑海中有三种方案，一个是将噪声地图作为噪声数据的弱实体集，一种是将噪声地图作为噪声数据的视图，还有一种是将噪声地图作为一个单独的实体集，最后得出的方案是将噪声地图单独出来。这样设计的原因是，噪声数据都是历史性的，不会改变，而在某一特定时段过后，噪声地图的数据就应该生成了，在这一时段的噪声地图不再变动，单独的实体也更容易在之后的地图算法中对数据进行操作。在某些设计决策中，需要考虑到数据的某些特性，如这里数据的历史时间特性，以及数据和程序交互的方式，以得到更适合程序的数据库设计。

还有很多设计问题以及改进是在数据库审查时解决的。印象较为深刻的是，用户表中需要对用户是否激活设立一个字段，这是我在之前的设计中完全没有想到的。我毕竟还是一个年轻的程序员，也是第一次进行数据库设计，在很多类似这样的数据库设计细节，我们显然不如边老师这样有经验的大牛，还需要虚心学习，多吸取这方面的经验。

数据库设计中关于数据操作和约束的部分，并没有太大的收获，因为项目需求中对这两个部分没有实际的需求，我也没有想到什么严格的约束。希望以后有机会在其他项目中，对这些部分的设计发起挑战。

这就是数据库设计的全部心得了，目前已经在开发了，希望一切顺利，世界和平。

转载于:https://www.cnblogs.com/xmdyd/p/10005244.html