【MySQL】 |
您所在的位置:网站首页 › 非冗余蛋白数据库是什么 › 【MySQL】 |
文章目录
为什么需要数据库设计范式范式简介范式都包括哪些键和相关属性的概念第一范式(1st NF)第二范式(2nd NF)第三范式(3rd NF)
反范式化概述应用举例反范式化的新问题反范式的适用场景
BCNF(巴斯范式)案例案例一案例二
第四范式案例案例一案例二
第五范式、域键范式范式的实战案例
为什么需要数据库设计
在关系型数据库中,关于数据表设计的基本原则、规则就称为范式。可以理解为,一张数据表的设计结构需要满足的某种设计标准的级别 。要想设计一个结构合理的关系型数据库,必须满足一定的范式。 范式都包括哪些目前关系型数据库有六种常见范式,按照范式级别,从低到高分别是:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。
举例:这里有两个表: 球员表(player):球员编号 | 姓名 | 身份证号 | 年龄 | 球队编号球队表(team):球队编号 | 主教练 | 球队所在地超键:对于球员表来说,超键就是包括球员编号或者身份证号的任意组合,比如(球员编号) (球员编号,姓名)(身份证号,年龄)等。 候选键:就是最小的超键,对于球员表来说,候选键就是(球员编号)或者(身份证号)。 主键:我们自己选定,也就是从候选键中选择一个,比如(球员编号)。 外键:球员表中的球队编号。 主属性、非主属性:在球员表中,主属性是(球员编号)(身份证号),其他的属性(姓名)(年龄)(球队编号)都是非主属性。 第一范式(1st NF)一、第一范式:主要是确保数据表中每个字段的值必须具有原子性,也就是说数据库表中每个字段的值为不可再次拆分的最小数据单元。 二、我们在设计某个字段的时候,对于字段X来说,不能把字段X拆分成字段X-1和字段X-2。事实上,任何的DBMS都会满足第一范式的要求,不会将字段进行拆分。 一、第二范式要求在满足第一范式的基础上,还要满足==数据表里的每一条数据记录都是可唯一标识的。而且所有非主键字段,都必须完全依赖主键,不能只依赖主键的一部分。==如果知道主键的所有属性的值,就可以检索到任何元组(行)的任何属性的任何值。(要求中的主键,其实可以拓展替换为候选键) 非主键字段完全依赖主键:假如表中字段1、字段2组成了一个唯一主键,其余字段(非主键字段)根据这两个字段的值就能确定唯一值,如果某个非主键字段根据字段1(或字段2)就能确定自己的值,那么这就叫非主键字段依赖主键的一部分,这种情况建议给字段1(或字段2)和该非主键字段建立一张独立的表,然后将该表与原来的表进行关联
一、第三范式是在第二范式的基础上,确保数据表中的每一个非主键字段都和主键字段直接相关,也就是说,要求数据表中的所有非主键字段不能依赖于其他非主键字段。(即,不能存在非主属性A依赖于非主属性B,非主属性B依赖于主键C的情况,即存在“A—B—C”的决定关系)通俗的讲,该规则的意思是所有非主键属性直接不能有依赖关系,必须相互独立 二、这里的主键可以拓展为候选键
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() 当冗余信息有价值或者能大幅度提高查询效率的时候,我们才会采取反范式的优化。 一、增加冗余字段的建议 一、分析下表的范式情况: 二、是否符合三范式(如何判断一张表的范式呢?我们需要根据范式的等级,从低到高来进行判断。):首先,数据表每个属性都是原子性的,符合 1NF 的要求;其次,数据表中非主属性”数量“都与候选键全部依赖,(仓库名,物品名)决定数量,(管理员,物品名)决定数量。因此,数据表符合 2NF 的要求;最后,数据表中的非主属性,不传递依赖于候选键。因此符合 3NF 的要求 三、存在的问题:既然数据表已经符合了 3NF 的要求,是不是就不存在问题了呢?我们来看下面的情况: 增加一个仓库,但是还没有存放任何物品。根据数据表实体完整性的要求,主键不能有空值,因 此会出现 插入异常 ;如果仓库更换了管理员,我们就可能会 修改数据表中的多条记录 ;如果仓库里的商品都卖空了,那么此时仓库名称和相应的管理员名称也会随之被删除。你能看到,即便数据表符合 3NF 的要求,同样可能存在插入,更新和删除数据的异常情况。 四、问题解决 首先我们需要确认造成异常的原因:主属性仓库名对于候选键(管理员,物品名)是部分依赖的关系,这样就有可能导致上面的异常情况。因此引入BCNF,它在 3NF 的基础上消除了主属性对候选键的部分依赖或者传递依赖关系。 如果在关系R中,U为主键,A属性是主键的一个属性,若存在A->Y,Y为主属性,则该关系不属于BCNF。 根据 BCNF 的要求,我们需要把仓库管理关系warehouse_keeper表拆分成下面这样: 仓库表 :(仓库名,管理员) 库存表 :(仓库名,物品名,数量) 这样就不存在主属性对于候选键的部分依赖或传递依赖,上面数据表的设计就符合 BCNF。 案例二有一个 学生导师表 ,其中包含字段:学生ID,专业,导师,专业GPA,这其中学生ID和专业是联合主键。 ![]() ![]()
职工表(职工编号,职工孩子姓名,职工选修课程)。在这个表中,同一个职工可能会有多个职工孩子姓名。同样,同一个职工也可能会有多个职工选修课程,即这里存在着多值事实(存在多个一对多的情况,即非平凡的多值依赖),不符合第四范式。 如果要符合第四范式,只需要将上表分为两个表,使它们只有一个多值事实,例如: 职工表一 (职工编号,职工孩子姓名), 职工表二 (职工编号,职工选修课程),两个表都只有一个多值事实,所以符合第四范式。 案例二建立课程、教师、教材的模型。我们规定,每门课程有对应的一组教师,每门课程也有对应的一组教材,一门课程使用的教材和教师没有关系。我们建立的关系表如下:课程ID,教师ID,教材ID;这三列作为联合主键。(为了表述方便,我们用Name代替ID,这样更容易看懂) 一、除了第四范式外,我们还有更高级的第五范式(又称完美范式)和域键范式(DKNF)。 二、在满足第四范式(4NF)的基础上,消除不是由候选键所蕴含的连接依赖。如果关系模式R中的每一个连接依赖均由R的候选键所隐含,则称此关系模式符合第五范式。 三、函数依赖是多值依赖的一种特殊的情况,而多值依赖实际上是连接依赖的一种特殊情况。但连接依赖不像函数依赖和多值依赖可以由 语义直接导出 ,而是在 关系连接运算 时才反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题。 四、第五范式处理的是 无损连接问题 ,这个范式基本 没有实际意义 ,因为无损连接很少出现,而且难以察觉。而域键范式试图定义一个 终极范式 ,该范式考虑所有的依赖和约束类型,但是实用价值也是最小的,只存在理论研究中。 范式的实战案例 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |