数据库 - 关系数据库基本知识

第一章 关系数据库基本知识

复习1.1问题的引出手工模式下用表格收集、表示和查阅信息步骤：表格的设计：根据要收集数据的结构设计空白表格填写或查阅表格数据：填写过程以添加信息为主，但也难免要进行修改（涂改）和删除（划去）。填写和查阅需要交替进行。校对表格数据：录入完成后对数据进行校对前三个步骤正对应了我们研究的数据模型的三个要素：数据结构、数据操纵和数据约束。1.1.1 表格设计手工表格设计原则：尽可能地减少重复：我们把学生基本信息表以班级为单元组织，这样班级信息就可放在表头，避免了每个学生都出现重复的班级信息。避免重复也就减少了填写表格的工作量及出现不一致差错的可能性。达到上述目标的方法是进行多表的设计：学生信息表和班级信息表。这些设计原则就是关系型数据库设计的范式中所要求的内容，上述三部分叙述对应范式中的冗余、各种异常和模式分解。1.1.2 数据操纵手工情况下对表格操作分为两种：表格信息的维护和表格信息的查阅。对表格信息维护包括增加行、修改某些行信息和删除某些行。手工情况下若要增加列，往往由于纸张宽度的限制，要重新做表，然后把原表格数据抄入已增加新列的新表中，导致这种重复的工作的原因是由于表格设计时考虑不周。对表格数据的查阅可能要同时对比着查阅多个表格，提高查阅速度的方法是对信息分组、排序或提供索引表。对应上述工作，关系型数据库提供了数据插入、删除和更新语句，同时提供了手工无法比拟的查询功能，查询操作包括选择、投影、连接、除、并、差、交和笛卡尔积运算。同样，增加一个列不属于数据操纵语言，而属于数据定义语言，是设计阶段必须完成的工作。类似手工操作，提高查询效率的有效方法之一是建立索引。1.1.3 数据校对对手工表格数据校对所包含的内容是否重复：各表格数据的一致性：如各表格中姓名的一致性数据是否合乎逻辑：如年龄、身高是否在合理的范围。上述手工校对的内容对应的三种数据约束：实体完整性、参照完整性和用户定义完整性。1.2 关系型数据结构域：把同质的列中表中独立出来，域包含了这些列取值类型和范围定义。笛卡尔积：由若干域构成一个二维表的表头（结构），每个域对应一个列名（属性），各列在其对应域取值范围内的所有取值的组合，称为这些域的笛卡尔积。（是行的集合、通常元素个数无数、无实际意义）关系（二维表）：笛卡尔积的子集，元素个数可数、有实际意义。关系的码：若关系中某个属性组的值可唯一标识一个元组（行），称该属性组为关系的码。码具有唯一性和最小性特性。1.3 关系模型的数据操作

查询操作是关系模型数据操作的核心复杂的插入、删除和更新操作需要使用子查询。数据操作的复杂性主要表现为查询操作查询操作要实现下列运算集合运算：并、差、交和广义笛卡尔积关系运算：选择、投影、连接、除1.4 关系模型的完整性约束

实体完整性：通过设置主键实现参照完整性：通过定义引用关系（外键）实现用户定义完整性：包括非空约束（NotNull）、唯一性约束（Unique）、列级和行级自定义逻辑关系约束（check）等。第二章 范式及其对数据库设计的

指导意义

范式理论及对实践指导意义概述。范式：1NF、2NF、3NF、BCNF、4NF、5NF实例分析及1NF、3NF的认识误区关系模型下的树结构表达供应商和系名问题范式的局限－对冗余的进一步讨论单表行间冗余多表间冗余2.1 范式理论及对实践指导意义概述1）范式理论形成：1971年，由1970年首先提出“大型共享数据库数据的关系模型”的关系数据库之父EdgarFrankCodd相继提出了三级规范化形式1NF-3NF1974年，E.F.Codd和Boyce共同提出BCNF1977RonaldFagin提出了第四范式以后又相继提出了5NF（Project-JoinNormalForm(PJ/NF))、DKFN（Domain/KeyNormalForm）和6NF2）各范式之间关系：1NF2NF3NFBCNF4NF5NFDKNF6NF3）规范化方法：一个属于低一级的范式的关系模式可以通过模式分解转换成属于高一级范式的关系模式，这个过程称为关系模式的规范化。4）规范化目的：消除关系中的数据冗余由于数据冗余引发的问题：浪费了存储资源，并且重复的数据占用的空间随数据量的递增而递增。由于数据的重复，为保证数据的一致性，将增加数据维护（插入、更新和删除）的代价，从而降低了系统的开发和运行效率各种意外还是可能造成重复数据的不一致，从而降低了系统的稳定性和可靠性。是产生插入，更新和删除异常根源（见下例）插入，更新和删除异常实例：假设存在下列关系，包含学生和系的基本信息：学号 姓名 所在系 系主任001 zhang 数学 MrLi002 wang 数学 MrLi003 zhou 数学 MrLi004 feng 计算机 Mrchen005 dong 计算机 Mrchen该关系存在插入，更新和删除异常。插入异常：当新成立一个系但还没有学生时，产生插入异常。删除异常：当一个系的学生被全部删除后，系信息也被删除。更新异常：当系名称或系主任发生变化，必须同时更新这个系所有学生记录，若漏改一个，就产生更新异常。5）规范化理论对实践的指导意义异常分类：关系设计不规范引起插入，更新和删除异常有的可以通过严密的算法避免发生，有的则不能避免。在上例中，插入和删除异常不可避免，而更新异常却可以避免。不可避免异常：若数据库的设计中存在不可避免的异常时，需求将无法实现，设计者会自觉地消除这些异常。在上例中，一般会增加一个“系（系名，系主任）”关系来排除不可避免的插入和删除异常。这时，规范化设计成为设计师自觉的行动可避免异常：关系规范化理论对设计者有指导意义的是消除可避免异常引起的数据冗余。冗余和范式关系：一般消除了一个关系中的数据冗余（除外键引用为必要的数据冗余外），该关系也就符合了范式要求。一个关系符合范式要求，一般就不会产生数据冗余，但必须注意的是范式可以消除一个关系中的（单行）数据冗余，但不能消除一个表的行间冗余和多个关系之间的数据冗余。2.2 范式

2.2.1 1NF及对实践的指导意义

1）定义1NF的定义1：若关系中所有属性是不可再分的基本项（原子项），即关系中的属性不能是组合属性，称关系属于或服从第一范式。1NF的定义2：关系模式R中不能含有任何重复的数据项。（RobertD.Schnneider规划与建立高性能SQLServer6.5数据库）第一范式是关系数据模式必须遵循的规范，其他规范均建立在此基础之上。关系的一切数学理论均基于关系模式服从1NF。如一个学生的成绩包括数学，语文，外语等，则成绩不能作为学生关系中的一个属性。要使其符合1NF,必须把数学，语文，外语成绩直接作为学生关系的属性。由于关系数据库中表中列之间的关系相互并列,本身不支持层次结构或数组,所以表面上看,只要是二维表,就一定符合1NF2）1NF的第一层次的解释3）1NF的第二层次的解释不要或没有必要把若干属性或代码组合成一个组合属性或组合代码放在一个数据列中。这同样违反1NF。这样做的风险是数据库系统对组合属性中某属性的可操作性(子串)一定不如对列的可操作性。解决上述问题的方法也不要简单地把组合属性分解成列,当这些属性有扩充的可能时,应单独建立一个关系。（后面有详例分析）4）1NF的第三层次的解释1NF要求在一行中不能有重复组，不管是重复的列还是列中含有的重复信息都不允许。(数据库设计)如不要把数学成绩，语文成绩和外语成绩作为学生关系中的属性，因为，一旦增加一门课程，该关系就必须作修改。正确的做法是把成绩独立出来，形成的关系模型为：成绩（学号，学科号，成绩）类似的如在学生关系中有联系电话属性，而每一个学生可能有不确定的电话数量，则增加属性“电话1”、“电话2”…，同样不符合1NF要求，正确的做法是增加关系：R(学号，电话号码)2.2.2 2NF及对实践的指导意义关系属于第一范式并且每一个非主属性完全依赖于码，则称关系属于第二范式。由于非主属性均函数依赖于码，所以第二范式去除了非主属性对码的部分依赖。假设(x,y)为关系R(U)的码，有非主属性z，yz，由于y不包含码，所以关系的行中y值必有重复，yz，z值与y值同步重复。一般可以把R(U)分解成R1(U-{z})和R2(y,z)，使子关系均属于2NF，同时消除了冗余。 单据号 单据日期 品号 品名 数量

b001 2003-2-1 G01 A 10 b001 2003-2-1 G02 B 12 b002 2004-2-7 G02 B 20{单据号，品号}为关系的主码，“单据日期”为非主属性，“单据号”“单据日期”，即非主属性“单据日期”部分依赖于码,这种设计的数据冗余显而易见。把关系分解为：单据摘要（单据号*、单据日期）和单据明细（单据号*，品号*，品名，数量），通过单据号建立关联。例.单据的单表设计就不属于第2范式思考练习:分别完成单据的两种设计下的下列操作的设计，并进行比较：单据明细的增加，删除和修改单据的增加和删除。空白单据的处理 若把学生学科成绩设计成（学号，姓名，学科号，学科名，成绩），该关系就不符合第二范式。（“学号”，“学科号”）为该关系的主键（码），非主属性中，除“成绩”完全依赖于主键，“姓名”和“学科名”不完全依赖于主键，即仅分别完全依赖于主键的子集“学号”和“学科号”。 要使其符合2NF，必须把上述关系分解成三个关系：学生(学号,姓名,…)、学科(学科号,学科名,…)和成绩(学号,学科号,成绩)。例.学生学科成绩的关系模型设计2.2.3 3NF及对实践的指导意义关系属于第一范式且关系中不存在非主属性Z传递函数依赖于码，则称关系属于第三范式。在传递函数依赖XYZ的定义中隐含YX和ZY，但3NF定义中的传递函数依赖允许YX（YX）,由此才能保证2NF3NF。假如不放宽传递函数依赖条件，则关系：学生选课（学号，课程号，课程名）不符合2NF但符合3NF，因为我们找不到属性组Y，使唯一的非主属性“课程名”传递函数依赖于码(学号,课程号)，即(学号,课程号)

Y课程名。而定义条件放宽后，可取Y=“课程号”。第三范式是在关系中去除非主属性对码的传递函数依赖。不属于3NF必然存在冗余X，Y，Z为关系R(U)的属性组，且X为码，XYZ，由于Y+>X，所以Y必不包含码，在关系的行中Y值必有重复，而YZ，所以Z值同步重复。一般可以把R(U)分解成R1(U-{Z})和R2(Y,Z)，使子关系均属于3NF，同时消除了冗余。如在学生关系中增加所在“系”和“系主任”属性，则该关系就不符合第三范式，因为由依赖关系“学号

系

系主任”，中间就存在了传递函数依赖，学号

系主任。 学号 姓名 系 系主任 001 wang 数学 Li 002 Feng 数学 Li 003 Cheng 数学 Li 004 Huang 物理 Xu

显然这种设计存在数据冗余正确的做法是在学生关系中增加“系编号”属性，同时增加一个关系：系（系编号，系名，系主任）。 学号 姓名 系号 系号 系 系主任 001 wang 01 01 数学 Li 002 Feng01 02 物理 Xu 003 Cheng01 004 Huang02单据中包含商品代码外,还包括商品属性,同样不符合第三范式,因为存在下列传递函数依赖:(单据号,单据明细序号)商品代码商品属性。2.2.4 BCNF-扩充的第三范式关系模式R(U,F)1NF,若XY(Y

X),X必包含码,则R(U,F)BCNF。BCNF是在3NF基础上去除主属性对码的部分和传递依赖。X，Y为关系R(U)的属性组，XY，且X不包含码，在关系的行中X值必有重复，而XY，所以Y值同步重复。一般可以把R(U)分解成R1(U-{Y})和R2(X,Y)，使子关系均属于BCNF，同时消除了冗余。属于3NF但不属于BCNF的例：

学生选课（学号，课程号，教师编号，成绩），假设一个教师只上一门课。则：教师编号

课程号，但教师编号不是关系的码，所以此关系不属于BCNF。 学号 课程号 教师编号 成绩

001 数据库 Li 89 001 C语言 Zhang 76 002 数据库 Li 99 003 数据库 Li 87 显然这种设计存在数据