数据库设计心得
数据库设计心得
麓山房管总队 - 苏文江 - 201626010427
数据库设计过程回顾
项目简介:
1.基于实时定位和实时照片比对的方法,借助手机平台,完成日常的查寝任务,
2.当发生特殊情况时,也可以一键获取学生手机的位置。
数据库接口简介:
- 用户的登陆注册
用户写入用户名,密码,对应的学号/工号,手机号,和一些其他功能相关的信息。
- 用户写入信息
每次签到时,学生需要写入实时位置和实时图像信息。
- 用户读取信息
后台服务器读取本次写入的数据与系统留存的进行比对,完成查寝结果的自动生成,或者老师读取某位同学的电话号码。
- 统计签到结果
DBMS的检索信息的效率比在后台用循环查找的效率高,借助此特点,可以在数据库部分完成未签到人员的统计。
数据库版本迭代:
Version 1.0

在此版本中,学生表由于部分信息是不变的,部分信息是每次查寝更新的,所以将学生表分为两个表,分别为学生基本信息表和学生功能信息表,学号为基本信息表的主键,在功能信息表中,学号既是主键,又是外键,违背了数据库按类分表的原则。
此外,该数据库的扩展性和应变性不好,每一个学生信息后面添加了辅导员工号这个属性,万一换个老师,需要修改的数据量是巨大的。
Version 2.0
在这个版本中,首先将学生表合成一个表,为了扩展性考虑,在学生表中添加了学院,年级,专业三个属性,同时,数据库中添加了学院表,年级表,专业表,学院_年级_专业_辅导员_关系表,由于版本1中两个注册表格式相同,为了项目其他模块的需要,将这两个表合为一个注册表,并且添加账户类型属性,接下来我们来具体看一下这些表,学生表中,学号为主键,学院,年级,专业的组合为外键,还有一些功能性属性,学院表中,学院为主键,年级表中,年级为主键,专业表中,专业为主键,辅导员表中,工号为主键,关系表中,学院,年级,专业的组合为主键,学院,年级,专业,辅导员工号各自都是外键,通过关系表的主键和学生表的外键,可以直接定位学生所对应的辅导员,如果学院换了辅导员,也只需要改变关系表中的一行,此外,该数据库可以契合我们学校的23个学院的体系,为日后扩展打下了良好基础。
Version 3.0

考虑到反范式主键设计原则:
尽量避免使用业务主键,尽量使用逻辑主键。
如果要使用业务主键必须保证业务主键相关的业务逻辑改变的概率为0。
给每个表添加一行冗余列作为主键,进一步提高了数据库的业务主键应变性,减小了主键的大小,查询效率提高,被引用时空间消耗减小。将业务主键设计为唯一索引,首先唯一性确保了数据库主键的设计原则,其次,将它设计为索引,也可以对它像主键一样进行一系列的查询操作。

Version 4.0
在小班课讨论数据库的时候,胡军老师给我们组提了一个建议,学生表的一半信息变动,另一半不动,应该把他们分开,只不过功能信息表中不加主键,将学号作为唯一外键即可。

心得体会
实际设计,才会发现问题
对数据库的理解也会更加深刻。
勤于改变,越早更改,成本越低。

浙公网安备 33010602011771号