Download
1 / 39
390 likes | 557 Views
æ•°æ®åº“应用基础. 第 5 ç« æ•°æ®åˆ†æž. åœ¨æœ¬ç« é‡Œï¼Œæ‚¨å°†å¦ä¹ 以下主è¦å†…容： 规范化的æ„义和任务 函数ä¾èµ–的概念 部分函数ä¾èµ–å’Œä¼ é€’å‡½æ•°ä¾èµ–的概念 冗余ã€æ›´æ–°å¼‚常的产生和解决方法 关系的分类 1NF 〠2NF 〠3NF åŠ BCNF 的概念与应用 å规范化的æ„义和基本原则 评价数æ®æ¨¡åž‹çš„实用方法. 5.1 æ•°æ®åˆ†æž. E-R 模型 é‡ç‚¹æ˜¯åœ¨äºŽç†æ¸…实体间的关系。但是，仅处ç†å¥½å®žä½“间的关系是远远ä¸å¤Ÿçš„，还应该进一æ¥åœ°å¯¹å®žä½“进行分æžï¼Œå¤„ç†å¥½å®žä½“ä¸æ‰€åŒ…å«çš„å„个属性间的关系 。 æ•°æ®åˆ†æž
E N D
数据库应用基础 第5章 数据分析
在本章里，您将学习以下主要内容： • 规范化的意义和任务 • 函数依赖的概念 • 部分函数依赖和传递函数依赖的概念 • 冗余、更新异常的产生和解决方法 • 关系的分类 • 1NF、2NF、3NF及BCNF的概念与应用 • 反规范化的意义和基本原则 • 评价数据模型的实用方法
5.1 数据分析 • E-R模型 重点是在于理清实体间的关系。但是，仅处理好实体间的关系是远远不够的，还应该进一步地对实体进行分析，处理好实体中所包含的各个属性间的关系。 • 数据分析 是为实现简单的、无冗余的、灵活的并可扩展的数据库而准备数据模型的过程。同时，数据分析也指用来改进数据模型的技术，其专门的技术称为规范化。
5.2 规范化 • 规范化 是一种数据分析技术，该技术组织数据属性以便它们可以组合起来形成无冗余的、稳定的、灵活的并具有适应性的实体。 • 与E-R模型不同，规范化将把工作的重点放在数据属性上，而不在实体间的联系。 • 最好的办法就是每个关系只有一个主题。 • 如果某个关系的主题有两个或多个，我们就应该把它分解成多个关系，这就是规范化的基本工作。
关系（或者关系模式）是一种实体在数据库中的物理模型，代表了逻辑数据模型中实体的技术实现。在一定意义上它与一个实体或一个表是相同的。关系（或者关系模式）是一种实体在数据库中的物理模型，代表了逻辑数据模型中实体的技术实现。在一定意义上它与一个实体或一个表是相同的。 学生(学号,姓名,性别,出生日期,民族,班级号,班级名称) 关系 主键 外键
5.3 依赖 • 数据依赖表示数据间存在的一种限制或制约关系。其实，“依赖”普遍存在于各种业务数据之间。 • 常见的数据依赖有：函数依赖、多值依赖、连接依赖等。 • 其中，函数依赖在现实世界中存在最广泛。
5.3.1 函数依赖 • 函数依赖是属性之间的一种联系。假设给定了一个属性的值，我们就可以获得或查知另一属性的值。 • 如果属性X的值决定属性Y 的值，那么属性Y函数依赖于属性X。也就是说，如果知道X 的值，就可以获得Y的值。 • 函数依赖可记为：XY。
学生依赖关系图 • 学号（姓名，性别，身份证号，民族，专业，班级） • 身份证号（姓名，性别，学号，民族，专业，班级） • 学号和身份证号为决定因素，其他属性则函数依赖于学号或身份证号。 学号 姓名 性别 身份证号 民族 专业 班级
学号 课程 成绩 • 学号和课程构成组合键，可以看出学号和课程共同决定成绩。 • 如果X→(Y，Z)，则X→Y，且X→Z。 • 如果（X，Y）→Z，那么，一般情况下，X→Y或 Y→Z都不成立。
决定因子未必是主键，也未必是主键的全部。 学号 姓名 性别 项目名称 项目类别
5.3.2 部分依赖 • 当使用多个属性作为关系的复合主键时，属性间除了存在以完整主键为基础的依赖关系外，还有一种仅以主键的一部分为基础的依赖关系。这种依赖关系就称为部分依赖。 药品号 供应商号 品名 规格 单位 供应商名称 供应商地址 供应商电话
模式分解 • 部分依赖可能导致数据间的关联出现问题。如果主键是由单个的属性构成，该关系就不会存在部分依赖。 • 解决存在部分依赖的方法事实上很简单，从主题上来说，就是使一个关系只表现一个主题。将每个主题分解为一个关系。
5.3.3 传递依赖 • 在数学上，相等具有传递性。即，如果A=B，B=C，则A=C。 • 在函数依赖中，也有类似的传递存在，即：若X决定Y（反之不可），而Y能决定Z，则X就能决定Z，这就是传递依赖。 挂号单号 日期 姓名 性别 年龄 医生号 医生姓名 医生性别 职称 科室电话 科室号 科室名称 科室负责人
5.4 冗余与更新异常 • 如果关系中数据属性间出现了部分依赖或传递依赖，就会引起数据的冗余。 • 由于存在数据冗余，当对数据进行更新时就会有更新异常发生。 • 本节中，我们讨论冗余和更新异常发生的原因、状况和解决办法。
5.4.1 冗余 • 数据冗余的存在，将导致以下问题 • 首先，在一个表中保存了大量的重复数据。这些数据，将占用一定数量的存储空间，造成浪费，并且影响处理速度。 • 其次，如果要更新一项数据，就必须同时更新表中的所有具有相同意义的值。 • 例如，若挂号单中不仅包含医生号也含有医生姓名，则当医生姓名被修改时，更新将针对挂号单中所有与指定医生号的记录进行。否则，就会出现医生号与医生姓名不一致的情况。
解决了不良的依赖之后，总会比开始时多出一些关系。各个关系之间通过外键来建立联系。在子关系中放置的父关系的外键，不算冗余。解决了不良的依赖之后，总会比开始时多出一些关系。各个关系之间通过外键来建立联系。在子关系中放置的父关系的外键，不算冗余。 • 实际上，完全不存在冗余的情况在数据库设计时很少见。 • 过于理想化的数据模型会给实现数据库设计带来一定的麻烦，同时也会增加大量的时间开销。因此，有些时候人们也会适当的进行取舍，容许存在一些冗余，以便提高查询以及其它使用频率较高的操作的效率。
5.4.2 更新异常 • 当我们对一个表进行更新时，往往会产生一些意想不到的且不希望产生的结果，这就是更新异常. • 产生更新异常的原因是关系模式设计的不好，关系中存在有不良函数依赖。
插入异常 • 插入异常就是一个实体的事实直到有了另外一个实体的事实时才能插入的现象。 • 删除异常 • 删除一个实体的事实的同时，不在意地删除了关于另一个实体的事实 。 职工编号 姓名 性别 年龄 部门编号 部门名称 部门负责人
当部门重新编号时，所有该部门的职工编号都要更新，否则也将出现异常。当部门重新编号时，所有该部门的职工编号都要更新，否则也将出现异常。
约束检查 • 在数据库技术中，对操作是否违反一定规则的检查叫做约束检查。 • 可以把这种约束的具体内容定义到数据库中，当用户对相关表进行操作时，由DBMS根据约束定义的内容进行相应的检查，从而阻止违反约束的操作。 • 如果所使用的DBMS不提供这种检查，那么这种约束必须通过应用程序中的特定代码来强制实行。
约束检查 • 参照完整性 • 子表中外键的值参照了主表键值。 • 职工所在的部门必须存在。 • 实体完整性 • 主键值不得为空。
5.5 关系的分类 • 关系可以根据其中易出现的更新异常的类型进行分类。 • 用以防止异常的关系和技术称作范式（Normal Form，简称NF） • 一个关系如果符合某个范式的要求，就可以说该关系在某范式中。 • 这些范式是嵌套的，就是说属于某个范式的关系也属于之前的范式。
所谓“第几范式”，是表示关系的某一种级别。一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这个过程就是规范化的具体工作内容。所谓“第几范式”，是表示关系的某一种级别。一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这个过程就是规范化的具体工作内容。 第一范式(1NF) 第二范式(2NF) 第三范式(3NF) Boyce-Cood范式(BCNF) 第四范式(4NF) 第五范式(5NF) * 域/关键字范式（DK/NF）
5.5.1 第一范式 • 一个表要成为关系必须遵守以下规则： • 表的每一格必须是单值的，数组和重复的组都不能作为值。 • 任意一列（属性）的所有条目都必须是同一类型的，每一列都有惟一的名字，但列在表中的顺序是没有意义的，表中任意两行（元组）不能相同，行的顺序是没有意义的。
5.5.1 第一范式 • 任何符合关系定义的数据表都在第一范式中。 • 从实体的角度来描述，就是如果所有属性对于实体的单个实例都只具有一个值，则这个实体是第一范式的。
不在第一范式的表 出现了多值
分解后的情况 出版社（出版社号，出版社名称） 图书（书号，书名，出版社号）
5.5.2 第二范式 • 如果一个关系的所有非键属性都依赖于整个主键，那么该关系就属于第二范式。 • 即第二范式中不存在部分依赖。 • 根据这一定义，每个以单个属性作为主键的关系自动进入第二范式。
出现了部分依赖的表 客户需求（客户号，产品号，客户名称，产品名称）
分解后的情况 客户（客户号，客户名称） 产品（产品号，产品名称） 客户需求（客户号，产品号）
5.5.3 第三范式 • 一个关系如果在第二范式中，且没有传递依赖，则该关系在第三范式中。 有传递依赖的关系 学号→楼号，楼号→费用
分解后的情况 费用标准（楼号，费用标准） 住宿费（学号，楼号，缴费金额，缴费时间）
5.5.4 Boyce-Codd范式 • 若一个关系的每个决定因素都是候选键，则该关系在BCNF中。 • 导师（学号，专业、教师） • 候选键 • （学号，专业） →教师 • （学号，教师） →专业 • 函数依赖 • 教师→专业
存在不是候选键的决定因素 因为一个教师只能指导一个专业，所以教师是一个决定因素。
分解后的情况 导师（学号，教师）指导专业（教师，专业）
5.6 反规范化 • 权衡一下得失，我们可能会在多个方案中选择非规范化的设计，因为处理容易有时对我们来说可能更重要。 • 总体上来说，用于存放历史数据的表，可以考虑多一点违反规范化。因为，它们很少更新，更多的是对它们的查询，查询时涉及到的表越少，效率就越高。
5.7 评价数据模型 • 针对在业务系统中可能提出的与数据模型对应的数据库结构的查询来考虑E-R模型。 • 评价E-R模型时，可以构造这种问题给用户看，然后要用户构造他们自己的问题。把他们的问题施加到设计上，检查设计的合理性，同时也考虑实现的可能性。当模型不能提供问题的答案，设计就有可能出了问题，如果问题是必须回答的，那么就必须修改模型。
5.7 评价数据模型 • 当我们设计好数据库时，往往会还要对它仔细审查和分析，判断它是否满足规范化设计的要求，是否满足实际处理的需要。 • 要根据设计方案对每个表进行全面的检查，对那些不易处理的表，则根据系统需求对它们再次修改。一旦发现设计不合理，就应该及时进行处理。免得以后的工作进行到某一阶段时不得不前功尽弃。
