Question

从这学期开始，张大胖开始学习数据库， 听说这门课很重要， 很基础， 但是大胖学的很烦。

其实刚开始的时候还行， 课程先讲了讲数据库的作用， 他听的津津有味， 但讲到后边， 当那些文绉绉的术语像关系演算、函数依赖、规范化...... 出现的时候， 大胖彻底的懵了。

他实在是不明白， 这个看起来像一个表格的东西为什么搞这么多数学的公式， 最烦数学了。

周末大胖跑去向大神好基友 Bill 诉苦 ：“这关系数据库不就是一个二维的表格吗， 就像 Excel 那样， 一行一列的， 为什么搞的这么复杂， 还有数学的东西？”

Bill 笑了笑说： “看起来确实像个表格， 但是和表格很不一样， 你看看这个例子， 然后想想能直接用关系数据库来保存吗？”

（表格 1 订单表 ）

大胖说： “似乎不行，你看一个订单号 X2001 对应一个用户，U001(白展堂)， 还对应两行产品， P101（路由器）, P102（充电宝） ， 不过， 我能不能改成这样： ”

（表格 2 点击看大图）

Bill 一看， 这张大胖竟然把多行合并成了一行， 中间用逗号分开， 不由的又气又笑：

“你要是参加工作了， 设计出这样的数据库表， 老板非骂死你不可。 你要记住呀， 我们关系数据库最忌讳的就是在一个单元格里存储多个值。 这是典型的‘非规范化’的设计”

“非规范化？ 那怎么办？ ”

“拆分， 把它拆成规范化的 ” 说着，Bill 搞了两个表格出来：

（表 4： 订单细节表）

“明白了， 这样的拆分就可以保证一个单元格只有个值了” 张大胖说。

“这种形式的表， 我们就叫做 第一范式 ， 不止如此， 你看看表格 3 订单表， 是不是一个订单号就能唯一的确定一行？ ”

“对， 订单表确实是这样的， 但是表格 4 单单用订单号就不行了， 还得加上产品编码， 才能确定同一行的其他值。”

Bill 说： ”所以我们说表 3 的主键是 （订单号）， 表 4 的主键是（订单号，产品编码）， 这是一个复合主键“

大胖高兴的说： “啊， 这第一范式看来很简单嘛”

“别急， 你再看看表格 4：订单细节表， 虽然说 （订单号，产品编码） 是主键， 能确定其他属性的值， 但是 产品名称和单价 实际上并不依赖于 订单号。 如果我们想添加一个新的产品比如 ipad， 你会发现没法放入这张表， 因为没有订单号！ ”

“奥， 必须先有订单才能有产品， 这确实是太扯了， 难道再拆分？” 大胖问？

“必须拆， 要不然就没法工作”

（表 4.1 订单细节表）

（表 4.2 产品表）

“我明白了， 现在表 4.1 中主键还是（订单号，产品编码)， 剩下的属性（数量) 肯定依赖于这个主键了， 表 4.2 也类似。”

Bill 总结说：“ 这种所有属性仅仅依赖于主键的情况就是 第二范式 。 ”

“这些范式术语听起来一本正经的， 很学究， 背后还是挺有用的嘛。 那表格 3 中主键是（订单号）， 其他所有属性都依赖于主键， 已经是第二范式了吧”

Bill 说 ：“可以这么认为， 但是这个表有个好玩的情况， 就是订单号能决定用户 ID, 而用户 ID 能决定用户名称， 这就出现了传递依赖： 订单号->用户 ID->用户名称 。 你看看用户信息其实也无法单独管理了， 也得拆分， 这个很简单， 你来试试？ ”

张大胖迅速的鼓捣出两张表来：

（表 3.1 订单表）

（表 3.2 用户表）

Bill 说：“不错， 现在就没有传递依赖了， 我们可以称之为 第三范式 了”

“我有个疑问啊” 大胖问道， ”为了满足所谓的范式要求， 我们把最初的大表拆的如此‘分散’， 到时候查询的时候岂不非常麻烦？？“

“可不是， 把这些‘分散表’连接(Join) 起来才能形成最初的那张表， 如果在数据量特别巨大的时候， 这种连接挺耗时的。 在实践中我们有时候不得不违反范式，做点数据的冗余。 比如说我们虽然把表 3.2 用户表单独拆分了出来， 但是有时候为了性能， 还会在表 3.1 中把用户名也加上， 为一个冗余。 ”