mysql数据库优化--(3)设计 范式 Normal Format, 规范的格式
来源:互联网 发布:李乐的霍去病 知乎 编辑:程序博客网 时间:2024/05/29 17:00
数据设计数据表是,通用的规范规则,帮助设计更优秀的数据表结构.
范式的定义是层级定义, 1NF, 2NF, 3NF…… 6NF第一,第二…第六范式.
当前级别的范式,都是在满足前一级别的基础上,在增加规范内容.
通常满足3NF范式即可!
一:字段原子性;二:主键独立性;三:减少传递依赖
结论:
1 每类实体独立一张表
2 每张表存在独立的自动增长的非业务逻辑ID作为主键
3 使用关联字段或者关联表,去表示实体间的联系
3.1 1NF,第一范式,满足原子性
字段,属性应该独立,不可再分的.就称之为字段满足原子性.
看下面的设计:
表示,老师在某个班级的那个阶段,进行授课.
老师
性别
班级
教室
授课时间
孔子
男
PHP4
203
2016-01-01 到 2016-3-15
老子
男
PHP4
203
2016-3-16到 2016-6-11
孔子
男
Java3
201
2016-03-17
观察授课时间字段?
在数据上由两个部分组成: 1开始2结束时间
如果在应用程序中,需要仅仅需要开始的时间.授课时间的字段,就不满足逻辑上的原子性.
老师
性别
班级
教室
开始时间
结束时间
孔子
男
PHP4
203
2016-01-01
2016-3-15
老子
男
PHP4
203
2016-3-16
2016-6-11
孔子
男
Java3
201
2016-03-17
2016-5-12
再思考:如果应用程序,就是需要授课时间段,而没有需要独立的开始时间和结束时间呢?
可见,授课时间是不需要再拆分的.
拆分后,满足逻辑上的原子性.而不拆分,也满足新的逻辑上的原子性.
可见,逻辑上的原子性,是依赖于当前的应用程序需求的.
物理结构上,关系型数据库系统的表,都满足物理的原子性.
二维表,都满足第一范式!1NF.
3.2 2NF,在满足第一范式的前提下,消除对主键的部分依赖
增加独立的主键字段!
主键:表中,记录的唯一标志.称之为主键. primary key.
主键可以由1个或多个字段构成:
如下表:在不增加字段的情况下,建立主键:
老师
性别
班级
教室
开始时间
结束时间
孔子
男
PHP4
203
2016-01-01
2016-3-15
老子
男
PHP4
203
2016-3-16
2016-6-11
孔子
男
Java3
201
2016-03-17
2016-5-12
选择老师+班级两个字段组成联合主键.
部分依赖:在联合主键的情况下,表中的非主键字段,依赖于(A字段确定,就可以确定B字段,称之为B字段依赖于A字段)联合主键中的部分字段.
例如,性别字段,就由老师字段决定,性别字段部分依赖于主键中的老师字段.就产生了部分依赖!
消除联合主键,也就消除了部分依赖的可能性.
增加一个于业务逻辑无关的自动增长的ID字段,作为记录的主键.
ID
老师
性别
班级
教室
开始时间
结束时间
23
孔子
男
PHP4
203
2016-01-01
2016-3-15
25
老子
男
PHP4
203
2016-3-16
2016-6-11
57
孔子
男
Java3
201
2016-03-17
2016-5-12
此时,主键由ID构成.没有联合主键,就没有部分依赖!
就满足了第二范式.
3.3 3NF,第三范式,满足第二,消除对主键传递依赖
传递依赖:
字段,依赖于非主键之外的其他字段.就成为形成了对主键的传递依赖.
例如:
ID
老师
性别
班级
教室
开始时间
结束时间
23
孔子
男
PHP4
203
2016-01-01
2016-3-15
25
老子
男
PHP4
203
2016-3-16
2016-6-11
57
孔子
男
Java3
201
2016-03-17
2016-5-12
性别依赖非ID的,老师字段.性别依赖于非主键字段,产生了传递依赖.
解决思路:将同一种实体,使用一张表进行存储,解决之后,老师,班级,授课信息分别在表中存储,如果需要,使用主键字段,进行关联即可:
授课信息表:
ID
老师ID
班级 ID
开始时间
结束时间
23
1
11
2016-01-01
2016-3-15
25
2
11
2016-3-16
2016-6-11
57
1
12
2016-03-17
2016-5-12
老师表
老师ID
老师
性别
1
孔子
男
2
老子
男
班级表
班级ID
班级 ID
教室
11
PHP4
203
12
Java3
201
以上的设计就满足了第三范式.
可见,满足,每种实体,一张表,实体间的关系,使用关联字段表示,就可以满足第三范式!
3.4 为什么要满足范式?
尽可能减少数据冗余.
提升更新的便利性.
3.5 逆范式优化
为了提升某个操作的速度,而打破范式,称之为逆范式!
有种优化策略.
例如:
问题表 question
问题ID
标题
发布时间
分类ID
分类表: category
分类ID
分类标题
下面的SQL需求:查询分类,及其分类对于的问题数量:
select c*, count(q.question_id) as question_number from category c left join question q using(category_id) group by c.category_id;
当,查询分类时,总是需要查询到分类对应的问题的数量
每当查询category,就需要连接 question.question的数据量一定会很大.
设计分类表时,强制增加一个字段,问题数量:
分类ID
分类标题
问题数量
此时在一张表中就可以获取分类及其对应的问题数量.
效率是提升了,数据冗余了.打破了范式.就是逆范式的优化方案!
注意,打破范式,带来业务逻辑的增加.
必须要设计好再做,哪些操作会影响当前的数据设计,必须要同时更新才可以!
比如上例所述:当增加或删除问题时,需要额外增加数据逻辑,对分类表中对应的'问题数量'字段进行修改(增减),增加了业务量和数据风险.慎做!
- mysql数据库优化--(3)设计 范式 Normal Format, 规范的格式
- 数据库设计-数据库范式(Normal Forms)
- Normal Form 范式 数据库设计原理
- 数据库设计中的范式规范
- 数据库范式-Normal Form
- MySQL优化技术:3范式的表设计
- 数据库设计的3范式
- 数据库 - 范式(Normal Form, NF)
- MySql--数据库设计三范式
- 数据库的设计范式
- 数据库的设计范式
- 数据库的设计范式
- 数据库设计的范式
- 数据库的设计范式
- 数据库的设计范式
- 数据库的设计范式
- 数据库设计的范式
- 数据库范式的设计
- PhoneGap || Cordova 安装以及导入AndroidStudio 遇到的问题
- Filter和Servlet的区别
- 55-Jump Game
- Java之FileChannel类的理解和使用
- MyBatis常用对象SqlSessionFactory和SqlSession介绍和运用
- mysql数据库优化--(3)设计 范式 Normal Format, 规范的格式
- 56-Merge Intervals && 57-Insert Interval
- 写给非专业人士看的 Shadowsocks 简介
- PAT练习-程序运行时间
- 61-Rotate List
- 20170623
- 三元式,四元式,逆波兰表达式
- 62-Unique Paths
- CDN 是个啥