函数依赖规范化.ppt

规范化 规范化的必要性与重要性 规范化在整个数据库设计知识结构中的位置 规划化解决的问题 规范化在数据库概要设计中的位置 一个异常模式设计 例：lending(branch_name,branch_city,asset(分支机构的资产额)，customer_name,loan_number,amount) 一个异常模式设计 “好”的模式： 不会发生插入异常、删除异常、更新异常， 数据冗余应尽可能少。 异常原因： 解决方法： 规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。 重点内容 函数依赖 三种范式、BCNF范式 模式分解 函数依赖 1 函数依赖定义 2 用函数依赖解释候选码、超码 3 函数依赖的等价性 4 函数依赖的推理规则 5 最小函数依赖集 1 函数依赖的定义 关系R上的函数依赖：如果R的两个元组在属性A1,A2,…..An上一致（也就是说，两个元组在这些属性相对应的各个分量具有相同的值），则它们在另一个属性B上也应该是一致。 记作：A1 A2…..An →B 函数依赖举例 Movie(title,year,length,filmType, studioName,starName） Title year-length Title year - filmtype Title year - studioName 简写： title year - length filmtype studioName 函数依赖说明 强调：函数依赖是针对关系模式， 而不是特定的实例。 2 用函数依赖解释候选码、超码 如果一个或多个属性的集合{A1,A2,….An}满足如下条件，就称该集合为关系R的键码。 1．? 这些属性函数决定该关系的所有其他属性。 2．? {A1,A2,….An}的任何真子集都不能函数决定R的所有其他属性。 键码举例 MovieStar(title,year,length,filmType,studioName,starName） ?属性组{title,year,starName}构成了Movie关系的键码。 Title year starName-length filmType 必须证明：{title,year,starName}的任何真子集都不能函数决定所有其他的属性。 键码举例 首先：观察title 和year不能决定starName，因为很多电影有多个影星。 {year,starName}也不是键码，因为一个影星在同一年中可能出演多部电影，因此， year,starname→title 不是函数依赖。 同样{title,starName}也不是键码。 从而确定了{title, year,starName}是最小的集合 关系的键码（候选码） 说明： 有时一个关系有多个键码（候选码），这样的话，通常要指定其中一个为主键码。 超键码 包含键码（候选码）的属性集称为“超键码 superkey”,即键码的超集（superset of a key）。 键码和超键码的关系： 每个键码都是超键码 但是，某个超键码不是（最小的）键码 超键码满足键码的第一个条件，但是不一定满足键码的第二个条件。 寻找关系的键码 判断键码的第一条规则：来自实体集的关系的键码就是该实体集或类的键码属性。 例：Movie(title,year,length,filmtype) Stars(name,address) 寻找关系的键码 第二条规则：如果关系R来自一个联系，则该联系的多样性将会影响R的键码。有三种情况： l?如果联系是“多对多”的，则相连的两个实体集的键码都是R 的键码属性。 l??如果是从实体集E1到实体集E2的“多对一”联系，那么实体集E1的键码属性是R的键码属性，而E2的键码属性则不是R的键码属性。 l?如果联系是“一对一”的，则联系两端的任何一个实体集的键码属性都是R的键码属性，即R的键码属性不是唯一的。 寻找关系的键码 例： Movie(title,year,length,filmtype) 多 Studios(name,address) 一 Owns(title,year,studioName) ? ?Movie 与 Stars 多对多 Stars-in(主演) Stars-in(title,year,starName) 寻找关系的键码 多向联系的情况： 如果多向联系R有一个箭头指向实体集E，则相应的关系中，除了E的键码以外，至少还存在一个键码。 3 函数依赖的等价性 在不改变关系的合法实例集的条件下，函数依赖通常可以用几种不同的的方式来表示。如果满足这种