ch7 关系数据库设计理论复习

Repetition of Information.（姓名，身份证号，出生日期） Inability to represent certain information.（姓名，出生 日期）
Avoid redundant（冗余） data Ensure that relationships among attributes are represented （代表性） Facilitate the checking of updates for violation（违背） of database integrity constraints（完整性）.
例如：一个具有属性集A,B,C的关系。该关系有如下的函数依 赖：{A B，B C}。{A}的闭包是什么？即{A} + 是什么？ 样式



因为在闭包的计算中，我们允许平凡依赖，所以A总在{A}＋中。 因为在关系的函数依赖中存在A B，因此，B也应在{A}＋中。 根据函数依赖集中的A B，B C，可推导出A C，故C也应在{A} ＋中。 记作{A}＋＝{A,B,C} 即A可以函数决定属性A,B,C。
求解步骤：




设属性集X最终将成为闭包。首先将X初始化为 {A1,A2, …,An }。 然后，重复地搜索某个函数依赖B1,B2, …,BnC，使得 所有的B1,B2, …,Bn都在属性集X中，但C不在其中，于 是将C加到属性集X中。 根据需要多次重复步骤2，直到没有属性能加到X中。由 于X是只增的，而任何关系的属性树木必然是有限的，因 此最终再没有属性可以加到X中。 最后得到的不能再增加的属性集X就是{A1,A2, …,An}＋ 的正确值。
Relational Database Design
我们如何判断我们所设计的数据库 是一个好的数据库呢？
Relational Database Design
First Normal Form 第一范式 Pitfalls（陷阱） in Relational Database Design Functional Dependencies 函数依赖 Decomposition 分解 Boyce-Codd Normal Form BC范式 Third Normal Form 第三范式 Multivalued Dependencies and Fourth Normal Form 多值依赖与第四范式 Overall Database Design Process 数据库设计的总过程
Functional Dependencies (Cont.)
A functional dependency is a generalization（概括） of the notion（概念） of a key. 从函数依赖的角度出发来认识关系的键码（keys of relation） We say a set of one or more attributes {A1,A2, …,An} is a key for a relation if :如果一个和多个属性{A1,A2, …,An} 满足如下条件，我们就称该集合为关系R的键码。

如果某个C在A中，我们可以利用平凡依赖规则将其从右 边删除。
Closure of a Set of Functional Dependencies
We can find all of F+ by applying Armstrong’s Axioms（阿姆斯特朗公理）:
if , then (reflexivity 自反) if , then (augmentation增补) if , and , then (transitivity传递)
(title,year) length
(title,year) studioName
(title,year) fileTpye
由于三个依赖的左边完全相同，都是(title,year) 我门可以用 简写的形式把它们汇总在一行中： (title,year) length, fileType,studioName
Functional Dependencies
如果R的两个元组在属性A1,A2, …,An上一致，则它们在另 一个属性B上也应该一致。这种依赖正式记作A1,A2, …,An B，称为B函数依赖于A1,A2, …,An，也可以说 “A1,A2, …,An函数决定B”。
例如关系 Movie(title,year,length,filmTpye,studioName,starName) 我们可以合理地断言关于Movie的几个函数依赖。
从以上分解中，我们不难看到：如此将一个关系模式分解 成两个关系模式后：

减少了冗余 消除了插入异常 消除了删除异常 修改简单
Decomposition（分解）
并不是任意地将一个关系模式分解成两个关系模式就一定会 产生好的关系模式，关系模式的分解也可能带来一些新的问 题。 例如：将Lending-schema 分解成: Branch-customer = (branch-name, customer-name) Loan-info = (branch-name, loan-number,amount) 如此分解，既不能解决以前存在的问题，还会带来新的异 常（anomalies）。 究竟应该如何分解才能消除异常？在关系分解中应该遵循的 基本原则是什么？
通常我们所说的函数依赖都是指非平凡函数依赖
Closure of a Set of Functional Dependencies
假设{A1,A2, …,An }是属性集，S是函数依赖集，属性集 {A1,A2, …,An}在依赖集S下的闭包是这样的属性集B，它使得 满足依赖集S中的所有依赖的每个关系也都满足A1,A2, …,An B。也就是说， A1,A2, …,An B是蕴含于S中的函数依赖。 我们用{A1,A2, …,An}+ 来表示属性集A1,A2, …,An的闭包。
example
Relation schema: Lending-schema = (branch-name, branch-city, asset, customer-name, loan-number, amount) 存在以下4个问题：

wenku.baidu.com

插入异常：例如要插入一个新的银行信息，如果该银行没有 客户，就无法插入该银行信息。 删除异常：如果删除某银行的所有客户信息，则该银行的信 息（branch_name, branch-city, asset ）记录就要被删除。 （ 因为customer_name是主属性，删除了客户名称，整个 元组就不存在了。） 数据冗余：一个branch-name就可以唯一地确定一个 branch-city和asset 。而在该关系模式中，如果一个银行有1 万个客户，该银行的branch-city和asset就要重复1万次。 修改复杂：假设某银行有5万客户，如果该银行的branchcity和asset branch-city和asset变动的话，则需要对5万个 元组中全部的branch-city和asset信息进行修改。
Functional Dependencies (Cont.)
平凡函数依赖和非平凡函数依赖 A functional dependency is trivial（平凡） if it is satisfied by all instances of a relation
平凡函数依赖在任何关系中都成立 E.g.在任何关系中都成立

Those attributes functionally determines all other attributes of the relation.这些属性函数决定该关系的所有 其他属性。 No proper subset of {A1,A2, …,An} functionally determines all other attributes of R. i.e, a key must be minimal. {A1,A2, …,An}的任何真子集都不能函数决定R的 所有其他属性。也就是说，键码必须是最小的。
Closure of a Set of Functional Dependencies
求闭包的过程： 从给定的属性集触发，一旦包含了某函数依 赖左边的属性，就把其右边的属性增加进来， 就这样不断地扩展该集合，最终，当该集合 再也无法扩展时，得到的结果就是闭包。
Closure of a Set of Functional Dependencies
Closure of a Set of Functional Dependencies
The Transitive Rule 传递规律

如果A1,A2, …,An B1,B2, …,Bn和
B1,B2, …,Bn C1,C2, …,Cn，在关系R中成立，则 A1,A2, …,An C1,C2, …,Cn在R中也成立。

Closure of Functional Dependencies (Cont.)
We can further simplify manual computation of F+ by using the following additional rules.
First Normal Form
A relational schema R is in first normal form if the domains of all attributes of R are atomic 如果一个关系模式R的所有属性都是不可分的基本数 据项，则称关系R属于第一范式。 记作R 1NF. 第一范式是对关系模式的一个最起码的要求。 不满足第一范式的数据库模式不能称为关系数据库。 当然并不是满足第一范式的关系模式就一定是一个好 的关系模式。仍然可能存在很多的问题。
Pitfalls in Relational Database Design
Relational database design requires that we find a “good” collection of relation schemas. A bad design may lead to

customer-name, loan-number customer-name customer-name customer-name

In general, is trivial if
非平凡函数依赖 即 如(title,year) length

Functional Dependencies (Cont.)
有时在一个关系中有多个键码，这样的话，通常要 指定其中的一个键码为主键码（primary key），在 商业数据库系统中，主键码的选择会影响某些实现细 节。
Functional Dependencies (Cont.)
包含键码的属性集成为“超键码”superkey， 因此，每个键码都是超键码，但是，某些超 键码不是键码。 注意：每个超键码都满足键码的第一个条件： 函数决定它所在的关系的所有其他属性，但 是，超键码不必满足键码的第二个条件：最 小化条件。
Design Goals:


Decomposition（分解）
在关系模式的设计有缺陷时，我们通过更详细地分析这些 缺陷引起地问题，引入“分解”的思想，即把一个关系模 式分解成两个更小的模式来消除某些问题。
Decompose the relation schema Lending-schema into: Branch-schema = (branch-name, branch-city,assets) Loan-info-schema = (customer-name, loan-number, branchname, amount)