数据库范式:
1NF:如果关系R 中所有属性的值域都是单纯域,那么关系模式R是第一范式的
那么符合第一模式的特点就有
有主关键字且不能为空,不能重复;字段是atomic不可以再分
例如:
StudyNo | Name | Sex | Contact
20040901 john Male Email:kkkk@ee.net,phone:222456
20040901 mary famale email:kkk@fff.net phone:123455
以上的表就不符合,第一范式:主键重复(实际中数据库不允许重复的),而且Contact字段可以再分,所以变更为正确的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male kkkk@ee.net 222456
20040902 mary famale kkk@fff.net 123455
很显然,在当前的database中,不可能做出不符合1NF的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。
2NF:如果关系模式R是1NF的,而且关系中每一个非主属性不部分依赖于主键,称R是2NF的。所以第二范式的主要任务就是
满足1NF的前提下,消除部分函数依赖。
StudyNo | Name | Sex | Email | Phone | ClassNo| ClassAddress
01 john Male kkkk@ee.net 222456 200401 A楼2
01 mary famale kkk@fff.net 123455 200402 A楼3
这个表完全满足于1NF,主键由StudyNo和ClassNo组成,这样才能定位到指定行
但是,存在决定关系:
ClassNo --> ClassAddress
StudyNo --> Name Sex Email Phone
即存在组合关键字中的字段决定非关键字的情况.由于不符合2NF,表会存在如下问题:
数据冗余:同一门课程由n个学生选修,ClassAddress就重复n-1次;同一个学生选修了m门课程,Name Sex Email Phone也重复了m-1次。
更新异常:若调整了class的address,数据表中所有行ClassAddress都要更新,否则会出现同一门课程address不同的情况。
插入异常:假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有StudyNo关键字,ClassNo和ClassAddress也无法记录入数据库。
删除异常:假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,ClassNo和ClassAddress也被删除了.
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male kkkk@ee.net 222456 200401
01 mary famale kkk@fff.net 123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
很明显,如果是单主键的表,也肯定是符合2NF的。
3NF:满足2NF的前提下,消除传递依赖。所谓传递依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足3NF的数据库表应该不存在如下依赖关系:
关键字段 → 非关键字段x → 非关键字段y
例:
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male kkkk@ee.net 优秀 $1000
20040902 mary famale kkk@fff.net 良 $600
这个完全满足了2NF,但是bounsLevel和bouns存在传递依赖.StudyNo --> bounsLevel --> bouns.即存在非关键字段bounsLevel\bouns对关键字段StudyNo的传递函数依赖.
更改为:
表一
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male kkkk@ee.net 1
20040902 mary famale kkk@fff.net 2
表二
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
这里我比较喜欢用bounsNo作为主键,
基于两个原因
1)不要用字符作为主键。可能有人说:如果我的等级一开始就用数值就代替呢?
2)但是如果等级名称更改了,不叫 1,2 ,3或优、良,这样就可以方便更改,所以我一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
BCNF:鲍依斯-科得范式.在3NF的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BCNF.
例:配件管理关系模式 WPE(WNO,PNO,ENO,QNT)分别表仓库号,配件号,职工号,数量。有以下条件
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析:由以上得 PNO 不能确定QNT,由组合属性(WNO,PNO)来决定,存在函数依赖(WNO,PNO) -> ENO。由于每个仓库里的一种配件由专人负责,而一个人可以管理几种配件,所以有组合属性(WNO,PNO)才能确定负责人,有(WNO,PNO)-> ENO。因为 一个职工仅在一个仓库工作,有ENO -> WNO。由于每个仓库里的一种配件由专人负责,而一个职工仅在一个仓库工作,有 (ENO,PNO)-> QNT。
找一下候选关键字,因为(WNO,PNO) -> QNT,(WNO,PNO)-> ENO ,因此 (WNO,PNO)可以决定整个元组,是一个候选关键字。根据ENO->WNO,(ENO,PNO)->QNT,故(ENO,PNO)也能决定整个元组,为另一个候选关键字。属性ENO,WNO,PNO 均为主属性,只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的,并且是直接依赖,所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO,主属性ENO是WNO的决定因素,但是它本身不是关键字,只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字(ENO,PNO)的部 分依赖,因为(ENO,PNO)-> ENO但反过来不成立,而P->WNO,故(ENO,PNO)-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖,但存在主属性对候选关键字的传递依赖,同样也会带来麻烦。如一个新职工分配到仓库工作,但暂时处于实习阶段,没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全,则在删除配件的同时该职工也会被删除。
解决办法:分成管理EP(ENO,PNO,QNT),关键字是(ENO,PNO)工作EW(ENO,WNO)其关键字是ENO
缺点:分解后函数依赖的保持性较差。如此例中,由于分解,函数依赖(WNO,PNO)-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此,分解之后的关系模式降低了部分完整性约束。
4NF:满足3NF的前提下,消除多值依赖
product | agent | factory
Car A1 F1
Bus A1 F2
Car A2 F2
在这里,Car的定位,必须由 agent 和 Factory才能得到(所以主键由agent和factory组成),可以通过 product依赖了agent和factory两个属性
所以正确的是
表1 表2:
product | agent factory | product
Car A1 F1 Car
Bus A1 F2 Car
Car A2 F2 Bus
5NF:如果关系模式R中的每一个连接依赖, 都是由R的候选键所蕴含, 称R是第五范式的
看到定义,就知道是要消除连接依赖,并且必须保证数据完整
例子
A | B | C
a1 b1 c1
a2 b1 c2
a1 b2 c1
a2 b2 c2
如果要定位到特定行,必须三个属性都为关键字。
所以关系要变为 三个关系,分别是A 和B,B和C ,C和A
如下:
表1 表2 表3
A | B B | C C | A
a1 b1 b1 c1 c1 a1
a1 b2 b1 c2 c1 a2
连接:
假设存在2个表:
一个book的基本信息表:
一个租书人的信息表:
1.right join/right outer join
我们以左边book表为准,则tenant中的记录只有当其bookID在book中存在时才会显示出来,tenant中的BOOKID 16 17在book表没有对应记录,所以显示为NULL.
2.right join/right outer join
我们以右边tenant表为准,则左表book中的记录只有当其ID在右边tenant中存在时才会显示出来,左边中ID为5.6因为在tenant中没有相应记录,所以显示为NULL.
3.inner join/join;它为返回同时存在于book 和tenant中的记录.
4.cross join
- 大小: 2.6 KB
- 大小: 3.6 KB
- 大小: 2.6 KB
- 大小: 4.2 KB
- 大小: 2.6 KB
- 大小: 4 KB
- 大小: 2.5 KB
- 大小: 3 KB
- 大小: 2.9 KB
分享到:
相关推荐
数据库系统概念(Database System Concepts Sixth Edition)教学课件PPT
里面包含《数据库系统概念》 中文版,以及《Database System Concepts》 英文版
数据库系统概念第六版书后习题全部答案(英文)Database_System_Concepts_6th_edition-solutions to practice exercises and exercises (answers)
Database System Conoepts 第五版 英文,pdf格式
数据库系统概念 database system concepts 英文 第六版 高清
database system concepts 英文版 第五版 因为是扫描版所以比较大,一共13个压缩包。。。
Database System Concepts——数据库系统概念第六版(英文版) 作者: Abraham Silberschatz (Yale University) Henry F. Korth (Lehigh University) S. Sudarshan (Indian Institute of Technology, Bombay) 本书...
本书是经典的数据库系统教科书《Database System Conoepts》的最新修订版,全面介绍数据库系统的各种知识,透彻阐释数据库管理的基本概念。本书内容丰富,不仅讨论了数据库查询语言、模式设计、数据仓库、数据库应用...
数据库系统概念 第6版 Database system concepts 6th 习题 答案 完整版
Database System Concepts(《数据库系统概念》)第五版这本书后Exerices部分答案。 每章的后面几题的答案,与网上盛传的前面几道的不同。
本书是经典的数据库系统教科书《Database System Conoepts》的最新修订版,全面介绍数据库系统的各种知识,透彻阐释数据库管理的基本概念。本书内容丰富,不仅讨论了数据库查询语言、模式设计、数据仓库、数据库应用...
1数据库概念-如何创建数据库和删除数据库等等
database system concepts 英文版 第五版 因为是扫描版所以比较大,一共13个压缩包。。。
database system concepts 英文版 第五版 因为是扫描版所以比较大,一共13个压缩包。。。
本书是经典的数据库系统教科书《Database System Conoepts》的最新修订版,全面介绍数据库系统的各种知识,透彻阐释数据库管理的基本概念。本书内容丰富,不仅讨论了数据库查询语言、模式设计、数据仓库、数据库应用...
探讨了数据仓库和联机分析处理数据库设计中使用的维数据库概念 作者简介 作者:(美国)克罗恩克(David M.Kroenke) (美国)奥尔(David Auer) 目录 Preface xvii PART 1 GETTING STARTED Chapter 1:...
数据库系统概念 第六版 原版ppt合集 Database System Concepts Sixth Edition ppt
database system concepts 英文版 第五版 因为是扫描版所以比较大,一共13个压缩包。。。