数据库设计过程中不仅要考虑遵循第三范式，还要考虑是否冗余

很多数据库设计书籍都强调数据库设计三范式，而三范式的一个重要工作就是消除冗余，可以消除冗余在大多数情况下是正确的。当在实际的业务模型中，处理复杂的业务时有时冗余某些信息是更好的。

一、业务需求

值班排班业务：
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生成的逻辑结构转换成物理结构

数据库的设计并不是一成不变，需要结合实际业务场景进行灵活的变化

补充一下数据库三范式的概念：
范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
下面就简单介绍下这三个范式。

第一范式（1NF）

强调的是列的原子性，即列不能够再分成其他几列。
考虑这样一个表：【联系人】（姓名，性别，电话）
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。

第二范式（2NF）

首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式（3NF）

在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。

第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。

首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。

其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。

第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

如何在数据库三范式的基础上进行数据库冗余设计相关推荐

python学习笔记 day44 数据库三范式
参考自 https://www.cnblogs.com/wangfengming/articles/7929118.html 1. 数据库三范式概念: 为了建立减少冗余,结构合理的数据库,涉及数据库时 ...
数据库三范式经典实例解析
数据库的三范式 1N:关系R中的属性都是不可分割的项. 2N:在1N的基础上,每个非主属性完全函数依赖于码. 3N:在2N的基础上,每一个非主属性既不部分依赖于码也不传递依赖于码. 1N | ...
为什么我不喜欢数据库三范式
插曲最近,一个远房亲戚的小表弟准备选修专业找到我问: "哥,现在学数据库有没有前途阿?""当然有啊,前途大大的呢""那我现在开始学数据库,需要先从 ...
MySQL笔记（七）数据库三范式
这是我在学习Mysql之路上做的笔记,今天将它粘出来.这一篇主要是数据库三范式.有错误的欢迎大家指出... 数据库三范式 (1)第一范式(1NF): 定义:每一列都是不可分割的原子数据项(强调的是列的 ...
从数据库三范式角度分析一对多、多对多和一对一关系
文章目录前言一.三范式的目的二.三范式及其对应关系 1.第一范式 2.第二范式 3.第三范式 4.一对一关系总结前言几乎绝大多数项目的最终目的都是通过操作数据库来实现的,所以,操作数据库的 ...
数据库三范式通俗理解 -数据库三范式官方定义
数据库三范式官方定义第一范式(1NF):数据库表中的字段都是单一属性的,不可再分. 第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖第三范式(3NF):在第二范式的 ...
MySql——数据库三范式
用于自己学习时的简单解释数据库三范式:是数据库的设计原则,主要目的是为了避免数据冗余. 数据库的设计应当遵循三范式第一范式:任何一张表都应该有主键,每一个字段必须具有原子性不可再分第二范式:在第 ...
数据库三范式【看了就有收获，最简单的例子解释】
1. 数据库的三范式是什么???? 范式=规范,原则上是必须遵循的(但是需求不同可以不遵循),特殊情况可以不遵循第一范式(1NF):符合数据表的原子性[就是每一个属性不可再分] 表中的同一列数据相同 ...
数据库三范式无重复列完全依赖主键属性不依赖非主属性
参考:http://www.cnblogs.com/xrq730/p/5100442.html 细说数据库三范式 2.1 第一范式(1NF)无重复的列,保证每列的原子性,即每一列的各个属性值之间不能有 ...

如何在数据库三范式的基础上进行数据库冗余设计