第1章 Oracle Database 10g数据库基础.docx
《第1章 Oracle Database 10g数据库基础.docx》由会员分享，可在线阅读，更多相关《第1章 Oracle Database 10g数据库基础.docx（25页珍藏版）》请在冰豆网上搜索。
第1章OracleDatabase10g数据库基础
第1章OracleDatabase10g数据库基础
本章学习目标：
●掌握数据库基本概念。
●掌握数据库设计的方法和步骤。
●了解OracleDatabase10g数据库的概况。
●了解OracleDatabase10g数据库的体系结构。
关系数据库是当前信息管理系统中最常用的数据库。
20世纪80年代以来，计算机厂商新推出的各种数据库管理系统的产品几乎都是关系数据库。
其中，OracleDatabase10g是关系数据库，也是目前大型网络数据库中的主流数据库。
1.1关系数据库
1.1.1关系模型
关系模型由三部分组成：
数据结构、关系操作、关系的完整性。
在介绍三个组成部分之前，先来了解关系模型的基本术语。
1.关系模型的基本术语
（1）关系模型：
用二维表格结构来表示实体及实体间联系的模型称为“关系模型”（RelationalModel）。
（2）属性和值域：
在二维表中的列（字段、数据项）称为属性（Attribute），列值称为属性值，属性值的取值范围称为值域（Domain）。
（3）关系模式：
在二维表格中，行定义（记录的型）称为关系模式（Relationschema）。
（4）元组与关系：
在二维表中的行（记录的值），称为元组（Tuple），元组的集合称为关系，关系模式通常也称为关系。
（5）关键字或码：
在关系的属性中，能够用来惟一标识元组的属性（或属性组合）称为关键字或码（Key）。
关系中的元组由关键字的值来惟一确定，并且关键字不能为空。
例如，学生表中的学号就是关键字。
（6）候选关键字或候选码：
如果一个关系中，存在着多个属性（或属性的组合）都能用来惟一标识该关系的元组，这些属性或属性的组合都称为该关系的候选关键字或候选码（CandidateKey）。
（7）主关键字或主码：
在一个关系中的若干候选码中指定为关键字的属性（或属性组合）称为该关系的主关键码（PRIMARYKEY）或主码。
（8）非主属性或非码属性：
关系中不组成码的属性均为非主属性或非码属性（NonPrimaryAttribute）。
（9）外部关键字或外键：
当关系中的某个属性或属性组合虽不是该关系的关键字或只是关键字的一部分，但却是另一个关系的关键字时，称该属性或属性组合为这个关系的外部关键字或外键（ForeignKey）。
（10）从表与主表：
是指以外键相关联的两个表，以外键为主键的表称为主表（主键表），外键所在的表称为从表（外键表）。
例如，学生（学号，姓名，出生日期，入学时间，系）与选课（学号，课程号，成绩）两个表，对于“选课表”，学号是外键，对于“学生表”，学号是主键。
“学生表”为主表，“选课表”为从表。
2.关系模型的数据结构
关系模型的数据结构是一种二维表格结构，在关系模型中现实世界的实体与实体之间的联系均用二维表格来表示。
如表1.1所示。
表1.1关系模型数据结构
学生表
学号
姓名
性别
出生日期
系部名称
入学时间
060101001001
张三
男
1987.12.30
计算机
2006-9-18
060202002001
郭韩
男
1987.09.07
经济管理
2006-9-18
060401001001
刘云
女
1986.11.12
传播技术
2005-9-14
3.关系操作
关系模型中给出了关系操作的能力与特点。
关系操作的特点是集合操作，即操作的对象和结果都是集合，这种操作称为一次一个集合的方式。
关系操作的能力有选择操作（Select）、投影（Project）、连接（Join）、除（Divide）、并（Union）、交（Intersection）、差（Difference）等查询（Query）操作和插入（Insert）、删除（Delete）、修改（Update）操作。
（1）数据查询。
数据查询是将数据从关系数据库中取出并放入指定内存，放入指定内存的数据可以来自于一个关系，也可以来自于多个关系。
（2）数据插入。
数据插入是数据添加到指定关系中，形成关系中的元组。
（3）数据删除。
数据删除的基本单位是一个关系中的元组，是将指定关系中的指定元组删除。
（4）数据修改。
数据修改是在一个关系中修改指定的元组的指定属性。
数据修改包含删除需要修改的元组和插入修改后的元组两部分操作。
关系操作的能力可以用关系代数来表示。
关系代数是一种抽象的查询语言，这些抽象的语言与具体的DBMS中实现语言并不完全一致。
在实际的关系数据库中，采用一种介于关系代数和关系演算之间的语言SQL，它是关系数据库的标准语言。
4.关系模型的数据完整性
数据完整性是指关系模型中数据的正确性与一致性。
关系模型允许定义的完整性约束有：
实体完整性、域完整性、参照完整性和用户自定义的完整性约束。
关系型数据库系统提供了对实体完整性、域完整性和参照完整性约束的自动支持，也就是在插入、修改、删除操作时，数据库系统自动保证数据的正确性与一致性。
（1）实体完整性规则（EntityIntegrityRule）
这条规则要求关系中的元组在组成主键的属性上不能为空。
例如，学生表中的学号属性不能为空。
（2）域完整性规则（DomainIntegrityRule）
这条规则要求表中列的数据必须具有正确的数据类型、格式以及有效的数据范围。
例如，选课表中的成绩列的数值不能小于0，也不能大于100。
（3）参照完整性规则（ReferenceIntegrityRule）
这条规则要求不能引用不存在的元组。
例如，在学生选课表中的学号列不能引用学生表中没有的学号。
（4）用户定义的完整性规则（User-DefinedIntegrityRule）
用户自定义的完整性规则是应用领域需要遵守的约束条件，体现了具体应用领域的语义约束。
1.1.2关系数据库规范化理论
前面讨论了数据库系统的一些基本概念、关系模型的三个部分以及关系数据库的标准语言。
那么，针对一个具体数据库应用问题，应该构造几个关系模式，每个关系由那些属性组成，即如何构造适合于它的数据模式，这是关系数据库逻辑设计的问题。
为了使数据库设计的方法走向规范，1971年E.F.Codd提出了规范化理论，目前规范化理论的研究已经取得了很多的成果。
关系数据理论就是指导产生一个具有确定的、好的数据库模式的理论体系。
5.问题的提出
首先，我们来看不规范设计的关系模式所存在的问题。
例如，给出一组如下关系实例：
学生关系：
学生（学号，姓名，性别，出生日期，入学时间，籍贯，班级代码）
课程关系：
课程（课程号，课程名称，备注）
选课关系：
选课（学号，课程号，专业学校，专业代码，学年学期，课程性质，备注）
可能有以下两种数据模式：
①只有一个关系模式：
学生—选课—课程（学号，姓名，性别，出生日期，入学时间，籍贯，班级代码，课程号，课程名称，专业学校，专业代码，学年学期，课程性质，备注）
②用三个关系模式：
学生，课程，选课。
比较这两种设计方案。
第一种设计可能有下述问题。
●数据冗余：
如果学生选多门课程时，则每选一门课程就必须存储一次学生信息的细节，当一门课程被多个同学选学时，也必须多次存储课程的细节，这样就有很多的数据冗余。
●修改异常：
由于数据冗余，当修改某些数据项（例如“姓名”）时，可能有一部分有关元组被修改，而另一部分元组却没有被修改。
●插入异常：
当需要增加一门新课程，而这门课程还没有被学生选学时，则该课程不能进入数据库中。
因为在学生—选课—课程关系模式中，（学号，课程号）是主键，此时学号为空，数据库系统会根据实体完整性约束规则拒绝该元组的插入。
●删除异常：
如果某个学生的选课记录都被删除了，那么，此学生的细节信息也一起被删除了，这样我们就无法找到这个学生的信息了。
第二种设计方案不存在上述问题。
数据冗余消除了，插入、删除、修改异常消除了。
即使学生没选任何课程，学生的细节信息也仍然保存在学生关系中；即使课程没有被任何学生选学，课程的细节信息也仍然保存在课程关系中。
解决了冗余及操作异常问题，又出现另外一些问题，如果我们要查找选修语文课程的学生姓名，则需要进行三个关系的连接操作，这样代价很高。
相比之下，学生—选课—课程关系直接投影、选择就可以完成，代价较低。
如何找到一个好的数据库模式？
如何判断是否消除了上述四种问题？
这就是关系数据理论研究的问题。
关系数据理论主要包括三个方面的内容：
数据依赖，范式，模式设计方法，其中数据依赖起核心作用。
6.数据依赖
现实世界随着时间在不断地变化，因而从现实世界经过抽象而得到的关系模式的关系也会有所变化。
但是，现实世界的许多已有事实限定了关系模式所有可能的关系必须满足一定的完整性约束条件。
这些约束条件通过对属性取值范围的限定反映出来，我们称之为依赖于值域元素语义的限制，例如，学生出生日期为1986而入学时间也为1986，这显然是不合理的；这些约束条件通过对属性值之间的相互关联（主要体现在值的相等与否）反映出来，这类限制统称为数据依赖，而其中最重要的是函数依赖和多值依赖，它是数据模式设计的关键。
关系模式应当刻画出这些完整性约束条件。
（1）函数依赖。
函数依赖普遍存在于现实生活中，比如描述一个学生的关系，学生（学号，姓名，系名），由于一个学号只对应一个学生，一个学生只在一个系学习，因而，当学号值确定之后，姓名和该学生所在的系名的值也就惟一的确定了，这样我们就称“学号”函数决定“姓名”和“系名”，或者说“姓名”和“系名”函数依赖于“学号”，记为：
学号→姓名，学号→系名。
函数依赖的定义：
设R（U）是属性集U上的关系模式，X与Y是U的子集，若对于R（U）的任意一个当前值r，如果对r中的任意两个元组t和s，都有t[X]≡s[X]，就必有t[Y]≡s[Y]（即若它们在X上的属性值相等，在Y上的属性值也一定相等），则称“X函数决定Y”或“Y函数依赖与X”，记作：
X→Y，并称X为决定因素。
函数依赖和其它数据依赖一样，是语义范畴的概念，我们只能根据语义来确定一个函数依赖，而不能试图用数学来证明。
（2）函数依赖的分类。
关系数据库中函数依赖主要有如下几种：
①平凡函数依赖和非平凡函数依赖
设有关系模式R（U），X→Y是R的一个函数依赖。
若对任何X、Y∈U，此函数依赖对R的任何一个当前值都成立，则称X→Y是一个平凡函数依赖。
若X→Y，但Y∈X，则称X→Y是非平凡函数依赖，若不特别声明，都是讨论非平凡函数依赖。
②完全函数依赖和部分函数依赖
设有关系模式R（U），X→Y是R的一个函数依赖，且对于任何X′∈X，X′→Y都不成立，则称X→Y是一个完全函数依赖。
反之，如果X′→Y成立，则称X→Y是一个部分函数依赖。
③传递函数依赖
设有关系模式R（U），X，Y，Z∈U，如果X→Y，Y→Z，且Y∈X，Y不函数决定X，有X→Z，则Z传递函数依赖于X。
（3）多值依赖
多值依赖普遍存在于现实生活中，比如学校中的某一门课程由多个教师讲授，他们使用同一套参考书，每个教师可以讲授多门课程，每种参考书可以供多门课程使用。
关系模式“授课”如表1.2所示。
表1.2授课表
课程
教师
参考书
物理
杨靖康
普通物理
物理
杨靖康
物理习题集
物理
王丽
普通物理
物理
王丽
物理习题集
数学
杨靖康
数学分析
数学
杨靖康
微分方程
数学
王丽
数学分析
数学
王丽
微分方程
在关系模型“授课”中，当物理课程增加一名讲课教师{马红}时，必须插入多个元组：
{物理，马红，普通物理}；{物理，马红，物理习题集}。
同样，某一门课程是{数学}要去掉一本参考书{微分方程}时，则必须删除多个元组：
{数学，杨靖康，微分方程}；{数学，王丽，微分方程}。
我们发现此表对数据的修改很不方便，数据的冗余也很明显。
仔细考察这个关系模式，发现他们存在着多值依赖，也就是对于一个{物理，普通物理}有一组（教师）值{杨靖康，王丽}，这组值仅仅决定于（课程）上的值，而与（参考书）的值没有关系。
下面是称为多值依赖的数据依赖的定义：
设R（U）是属性集U上的一个关系模式。
X，Y，Z是U的一个子集，并且Z=U-X-Y。
当且仅当对R（U）的任一关系r，给定的一对（x，z）值，有一组Y的值，这组值仅仅决定于x值而与z的值无关，则关系模式R（U）中多值依赖X→→Y成立。
7.关系模式的规范化
在介绍了关系数据理论的一些基本概念之后，下面讨论如何根据属性间依赖情况来判定关系是否具有某些不合适的性质，按属性间的依赖情况来区分关系规范化的程度为第一范式、第二范式、第三范式和第四范式等，以及如何将具有不合适性质的关系转换为更合适的形式。
关系数据库中的关系要满足一定的要求，满足不同程度要求的为不同范式，满足最低要求的叫第一范式，简称1NF，在第一范式中进一步满足一些要求的为第二范式，其余范式依此类推。
不是1NF的关系都是非规范化关系，满足1NF的关系称为规范化的关系。
数据库理论研究的关系都是规范化的关系。
1NF是关系数据库的关系模式应满足的最起码的条件。
（1）第一范式。
如果关系模式R的每一个属性都是不可分解的，则R为第一范式的模式，记为：
R∈1NF模式。
例如有关系：
学生1（学号，姓名，性别，出生日期，系名，入学时间，家庭成员）。
关系“学生1”不满足第一范式，因为属性（家庭成员）可以再分解为（父亲）、（母亲）等属性。
解决的方法是将“学生1”关系分解为：
学生（学号，姓名，性别，出生日期，系名，入学时间）；家庭（学号，家庭成员姓名，亲属关系）两个关系。
（2）第二范式。
如果关系模式R是第一范式，且每个非码属性都完全函数依赖于码属性，则称R为满足第二范式的模式，记为：
R∈2NF模式。
例如有关系：
选课1（学号，课程号，系名，出生日期，成绩）。
关系“选课1”不满足第二范式，因为属性“成绩”完全依赖于主码（学号，课程号），而属性（系名），（出生日期）只依赖于部分主码（学号），所以，不是每一个非码属性都完全函数依赖于码属性，如图1.1所示。
解决的方法是将“选课1”关系投影分解为：
选课（学号，课程号，成绩），学生（学号，姓名，性别，出生日期，系名，入学时间）两个关系模式。
图1.1不符合第二范式的函数依赖示例
图1.2学生2中的函数依赖
图1.1不符合第二范式的函数依赖示例
图1.2学生2中的函数依赖
（3）第三范式。
如果关系模式R是第二范式，且没有一个非码属性是传递函数依赖于候选码属性，则称R为满足第三范式的模式，记为：
R∈3NF模式。
例如有关系：
学生2（学号，姓名，性别，出生日期，系名，入学时间，系宿舍楼）。
关系“学生2”不满足第三范式，因为属性（系宿舍楼）依赖于主码（学号），但也可以从非码属性（系名）导出，即（系宿舍楼）传递依赖（学号），如图1.2所示。
解决的方法同样是将关系“学生2”分解为：
学生（学号，姓名，性别，出生日期，系名，入学时间）；宿舍楼（系名，宿舍楼）两个关系模式。
（4）扩充第三范式。
如果关系模式R是第三范式，且每一个决定因素都包含有码，则称R为满足扩充第三范式的模式，记为：
R∈BCNF模式。
例如有关系：
教学（学生，教师，课程）。
每位教师只教一门课。
每门课有若干个教师教，学生选定某门课程，就对应一个固定的教师。
由语义可得到如图1.3所示的函数依赖。
图1.3教学中的函数依赖
“教学”关系不属于BCNF模式，因为（教师）是一个决定因素，而（教师）不包含码。
解决的方法是将关系“教学”分解为：
学生选教师（学生，教师）；教师任课（教师，课程）两个关系模式。
（5）第四范式。
如果关系模式R是第一范式，且每个非平凡多值依赖X→→Y（Y∈X），X都含有码，则称R为满足第四范式的模式，记为：
R∈4NF模式。
例如有关系：
授课（课程，教师，参考书）。
每位教师可以上多门课，每门课可以由若干教师讲授，一门课程有多种参考书。
在“授课”关系中，课程→→教师，课程→→参考书，它们都是非平凡的多值依赖。
而（课程）不是码，关系模式“授课”的码是（课程，教师，参考书），因此关系模式“授课”不属于第四范式。
解决的方法是将“授课”关系分解为：
任课（课程，教师）；教参（课程，参考书）两个关系。
8.关系规范化小结
关系模式规范化的过程是通过对关系模式的分解，把低一级的关系模式分解为若干个高一级的关系模式，逐步消除数据依赖中的不合理部分，使模式达到某种程度的分离，即“一个关系表示一事或一物”。
所以规范化的过程又称为“单一化”。
关系规范化的过程如图1.4所示。
图1.4各种范式及规范化过程
1.2关系数据库设计
一个信息系统的各部分能否紧密地结合在一起以及如何结合，关键在数据库。
因此，对数据库进行合理的逻辑设计和有效的物理设计才能开发出完善而高效的信息系统。
数据库设计是信息系统开发和信息建设的重要组成部分。
1.2.1需求分析
需求分析就是分析用户的需求。
需求分析是设计数据库的起点，需求分析的结构将影响到各个阶段的设计，以及最后结果的合理性与实用性。
9.需求分析的任务
需求分析的任务是通过详细调查现实世界中要处理的对象（组织、部门、企业）等，在了解现行系统工作情况，确定新系统功能的过程中，收集支持系统运行的基础数据及其处理方法，明确用户的各种需求。
调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下需求：
（1）信息需求。
指用户要从应用系统中获得信息的内容与性质。
即未来系统中要输入的信息，从数据库中要获得什么信息等。
由信息的要求就可以导出数据的要求，即在数据库中存储什么数据
（2）处理要求。
指用户要完成什么样的处理，对处理的响应时间有什么要求，是什么样的处理方式。
（3）安全性与完整性要求。
确定用户的需求是非常困难的，因为用户往往对计算机应用不太了解，难以准确表达自己的需求。
另一方面，计算机专业人员又缺乏用户的专业知识，存在与用户准确沟通的障碍。
只有通过不断与用户深入地交流，才能准确地确定用户的真正需求。
10.需求分析基本步骤
需求分析一般要进行如下几步：
（1）需求的收集：
收集数据及其发生时间、频率，数据的约束条件、相互联系等。
（2）需求的分析整理
①数据流程分析，结果描述产生数据流图。
②数据分析统计，对输入、存储、输出的数据分别进行统计。
③分析数据的各种处理功能，产生系统功能结构图。
11.阶段成果
需求分析阶段成果是系统需求说明书，此说明书主要包括数据流图、数据字典、各类数据的统计表格、系统功能结构图和必要的说明。
系统需求说明书将作为数据库设计的全过程依据的文件。
1.2.2概念结构设计
如前所述，表达概念设计结果的工具成为概念模型。
将需求分析得到的用户需求抽象为信息世界的概念模型的过程就是概念结构设计。
它是整个数据库设计的关键。
概念设计不依赖于具体的计算机系统和DBMS。
12.概念设计的策略和步骤
（1）设计概念结构的策略有如下几种：
①自顶向下：
首先定义全局概念结构的框架，再做局部细化。
②自底向上：
先定义每一局部应用的概念结构，然后按一定的规则把他们集成，进而得到全局的概念结构。
③由里向外：
首先定义核心结构，然后再扩展。
④混合策略：
就是将自顶向下和自底向上结合起来，先用前一种方法确定框架，再用自底向上设计局部概念，然后再结合起来。
（2）常用自底向上策略的设计步骤
①进行局部抽象，设计局部概念。
②将局部概念模式综合成全局概念模式
③进行评审，改造。
13.采用E-R方法的数据库概念设计步骤
采用E-R方法的数据库概念设计步骤分三步：
图1.5局部E-R模型设计步骤
（1）设计局部E-R模型，局部E-R图的设计步骤如图1.5所示。
在设计E-R模型的过程中应遵循这样一个原则：
现实世界中的事物能作为属性对待的，尽量作为属性对待。
什么样的事物可以作为属性对待？
下列两类：
●作为属性，不能是再具有需要描述的性质。
●属性不能与其它实体具有联系。
（2）设计全局E-R模型。
将所有局部的E-R图集成为全局的E-R概念模型，一般采用两两集成的方法，即先将具有相同实体的E-R图，以该相同的实体为基准进行集成，如果还有相同的实体，就再次集成，这样一直继续下去，直到所有具有相同实体的局部E-R图都被集成，从而得到全局的E-R图。
在集成的过程中，要消除属性、结构、命名三类冲突，实现合理的集成。
（3）全局E-R模型的优化。
一个好的全局的E-R模型能反映用户功能需求外，还应做到实体个数尽可能少，实体类型所含属性尽可能少，实体类型间的联系无冗余。
全局E-R模型的优化就是要达到这三个目的。
采用以下集中方法：
①合并相关的实体类型：
把1：
1联系的两个实体类型合并，合并具有相同键的实体类型。
②消除冗余属性与联系：
消除冗余主要采用分析法，并不是所有的冗余必须消除，有时为了提高效率，可以保留部分冗余。
1.2.3逻辑结构设计
概念结构是独立于任何数据模型的信息结构。
逻辑结构设计的任务就是将概念模型转化成特定的DBMS系统所支持的数据库的逻辑结构（数据库的模式和外模式）。
14.逻辑结构设计的步骤
由于现在设计的数据库应用系统都普遍采用支持关系模型的RDBMS，所以这里仅介绍关系数据库逻辑结构的设计。
关系数据库逻辑结构设计时一般分三步：
（1）将概念结构向一般的关系模型转换。
（2）将转换来的关系模型向特定的RDBMS支持的数据模型转换。
（3）对数据模型进行优化。
15.E-R模型向关系数据库的转换规则
如何将E-R模型的实体和实体间的联系转换成关系模式，如何确定这些关系模式的属性和码，这些问题是通过E-R模型向关系模式转换的规则来解决的。
E-R模型向关系数据库的转换规则是：
（1）一个实体型转换为一个关系模式。
实体的属性就是关系的属性，实体的码就是关系的码。
（2）一个1:
1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
如果转换为一个独立的关系模式，则相连的每个实体的码及该联系的属性是该关系模式的属性，每个实体的码均是该关系模式的候选码。
（3）一个1:
n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式。
与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
（4）一个m:
n联系转换为一个关系模式。
与该联系相连的各个实体的码及联系本身的属性转换为关系的属性，而该关系的码为各实体的码的组合。
（5）三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码及联系本身的属性转换为关系的属性，而该关系的码为各实体码的组合。
（6）具有相同码的关系模式可以合并。
16.关系数据库的逻辑设计
关系数据库逻辑设计的过程如下：
（1）导出初始的关系模式：
将E-R模型按规则转换成关系模式。
（2）规范化处理：
消除异常，改善完整性、一致性和存储效率。
（3）模式评价：
检查数据库模式是否能满足用户的要求，它包括功能评价和性能评价。
（4）优化模式：
采用增加、合并、分解关系的方法优化数据模型的结构，提高系统性能。
（5）形成逻辑设计说明书。
1.3OracleDatabase10g简介
Oracle是目前最流行的关系数据库管理系统，被越来越多的用户在信息系统管理、企业数据处理、Internet、电子商务网站等领域作为应用数据的后台处理系统。
世界500强的企业中有70%使用的是Oracle数据库。
它采用标准的SQL（结构化查询语
升级会员 