数据库设计时一般需要遵循一定的规则,在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须满足一定的范式。以实现避免数据库设计的冗余。
第一范式:每个属性(即列)是原子性,不可分割的。
姓名 | 性别 | 年龄 | 住址 |
张三 | 男 | 23 | 陕西省西安市雁塔区南大街23号 |
第二范式:第二范式是基于第一范式的,它的意思是指表中的每个属性都必须和主键相关,而不是和主键的一部分相关,这种情况主要存在于表中存在两个属性作为主键的时候。也可以理解为一个表中只能保存一种数据,不可以把多种不相关的属性保存到一个表中。如下设计
订单编号 | 商品编号 | 商品名称 | 数量 | 单价 | 客户 | 联系方式 |
A0001 | P0001 | 可口可乐 | 50 | 3 | 张三 | 111111111 |
A0002 | P0002 | 百事可乐 | 50 | 3 | 李四 | 22222222 |
A0001 | P0003 | 王老吉 | 80 | 3 | 王五 | 33333333 |
订单编号和商品编号同时作为主键时(因为订单可能包含多种商品),当前设计就不符合第二范式。因为商品名称、价格,和订单编号没有关系。所以需要把不相关的信息分开。
依次为:订单信息,订单项目表,商品表。
订单编号 | 客户 | 联系方式 |
A0001 | 张三 | 11111111 |
A0002 | 李四 | 2222222 |
A0001 | 王五 | 3333333 |
订单编号 | 商品编号 | 数量 |
A0001 | P0001 | 50 |
A0002 | P0002 | 50 |
A0001 | P0003 | 80 |
商品编号 | 商品名称 | 单价 |
P0001 | 可口可乐 | 3 |
P0002 | 百事可乐 | 3 |
P0003 | 王老吉 | 3 |
这样分割之后就比较清晰了。
第三范式:每个属性都和主键直接相关,而不是间接相关,或者可以说是属性之间不能存在依赖关系,比如a-->b-->c 这样就不符合第三范式。如果某一属性依赖于其他非主键属性,而其他非主键属性又依赖于主键,那么这个属性就是间接依赖于主键,这被称作传递依赖于主属性。
比如Student表(学号,姓名,年龄,性别,所在院校,院校地址,院校电话)
这样的设计就不可以,因为学号----->所在院校----->院校地址,学号----->所在院校-------->院校电话
应该提取两个表,(学号,姓名,年龄,性别,所在院校)--(所在院校,院校地址,院校电话)
参考地址如下:
http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html
http://baike.baidu.com/link?url=eIS39KIi5TFPwuBdVuVzR43G8Yr-M7R3E79p_ws9jl1AtrqGT8HpRbOr-zYYLw3DkqqOqHy8LSssVW5bKYR4Y_