[TOC]
Java进阶 MySQL三范式正确理解
1、什么是三范式?
首先我们要知道什么是三范式
为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库,必须满足一定的范式。
在实际开发中最为常见的设计范式有三个:
2、第一范式(确保每列保持原子性)
第一范式是最基本的范式。如果数据库表中的**所有字段值都是不可分解的原子值**,就说明该数据库表满足了第一范式。1NF是所有关系型数据库的最基本要求。
第一范式的合理遵循需要根据系统的**实际需求**来定。比如某些数据库系统中需要用到“地址”这个属性,本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示。
用户信息表:
编号 | 姓名 | 性别 | 年龄 | 联系电话 | 省份 | 城市 | 详细地址 |
---|---|---|---|---|---|---|---|
1 | 张三 | 男 | 11 | 130x | 四川 | 成都 | 青羊区 |
2 | 李四 | 男 | 22 | 140x | 福建 | 福州 | 石狮市 |
3 | 王五 | 女 | 33 | 150x | 江苏 | 扬州 | 生态科技新城 |
上表所示的用户信息遵循了第一范式的要求,这样在对用户使用城市进行分类的时候就非常方便,也提高了数据库的性能。
3、第二范式(确保表中的每列都和主键相关)
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。**也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中**。(2NF在1NF的基础之上,消除了非主属性对于码的部分函数依赖)
什么是“码”?
设 K 为某表中的一个属性或属性组,若除 K 之外的所有属性都完全函数依赖于 K(这个“完全”不要漏了),那么我们称 K 为候选码,简称为码。在实际中我们通常可以理解为:假如当 K 确定的情况下,该表除 K 之外的所有属性的值也就随之确定,那么 K 就是码。一张表中可以有超过一个码。(实际应用中为了方便,通常选择其中的一个码作为主码) 例如:对于表3,(学号、课名)这个属性组就是码。该表中有且仅有这一个码。(假设所有课没有重名的情况)
现在要设计一个订单信息表,因为订单中可能会有多种商品,所以要将订单编号和商品编号作为数据库表的联合主键,如下表所示。
订单信息表:
订单编号 | 商品编号 | 商品名称 | 数量 | 单位 | 价格 | 客户 | 所属单位 | 联系方式 |
---|---|---|---|---|---|---|---|---|
001 | 1 | 机票 | 10 | 张 | 1000 | 张三 | 百度 | 130x |
002 | 2 | 动车票 | 20 | 张 | 500 | 李四 | 华为 | 140x |
003 | 3 | 客车票 | 30 | 张 | 200 | 王五 | 腾讯 | 150x |
这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示。
订单所属表:
订单编号 | 客户 | 所属单位 | 联系方式 |
---|---|---|---|
001 | 张三 | 百度 | 130x |
002 | 李四 | 华为 | 140x |
003 | 王五 | 腾讯 | 150x |
商品数量表:
订单编号 | 商品编号 | 数量 |
---|---|---|
001 | 1 | 10 |
002 | 2 | 20 |
003 | 3 | 30 |
商品信息表:
商品编号 | 商品名称 | 单位 | 商品价格 |
---|---|---|---|
1 | 机票 | 张 | 1000 |
2 | 动车票 | 张 | 500 |
3 | 客车票 | 张 | 200 |
这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。
4、第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的**每一列数据都和主键直接相关,而不能间接相关**。3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。
比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
订单信息表:
订单编号 | 订单项目 | 负责人 | 业务员 | 订单数量 | 客户编号 |
---|---|---|---|---|---|
001 | 机票 | 张三 | 赵六 | 10 | 1 |
002 | 动车票 | 李四 | 田七 | 20 | 2 |
003 | 客车票 | 王五 | 牛八 | 30 | 1 |
客户信息表:
客户编号 | 客户名称 | 所属公司 | 联系方式 |
---|---|---|---|
1 | 刘某 | 百度 | 130X |
2 | 赵某 | 华为 | 140X |
这样在查询订单信息的时候,就可以使用客户编号来引用客户信息表中的记录,也不必在订单信息表中多次输入客户信息的内容,减小了数据冗余。
提前预热:五大约束
- primary KEY: 设置主键约束;
- UNIQUE:设置唯一性约束,不能有重复值;
- DEFAULT: 默认值约束,height DOUBLE(3,2)DEFAULT 1.2 height不输入是默认为1.2;
- NOT NULL:设置非空约束,该字段不能为空;
- FOREIGN key : 设置外键约束。