关系型数据库的范式总结

一、理解范式:

范式:指符合某一种级别的关系模式的集合。在设计关系数据库的时候,根据满足依赖关系要求定义的不同,定义为不同的范式。

  • 第一范式(1NF)无重复的列
  • 第一范式(1NF)中数据库表的每一列都是不可分割的基本数据项
  • 同一个列中不能够由多个值
    即实体中的某个属性不能有多个值或者不能有重复的属性
  • 简而言之,第一范式就是无重复的列
  • 在任何一个关系数据库中,第一范式(1NF)是对关系模型的基本要求,不满足第一范式(1NF)的数据库就不是关系型数据库。
  • 第二范式(2NF)属性完全依赖于主键[消除部分子函数依赖]
  • 要满足第二范式(2NF)必须先满足第一范式(1NF)
  • 第二范式(2NF)要求数据库表中的每个实例或者行必须都可以被唯一的区分为了实行这样的区分,通常需要为表加上一个列,以用于存储每个实例的唯一标识
  • 第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓的完全依赖是指不能存在仅依赖主关键字的一部分的属性,如果存在,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成新的实体,新实体与原来的实体是 的关系。为了实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是属性完全依赖于主键。
  • 第三范式(3NF)属性不依赖于其他非主属性[消除传递依赖]
  • 满足第三范式(3NF)必须先满足第二范式(2NF)
    简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息
  • 例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性
二、具体实例剖析:
下面列举一个学校的学生系统的实例,以示几个范式的应用。
   在设计数据库表结构之前,我们先确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息,说关心的问题有如下几个方面。
   1)学生有那些基本信息 
   2)学生选了那些课,成绩是什么 
   3)每个课的学分是多少 
   4)学生属于那个系,系的基本信息是什么。
  • 首先第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统(DBMS)中,不允许你把数据库表的一列再分成二列或多列,因此做出的都是符合第一范式的数据库。
  • 我们再考虑第二范式(2NF),把所有这些信息放到一个表中(学号,学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话)下面存在如下的依赖关系。
  1)(学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话) 
  2) (课程名称) → (学分) 
  3)(学号,课程)→ (学科成绩)
  • 根据依赖关系我们可以把选课关系表SelectCourse改为如下三个表:
  学生:Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话); 
  课程:Course(课程名称, 学分); 
  选课关系:SelectCourse(学号, 课程名称, 成绩)。
  • 事实上,对照第二范式的要求,这就是满足第二范式的数据库表,若不满足第二范式,会产生如下问题
  • 数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。
  • 更新异常:
    1)若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。
    2)假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。
  • 删除异常 : 假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。
  • 我们再考虑如何将其改成满足第三范式(3NF)的数据库表,接着看上面的学生表Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话),关键字为单一关键字"学号",因为存在如下决定关系:
  •   (学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话) 
    
  • 但是还存在下面的决定关系
  •    (学号) → (所在学院)→(学院地点, 学院电话) 
    
  • 即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
  • 它也会存在数据冗余、更新异常、插入异常和删除异常的情况(这里就不具体分析了,参照第二范式中的分析)。根据第三范式把学生关系表分为如下两个表就可以满足第三范式了:
  •    学生:(学号, 姓名, 年龄, 性别,系别); 
    
  •    系别:(系别, 系办地址、系办电话)。
    
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容