数据库范式:
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》 英文版
数据库系统概念第六版书后习题全部答案(英文)Database_System_Concepts_6th_edition-solutions to practice exercises and exercises (answers)
《数据库系统概念》第六版是一本深入探讨这一主题的经典教材,提供了丰富的教学课件PPT,旨在帮助学生和专业人士理解数据库系统的本质和应用。以下是对该书及课件中关键知识点的详细解释: 1. 数据库系统基础:...
Oracle 12c Database Concepts 是 Oracle 官方发布的一份关于 Oracle 12c 数据库概念的详细解析文档,该文档涵盖了 Oracle 12c 数据库的基本概念、架构、管理、安全、性能优化、 Troubleshooting 等方面的知识点。...
数据库系统概念 第6版 Database system concepts 6th 习题 答案 完整版
Database System Conoepts 第五版 英文,pdf格式
数据库系统概念 database system concepts 英文 第六版 高清
database system concepts 英文版 第五版 因为是扫描版所以比较大,一共13个压缩包。。。
9. **应用示例**:为了帮助用户快速上手,Labview 2018 Database Connectivity Toolkit通常会包含一些示例VI,展示如何连接数据库、执行查询以及处理结果集等基本操作,为初学者提供指导。 10. **兼容性**:尽管此...
数据库(Database)是按照数据结构来组织、存储和管理数据的仓库。它不仅包含数据本身,还有一系列规则和方法,用于确保数据的完整性和一致性。SQL Server是微软公司推出的一款关系型数据库管理系统,广泛应用于各种...
《数据库系统概念》是数据库领域的经典教材,第五版提供了深入且全面的数据库理论与实践知识。这份压缩包包含了该书的课后习题答案,覆盖了所有章节,为学习者提供了解题思路和参考,帮助他们更好地理解和掌握数据库...
本书是经典的数据库系统教科书《Database System Conoepts》的最新修订版,全面介绍数据库系统的各种知识,透彻阐释数据库管理的基本概念。本书内容丰富,不仅讨论了数据库查询语言、模式设计、数据仓库、数据库应用...
在"DataBase 5.0_database:5_数据库、文件_"这个主题中,我们将深入探讨数据库的基本概念、数据库管理系统(DBMS)以及如何对文本表格数据进行操作。 数据库是一种有组织地存储和检索数据的系统,它可以视为一个...
Database System Concepts(《数据库系统概念》)第五版这本书后Exerices部分答案。 每章的后面几题的答案,与网上盛传的前面几道的不同。
本书是经典的数据库系统教科书《Database System Conoepts》的最新修订版,全面介绍数据库系统的各种知识,透彻阐释数据库管理的基本概念。本书内容丰富,不仅讨论了数据库查询语言、模式设计、数据仓库、数据库应用...
数据库系统概念(杨冬青)习题答案Chapter 1 provides a general overview of the nature and purpose of database systems. The most important concept in this chapter is that database systems allow data to ...