标签：范式 之三 部门 100001 employee 103 101 数据库

示例表数据

假设有一个名为employee的员工表，它有九个属性：id(员工编号)、name(员工名称)、mobile(电话)、zip(邮编)、province(省份)、city(城市)、district(区县)、deptNo(所属部门编号)、deptName(所属部门名称)、表总数据如下：

由于此员工表是非规范化的，我们将面对如下的问题。

• 修改异常：上表中张三有两条记录，因为他隶属于两个部门。如果我们要修改张三的地址，必修修改两行记录。假如一个部门得到了张三的新地址并进行了更新，而另一个部门没有，那么此时张三在表中会存在两个不同的地址，导致了数据不一致

• 新增异常：假如一个新员工假如公司，他正处于入职培训阶段，还没有被正式分配到某个部门，如果deptNo字段不允许为空，我们就无法向employee表中新增该员工的数据。

• 删除异常：假设公司撤销了D3部门，那么在删除deptNo为D3的行时，会将李四的信息也一并删除。因为他隶属于D3这一部门。

第一范式(1NF)

表中的列只能含有原子性(不可再分)的值。

表中的张三有两个手机号存储在mobile列中，违反了 1NF 规则。为了使表满足 1NF，数据应该修改如下：

第二范式(2NF)

第二范式要同时满足下面两个条件

• 满足第一范式

• 没有部分依赖

例如，员工表的一个候选键是{id，mobile，deptNo}，而deptName依赖于deptNo，同样 name 依赖于 id，因此不是 2NF的。为了满足第二范式的条件，需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表。如下：

员工表 employee

部门表 dept

员工部门关系表 employee_dept

员工电话表 employee_mobile

第三范式(3NF)

第三范式要同时满足下面两个条件

• 满足第二范式
• 没有传递依赖

例如，员工表的province、city、district依赖于zip，而zip依赖于id，换句话说，province、city、district传递依赖于id，违反了 3NF 规则。为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表，如下

employee

地区表area

在关系数据库模型设计中，一般需要满足第三范式的要求。如果一个表具有良好的主外键设计，就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。而如果连接的表过多，会影响查询性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新关系，指定最合适的规范化程度。不要为了遵循严格的规范化规则而修改业务需求。

标签：范式,之三,部门,100001,employee,103,101,数据库
来源： https://www.cnblogs.com/peijz/p/12360450.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。