首页 / 更多教程 / 关系型数据库之三范式介绍
关系型数据库之三范式介绍
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了关系型数据库之三范式介绍,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含3201字,纯文字阅读大概需要5分钟。
内容图文
示例表数据
假设有一个名为employee
的员工表,它有九个属性:id
(员工编号)、name
(员工名称)、mobile
(电话)、zip
(邮编)、province
(省份)、city
(城市)、district
(区县)、deptNo
(所属部门编号)、deptName
(所属部门名称)、表总数据如下:
id | name | mobile | zip | province | city | district | deptNo | deptName |
---|---|---|---|---|---|---|---|---|
101 | 张三 | 13910000001<br />13910000002 | 100001 | 北京 | 北京 | 海淀区 | D1 | 部门1 |
101 | 张三 | 13910000001<br />13910000002 | 100001 | 北京 | 北京 | 海淀区 | D2 | 部门2 |
102 | 李四 | 13910000003 | 200001 | 上海 | 上海 | 静安区 | D3 | 部门3 |
103 | 王五 | 13910000004 | 510001 | 广东省 | 广州 | 白云区 | D4 | 部门4 |
103 | 王五 | 13910000004 | 510001 | 广东省 | 广州 | 白云区 | D5 | 部门 5 |
由于此员工表是非规范化的,我们将面对如下的问题。
修改异常:上表中张三有两条记录,因为他隶属于两个部门。如果我们要修改张三的地址,必修修改两行记录。假如一个部门得到了张三的新地址并进行了更新,而另一个部门没有,那么此时张三在表中会存在两个不同的地址,导致了数据不一致
新增异常:假如一个新员工假如公司,他正处于入职培训阶段,还没有被正式分配到某个部门,如果
deptNo
字段不允许为空,我们就无法向employee
表中新增该员工的数据。删除异常:假设公司撤销了D3部门,那么在删除
deptNo
为D3的行时,会将李四的信息也一并删除。因为他隶属于D3这一部门。
第一范式(1NF)
表中的列只能含有原子性(不可再分)的值。
表中的张三有两个手机号存储在mobile列中,违反了 1NF 规则。为了使表满足 1NF,数据应该修改如下:
id | name | mobile | zip | province | city | district | deptNo | deptName |
---|---|---|---|---|---|---|---|---|
101 | 张三 | 13910000001 | 100001 | 北京 | 北京 | 海淀区 | D1 | 部门1 |
101 | 张三 | 13910000002 | 100001 | 北京 | 北京 | 海淀区 | D1 | 部门1 |
101 | 张三 | 13910000001 | 100001 | 北京 | 北京 | 海淀区 | D2 | 部门2 |
101 | 张三 | 13910000002 | 100001 | 北京 | 北京 | 海淀区 | D2 | 部门2 |
102 | 李四 | 13910000003 | 200001 | 上海 | 上海 | 静安区 | D3 | 部门3 |
103 | 王五 | 13910000004 | 510001 | 广东省 | 广州 | 白云区 | D4 | 部门4 |
103 | 王五 | 13910000004 | 510001 | 广东省 | 广州 | 白云区 | D5 | 部门 5 |
第二范式(2NF)
第二范式要同时满足下面两个条件
满足第一范式
没有部分依赖
例如,员工表的一个候选键是{id,mobile,deptNo},而deptName依赖于deptNo,同样 name 依赖于 id,因此不是 2NF的。为了满足第二范式的条件,需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表。如下:
员工表 employee
id | name | zip | province | city | district |
---|---|---|---|---|---|
101 | 张三 | 100001 | 北京 | 北京 | 海淀区 |
102 | 李四 | 200001 | 上海 | 上海 | 静安区 |
103 | 王五 | 510001 | 广东省 | 广州 | 白云区 |
部门表 dept
deptNo | deptName |
---|---|
D1 | 部门1 |
D2 | 部门2 |
D3 | 部门3 |
D4 | 部门4 |
D5 | 部门5 |
员工部门关系表 employee_dept
id | deptNo |
---|---|
101 | D1 |
101 | D2 |
102 | D3 |
103 | D4 |
104 | D5 |
员工电话表 employee_mobile
id | mobile |
---|---|
101 | 13910000001 |
101 | 13910000002 |
102 | 13910000003 |
103 | 13910000004 |
第三范式(3NF)
第三范式要同时满足下面两个条件
- 满足第二范式
- 没有传递依赖
例如,员工表的province、city、district依赖于zip,而zip依赖于id,换句话说,province、city、district传递依赖于id,违反了 3NF 规则。为了满足第三范式的条件,可以将这个表拆分成employee和zip两个表,如下
employee
id | name | zip |
---|---|---|
101 | 张三 | 100001 |
102 | 李四 | 200001 |
103 | 王五 | 510001 |
地区表area
zip | province | city | district |
---|---|---|---|
100001 | 北京 | 北京 | 海淀区 |
200001 | 上海 | 上海 | 静安区 |
51000 | 广东省 | 广州 | 白云区 |
在关系数据库模型设计中,一般需要满足第三范式的要求。如果一个表具有良好的主外键设计,就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率,同时保证数据完整性。然而,我们在实际应用中也要防止过度规范化的问题。规范化程度越高,划分的表就越多,在查询数据时越有可能使用表连接操作。而如果连接的表过多,会影响查询性能。关键的问题是要依据业务需求,仔细权衡数据查询和数据更新关系,指定最合适的规范化程度。不要为了遵循严格的规范化规则而修改业务需求。
内容总结
以上是互联网集市为您收集整理的关系型数据库之三范式介绍全部内容,希望文章能够帮你解决关系型数据库之三范式介绍所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。