精华内容
下载资源
问答
  • 关系数据库范式

    2021-03-11 23:04:33
    种类:目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 范式之间的关系 范式的特点 优点 1.

    什么是范式

    1. 概念:设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。
    2. 种类:目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。
    3. 范式之间的关系
      在这里插入图片描述
    4. 范式的特点
    • 优点
    1. 减少数据冗余(这是最主要的好处,其他好处都是由此而附带的)
    2. 消除异常(插入异常,更新异常,删除异常)
    3. 让数据组织的更加和谐
    • 缺点
      范式越高,意味着表越多,多表联合查询的几率就越大,SQL查询的效率就变低

    第一范式(1NF)

    • 理解:每一列都不可再分割,也就是保持原子特性
    • 举例:

    不满足第一范式的表

    学号 姓名 家庭住址
    0001 张三 xx省xx市xx区xx街道xx小区
    • 表的缺点:
    1. 数据冗余,如果有多个学生在同一个小区,那么同样的地址要多次存储
    2. 修改异常,如果有学生更换家庭住址,那么就得对整个家庭住址去修改
    3. 查询效率太低,如果要查找在xx市的所有学生,那么必须对每个学生的家庭住址整个字段去进行字符匹配
    • 修改:表可以拆分为学生表和地址表,表中家庭住址可以拆分为省市区等几个字段

    符合第一范式的表

    学号 姓名 地址ID
    0001 张三 1
    地址ID 区街道 小区
    1 xx省 xx市 xx区 xx街道

    第二范式(2NF)

    • 理解:在符合第一范式的基础上,消除非主属性对主键的部分依赖,使非主属性完全依赖于主键
    • 举例:

    不满足第二范式的表

    学号 姓名 年龄 课程名称 成绩 学分
    • 表的问题:
    1. 关键字为组合关键字(学号, 课程名称),这个数据库表不满足第二范式,因为存在如下决定关系:(课程名称) → (学分) (学号) → (姓名, 年龄),即存在组合关键字中的字段决定非关键字的情况。
    2. 数据冗余:一门课被多个同学选修,那么课程名称和学分就多次重复存储。
    3. 插入异常:当有一门新课没人选修时,这门课就因为没有主键而插不进来。
    4. 删除异常:当一门课之北一个同学选修时,删除这个同学时这门课也会被删除。
    5. 修改异常:当一门课程的学分需要修改时,就得修改每个选修这门课的同学。
    • 修改:将上表拆分为如下两个符合第二范式的表
    学号 姓名 年龄 课程ID 成绩
    课程ID 课程名称 学分

    第三范式(3NF)

    • 理解:在满足第二范式的基础上,属性不依赖于其它非主属性(消除非主属性对主键的传递依赖)
    • 举例:不满足第三范式的表
    学生ID 学生姓名 学生性别 学院id 学院电话
    • 表的缺点:
    1. 由学生id无法直接推出学院电话,而是由学生id->学院id->学院电话,存在非主属性对主键的传递依赖
    2. 数据冗余:一个学院有多名学生,那么学院电话就需要存储多次
    3. 插入异常:当一个学校没有学生时,学院电话就无法存储
    4. 修改异常:当一个学院电话需要修改时,就需要修改多次
    5. 删除一场:当一个学院只有一个学生时,学生被删除那么学院电话就被删除
    • 修改:将表拆分为两个符合第三范式的表
    学生ID 学生姓名 学生性别 学院id
    学院id 学院名称 学院电话

    BC范式(BCNF)

    巴斯-科德范式(BCNF)是第三范式(3NF)的一个子集,即满足巴斯-科德范式(BCNF)必须满足第三范式(3NF)

    • 理解:在满足第三范式基础上,满足一下三个条件
      1 所有非主属性对每一个候选键都是完全函数依赖;
      2 所有的主属性对每一个不包含它的候选键,也是完全函数依赖;
      3 没有任何属性完全函数依赖于非候选键的任何一组属性。

    • 举例:假设仓库管理关系表(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。主键(仓库ID,管理员ID, 存储物品ID)

    仓库ID 存储物品ID 管理员ID 数量
    • 表中的问题:
    1. 我们发现:(仓库ID, 存储物品ID) →(管理员ID, 数量),(管理员ID, 存储物品ID) → (仓库ID, 数量)
      所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是仓库管理关系表的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:
      (仓库ID) → (管理员ID),(管理员ID) → (仓库ID)
      即存在不满足上述的第二种情况:主属性(管理员)部分依赖于不包含它的候选键(仓库ID, 存储物品ID),所以其不符合BCNF范式。它会出现如下异常情况:
    2. 数据冗余
    3. 删除异常:当仓库被清空后,所有”存储物品ID”和”数量”信息被删除的同时,”仓库ID”和”管理员ID”信息也被删除了。
    4. 插入异常:当仓库没有存储任何物品时,无法给仓库分配管理员。
    5. 更新异常:如果仓库换了管理员,则表中所有行的管理员ID都要修改。
    • 修改:将表拆分为两个符合BC范式的表
    仓库ID 管理员ID
    仓库ID 存储物品ID 数量

    第四范式(4NF)

    • 理解:消除表中的多值依赖
    • 举例:通俗可能不严谨地讲,就是一个表中只有三个属性X,Y,Z,如果多值依赖X→→Y成立,则对于X、Z中一对值(x,z),确定一组Y值,这组值仅与x有关与z无关。

    判断是第几范式

    • 范式关系:5NF⊆4NF⊆BCNF⊆3NF⊆2NF⊆1NF。由上面关系可知,假如满足3NF,肯定也满足2NF,以此类推。
    • 化简过程:给定一个1NF范式,删去部分函数依赖就是2NF;删去传递函数依赖就是3NF;使每个关系都含有码,就变成了BCNF范式;删除非平凡且非函数依赖的多值依赖就是4NF。
    展开全文
  • 【MySQL】数据库范式

    2021-01-22 11:46:27
    1、数据库范式简介 ...2、应用范式优点 (1)减少数据冗余(这是最主要的好处,其他好处都是由此而附带的) (2)消除异常(插入异常,更新异常,删除异常) (3)让数据组织的更加和谐 3、常见范式

    目录

    1、数据库范式简介

    2、应用范式优点

    3、常见范式简述

    1)第一范式(1NF)

    2)第二范式(2NF)

    3)第三范式(3NF)

    4)BC范式(BCNF)

    5)第四范式(4NF)

    4、存在的问题

    5、各范式关系图


     

    1、数据库范式简介

    设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

    但是数据库范式绝对不是越高越好,范式越高,意味着表越多,多表联合查询的几率就越大,SQL查询的效率就变低。

    一般开发中只遵从第三范式就好,是具体情况而定。

    2、应用范式优点

    (1)减少数据冗余(这是最主要的好处,其他好处都是由此而附带的)

    (2)消除异常(插入异常,更新异常,删除异常)

    (3)让数据组织的更加和谐

    3、常见范式简述

    常见的范式有1NF、2NF、3NF、BCNF以及4NF。下面对这几种常见的范式进行简要分析。

    1)第一范式(1NF)

    特点:每一列保持原子特性,列都是基本数据项,不能够再进行分割,否则设计成一对多的实体关系。

    实例:

    • 学生表(学号、用户名、性别、年龄,地址)

    例:陕西省西安市未央区学府中路西安工业大学

    地址信息还包含省市区可以拆分

    • 拆分改造后:

    学生表(学号、用户名、性别、年龄、地址ID)

    地址表(地址ID、省、市、区、街道、学校)

    注意:不符合第一范式不能称作关系型数据库。

    2)第二范式(2NF)

    特点:非主属性完全依赖于主键(主要针对联合主键-->消除部分依赖)

    符合第一范式的基础上非主属性完全依赖于主关键字,如果不是完全依赖主键,应该拆分成新的实体,设计成一对多的实体关系。

    示例

    • 学生选课表(学生ID、学生姓名、学生性别、课程ID、课程成绩)

    主键(学生ID、课程Id)

    学生姓名-》学生ID  -》部分依赖

    学生性别-》学生ID  -》部分依赖

    课程成绩-》(学生ID、课程id)-》完全依赖

    • 拆分改造后:

    学生表(学生ID、学生姓名、学生性别)

    主键:学生ID

    课程成绩表(课程ID、学生ID、成绩)

    主键:(课程ID、学生ID)

    由于不符合2NF,这个选课关系表会存在如下问题:

    (1) 数据冗余:

    同一名学生选了n门课程,姓名和性别就重复了n-1次。

    (2) 更新异常:

    若调整了某名同学的姓名,这位同学如果选了好多门课,数据表中所有行的姓名都要更新,否则会出现同一ID姓名不同的情况。

    (3) 插入异常:

    假设有一名新学生还没有选课。这样,由于还没有“课程ID”关键字,学生的个人信息也无法记录入数据库。

    (4) 删除异常:假设有一名因学生考试作弊课程成绩被删除,则该学生个人信息也被删除。

    3)第三范式(3NF)

    特点:属性不依赖于其它非主属性(消除依赖传递)

    基于第二范式的基础非主属性只依赖于主属性。

    要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

    示例:

    • 学生表(学生ID、学生姓名、学生性别、学院id、学院电话)
      主键:学生ID
      学生姓名→学生ID
      学生性别→学生ID
      学院名称→学生ID
      学院电话 → 学生ID → 查询学院id → 查询学院电话
    • 拆分改造后:
      学生表:(学生ID、学生姓名、学生性别、学院ID)主键:学生ID
      学院表:(学院ID、学院名称、学院电话) 主键:学院ID

    拆分改造前由于不符合3NF,这个学生选课表会存在如下问题:

    (1)数据冗余
    有n名学生,则学院id和学院电话就被重复了n次。

    (2)更新异常
    若调整了学院电话,数据表中所有行的学院电话值都要更新,否则会出现同一学院id学院电话不同的情况。有上万个学生就要改上万次。

    (3)插入异常

    假设有一个学院没有电话,这样,由于还没有“学院电话”关键字,学生的个人信息也无法记录入数据库。

    (4)删除异常

    学生毕业要删除学生信息,删除后学院的电话也没有了。

    注意:一般关系型数据库满足第三范式就可以了!

    4)BC范式(BCNF)

    特点:每个表中只有一个候选键

    基于第三范式的基础上, 每个表中只有一个候选键。(不重复的属性称为候选键)

    在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

    示例:

    • 假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作,一个仓库只有一个管理员,一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:

    主键:(仓库ID,管理员ID, 存储物品ID)

    (仓库ID,管理员ID, 存储物品ID) → (数量)

    但是我们发现:

    (仓库ID, 存储物品ID) →(管理员ID, 数量)

    (管理员ID, 存储物品ID) → (仓库ID, 数量)

    所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

    (仓库ID) → (管理员ID)

    (管理员ID) → (仓库ID)

    即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:

    (1)数据冗余

    由于仓库ID和管理员ID是对应的,所以可以只存一个仓库ID就可以找到物品数量,没有必要再存管理员ID。要一个就行了。

    (2)删除异常

    当仓库被清空后,所有”存储物品ID”和”数量”信息被删除的同时,”仓库ID”和”管理员ID”信息也被删除了。

    (3)插入异常

    当仓库没有存储任何物品时,无法给仓库分配管理员。

    (4)更新异常

    如果仓库换了管理员,则表中所有行的管理员ID都要修改。

    把仓库管理关系表分解为二个关系表:

    仓库管理:StorehouseManage(仓库ID, 管理员ID);

    仓库:Storehouse(仓库ID, 存储物品ID, )。

    这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。

    5)第四范式(4NF)

    特点:消除表中的多值依赖

    基于BC范式的基础上,​消除表中的多值依赖,也就是说可以减少维护数据一致性的工作。

    示例:

    • 课程表
    课程id 教材id 课程名称
    1 1 数学
    2 2 语文
    • 教材表
    教材id 教材名称
    1 人教版数学,苏教版数学
    2 人教版语文,苏教版语文

     

    这样两本一个教材id就对应两个出版社教材,只有教材ID就说不清楚了。修改办法如下

    • 课程表
    课程id 教材id 课程名称
    1 102 数学
    2 201 语文
    • 教材表
    教材id 教材名称
    101 人教版数学

    102

    苏教版数学

    201 人教版语文
    202 苏教版语文

    4、存在的问题

    从上面对于数据库范式进行分解的过程中不难看出,应用的范式越高,表越多。表多会带来很多问题:

    (1)查询时需要连接多个表,增加了SQL查询的复杂度

    (2)查询时需要连接多个表,降低了数据库查询性能

    因此,并不是应用的范式越高越好,要看实际情况而定。第三范式已经很大程度上减少了数据冗余,并且基本预防了数据插入异常,更新异常,和删除异常了。

    5、各范式关系图

    image.png

    展开全文
  • Oracle 数据库范式

    2016-06-13 08:54:00
    如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本 (repetition)。标准化的优点是明显的,它避免了数据冗余,自然就节省了空间,也对数据的一致性(consistency)提供了...

    标准化表示从你的数据存储中移去数据冗余 (redundancy)的过程。如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本 (repetition)。标准化的优点是明显的,它避免了数据冗余,自然就节省了空间,也对数据的一致性(consistency)提供了根本的保障, 杜绝了数据不一致的现象,同时也提高了效率。

    第一范式(1NF;The First Normal Form)

    第一范式是最低的规范化要求,第一范式要求数据表不能存在重复的记录,即存在一个关键字。1NF的第二个要求是每个字段都不可再分,即已经分到最小,关系数据库的定义就决定了数据库满足这一条。主关键字达到下面几个条件:
    1. 主关键字段在表中是唯一的
    2. 主关键字段中没有复本
    3. 主关键字段不能存在空值
    4. 每条记录都必须有一个主关键字
    5. 主关键字是关键字的最小子集

    满足1NF的关系模式有许多不必要的重复值,并且增加了修改其数据时疏漏的可能性。为了避免这种数据冗余和更新数据的遗漏,就引出了第二范式(2NF)。

    第二范式(The Second Normal Form)

    定义:如果一个关系属于1NF,且所有的非主关键字段都完全地依赖于主关键字,则称之为第二范式,简记为2NF。
    为了说明问题现举一个例子来说明:有一个库房存储的库有四个字段(零件号码,仓库号码,零件数量,仓库地址),
    这个库符合1NF,其中“零件号码”和“仓库号码”构成主关键字。
    但是因为“仓库地址”只完全依赖与“仓库号码”,即只依赖于主关键字的一部分,所以它不符合2NF,
    这样首先存在数据冗余,因为仓库数量可能不多。
    其次,存在如果更改仓库地址时,如果漏改了某一记录,存在数据不一致性。
    再次,如果某个仓库的零件出完了,那么这个仓库地址就丢失了,即这种关系不允许存在某个仓库中不放零件的情况。
    我们可以用投影分解的方法消除部分依赖的情况,而使关系达到2NF的标准。
    方法是从关系中分解出新的二维表,是每个二维表中所有的非关键字都完全依赖于各自的主关键字。
    我们可以如下分解:分解成两个表(零件号码,仓库号码,零件数量)和(仓库号码,仓库地址)。
    这样就完全符合2NF了。

    第三范式(The Third Normal Form)

    定义:如果一个关系属于2NF,且每个非关键字不传递依赖于主关键字,这种关系是3NF。
    从2NF中消除传递依赖,就是3NF。比如有一个表(姓名,工资等级,工资额),其中姓名是关键字,
    此关系符合2NF,但是因为工资等级决定工资额,这就叫传递依赖,它不符合3NF,
    我们同样可以使用投影分解的办法分解成两个表:(姓名,工资等级),
    (工资等级,工资额)。

    一 般情况,规范化到3NF就满足需要了,规范化程度更高的还有BCNF,4NF,5NF,因为不常用,不作解释和讨论。它们下层都是上层的子集,规范办法 是:1NFà(消除非主属性对关键字的部分函数依赖)à2NFà(消除非主属性对关键字的传递函数依赖)à3NFà(消除主属性对关键字的部分和传递依 赖)àBCNFà(消除非平凡且非函数依赖的多值依赖)à4NFà(消除不为候选关键字所隐含的连接依赖)à5NF。

    投影分解
    上面提到了投影分解方法,关系模式的规范化过程是通过投影分解来实现的。这种把低一级关系模式分解成若干高一级关系模式的投影分解不是唯一的,应在分解中注意满足三个条件:
    1. 无损连接分解,分解后不丢失信息
    2. 分解后得的每一关系都是高一级范式,不要同级甚至低级分解
    3. 分解的个数最少,这是完美要求,应做到尽量少。

    规范化的利弊
    有一利必有一弊。规范化的优点是明显的。他避免了大量的数据冗余,节省了空间,保持了数据的一致性,
    如果完全达到3NF,你不会在超过一个地方更改同一个值。如果你的记录经常的改变,这个优点回超过所有可能的缺点!
    它最大的不利是,你把信息放置在不同的表中,增加了操作的难度,同时把多个表连接在一起的花费也是巨大
    的 (“时间空间互换理论”,此理论乃笔者杜撰,千万别拿出去当论据!节省了时间必然付出空间的代价,反之,节省了空间也必然付出时间的代价,时间和空间在计 算机领域中是一个矛盾统一体,它们互相作用,对立统一)。因为表和表的连接操作是做两个关系的笛卡儿积(如果表一n条记录,表二m条记录,如果没有任何连 接条件的话,连接在一起就是n*m条记录,其数量是不可承受的,毋宁说大量的表连接在一起了),必然会产生大量无用甚至无效的记录,性能的代价是巨大的。

    非规范化(Denormalization)
    即 使你花费你所有的午休时间,作出一个完全规范化的数据库(你的大学教授可以证明),它仍然不是完美的。规范化设计所带来的性能问题可能你无法承受。如果出 现这种情况,你就要准备进行非规范化了。非规范化就是你为了获得性能上的利益所进行的违反规范化规则的操作,并没有什么魔法在里面。它是一个性能利益分 析,尝试和再尝试和不断的再评估过程。它也有很多方法,不过大部分都与实际应用有关系,包括复制属性,复制外来关键字,表合并,表重新组合等等,你可以根 据实际的应用选择最有效的方法。

     
     
    引言

      数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁 的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员 制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。

      设计范式是不是很难懂呢?非也,大学教材上给我们一堆数学公式我们当然看不懂,也记不住。所以我们很多人就根本不按照范式来设计数据库。

      实质上,设计范式用很形象、很简洁的话语就能说清楚,道明白。本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。

      范式说明

      第一范式(1NF):数据库表中的字段都是单一属性的,不可再分{个人理解:就像一个家庭,有几个儿子,其它的儿子都是由一个部份构成,唯独有一个儿子需要两个部份构成,即这就不是一个正常的家庭,呵呵,说得过分了} 。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。

      例如,如下的数据库表是符合第一范式的:
    字段1
    字段2
    字段3
    字段4
     
     
     
     

      而这样的数据库表是不符合第一范式的:
    字段1
    字段2
    字段3
    字段4
     
     
    字段3.1
    字段3.2
     

      很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的 。

      第二范式(2NF):数据库表中不存在非关键字段 对任一候选关键字段 的部分 函数依赖 (部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段 的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。{个人理解:如在一个家庭里面,任何决定都只能是爸爸、妈妈一致通过后才能够算数,就说明是正常的;如果有一个女儿可以只由妈妈决定做什么,那么这就违背了原则,就不满足约定。}
     
     


      假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系:

      (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

      这个数据库表不满足第二范式,因为存在如下决定关系:

      (课程名称) → (学分)

      (学号) → (姓名, 年龄)

      即存在组合关键字中的字段决定非关键字的情况。

      由于不符合2NF,这个选课关系表会存在如下问题:

      (1) 数据冗余:

      同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。

      (2) 更新异常:

      若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。

      (3) 插入异常:

      假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。

      (4) 删除异常:

      假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。 

      把选课关系表SelectCourse改为如下三个表:

      学生:Student(学号, 姓名, 年龄);

      课程:Course(课程名称, 学分);{个人理解:可以在该加上ID字段作为主键,因为如果以后课程名称有变动,再如果这个数据库运行了10年,有1000万次选课记录,那么你要去更新这一千万条记录,也算是一个费资源的问题。如果有了ID,不管你名称怎么变,都只会影响一条当前记录} 

           SelectCourse(学号, 课程名称, 成绩)。{这里相应就改为:SelectCourse(学号, 课程ID,成绩)} 

            这样的数据库表是符合第二范式的,消除了数据冗余、更新异常、插入异常和删除异常。

      另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。

       第三范式(3NF):在第二范式的基础上,数据表中如果不存在非关键字段 对任一候选关键字段 的传递 函数依赖 则符合第三范式。所谓传递函数依赖,指的是如 果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:

      关键字段 → 非关键字段x → 非关键字段y

      假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系:

      (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)

      这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:

      (学号) → (所在学院) → (学院地点, 学院电话)

      即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

      它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。

      把学生关系表分为如下两个表:

      学生:(学号, 姓名, 年龄, 所在学院);

      学院:(学院, 地点, 电话)。

      这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。

      鲍依斯-科得范式(BCNF):在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
     假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:

      (仓库ID, 存储物品ID) →(管理员ID, 数量)

      (管理员ID, 存储物品ID) → (仓库ID, 数量)

      所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

      (仓库ID) → (管理员ID)

      (管理员ID) → (仓库ID)

      即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:

      (1) 删除异常:

      当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。

      (2) 插入异常:

      当仓库没有存储任何物品时,无法给仓库分配管理员。

      (3) 更新异常:

      如果仓库换了管理员,则表中所有行的管理员ID都要修改。

      把仓库管理关系表分解为二个关系表:

      仓库管理:StorehouseManage(仓库ID, 管理员ID);

      仓库:Storehouse(仓库ID, 存储物品ID, 数量)。

      这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。
    范式应用

      我们来逐步搞定一个论坛的数据库,有如下信息:

      (1) 用户:用户名,email,主页,电话,联系地址

      (2) 帖子:发帖标题,发帖内容,回复标题,回复内容 

      第一次我们将数据库设计为仅仅存在表:
    用户名
    email
    主页
    电话
    联系地址
    发帖标题
    发帖内容
    回复标题
    回复内容

      这个数据库表符合第一范式,但是没有任何一组候选关键字能决定数据库表的整行,唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段,即将表修改为:
    用户名
    email
    主页
    电话
    联系地址
    发帖ID
    发帖标题
    发帖内容
    回复ID
    回复标题
    回复内容

      这样数据表中的关键字(用户名,发帖ID,回复ID)能决定整行:

      (用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)

      但是,这样的设计不符合第二范式,因为存在如下决定关系:

      (用户名) → (email,主页,电话,联系地址)

      (发帖ID) → (发帖标题,发帖内容)

      (回复ID) → (回复标题,回复内容)

      即非关键字段部分函数依赖于候选关键字段,很明显,这个设计会导致大量的数据冗余和操作异常。
     
     


      我们将数据库表分解为(带下划线的为关键字):

      (1) 用户信息:用户名,email,主页,电话,联系地址

      (2) 帖子信息:发帖ID,标题,内容

      (3) 回复信息:回复ID,标题,内容

      (4) 发贴:用户名,发帖ID

      (5) 回复:发帖ID,回复ID

      这样的设计是满足第1、2、3范式和BCNF范式要求的,但是这样的设计是不是最好的呢?

      不一定。

      观察可知,第4项"发帖"中的"用户名"和"发帖ID"之间是1:N的关系,因此我们可以把"发帖"合并到第2项的"帖子信息"中;第5项"回复"中的 "发帖ID"和"回复ID"之间也是1:N的关系,因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余,新的设计为:

      (1) 用户信息:用户名,email,主页,电话,联系地址

      (2) 帖子信息:用户名,发帖ID,标题,内容

      (3) 回复信息:发帖ID,回复ID,标题,内容

      数据库表1显然满足所有范式的要求;

      数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖,即不满足第二范式的要求,但是这一设计并不会导致数据冗余和操作异常;

      数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖,也不满足第二范式的要求,但是与数据库表2相似,这一设计也不会导致数据冗余和操作异常。

      由此可以看出,并不一定要强行满足范式的要求,对于1:N关系,当1的一边合并到N的那边后,N的那边就不再满足第二范式了,但是这种设计反而比较好!

      对于M:N的关系,不能将M一边或N一边合并到另一边去,这样会导致不符合范式要求,同时导致操作异常和数据冗余。 
    对于1:1的关系,我们可以将左边的1或者右边的1合并到另一边去,设计导致不符合范式要求,但是并不会导致操作异常和数据冗余。

      结论

      满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的,在数据库表中存在1:1或1:N关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。

      在我们设计数据库的时候,一定要时刻考虑范式的要求。

    转载于:https://www.cnblogs.com/mutougezi/p/5579419.html

    展开全文
  • 为什么要满足三范式或者说说三范式优点?为什么实际设计时,会去选择反三范式? 什么是范式? 你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1...

    什么是范式?

    你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等。数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。一般在我们设计关系型数据库的时候,最多考虑到BCNF就够。符合高一级范式的设计,必定符合低一级范式,例如符合2NF的关系模式,必定符合1NF。

    关键词:某种设计标准的级别。

    什么是数据库三范式?

    • 第一范式:表中的每一个列不可再分,否则就不是关系数据库;数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。如果实体中的某个属性有多个值时,必须拆分为不同的属性 。通俗理解即一个字段只存储一项信息。
    • 第二范式:每行要有主键,非主键字段依赖主键,每一行都能区分,一个表只说明一个事物,这里的主键不包含业务逻辑。
    • 第三范式每一个表都不包含其他表已经包含的非主关键字信息,非主键字段不能相互依赖,每列都与主键有直接关系,不存在传递依赖;

    关键词:

    • 每一列分开点

    • 每一行要加主键

    • 表之间用外键关联

    为什么要满足三范式或者说说三范式优点?

    在关系数据库模型设计中,一般需要满足第三范式的要求。如果一个表具有良好的主外键设计,就应该是满足3NF的表。

    规范化带来的好处是

    • 通过减少数据冗余提高更新数据的效率
    • 同时保证数据完整性、一致性

    为什么实际设计时,会去选择反三范式?

    规范化程度越高,划分的表就越多,在查询数据时越有可能使用表连接操作。而如果连接的表过多,会影响查询性能。

    关键的问题要依据业务需求,仔细权衡数据查询和数据更新关系,指定最合适的规范化程度。不要为了遵循严格的规范化规则而修改业务需求。

    关键词:通过冗余字断提高查询性能,取了个高大上的名儿叫反范式。


    参考

    • https://www.zhihu.com/question/24696366/answer/29189700
    • https://www.jianshu.com/p/5a8bb84289a9
    • SQL必知必会
    展开全文
  • 文章目录范式理论何为范式,何为建模函数依赖1. 完全函数依赖2. 部分函数依赖3. 传递函数依赖第一范式第二范式第三范式 范式理论 何为范式,何为建模 范式理论和谁有关?和关系建模有关,通常我们说的三...优点: ???
  • 1NF:强调的是列的原子性,即一个列不能再分成其它几列。 2NF:首先强调必须满足1NF,其次满足:一是表必须包含主键;...避免数据库冗余(在范式化设计中一个数据只出现一次,相反在反范式设计中数据可能会被冗余...
  • 数据库连接池的优点运行原理:在我们不使用数据库连接池的时候,每次访问数据库都需要创建连接,使用完成之后需要释放关闭连接,而这样是很耗费资源的。当我们使用数据库连接池的时候,在tomcat启动的时候就创建了...
  • 数据库范式

    2020-08-27 01:03:51
    首先我们要搞明白为什么要使用数据库范式数据库范式优点是什么缺点是什么。 在程序开发过程中,如果不使用数据库范式的话比如的的用户表有name,详情表也有name,突然把一个name字段摆在你 眼前你也要...
  • 数据库范式化设计

    2020-08-12 18:07:37
    数据库中的数据规范化的优点是减少了数据冗余,节约了存储空间,相应逻辑和物理的I/O次数减少,同时加快了增、删、改的速度,但是对完全规范的数据库查询,通常需要更多的连接操作,从而影响查询速度。因此,有时...
  • 范式化的优点: 1)范式化的更新操作通常比反范式化要快。 2)当数据较好地范式化时,就只有很少或者没有重复数据,所以只需要修改更少的数据。 3)范式化的表通常更小,可以更好地放在内存里,所以执行操作会更...
  • 数据库三大范式

    2018-11-01 21:10:36
    1.做到每一列不能继续拆分 比如说不要出现类似如 中国吉林 这样的列名 要做到每一列都不可查分 2.一张表只做一件事 就是一张表只负责一部分 3.不存在依赖传递 例如A-&...数据库的三范式优点
  • 如何通俗地理解三个范式? 答:第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;...优点: 可以尽量得减少数据冗余,使得更新快,体积小 缺点:对于查询需要多个表进行关联,...
  • 1、数据库的介绍 ①定义:database,简称DB,实际上是一个文件集合,是一个储存数据的仓库,本质就是一个文件系统,...③优点:持久化存储、读写速度高、保证数据的有效性(不符合约束的数据存不进去)、对程序支持友好
  • 第一范式(1NF) 数据表的每一列都要保持它的原子特性,也就是列不能再被分割。 这张表就不符合第一范式规定的原子性,不符合...范式优点: 1.通常 范式结构的表更新快,开销小。 2.更少重复 3.更少使用到disti...
  • 数据库设计三范式

    2018-07-11 16:25:07
    如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本(repetition)。标准化的优点是明显的,它避免了数据冗余,自然就节省了空间,也对数据的一致性(consistency)提供了...
  • 什么是数据库: 存储数据的仓库,其本质是一个文件系统,数据库按照特定的格式将数据存储起来,用户可以对数据库中的数据进行增加,修改,删除及查询操作。 数据的存储方式: 1)内存中 优点:读写速度快。 ...
  • 今天上午去面试,看到这三道题,我卡神了。。。貌似一个也不知道,但用手机小小的百了一下,才回过神了…… ...首先来说数据库的三范式:从优点谈起吧,对数据库设计大有好处。它是是为了消除数据冗余、
  • 范式化设计目标的主要目的就是“减少不必要的更新”。但事事都具有两面性,在对数据库进行范式话设计的时候也不可避免的带来了一些副作用。...数据库范式设计其中的一些优点可能并不这么值得称道: 范式化节省了存
  • 1. 关系型数据库的三范式及反三范式 2.事务的四大特征 2.1 事务是什么? 2.2 Spring事务的传播特性和隔离级别 传播级别 隔离级别 3.触发器的使用场景? 4. sql组件 4.1 视图 视图的应用场景: 4.2索引 ...
  • 数据库3范式(3NF)的理解

    千次阅读 2016-09-06 15:29:49
    如果数据库设计达到了完全的标准化,则把所有的表通过关键字连接在一起时,不会出现任何数据的复本(repetition)。标准化的优点是明显的,它避免了数据冗余,自然就节省了空间,也对数据的一致性(consistency)提供了...
  • MySQL数据库的三大范式和备份 文章目录MySQL数据库的三大范式和备份前言1.MySQL数据库的三大范式1.范式的简介2.通俗的理解2.数据库备份的重要性2.1数据库备份的重要性2.2造成数据丢失的原因3.数据库备份的分类3.1从...
  • 百度百科:设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。 人类语言: 范式可以理解为设计一张数据表的表...
  • 数据库的设计(E-R图,数据库模型图,三大范式

    万次阅读 多人点赞 2018-08-30 13:34:49
    一.数据库设计的概念 数据库设计是将数据库中的数据实体及这些数据实体之间的关系,进行...反之,一个数据库被尽心策划了一番,具有良好的设计,那他的优点是: 1.效率会很高. 2.便于进一步扩展. 3.使得应用程序的开...
  • 优点: 1、易于维护:都是使用表结构,格式一致; 2、使用方便:SQL语言通用,可用于复杂查询; 3、复杂操作:支持SQL,可用于一个表以及多个表之间非常复杂的查询。 缺点: 1、读写性能比较差,尤其是海量数据的高...

空空如也

空空如也

1 2 3 4 5 ... 15
收藏数 287
精华内容 114
关键字:

数据库范式优点