数据库的三大范式
一、1NF 字段不可再分,原子性。
以订单举例子。
表1
表2
千万别设计成这样。
二、2NF 满足第二范式必须先满足第一范式,一个表只能说明一个事务,非主键属性必须完全依赖于主键属性。
将上面的表格拆分,使其满足第一范式。
表3 订单表
表4 订单细节表
表3中一个订单号能唯一确定一行,表3的主键是 订单号。
表4中订单号和产品编码可以唯一确定一行,表四的主键是订单号,产品编码,是一个符合主键。
虽然说 (订单号,产品编码) 是主键, 能确定其他属性的值, 但是 产品名称和单价 实际上并不依赖于 订单号。 如果我们想添加一个新的产品比如ipad, 你会发现没法放入这张表, 因为没有订单号!
继续拆分
表4.1 订单细节表
表六4.2产品表
这样符合第二范式了
三、满足3NF必须先满足2NF,每列有与主键有关系,不存在传递依赖。任何非主属性不依赖于其他非主属性。
表3中存在传递依赖,订单号能决定用户ID,而用户ID能决定用户名称,这个出现了传递依赖。订单号->用户ID->用户名称。
将表3进行拆分。
表3.1 订单表
表3.2 用户表
“不错, 现在就没有传递依赖了, 我们可以称之为 第三范式 了”
“我有个疑问啊” 大胖问道, ”为了满足所谓的范式要求, 我们把最初的大表拆的如此‘分散’, 到时候查询的时候岂不非常麻烦??“
“可不是, 把这些‘分散表’连接(Join)起来才能形成最初的那张表, 如果在数据量特别巨大的时候, 这种连接挺耗时的。 在实践中我们有时候不得不违反范式,做点数据的冗余。 比如说我们虽然把表3.2 用户表单独拆分了出来, 但是有时候为了性能, 还会在表3.1 中把用户名也加上, 为一个冗余。 ”