一,三大范式
1.第一范式(1NF)
原子性:强调的是列的原子性,即数据库中每一列的字段都是单一属性,不可再分的。并且这个单一属性必须是由基本的数据类型所构成的,如整数、字符串等。
举例:
这是一张员工表:
员工ID 姓名 性别 部门 联系电话
101 周星星 女 销售部 15015246623
现在我们来分析上表,这张员工表是不符合第一范式标准的,每个员工只有一个员工ID,也确实只有一个姓名,一个性别,只属于一个部门,但是在我们的实际生活中,每个人真的只有一个联系电话吗?这里我们就假设最少的情况,每个人都有个人电话和家庭电话,那么联系电话这一字段就是可再分的。这张表的结构设计就没有达到第一范式。
解决方案:我们只需要把联系电话这一字段分为个人电话字段和家庭电话字段,就完全符合了第一范式(如下表)。
员工ID 姓名 性别 部门 个人电话 家庭电话
101 周星星 女 销售部 15015246623 663323
2.第二范式(2NF)
依赖性:在满足1NF的基础上再满足依赖性的两个约束:一张表必须有一个主键;非主键类必须完全依赖于主键,而不能只依赖主键的一部分。
这是一张商品供销信息表:
商品 供销商 价格 重量 分类 供销商电话
啤酒 饮品1厂 3 300ml 液体 18016253155
啤酒 饮品2厂 5 300ml 液体 18055231233
可乐 饮品2厂 5 250ml 液体 18055231233
需要清楚几点:
1.商品与供销商是多对多的关系
2.该表中关键字是一组组合关键字<商品,供销商>,只有商品和供销商两个字段结合才可标识出一件商品
3.存在以下部分依赖的关系
商品---->价格,重量,分类
供销商---->供销商电话由以上存在的部分依赖关系就可知道该商品表不符合第二范式了,价格,重量,分类只依赖于商品这个主键,而供销商电话也只依赖于供销商这个主键,已经完全违背了第二范式非主键列必须完全依赖于主键而不能只依赖于主键的一部分这一原则了。
解决方案:把上表商品表拆分为商品表和供销商表两张表,既满足了非主键字段必须完全依赖主键这一条件又减少了供销商电话重复这一冗余。
商品 供销商 价格 重量 分类
啤酒 饮品1厂 3 300ml 液体
啤酒 饮品2厂 5 300ml 液体
可乐 饮品2厂 3 250ml 液体
供销商 供销商电话
饮品1厂 18016253155
饮品2厂 18055231233
3.第三范式(3NF)
在满足2NF的基础上,另外再满足一个条件:非主键列必须直接依赖于主键,不能存在传递依赖。
这是一张学生课表:
课程编号 课程名字 上课时间 任课老师 老师电话 老师职位
101 马克思理论基础 8:00 Lily 18016253155 讲师
102 经济学 14:00 Lucy 18055231233 教授
主键:课程编号
大致一看,上表中的非主键列确实完全是依赖于主键(课程编号)的,符合第二范式2NF。但是问题是:老师电话,老师职位直接依赖的是任课老师(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。
解决方案:依然是通过拆分,把上述学生课表拆分为课程表和教师表。
课程表:
课程编号 课程名字 上课时间 任课老师
101 马克思理论基础 8:00 Lily
102 经济学 14:00 Lucy
教师表:
任课老师 老师电话 老师职位
Lily 18016253155 讲师
Lucy 18055231233 教授
关于范式的一些其他了解
范式(Normal Form)是英国人在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中必须要遵循的规则和指导方法。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF,但是我们只要理解前三个范式就完全够用了,其他范式只是简单了解一下。
二,五大约束
1.PRIMARY KEY(primary key):设置主键约束;
2.UNIQUE(unique):设置唯一性约束,不能有重复值;
3.DEFAULT(default):默认值约束,height DOUBLE(3,2) height不输入是默认为(1,2)。
4. NOT NULL(not null):设置非空约束,该字段不能为空;
5. FOREIGN KEY (foreign key):设置外键约束。
(自我练习记录)