切换导航
简历
工具
演示
查询
导航菜单
服务端
30
前端
114
数据库
82
进阶开发
8
桌面程序
2
QA
15
软件使用
36
规范协议
5
操作系统
11
AI
0
复用资源
6
硬件
0
标签
SQL Server
Redis
MySQL
其它
Oracle
外部链接
.NET Core SDK和运行时安装包
淘宝 NPM 镜像
查询网
Tables Generator线上表格转换工具
引用cdn在线脚本和样式
首页
数据库
MySQL 数据库使用范式规范说明
[TOC] ### 1. 范式介绍 __范式全称:__Normal Format #### 1.1 范式是什么 范式:是一种离散数学中的知识,是为了解决一种数据的存储与优化的问题,保存数据的存储之后,凡是能通过关系寻找出来的数据,坚决不再重复存储,终极目标是为了减少数据的冗余 范式:是一种分层结构的规范,分为六层,每一层都比上一层更加严格,若要满足下一层范式,前提是满足上一层范式,六层范式分别是,1NF、2NF、3NF、……、6NF,1NF是最低层,要求最低,6NF是最高层,要求最严格 #### 1.2 MySQL数据库与范式的关联 MySQL数据库也是致力于节省存储空间,与范式所解决的问题不谋而合,在设计数据库的时候,可以利用到范式来指导设计,但是数据库不单是解决空间问题,还要保证效率问题,范式只解决空间问题,所有数据库的设计又不可能完全按照范式的要求实现,一般情况下,只有前三种范式需要满足,MySQL使用范式规范设计,只是一种参考意义,并不是强制的规范 #### 1.3 第一范式 1NF 第一范式:在设计表存储数据的时候,如果表中设计的字段存储的数据,在取出使用之前还需要额外的处理,例如拆分字段数据,那么说表的设计不满足第一范式,第一范式要求字段的数据具有原子性,原子性表示不可再分,下表的设计就违反了第一范式 |姓名|性别|职务|任职时间(开始时间-结束时间)| |--|--|--|--| |曹操|男|丞相|1922-10-01,1966-08-01| |刘表|男|荆州牧|1913-11-05,1926-02-21| |何进|男|大将军|1911-06-15,1916-03-11| 上表设计不存在问题,但如果`需求要求`数据查出来之后,需要拆分任职时间,分开展示开始时间和结束时间,那么这样的设计,数据就不具有原子性,也就违反了1NF,解决办法就是将任职时间字段进行差分,如下表 |姓名|性别|职务|任职开始时间|任职结束时间| |--|--|--|--|--| |曹操|男|丞相|1922-10-01|1966-08-01| |刘表|男|荆州牧|1913-11-05|1926-02-21| |何进|男|大将军|1911-06-15|1916-03-11| #### 1.3 第二范式 2NF 第二范式:在数据表设计过程中,如果有复合主键(多字段主键),且表中有字段并不是由整个主键来确定,而是依赖主键中的某个字段(主键的部分),存在字段依赖主键的部分的问题,称之为部分依赖,第二范式就是要解决表设计中可能存在的部分依赖,下表的设计就违反了第二范式 |姓名|性别|职务|任职开始时间|任职结束时间| |--|--|--|--|--| |曹操|男|丞相|1922-10-01|1966-08-01| |曹操|男|魏王|1952-10-01|1966-08-01| |董卓|男|丞相|1913-11-05|1926-02-21| |何进|男|大将军|1911-06-15|1916-03-11| 上表中,姓名无法作为主键,需要与职务结合才能作为主键,也就形成了复合主键,而当前表中的任职开始时间和任职结束时间都依赖主键,但性别只依赖姓名,出现了性别只依赖主键中的一部分,即产生了部分依赖,不符合第二范式 解决办法: + 可以将性别与姓名拆分成新表 + 取消符合主键,使用逻辑主键,例如创建一个新的字段id作为主键 |id|姓名|性别|职务|任职开始时间|任职结束时间| |--|--|--|--|--|--| |1|曹操|男|丞相|1922-10-01|1966-08-01| |2|曹操|男|魏王|1952-10-01|1966-08-01| |3|董卓|男|丞相|1913-11-05|1926-02-21| |4|何进|男|大将军|1911-06-15|1916-03-11| #### 1.4 第三范式 3NF 第三范式:理论上讲,应该一张表中的所有字段都应该直接依赖主键,逻辑主键除外,如果表设计中存在一个字段,并不是直接依赖主键,而是通过某个非主键字段依赖,最终实现依赖主键,把这种依赖方式称之为传递依赖,第三范式就是要解决传递依赖的问题 |id|姓名|性别|职务|任职开始时间|任职结束时间| |--|--|--|--|--|--| |1|曹操|男|丞相|1922-10-01|1966-08-01| |2|曹操|男|魏王|1952-10-01|1966-08-01| |3|董卓|男|丞相|1913-11-05|1926-02-21| |4|何进|男|大将军|1911-06-15|1916-03-11| 以上设计方案中,性别依赖姓名存在,姓名依赖主键,这里的主键id还是逻辑主键,它代表了性别和职务的复合主键,等于说姓名是主键的一部分,这样看性别就存在传递依赖的现象 解决办法:将存在传递依赖的字段,以及依赖的字段本身单独取出,形成一个单独的表,然后在需要对应的信息的时候,使用对应的实体表主键进行关联,例如将上面的表分成下面的两个表 |id|userId|职务|任职开始时间|任职结束时间| |--|--|--|--|--|--| |1|1|丞相|1922-10-01|1966-08-01| |2|1|魏王|1952-10-01|1966-08-01| |3|2|丞相|1913-11-05|1926-02-21| |4|3|大将军|1911-06-15|1916-03-11| |userId|姓名|性别| |--|--|--|--| |1|曹操|男| |2|董卓|男| |3|何进|男| #### 1.5 逆规范化 逆规范化:磁盘利用效率与查询效率的对抗,如果满足第三范式,需要拆分出多张表,而这些表的数据量又比较的大,连表查询影响到查询的效率时,可以逆规范化,采用数据冗余的方式来提高查询的效率,例如上面几张表,可以在表中添加姓名冗余字段,性别不是查询需求 |id|姓名|职务|任职开始时间|任职结束时间| |--|--|--|--|--|--| |1|曹操|丞相|1922-10-01|1966-08-01| |2|曹操|魏王|1952-10-01|1966-08-01| |3|董卓|丞相|1913-11-05|1926-02-21| |4|何进|大将军|1911-06-15|1916-03-11|
扫一扫手机看
点击排行
windows 文件资源管理器使用
Layui 弹窗open使用说明
SQL Server 中字符串函数使用
C# 使用QQ邮箱代理做邮件接收功能
SQL Server关于apply的两种形式cross apply 和 outer apply
ASP.NET MVC 模型的自定义验证
nvm安装及常用命令
SQL Server 中数据类型转换
SQL Server 中WITH AS短语的使用
IE浏览器下AJAX缓存问题导致数据不更新的解决办法
订阅号