对三范式的简单理解.docVIP

下面是对三范式的简单理解?第一范式：每列具有不可再分割的原子性 第二范式：每表必须有主键列，且其余各列均必须与该主键列具有内在的逻辑关系 第三范式：当建立表间关系时，子表中有且只有主键列作为父表的外键列 下图是我对三范式的简单理解:?????? ? ??????? 第一范式（1NF）：要求关系模式R的所有属性都是不可分的基本数据项，指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 ????? “地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。 用户信息表 ? 编号 姓名 性别 年龄 联系电话 省份 城市 详细地址 1 张红欣 男 26 0378河南 开封 朝阳区新华路23号 2 李四平 女 32 0751广州 广东 白云区天明路148号 3 刘志国 男 21 0371河南 郑州 二七区大学路198号 4 郭小明 女 27 0371河南 郑州 新郑市薛店北街218号 上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。 ??????? 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）首先要求数据库表中首先必须有主键。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。其次要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。 ??????? 比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。 订单信息表 ? 订单编号 商品编号 商品名称 数量 单位 商品价格 001 1 挖掘机 1 台 1200000￥ 002 2 冲击钻 8 个 230￥ 003 3 铲车 2 辆 980000￥ ??????? 这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。 而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，就非常完美了。如下面这两个所示。 订单信息表 ? 订单编号 商品编号 数量 001 1 1 002 2 8 003 3 2 商品信息表 ? 商品编号 商品名称 单位 商品价格 1 挖掘机 台 1200000￥ 2 冲击钻 个 230￥ 3 铲车 辆 980000￥ 这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。 ??????? 第三范式3NF是第二范式（2NF）的一个子集，即满足第三范式必须满足第二范式。第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关，即任何非主属性不得传递依赖于主属性。简而言之，就是要求一个关系中不包含已在其它关系已包含的非主关键字信息。（不满足时常采用投影分解法解决） ??????? 比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。 订单信息表 ? 订单编号 订单项目 负责人 业务员 订单数量 客户编号 001 挖掘机 刘明 李东明 1台 1 002 冲击钻 李刚 霍新峰 8个 2 003 铲车 郭新一 艾美丽 2辆 1 客户信息表 ? 客户编号 客户名称 所属公司 联系方式 1 李聪 五一建设 2 刘新明 个体经营 ??????? 这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。