0.数据库表设计三范式

数据库三范式

id	name	mobile	zip	province	city	district	deptNo	deptName
101	张三	13910000001 13910000002	100001	北京	北京	海淀区	D1	部门1
101	张三	13910000001 13910000002	100001	北京	北京	海淀区	D2	部门2
102	李四	13910000003	200001	上海	上海	静安区	D3	部门3
103	王五	13910000004	510001	广东省	广州	白云区	D4	部门4
103	王五	13910000004	510001	广东省	广州	白云区	D5	部门5

​ 由于此员工表时非规范化的，我们将面临如下的问题。

• 修改异常：上表中张三有两条记录，因为他隶属于两个部门。如果我们要修改张三的地址，必修修改两行记录。假如一个部门得到了张三的新地址并进行了更新，而另一个部门没有，那么此时张三在表中会存在两个不同的地址，导致了数据不一致。

• 新增异常：假如一个新员工假如公司，他正处于入职培训阶段，还没有被正式分配到某个部门，如果deptNo字段不允许为空，我们就无法向employee表中新增该员工的数据。

• 删除异常：假设公司撤销了D3部门，那么在删除deptNo为D3的行时，会将李四的信息也一并删除。因为他隶属于D3这一部门。

第一范式（1NF）：表中的列只能含有原子性(不可再分)的值。

• 表中的张三有两个手机号存储在mobile列中，违反了 1NF 规则。为了使表满足 1NF，数据应该修改如下：

  id	name	mobile	zip	province	city	district	deptNo	deptName
  101	张三	13910000001	100001	北京	北京	海淀区	D1	部门1
  101	张三	13910000002	100001	北京	北京	海淀区	D1	部门1
  101	张三	13910000001	100001	北京	北京	海淀区	D2	部门2
  101	张三	13910000002	100001	北京	北京	海淀区	D2	部门2
  102	李四	13910000003	200001	上海	上海	静安区	D3	部门3
  103	王五	13910000004	510001	广东省	广州	白云区	D4	部门4
  103	王五	13910000004	510001	广东省	广州	白云区	D5	部门5

第二范式（2NF）：满足第一范式且没有部分依赖。

• 例如，员工表的一个候选键是{id，mobile，deptNo}，而deptName依赖于deptNo，同样 name 依赖于 id，因此不是 2NF的。为了满足第二范式的条件，需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表。如下

  • 员工表employee

  id	name	zip	province	city	district
  101	张三	100001	北京	北京	海淀区
  102	李四	200001	上海	上海	静安区
  103	王五	510001	广东省	广州	白云区

  • 部门表dept

  deptNo	deptName
  D1	部门1
  D2	部门2
  D3	部门3
  D4	部门4
  D5	部门5

  • 员工部门关系表employee_dept

  id	deptNo
  101	D1
  101	D2
  102	D3
  103	D4
  104	D5

  • 员工电话表employee_mobile

  id	mobile
  101	13910000001
  101	13910000002
  102	13910000003
  103	13910000004

第三范式（3NF）：满足第二范式且没有依赖传递。

• 例如，员工表的province、city、district依赖于zip，而zip依赖于id，换句话说，province、city、district传递依赖于id，违反了 3NF 规则。为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表，如下

• employee

id	name	zip
101	张三	100001
102	李四	200001
103	王五	510001

• 地区表

zip	province	city	district
100001	北京	北京	海淀区
200001	上海	上海	静安区
51000	广东省	广州	白云区

在关系数据库模型设计中，一般需要满足第三范式的要求。如果一个表具有良好的主外键设计，就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。

然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。

而如果连接的表过多，会影响查询性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新关系，指定最合适的规范化程度。不要为了遵循严格的规范化规则而修改业务需求。