【图文】数据库系统原理第三章同步练习_百度文库
您的浏览器Javascript被禁用，需开启后体验完整功能，
享专业文档下载特权
&赠共享文档下载特权
&100W篇文档免费专享
&每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
数据库系统原理第三章同步练习
阅读已结束，下载本文到电脑
定制HR最喜欢的简历
你可能喜欢理论性的东西，往往容易把人人都看得懂的东西写成连鬼都看不懂，近似于主任医生开的药方。从前学范式的时候，把书中得概念翻来覆去看，看得痛心疾首深恶痛绝，再加上老师深切误导，最后一塌糊涂。借助网络资源，自己写了一篇，自己是看懂了，希望对大家也有所帮助，有错误帮忙指正。
数据库范式（Normal forms）：是用于规范关系型数据库设计，以减少谬误发生的一种准则。
1NF(first normal form)：
Table faithfully represents a relation and has no repeating groups.
数据库表必须如实地展现&关系&，并且不允许有&重复组&出现。
这样的概念真是令人痛心疾首，我们只好再搬出1NF的的作者之一Chris Date的解释：
1. There's no top-to-bottom ordering to the rows.
（任意两行没有特定的顺序关系。不存在一个特定的理由要某一行必须在另一行之前。）
2. There's no left-to-right ordering to the columns.
（任意两列没有特定的顺序关系。）
3. There are no duplicate rows.
（不允许存在重复的行。如果一张表没有Unique Key，事实上它是违反1NF的。）
4. Every row-and-column intersection contains exactly one value from theapplicable domain (and nothing else).
（不允许出现空值Null，这一点不同作者是有争议的。事实上我们常常违背这点。）
5. All columns are regular [i.e. rows have no hidden components such as row IDs,object IDs, or hidden timestamps].
（不允许存在隐藏字段。不知道Oracle的Rowid属不属于这个？）
有人从第四点的&one value&大肆挖掘，于是我们就见到了书上这样的定义：&如果一个关系模式R的所有属性都是原子的，即不可再分的基本数据项，则R&I1NF&。
这一点被认为是1NF的核心，&关系模式R&&&表&，&属性&& &列&，下面是一种与1NF不一致的情况，通常这是一类很明显的设计缺陷：
对上例我们不能把它拆分成FavoriteColor1、FavoriteColor2&&因为首先我们不能确定该拆分成几列；其次FavoriteColor1与FavoriteColor2在结构、含意方面都是相同的，这实际上也是一类&repeating group&；同时这种设计会导致某些查询困难，比如&有哪些艺人喜欢黄色？&
解决方案是将表拆分成两个：
对1NF最核心的&原子性&，违反此规范的可能性：接近于0%。不过，网上很多帖子说在关系型数据库中根本不可能违背1NF，我认为这是不对的。
2NF(second normal form):
No non-prime attribute in the table is functionally dependent on a part (proper subset) of a candidate key.
不存在非主属性对任一候选键的部分函数依赖。
如果解释完下面几个概念，这个定义就可以读懂了：
Superkey：超级键（L）,如果属性或属性组合能唯一标识一条记录，则它是一个Superkey。
Candidate key：候选键，当Superkey只包含一个属性时，则它是一个候选键；当Superkey包含一组属性时，仅当这一组属性不包含另一Superkey时，它是一个候选键。换句话说，候选键是&纯净的&、最小化的Superkey。
Non-prime attribute：非主属性，未在任何候选键中出现的属性，即为非主属性。
举例来说，对表{First_name,Last_name,Address}，假定全名不重复，则：
Superkey：
{First_name,Last_name}
{First_name,Last_name,Address}
Candidate key:
{First_name,Last_name}
Non-prime attribute：
浅白版：&2NF针对的是复合候选键（即键包含的字段个数&1）的情况，非主属性不能只依赖于复合候选键中的一部分字段。&显然，如果是非复合候选键，如果它符合1NF，那么它一定符合2NF。
假设有这样一张涉及艺人与唱片公司的关系表：
显然，{Artist,Company}为可以作为一个候选键，DurationYears在这没有问题，但CompAddr是违反2NF的，它只依赖于候选键的一部分（依赖于Company），这是违反2NF的，为了消除这种情况，我们可以：
对于2NF，如果关系中的候选键只包含一个属性，可以直接略过。
在考虑2NF的过程中，不要把几个无关的实体的属性杂揉放在一个关系中，比如Artist是一个实体、Company是一个实体，它们可以有一系列的关联表（也是实体），但在关联表中尽量不要引入前两个实体的无关属性。
3NF(Third normal form)
Every non-prime attribute is non-transitively dependent on every key of the table.
不存在非主属性对任一键（候选键）的传递依赖。
传递依赖，你可以顾名思义，这里就不再引入定义了，举个例子，有下面一张表：
这里的候选键为{Tournament,Year}，显然有这样的决定关系：
{Tournament,Year}&Winner
{Tournament,Year}&Winner&Winner Date of Birth
其中第二条就属于违反3NF的情况，因为Winner Date of Birth依赖于Winner而不是直接依赖于候选键。这种情况下，可以将Winner,Winner Date of Birth单独作为一张表，这里不赘述。
我觉得大多数人凭借直观感觉，就可使设计的关系符合3NF，所以这些理论，你只需要姑且读之。
BCNF(Boyce-Codd normal form)（Boyce与Codd是该范式的两名作者。）
Every non-trivial functional dependency in the table is a dependency on a superkey.
表中的任何非平凡函数依赖，都必须是对superkey的依赖。
non-trivial functional dependency：非平凡函数依赖，如果存在一个决定关系x&y，且y并非x的子集，则叫着y非平凡函数依赖于x。
BCNF与3NF的最大区别是它并不仅针对非主属性（non-prime attribute）来说，它发生的时候常常是表中根本不存在非主属性，以至于它不可能违反2NF或3NF。而BCNF的出现就是为了扩大&打击面&。
于是BCNF的主旨是：补充对发生在主属性（prime attribute）身上的函数依赖的约束，因为对于非主属性的约束已经在3NF中完成了。
例子，使用关系表描述学生、课程、教师的关系（假定一名教师只负责一门课程，一门课程则可以由多位教师负责）：
{Student,Course}
{Student,Teacher}
因此这里不存在非主属性，而在主属性的函数依赖中，存在Teacher&Course，这属于违反BCNF的情况。
可是，问题是这个表看起来还挺正常的啊？！它的毛病在于，我们无法阻止类似最后一行这样的数据插入，而这会导致与前提&一名教师只负责一门课程&违背。所以我们还是需要将它拆分：
这样，在&Teacher-Course&表中，借助主键的帮助，最后可以避免违背&一名教师只负责一门课程&这个前提。
那么，如果没有这样一个前提，是初的设计是否符合BCNF？目前看来是的。
真实的情况可能更为复杂，下面这个更接近于我的一些经历：
1）学生需要学习多门课程
2）一门课程可能有多位教师负责
3）一位教师可能负责多门课程
4）某一班级的某一课程对应的教师是固定的（一位）
据此，为了描述学生、课程、教师三者的关系，从这一团乱麻中最早跳出来的大概是这样的表：
{Student,Course}
我们可以明显地看到Student&Class违反了2NF，于是：
从这两张表，仔细考虑，即便我们通过Class关联两张表，还是无法得出学生与课程的关系（只能得出可供该学生选择的课程），所以我们需要再添加一张表：
最后大概是这么三张表，可能还有其它的方案，这里只是举例说明，就不纠缠了。
在BCNF之后，还有4NF，5NF，DKNF，6NF，等什么时候有空了再看看是什么东东。
阅读(...) 评论()数据库基础
三层模式-两级映射内模式：数据以什么格式存储到物理文件，如何优化。数据存放。物理级数据库映射：不改应用程序概念模式：表。根据业务、应用分。概念级数据库映射：改表，不改应用程序外模式：视图。处理之后显示、不要显示全部的信息、提高安全性、灵活性。用户级数据库数据库设计：整个设计过程的流程及每个阶段的产出物。需求分析：整个系统对数据的要求（产出物：数据流图、数据字典、需求说明书）概念结构设计：产出物：E-R模型，和数据库管理系统无关的模型，可以用SQL Server、Oracle、My SQL，是一种数据的表达。转成关系模式：转成文字表达（表）的格式逻辑结构设计：产出物：关系模式（规范化理论）物理设计局部E-R图合成全局E-R图逐步集成：2+1+1+1一次集成冲突：属性冲突（属性域、属性取值）、命名冲突（同名异义、异名同义）、结构冲突（抽象级别不同，表和列）联系1-1 1-n 可以转换为2-3个关系模式n-n 可以转换为3个关系模式关系代数笛卡尔积：s1×s2 不会去掉相同字段投影：选列 πsno,sname(s1)或π1,2（s1）选择：6.连接：蝴蝶等值连接：=自然连接：不写条件：默认相同的字段做等值，去掉相同字段。关系代数：除法运算选课表RS（学生名、课程名） 课程表S（课程名）RS÷S ：解决的问题：找出选择了所有课程的学员名单规范化理论--函数依赖学号-&姓名部分函数依赖：主键的一个部分可以确定其他某一个属性传递函数依赖：A-&B-&C (B×-&A)规范化理论--价值与用途非规范化的关系模式可能存在的问题：数据冗余、更新异常、插入异常、删除异常等。安全和性能冲突规范化理论--键超键：唯一标识元组（可以是单个键或是键的组合，可能存在冗余属性）候选键：超键消除多余属性后能够唯一标识元组的键主键：候选键任选一个外键：其他关系的主键规范化理论--求候选键图示法：将关系模式化为“有向图”的形式找出入度为0的结点，尝试遍历这个图如果没有入度为0的结点，找中间结点（既有入度，也有出度）AB:表示组合键是候选键A和B:表示有两个候选键规范化理论--范式1NF:属性值都是不可分的原子值2NF:消除非主属性对候选键的部分依赖3NF:消除非主属性对候选键的传递依赖(如果没有非主属性，则至少为3NF)BCNF:消除主属性对候选键的部分依赖和传递依赖(每个决定因素必定包含某个候选码）规范化程度越高，数据密度越小。规范化理论--模式分解保持函数依赖的分解：所有的函数依赖都保持到新的关系模式中，没有缺失无损分解：可以还原（如rar），通过连接关系又可以还原成原始表
·表格法：行：拆分后的表；列：原始属性
连接之后有一行包含全部的属性，则是无损的
·公式法：适合一分为二 R1和R2交集-&（R1-R2）或（R2-R1）在原始的关系中，则是无损的有损：不能还原数据库并发控制事务：封装多个操作，如转账（要么全做，要么全不做）。原子性、一致性（执行前后的状态一致）、隔离性（互不影响）、持续性（执行后的影响是持续的）并发：为了提高效率并发可能产生的问题：丢失更新、不可重复读、读“脏”数据解决方案：封锁协议：
读锁加上去之后还能加读锁。写锁上面不能加锁。
一级：读之前加X锁（其他事务不能对数据进行写操作）。防止丢失更新。
二级：读之前加X锁（写锁）和S锁（读锁）。防止丢失更新和读脏数据
三级：读之前加X锁和S锁，直到事务结束才释放。都能防止。
两段锁协议：可串行化，可能发生死锁。封锁机制数据库完整性约束：实体完整性（主键）、参照完整性（外键/空）、用户自定义完整性触发器完成更加复杂的要求数据库安全：措施：用户标识和鉴定：身份认证存取控制：对用户进行授权密码的存储和传输：对远程终端信息用密码保护视图的保护：对视图进行授权，不同权限的用户使用不同的视图审计：用户对数据库的操作记录下来，用日志数据库备份和恢复：冷备份：静态备份，在数据库停止状态下备份（拷贝文件）热备份：动态备份，运行时备份完全备份：备份所有数据差量备份：上一次完全备份后变化的数据（变化量较大，但是恢复方便）增量备份：上一次备份后变化的数据（备份速度快，但是恢复慢，要把每一个增量版全部执行一遍）静态海量转储：系统无运行事务时进行，转储全部数据库静态增量转储：转储上一次转储后更新过的数据动态海量转储：转储其间允许对数据库进行存取或修改，全部动态增量转储：转储更新过的数据日志文件：对数据库的任何操作先写日志，再写数据文件。以防数据恢复不完整。数据库故障与恢复：事务本身的可预期故障：本身逻辑的问题，可设置rollback语句不可预期的故障：算数溢出、违反存储保护，可通过日志，撤销修改，回退到原始状态系统故障：数据库或操作系统停止运转，可通过检查点方法介质故障：外存被破坏，可使用日志重做业务分布式数据库--体系结构集中式数据库（原有的）根据联网的需求发展成为分布式数据库。分片透明性：水平分片:某段数据存在不同的位置
垂直分片：把表不同的列存在不同的位置
混合分片数据库优化集中式数据库：硬件系统、系统软件、数据库设计（表与视图，索引，SQL优化（限制条件顺序修改，如先做判断筛选，然后做等值连接、以不相干子查询代替相干子查询、只检索需要的列、用带IN的条件子句代替OR子句、把数据库连接存在缓冲池中））、应用软件（数据库连接池）分布式数据库：通信代价：全局查询树的变换、多副本策略、查询树的分解、半连接和直接连接数据仓库与数据挖掘广泛应用于BI：商业智能数据仓库：面向主题（数据库：面向业务）、集成的、相对稳定的（非易失的）、反映历史变化（随着时间变化，数据导入）数据源:抽取、清理（数据格式统一、冗余数据清除）、装载（放入数据仓库）、刷新（定期添加数据）数据仓库：数据集市：先建部门级，再建企业级OLAP服务器：（分析处理工作）：查询、报表、分析、数据挖掘工具数据挖掘：决策树、神经网络、遗传算法、关联规则挖掘算法分类：关联分析（挖掘出隐藏在数据间的相互关系）、序列模式分析（分析数据间的前因后果）、分类分析（分成不同类别）、聚类（共性聚合成大的类别）分析联邦数据库特征：分布性、异构性、自治性、透明性分类：紧耦合、松耦合NoSQL:not only SQL并发性能高；海量数据存储、查询效率高；向外扩展（把集群的100台机器扩展为200台）；特定应用领域；键值索引不足：成熟度不够；开源数据库产品的支持度不够；数据挖掘和商务智能支持不足；数据库专家少反规范化技术（逆规范化技术）：规范化程度越高，拆分表，每个表粒度过小，关联多表查询，增加处理时间和查询时间技术手段：增加冗余列、增加派生型冗余列（以空间换时间，牺牲一些规范程度）、重新组表、分割表大数据技术：数据量大、速度快、多样性、数据有价值（volume,velocity,variety,value)高度可扩展性、高性能、高容错性、支持异构环境、较短的分析延迟、易用且开放的接口、较低成本、向下兼容性
没有更多推荐了，关系数据库中码、主码、超级码、外码和候选码，主属性和非主属性的定义和区别？
[问题点数：40分，结帖人shuitaizhichuan]
本版专家分：0
结帖率 100%
CSDN今日推荐
本版专家分：0
匿名用户不能发表回复！|
其他相关推荐If an egg is broken by outside force, life ends. But if broken by inside force,
life begins!!
数据库 - 范式(Normal Form, NF)
设K为R&U,F&中的属性或属性组合。若K
则K称为R的侯选码，或候选键（Candidate Key）。
若候选码多于一个，则选定其中的一个做为主码，或主键（Primary Key）。
主属性与非主属性
包含在任何一个候选码中的属性 ，称为主属性（Prime attribute）
不包含在任何码中的属性称为非主属性（Nonprime attribute）或非码属性（Non-key attribute）
整个属性组是码，称为全码（All-key）
关系模式S(Sno,Sdept,Sage)，单个属性Sno是码，
SC（Sno，Cno，Grade）中，（Sno，Cno）是码
关系模式R（P，W，A）
一个演奏者可以演奏多个作品
某一作品可被多个演奏者演奏
听众可以欣赏不同演奏者的不同作品
码为(P，W，A)，即All-Key
关系模式 R 中属性或属性组X 并非 R的码，但 X 是另一个关系模式的码，则称 X 是R 的外部码（Foreign key）也称外码
如在SC（Sno，Cno，Grade）中，Sno不是码，但Sno是关系模式S（Sno，Sdept，Sage）的码，则Sno是关系模式SC的外部码
主码与外部码一起提供了表示关系间联系的手段
范式(Normal Form, NF)
范式是符合某一种级别的关系模式的集合
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式
范式的种类：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)
各种范式之间存在联系：
某一关系模式R为第n范式，可简记为R∈nNF。
一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化
如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF
第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库模式
但是满足第一范式的关系模式并不一定是一个好的关系模式
[例4] 关系模式 S-L-C(Sno, Sdept, Sloc, Cno, Grade)
Sloc为学生住处，假设每个系的学生住在同一个地方
函数依赖包括：
(Sno, Cno) F
Sno → Sdept
(Sno, Cno)
Sno → Sloc
(Sno, Cno)
Sdept → Sloc (语义：每个系的学生住在同一个地方)
S-L-C的码为(Sno, Cno)
S-L-C满足第一范式。
非主属性Sdept和Sloc部分函数依赖于码(Sno, Cno)
(1) 插入异常
(2) 删除异常
(3) 数据冗余度大
(4) 修改复杂
S-L-C不是一个好的关系模式
Sdept、 Sloc部分函数依赖于码。
S-L-C分解为两个关系模式，以消除这些部分函数依赖
??SC（Sno， Cno， Grade）
S-L（Sno， Sdept， Sloc）
若R∈1NF，且每一个非主属性完全函数依赖于码，则R∈2NF。
例：S-L-C(Sno, Sdept, Sloc, Cno, Grade) ∈1NF
S-L-C(Sno, Sdept, Sloc, Cno, Grade) ∈2NF
SC（Sno， Cno， Grade） ∈ 2NF
S-L（Sno， Sdept， Sloc） ∈ 2NF
将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
将一个1NF关系分解为多个2NF的关系，并不能完全消除关系模式中的各种异常情况和数据冗余。
分解成2NF模式集的算法
设关系模式R(U)，主键是W，R上还存在FD X→Z，并且Z是非主属性和X?W，那么W→Z就是一个局部依赖。此时应把R分解成两个模式
R1（XZ），主键是X；
R2（Y），其中Y=U-Z，主键仍是W，
外键是X(REFERENCES
利用外键和主键的连接可以从R1和R2重新得到R。
如果R1和R2还不是2NF，则重复上述过程，一直到数据库模式中每一个关系模式都是2NF为止。
请思考： 一个关系模式为R（A，B，C，D），假定该关系存在着如下函数依赖：A→B，A→C，C→D，则该关系模式属于第几范式？为什么？
该关系模式属于2NF，因为键是A，不存在部分函数依赖。但存在非主属性对键的传递函数依赖，故不属于3NF
关系模式R& 中若不存在这样的码X、属性组Y及非主属性Z（Z ∈ Y）, 使得X→Y，Y→Z成立，
Y → X，则称R& ∈ 3NF。
若R∈3NF，则每一个非主属性既不部分依赖于码也不传递依赖于码。(可以证明)
定理：如果R是3NF模式，那么R也是2NF模式。
证明：只要证明模式中局部依赖的存在蕴涵着传递依赖即可。设A是R的一个非主属性，K是R的一个候选键，且K→A是一个局部依赖。那么R中必存在某个K’?K，有K’→A成立。由于A是非主属性，因此A∩KK’=φ。从K’?K，可知 K’→K，但K→K’成立。因而从K→K’ 和K’→A可知K→A是一个传递依赖。
局部依赖和传递依赖是模式产生冗余和异常的两个重要原因。由于3NF模式中不存在非主属性对候选键的局部依赖和传递依赖，因此消除了很大一部分存储异常，具有较好的性能。
3NF还有下面一个等价的定义，如下所述。
定义6.7.1 设F是关系模式R的FD集，如果对F中每个非平凡的FD X→Y，都有X含有码，或者Y的每个属性都是主属性，那么称R是3NF的模式。
这个定义表明，如果非平凡的FD X→Y中Y是主属性，则X→Y不违反3NF条件；如果Y是非主属性，且X不含有码，则必存在着候选码W有W→X，此时就有W→Y是一个传递依赖，即R不是3NF模式。
例：2NF关系模式S-L(Sno, Sdept, Sloc)中
函数依赖：
Sno→Sdept
Sdept → Sno
Sdept→Sloc
Sno→Sloc，即S-L中存在非主属性对码的传递函数依
赖，S-L ∈ 3NF
将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
将一个2NF关系分解为多个3NF的关系后，仍然不能完全消除关系模式中的各种异常情况和数据冗余。
分解成3NF模式集的算法
设关系模式R（U），主键是W，R上还存在FD X→Z。并且Z是非主属性，Z?X，X不是候选键，这样W→Z就是一个传递依赖。此时应把R分解成两个模式：
R1（XZ），主键是X；
R2（Y），其中Y=U-Z，主键仍是W，
外键是X(REFERENCES
R1)。利用外键和主键相匹配机制，R1和R2通过连接可以重新得到R。
如果R1和R2还不是3NF，则重复上述过程，一直到数据库模式中每一个关系模式都是3NF为止。
设有关系模式R（职工名，项目名，项目费，部门名，部门经理），如果规定每个职工可以参加多个项目，每参加一个项目，就有一份项目费；每个项目只属于一个部门管理；每个部门只有一个经理。
给出关系模式R的基本函数依赖FD和候选键。
R的基本FD有3个：
（职工名，项目名）→项目费
项目名→部门名
部门名→部门经理
关系模式 R 的候选键为：（职工名，项目名）
R是否为2NF 模式？若不是，把R分解成2NF模式集。
R中有下面两个FD：
（职工名，项目名）→（部门名，部门经理）
项目名→（部门名，部门经理）
因为存在非主属性组（部门名，部门经理）对候选键（职工名，项目名）的局部函数依赖，所以R不是2NF。 R应分解成下列两个模式：
R1（职工名，项目名，项目费）
R2（项目名，部门名，部门经理）
R1与R2均为2NF。
R1，R2是否为3NF 模式？若不是，将其分解成3NF模式集。
R1已经是3NF。
在R2中存在非主属性‘部门经理’对候选键‘项目名’的传递函数依赖，所以R不是3NF。 R2应进一步分解成下列两个模式：
R21（项目名，部门名）
R22（部门名，部门经理）
R21与R22均为3NF。最终，R分解成{R1，R21，R22}。
数据库（第一范式，第二范式，第三范式）
3NF(Third Normal Form)
数据库-第一范式、第二范式、第三范式、BC范式、第四范式简析
MySQL （4） 第一范式 第二范式 第三范式
什么是第一，第二，第三范式
关系数据库范式快速识别方法--第几范式
数据库的四个范式之间的区别
数据库范式
没有更多推荐了，