数据库设计过程中不仅要考虑遵循第三范式，还要考虑是否冗余
很多数据库设计书籍都强调数据库设计三范式，而三范式的一个重要工作就是消除冗余，可以消除冗余在大多数情况下是正确的。当在实际的业务模型中，处理复杂的业务时有时冗余某些信息是更好的。
一、业务需求
值班排班业务：
1、可以设置值班人员；
2、可以设置值班班次；
3、可以进行值班编排；
二、概念结构设计
1、需求分析；
（略过）
2、画用例图；
progress（略过）
3、画E-R图：
1)、定义实体：组织成员、值班成员、班次、排班
2)、组织成员是组织中的全部成员
3)、值班成员依赖于组织成员
4)、排班依赖于班次和值班成员
5)、当前时间已经超过给值班人员排的班次的值班时间时，排班记录自动成为排班历史记录
简单写一下几个实体中的属性
值班成员 shift_contactor_setting(id,…)
班次 shift_setting(id,time,…);
排班 shift_arrange(id,shift_setting_id,shift_contactor_setting_id,date,…)
首先是满足了第三范式，都是我们继续看，当排班记录成为历史时，排班记录应该是不可变的。都是由于我们的排班表是依赖于班次表的，当修改班次记录时，排班历史也可能关联变化了。
这里考虑两种解决办法：
第一种
把班次的time冗余到排班表中： shift_arrange(id,shift_setting_id,shift_contactor_setting_id,date,time…)
新增排班时将班次表的time赋值给排班表的time
第二种
不做冗余，而是每次修改班次时，将旧的班次逻辑删除，然后增加一条新的班次记录；然后还需要将当前时间小于排班的时间的排班记录（也就是未成为历史记录的排班记录）关联的班次id设置为新的班次id，而已经成为排班历史记录的排班记录不作处理
查询时，需要显示排班记录中关联的被逻辑删除的班次
可以看出，第二种方式虽然没有任何冗余，都是增加了代码上的操作，更为复杂，所以这种场景更适合设计冗余字段
三、逻辑结构设计
powerDesigner
四、物理结构设计
MySQL或者将powerDesigner生成的逻辑结构转换成物理结构
数据库的设计并不是一成不变，需要结合实际业务场景进行灵活的变化