精华内容
下载资源
问答
  • 数据库三大范式的理解 一: 引言 作为一个数据库的学习者,搞懂关系数据库的三大范式是很有用的。然而教科书上有关数据库范式的介绍都是采用学术性的定义,语法羞涩,让人难懂,故写下自己对数据库范式的...

    数据库三大范式的理解


    一: 引言

    作为一个数据库的学习者,搞懂关系数据库的三大范式是很有用的。然而教科书上有关数据库范式的介绍都是采用学术性的定义,语法羞涩,让人难懂,故写下自己对数据库范式的理解,给初学者提供帮助,也备日后查看。

    本文不介绍规范化程度高于3NF的范式,因为其在实际应用中基本不会用到,原因也是很明显的(查询代价变大),因此,对于很多大型复杂的系统,其数据库设计都没有遵循所谓的范式,这也是为什么会出现所谓的逆规范化,好了,进入正题吧。

    二: 范式介绍

    a:第零范式

    第零范式就是指没有使用任何范式的设计,其添加数据的行为非常诡异,看看下表便知:

    假设一个学生学习了三门课程,每门课程都有成绩,那么,采用第零范式的设计将会是如下情况

    表a_0

    这样的话,会使得往表中添加数据变得非常麻烦,每次添加一个新的数据,都要添加相应的字段,而且,因为表中其他的记录可能不需要这么多字段,因此会浪费

    很多空间。如表a_1所示。

    表a_1

    由此可以看出,不对数据库任用任何范式是非常愚蠢的,因为不仅会产生大量无用的表字段,而且会使得表结构非常难以维护。由此,引出第一范式的介绍

    b: 第一范式

    第一范式就是在第零范式的基础上进行的改进,网上有很多人认为,所谓第一范式就是指表中的所有字段都是原子的、不可再分的,我个人认为此种理解也是正确的,原因不解释,我对第一范式的理解是,将

       第零范式中重复的字段抽取出来,作为表的数据,从而形成一个稳定的、冗余数据少得表结构。

    由此,可以得出符合第一范式的表结构应该是:

    此时,表的结构变得稳定了,而且表中的冗余信息相对第零范式也少了很多。可是,第一范式只是关系数据库设计的最低满足的范式,第一范式中仍然有很多的冗余信息,由此,需要引入第二范    式。

    c: 第二范式

    第二范式是满足属性对主键是完全函数依赖的,因此,满足第二范式的表当然也是满足第一范式的,第二范式的目的就是消除表中的部分依赖。

    这里,有几个概念要解释下,

    1: 完全函数依赖

    设有属性集K和P,若K中的所有属性共同能够推出P中的任意属性,且对于K的任何真子集,都不能推出P中的任意属性,则成K完全函数依赖P。

    2: 部分函数依赖

    与上相似,只是,K中存在真子集使得,该子集能推出p中任意属性。

    概念性的东西,往往都难懂,举个例子,方便大家理解:

    假如有一张学生成绩表,包含如下属性(学生Id,课程Id,课程分数,学生名字),其中,主键为(学生id,课程id),表中的数据如下:

    那么,此时这张表的设计就不满足第二范式,因为 主键(学生id,课程id) 能够唯一确定学生的姓名,因此,不满足属性完全函数依赖主键,因此不是第二范式。

    从上面的表数据易知,不满足第二范式的表至少有以下几个缺点:

    1:数据重复,浪费空间,因为每存一条记录,都要存学生的名字,这样就是得存在大量重复的数据。

    2: 插入异常,若学生还没有成绩,那么这个学生就没有名字。

    3: 更新异常,删除异常等

    解决方法:

    将student_name字段放入学生表中,即消除表中的部分依赖。

    d: 第三范式

    第三范式是指在满足第二范式的情况下,消除表中的传递依赖。

    所谓传递依赖,就是指x-->y,y-->z,那么可以得到y-->z.

    传递依赖常发生在主键、外键、外键相关的属性上,例如,假设有这样的表

    学生表(学生id,学生姓名,院系id,院系名) ,此处主键为(学生id),外键为(院系id)

    院系表(院系id,院长名称),主键为 (院系id)

    很明显,此处存在传递依赖,因为 学生id 可以唯一确定 院系id,而 院系id 可以唯一确定 院系名。

    表中的数据如下



    从上面的表数据易知,不满足第三范式的表至少有以下几个缺点:

    1 : 数据重复,浪费空间,因为学生表每存一条记录,都会记录住院系的名字,存在大量的重复数据。

    2: 插入异常,若新建一个院系,而该院系没有学生的话,该院系就没有名字。

    3: 更新异常,删除异常等



    三: 数据库设计的经验

    1: 表的数目不要太多,一般20-30张就够了。如果表的数目太多,则可以考虑采用同化操作,即将大体相同的实体放入到一张表中。

    2:当数据库中的信息非常庞大时,不要使用外键(逆规范化),因为由此可能带来非常大的性能损失。

    3:一般以消耗存储空间来换取效率。

    展开全文
  • 数据库三大范式的理解,简单易懂 解决方法: 1.第一范式:每一列属性都是不可再分的属性值,确保每一列的原子性。 例如:假如a表要存详细地址(包括省、市、县城、街道),那么我要要把详细地址拆分成四个...

    对数据库三大范式的理解,简单易懂

     

    解决方法:

    1.第一范式:每一列属性都是不可再分的属性值,确保每一列的原子性。

    例如:假如a表要存详细地址(包括省、市、县城、街道),那么我要要把详细地址拆分成四个字段分别存储相关的信息。

     

    2.第二范式:http://www.yayihouse.com/yayishuwu/chapter/2093

    展开全文
  • 由英国关系型数据库鼻祖 E.F.Codd在提出关系型数据库模型后总结出来一种理论,范式也是关系型数据库的理论基础,也是我们在设计数据库时需要遵守守则。简言之就是,数据库设计对数据存储性能,还有开发...

    范式,英文:Normal Form,简称NF。它的由英国关系型数据库鼻祖 E.F.Codd在提出关系型数据库模型后总结出来的一种理论,范式也是关系型数据库的理论基础,也是我们在设计数据库时需要遵守的守则。简言之就是,数据库设计对数据的存储性能,还有开发人员对数据的操作都有莫大的关系。所以建立科学的,规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。       目前在市面上,有迹可循的范式总共有8种,但是我们目前常用的是前三种,所以也简称为三范式,那么下面我们就来介绍这三大范式。我们可以结合表的实例来进行理解,现在假设有一张职工(staff)表,建表语句如下:

    [SQL] 纯文本查看 复制代码

    ?

    01

    02

    03

    04

    05

    06

    07

    08

    09

    10

    11

    12

    13

    CREATE TABLE `staff` (

      `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '职员编号',

      `name` VARCHAR(10) DEFAULT NULL COMMENT '职员名字',

      `gender` INT(1) DEFAULT NULL COMMENT '职员性别,1:男,0:女',

      `mobile` VARCHAR(30) DEFAULT NULL COMMENT '职员电话',

      `postcode` VARCHAR(10) DEFAULT NULL COMMENT '邮编',

      `province` VARCHAR(10) DEFAULT NULL COMMENT '省',

      `city` VARCHAR(10) DEFAULT NULL COMMENT '市',

      `county` VARCHAR(10) DEFAULT NULL COMMENT '区、县',

      `deptNo` VARCHAR(10) DEFAULT NULL COMMENT '职员所属部门',

      `deptName` VARCHAR(10) DEFAULT NULL COMMENT '职员所属部门名称',

      PRIMARY KEY (`id`)

    ) ENGINE=INNODB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;



           下面我们就根据三大范式来分析这张表的存在的问题,及如何更改让它更加的符合三大范式。
           1.第一范式:列的原子性

            当关系模式R的所有属性都不能在分解为更基本的数据单位时,称R是满足第一范式的,简记为1NF。满足第一范式是关系模式规范化的最低要求,否则,将有很多基本操作在这样的关系模式中实现不了。其实说得明白点,就是数据库表的每一个字段(列)都是单一属性、不可再分的。
            例如上面的staff表中有一个字段(mobile)是用来存储职员电话的,但是一般职员都有办公电话和家庭电话两个号码,那么就会出现在这个字段插入的数据会出现多个电话号码,违背了第一范式

           所以只要将mobile字段拆分成办公电话(businessPhone)和家庭电话(homePhone)就可以区分开,就能满足第一范式。
           第二范式:确保表中的每列都和主键相关,消除部分依赖
           在满足第一范式的基础之上,第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,只能有一个主键,而且主键只能为一个字段,不能是联合主键。
           以上面那张职员表(staff)为例,在这张表中一个候选键是{id,mobile,deptNo},而deptName依赖于deptNo,同样 name 依赖于 id,因此不符合第二范式的。为了满足第二范式的条件,可以将这个表拆分成staff、dept、staff_dept、staff_mobile四个表。如下:
          
           其实第二范式就是将有数据冗余的数据表通过表和表之间的外键关联起来,从而减小了数据库的冗余。
          第三范式:消除传递依赖,非主属性的依赖
          第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。举个例子,在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。再以上面的staff表为例,province、city、county依赖于postcode(邮编),而postcode依赖于id,换句话说,province、city、county传递依赖于id,违反了第三范式规则。为了满足第三范式的条件,我们可以再将staff表拆分成staff和address两个表,如下:

          总结:
          在设计数据库的时候我们要最大程度遵循三范式,当然三范式最大的问题在于查询的时候关联很多表,会导致查询效率很低。所以有些时候基于性能考虑,可以违反三范式,适当的做冗余,达到提高查询效率的目的。不过违反范式是适度的,必须为这种做法提供充分的理由。

    更多学习资料可关注:annalin1203

    展开全文
  • 前言:数据库设计其实不仅仅限制于三个范式,往下其实还有很多种,但对于大多数人来说,你又不搞科研,不造飞机大炮,掌握三大范式在工作中已经足够用了。 想法:数据库里有什么?说白了数据库里边不就是一张一张...

    首先声明一下,我的这个回答是个人工作总结,不适合考试答题昂

    欢迎关注我的博客

    前言:数据库设计其实不仅仅限制于三个范式,往下其实还有很多种,但对于大多数人来说,你又不搞科研,不造飞机大炮,掌握三大范式在工作中已经足够用了。

    想法:数据库里有什么?说白了数据库里边不就是一张一张的关系数据表吗?只是表与表之间靠主外键关联而已。所以,你就把他理解为一张张的资料,一张资料里存着找到另一张资料的唯一线索,这个线索就是关系。

    下面进入正题,也就是玩法:

    1NF: 列的原子性,就是每一列不能再分了。就比如性别要么男要么女,这种的就叫不能再分了,但是地址不行,你不能把一连串的地址写到一起,要分为省、市、县、县的那个楼或者大厦什么的。

    这是第一范式,不用问太多为什么,就像你买皮肤要充钱一样,你问人家就能免费给你吗?这是铁律。

    2NF:有主键和副键之分,副键完全依赖于主键,主键是唯一的标识,代表着这个对象,而其他副键都是用来描述对象的。通过主键找到这个对象的整体信息。

    3NF:这个其实工作久了就自然而然明白了。消除传递依赖,说白了就是有副键之间有关系的时候,最好另建一张表。这样就没有那么多冗余数据了。

    就比如说家居有样式,你还要整个样式得分,样式评级什么的,就得另加一张表来描述样式的了。一个表对应一个类。A就是A,B就是B,C就是C。

    还有就是存在1对多,多对多这种关系的时候,也要再分表,要不然数据冗余会特别大。100条数据还差点,1亿数据量就gg了。

    三大范式没什么,就是这么设计比较好,会让你的数据更具有层次感。跟磁盘分区是一个道理。

     

    备注:以上仅供参考,个人开发总结。希望对你有帮助,让我们共同进步。
    孰能无过,如有错误和疑问欢迎留言。

     

    转载于:https://www.cnblogs.com/onthewaytogrowth/p/11222084.html

    展开全文
  • 【本文版权归微信公众号"代码艺术"(ID:onblog)所有,若是转载请务必保留本段原创声明,违者必究。若是文章有不足之处,欢迎关注微信公众号私信与我进行交流!】 什么是范式:简言之就是,数据库设计对...三大...
  • 第一范式:列原子性,即每一列(每一个属性,字段)都不可分割。  举例:销售成本=成本单价*销售数量,所以这里就不可以以销售成作为字段。 第二范式:非主属性必须完全依赖于主属性,不能存在只依赖于主属性...
  • 数据库三大范式 数据库设计范式是数据库设计所需要满足规范,满足这些规范数据库是简洁、结构明晰,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。 1.第一范式(1NF):列不可再...
  • 数据库三大范式范式的简介 范式的英文名称是Normal Form,它是英国人E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础,也是我们在设计数据库结构...
  • 符合一范式的基础上,建立二范式。范式根据实际要求,不一定必须符合 第一范式 要求:每个属性都不可以再分 例子: 存在问题: 1、 数据沉余:如姓名,系名,系主任,重复了很多次 2、 插入异常:如果我新建一个...
  • 1.第一范式数据库的字段是单一属性,不可再分  不能是复合属性,如果存在,应该拆分为多个属性  不能是多值属性,如果存在,应该建立一个实体,而让此属性与其存在1对多关系)  不能是重复属性    2....
  • 分级拆分:如家庭住址、户籍等,常见省市县级联动,要把省、市、县部分拆分到列。 前后拆分:如文档基本信息存储时,可能会遇到按照文档格式统计需求,可以将文档名和文档格式拆分为两列存储。同样如姓名...
  • 范式的英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的。目前有迹可寻的共有8种范式,依次是:1NF,2NF,3NF,巴斯-BCNF(巴斯-科德范式),第4...
  • 数据库三大范式理解

    2019-05-05 20:37:39
    三大范式 经过研究和对使用中问题总结,对于设计数据库提出了一些规范,这些规范被称为范式 第一范式(1NF):列不可拆分 第二范式(2NF):保证每条记录唯一标识 第三范式(3NF):引用主键(保证主键属性和非...
  • 数据库三大范式 理解

    2020-03-24 15:55:32
    所谓第一范式(1NF)是指数据库每一列都是不可分割基本数据项,同一列中不能有多个值,即实体中某个属性不能有多个值或者不能有重复属性。即列不可分割 在任何一个关系数据库中,第一范式(1NF)是对关系...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 530
精华内容 212
关键字:

数据库三大范式的理解