Oracle基础教程-第1章-数据库模型.doc

Oracle基础教程 第1章 数据库模型 作者： 日期：2 个人收集整理 勿做商业用途第1章 数据库模型 学习目标 了解数据库相关概念，以及关系型数据库概念 理解数据库的定义，关系型数据库模型,ORACLE数据库管理系统体系结构 掌握关系型数据库E-R建模,ORACLE数据库体系结构的组成及相关概念 课前准备 数据库基本理论 数据库设计E-R模型 数据库设计范化 Oracle数据库体系结构 1。1本章简介 本章主要介绍数据库的基本知识，主要包括如下内容：与数据库相关的定义；关系型数据库ER建模；同时着重介绍了oracle数据库管理系统体系结构的主要方面：物理结构、逻辑结构、后台进程及相关工作原理,本章内容是本书的基本章节，深入理解本章内容有助于以后章节的学习与实践. 1。2数据库基本知识 当今人类社会已经进入了信息化时代，信息资源已经成为了人们生活中必不可少的重要而宝贵的资源。作为信息系统核心技术和重要基础的数据库技术有了飞速发展,并得到了广泛的应用. 由于大量的信息以数据的形式存于计算机系统中，为了方便人们查询、检索、处理加工，传播需要的信息，这就提出了需要对数据进行分类，组织、编码、存储检索和维护的数据库管理工作。而数据库管理技术本身也经历了长足的发展，先后经历了人工管理，文件系统和数据库系统三个阶段。 在人工管理阶段数据处理都是通过手工进行的，这种数据处理数据量少，数据不保存，没有软件系统对数据进行管理,这种管理方式对程序的依赖性太强，并且大量数据重复冗余.为了解决手工进行数据管理的缺陷，随着技术发展提出了文件管理的方式，解决了应用程序对数据的强依赖性问题，给程序和数据定义了数据存取公共接口，数据可以长期保存，数据不属于某个特定的程序，使数据组织多样化了（如：索引、链接文件等技术），但仍然存在大量数据冗余，数据不一致性,数据联系弱的特点（文件之间是孤立的，整体上不能反映客观世界事物内在联系），为了解决文件数据管理的缺点，人们提出了全新的数据管理的方法:数据库系统，该方法充分地使用数据共享,交叉访问,与应用程序高度独立，而数据库系统根据其建立的模型基础的不同而不同，其中最为广泛使用的是建立在关系模型基础之上的关系型数据库，如：Oracle数据库系统,SQL SERVER数据库管理系统等.这类数据库系统满足关系模型的三大要素：关系数据结构，关系操作集合，关系完整约束。以下我们将介绍这关系型数据库的特点。 1.2.1 数据库的特点 数据(DATA）：数据是描述现实世界事物的符号标记，是指用物理符号记录下来的可以鉴别的信息。包括：数字、文字、图形、声音、及其他特殊的符号。 数据库（DATABASE)：按照一定的数据模型组织存储在一起的，能为多个应用程序共享的，与应用程序相对独立的相互关联的数据集合。 数据库管理系统(DBMS-Database Management System）：是指帮助用户使用和管理数据库的软件系统。 数据库管理系统通常由以下三个部分组成： 用来描述数据库的结构，用户建立数据库的数据描述语言DDL 供用户对数据库进行数据的查询和存储等数据操作语言DML 其它的管理与控制程序（例如:TCL事务控制语言,DCL数据控制语言等) 数据库具有以下特点： 数据的结构化 数据共享 减少数据冗余 优良的永久存储功能 1。2.2 关系型数据库 关系型数库：是以关系数学模型来表示的数据。关系数学模型以二维表的形式来描述数据。一个完整的关系型数据库系统包含5层结构（由内往外） 用户 关系型数据库应用系统 关系型数据库管理系统、数据库 操作系统 硬件 图:1-1关系数据库系统5层结构 硬件 硬件是指安装数据库系统的计算机,包括两种。 服务器、客户机 操作系统 操作系统是指安装数据库系统的计算机采用的操作系统. 数据库、关系型数据库管理系统 关系型数据库是存储在计算机上的，可共享的、有组织的关系型数据的集合. 关系型数据库管理系统是位于操作系统和关系型数据库应用系统之间的数据库管理软件，它通常由以下三个部分组成：用来描述数据库的结构，用来建立用户数据库的数据描述语言DDL；供用户对数据库进行数据的查询和存储等操作的数据库操作语言DML；其它的管理和控制程序。 关系型数据库应用系统 关系型数据库应用系统指为满足用户需求，采用各种应用开发工具和开发技术开发的数据库应用软件 用户 用户是指和数据库打交道的人员，包括如下三类人员： 最终用户:应用程序的使用者，通过应用程序与数据库进行交互； 数据库应用系统开发人员：是指在开发周期内，完成数据库结构的设计，应用程序开发等任务; 数据库管理员：就是我们通常所说的数据库DBA，其职能就是对数据库做日常管理，如：数据备份，数据库监控，性能调整，安全监控与调整等任务。 1.3 数据库设计E-R模型 人们在现实生活中把需要实现的事物的数据特征按某种方式进行抽象，以便能够准确的，方便的表示信息世界，这种“抽象方式”就是使用合适的模型来描述信息世界。其中最常用的就是ER模型:即实体-联系法。这种方法接近人的思维，与计算机无关、冗余被用户接受，所以人们在设计数据库，把现实世界抽象为概念结构的时候总是常用ER模型来描述之。接下来我们将介绍概念设计中的E-R模型表示法. 1.3。1 概念结构（概念模型） 概念结构是对现实世界中的一种抽象,即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。概念结构的要点和图解如下： 概念结构独立于数据库逻辑结构，也独立于支持数据库的DBMS,不受其约束。 它是现实世界与机器世界的中介，它一方面能够充分反映现实世界,包括实体和实体之间的联系,同时又易于向关系、网状、层次等各种数据模型转换。 它应是现实世界的一个真实模型,易于理解，便于和不熟悉计算机的用户交换意见,使用户易于参与。 当现实世界需求改变时，概念结构又可以很容易地做相应调整。因此概念结构设计是整个数据库设计的关键所在. 物理设计逻辑设计概念设计 DBMS 数据库管理系统（语义和结构）客观事物用户要求 关系，网状，层次 概念结构数据模型 强调结构描述 机器世界 现实世界 信息世界 实现推理抽象 强调语义描述 图1-2 概念设计模型 1。3。2 概念结构的设计方法 设计概念结构通常有四类方法： 自顶向下:即首先定义全局概念结构的框架，然后逐步细化。 自底向上：即首先定义各局部应用的概念结构，然后将它们集成起来,得到全局概念结构。 逐步扩张：首先定义最重要的核心概念结构，然后向外扩充,以滚雪球的方式逐步生成其他概念结构，直至总体概念结构。 混合策略：即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。 其中最经常采用的策略是自顶向下地进行需求分析,然后再自底向上地设计概念结构。整个过程是:数据抽象与局部视图（E-R)设计视图的集成(全局E-R)。 但无论采用哪种设计方法，一般都以ER模型为工具来描述现实世界的概念结构模型： E-R模型为实体联系图，提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型. ER模型容易理解,接近于人的思维方式，并且与计算机无关. E-R模型本身是一种语义的模型，模型力图去表达数据的意义. ER模型只能说明实体间的语义联系，不能进一步说明数据结构。 1。3.3 E-R模型的重要概念： 实体：在ER模型中，实体用矩形表示，矩形内写明实体名，是实现世界中可以区别于其他对象的“事件”或“事物”如威迅公司中每个人都是实体，每个实体都由一组特性（属性）来表示。其中某一部分属性可以唯一标识实体,如员工编号.实体集是指具有属性的实体集合。比如威迅培训班中的老师和学生可以分别定义为两个实体集。 联系：在E-R模型中，联系用菱形表示,菱形内写明实体联系名，并用无向边分别与有关的实体联系在一起,同时在无向边旁标注联系的类型：1：1或1：N或M：N；同时联系分为:实体内部的联系和实体之间的联系。实体内部之间的联系反映数据在同一记录内部各字段间的联系。我们当前主要讨论实体集之间的联系，在两个实体集之间，两个实体存在如下三种对应关系: 1.一对一：实体集中一个实体最多只与一个实体集中一个实体相联系，记为1:1，就如电影院里一个座位只有能坐一个观众。 2.一对多:实体集中一个实体与一个实体集中多个实体相联系.记为:1：n，就如部门和员工( 假如：一个员工只能属于一个部门)，一个部门对应多名员工。 3.多对多：实体集中多个实体与另一个实体集中的多个实体相联系，记为：m：n，就如项目和职工，一个项目多名员工，每个员工可以同时进行多个项目。老师与学生之间就是多对多的联系. 属性:就是实体某方面的特性。如员工的姓名、年龄、工作年限、通讯地址等。 1。3.4 抽象的几种方法 概念结构是对现实世界的一种抽象，一般有三种抽象： 分类：（is member of) 聚集（is part of） 概括（is subset of)学生 以实体学生为例 张三 王五 李四李六 图13 分类(共同特征） 学生 姓名年龄性别学号 图14 聚集（组成） 学生 本科学生进修生专科学生研究生 图15 概括 （包括） 1。3。5 建立ER图时应避免冲突和冗余 我们建立ER图往往是一部分一部分的去完成，就好象做一个普通事情一样,做事总有个先后，建立ER图也不例外，往往先划分ER图,然后把画好的各部分ER图合并起来，此时往往会产生冲突或冗余，各部分之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。 属性冲突：(1）属性域冲突,即属性值的类型、取值范围或取值集合不同。 例如：属性“零件号”有的定义为字符型，有的为数值型。（2）属性取值单位冲突。例如:属性“重量”有的以克为单位，有的以公斤为单位。 命名冲突：（1）同名异义。不同意义对象相同名称.(2）异名同义（一义多名）。同意义对象不同名称：“项目和“课题”. 结构冲突：（1）同一对象在不同应用中具有不同的抽象。例如“课程”在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。（2）同一实体在不同局部视图中所包含的属性不完全相同,或者属性的排列次序不完全相同.（3）实体之间的联系在不同局部视图中呈现不同的类型。例如实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。解决方法是根据应用的语义对实体联系的类型进行综合或调整. 除冲突之外,合并E-R图需要注意的冗余问题： 冗余属性的消除：一般在各ER图中属性是不存在冗余的,但合并后容易出现冗余属性。因为合并后的ER继承了合并前各ER图的全部属性，属性就存在冗余的可能,比如：某一属性可以由其它属性确定。 冗余联系的消除：在ER图合并过程中，可能出现实体联系的环状结构，即某实体A和某实体B有直接联系。同时它们之间有通过别的实体发生间接联系，此时可以删除直接联系； 实体类型的合并：两个具有1：1联系或1：n联系的实体可以予以合并. 1.3.6 一个ER模型实力 为了能够把客观事物（用户要求）进行概念设计，转换成概念结构，以便下一步进行逻辑设计，我们选择ER模型来表示概念结构，这里举一个我们熟悉的学生选修课程的例子，让我们能很好的理解ER模型概念表示法: 示例：假设某学校某班的学生需要选修课程，同时学生想知道他们的班主任任课情况。 我们作如下分析： 首先我们可以从示例描述中得出如下客观事物： 因为示例提出的是某一个班主任，那么必然有一个班主任,而且是一个班主任老师,非多个,这符合实现客观情况。 班主任表：王老师 示例中是学生选修课程，那么肯定有学生列表，一般情况下，一个班级有多个学生，非一个学生.那么我们得出有学生对象表。 学生表：黎明王小赵华利斯. 在示例中显然还有课程对象以供学生选课及班主任任课. 课程表： 自然历史C语言Java语言。.。 根据以上分析，以及使用数据抽象方法我们得出示例中有三个实体: 这三个实体分别是:学生、班主任、课程； 1。实体属性如下： 学生（学号、姓名、年龄、性别） 班主任（教师号、教师姓名） 课程（课程号、课程名、学分） 2。各实体之间的联系有：班主任担任课程的1：n“任课”联系;学生选修课程的n：m“选修”联系；班主任和学生的“所属”联系1：n。 至此我们得出学生选课，和班主任任课情况E-R模型如下图：性别年龄姓名学号 教师号 学生 教授 班主任选修 成绩 任课 教师名 课程 学分课程名课程号 图：16 一个基本的完整ER图 1。3。7 ER模型向关系模型的转换 从ER模型向关系模型转换时，所有实体和联系都要转换成相应的关系模式，转换规则如下： 每个实体类型转换成一个关系模式. 一个1：1的联系可以转换为一个关系模式,或与任意一端的关系模式合并，若独立转换为一个关系模式，两端的关系码及联系的属性为该关系的属性；若与一端合并，那么将另一端的关系码及联系的属性合并到该端。 一个1：n的联系可以转换成一个关系模式,或与n端的关系模式合并。若独立转换为一个关系模式,两端的关系码及联系的属性为该关系的属性。N端的关系码为该关系的码。 一个m：n的联系可以转换成一个关系模式，那么两端的关系码及联系的属性为该关系的属性，关系的码为两端实体码的组合。 3个或3个以上的多对多的联系可以转换为一个关系模式，那么这些关系的码及联系的属性为关系的属性，而关系的码为各个实体码的组合. 具有相同码的关系可以合并。 根据上述原则：将图：16转换为关系模式如下： 学生(学号、姓名、年龄、性别、老师编号）：这符合转换规则中1:n的关系. 课程（课程号、课程名、学分、老师编号）：老师和课程实体之间,这符合转换规则中1：n的关系。 班主任（教师号,教师姓名） 将实体学生和课程m：n的关系转化成关系模式（学生号、课程号、成绩） 。 1.4 范式 上面我们通过举例说明了E-R模型向关系模式转换的方法与原则，但是这样转换得来的初始关系模式并不能完全符合要求，还会有数据冗余，更新异常等问题的存在,那么使得我们在构造数据库时还必须遵循一定的规则（如：依赖)进行规范化设计。在关系数据库中，这种规范化设计规则就是范式，范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，即满足不同的范式，目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）.满足最低要求的范式是第一范式（1NF）.在第一范式的基础上进一步满足更多要求的称为第二范式（2NF)，其余范式依此类推。一般说来，数据库只需满足第三范式（3NF）就行了。二范式（2NF），其余范式依此类推。一般说来，数据库只需满足第三范式(3NF）就行了。下面我们举例介绍第一范式(1NF）、第二范式（2NF）和第三范式（3NF) 1.4.1第一范式（1NF) 在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求,不满足第一范式（1NF）的数据库就不是关系数据库. 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项。同一列中不能有多个值,即实体中某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系，在第一范式（1NF)中表的每一行只包含一个实例的信息.如果关系模式的每一个属性都不可分解（即:就是数据表的每一列不可再分，无重复的列），则称该关系模式为第一范式： 实例如: 1：不满足第一范式的实例： 员工表员工的名称员工职务员工薪水和住址黎明 程序员 2000。00，苏州市枭雄 软件工程师 1500。00，上海市王丽 项目经理 8000。00，苏州市里程 总经理 10000.00，北京市 很明显上例中第三列“员工薪水和住址”属性可以再分拆，不符合第一范式的定义； 2.满足第一范式的例子: 员工表员工的名称 员工职务 员工薪水 住址黎明 程序员 2000。00 苏州市枭雄 软件工程师 1500.00 上海市王丽 项目经理 8000.00 苏州市里程 总经理 10000。00 北京市 很明显上例满足第一范式，因为每列都不能分拆，无重复的列，属性单一。 1.4.2 第二范式（2NF） 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的,即满足第二范式（2FN）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一的区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识，这个惟一属性列被称为关键字或主键、主码。 第二范式（2NF)要求实体的属性完全依赖于主关键字.所谓完全依赖是指不能存在仅依赖主关键字的一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来，形式一个新的实体，新实体与原实体之间是一对多的关系，为实现区分通常需要为表加上一个列,以存储各个实例的唯一表示.简而言之,第二范式就是非主键属性非部分依赖于关键字. 以下是满足第二范式的例子： 员工表 员工号 员工的名称 员工职务 员工薪水 住址0001 黎明 程序员 2000.00 苏州市0002 枭雄 软件工程师 1500。00 上海市0003 王丽 项目经理 8000。00 苏州市0004 里程 总经理 10000。00 北京市 在这个例子中除了满足第一范式的同时增加了主键,是唯一标识一个员工，符合第二范式的要求。 1。4。3 第三范式（3NF） 满足第三范式（3NF）必须先满足第二范式（2NF)。简而言之，第三范式（3NF)要求一个数据库表中不包含已在其他表中已包含的非主关键字信息。 以下是满足第三范式的简单例子： 部门表部门号 部门名称 部门主管1001 开发部 王维1002 人事部 李白1003 总办 杜甫1004 行政部 罗斯福 员工表员工号 员工的名称 员工所在部门编号 员工职务 员工薪水 住址0001 黎明 1001 程序员 2000。00 苏州市0002 枭雄 1002 软件工程师 1500.00 上海市0003 王丽 1003 项目经理 8000.00 苏州市0004 里程 1004 总经理 10000。00 北京市 员工信息表中列出部门编号后就不能再将部门名称等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之,第三范式是属性不依赖于其它非主键属性. 1。4.4范式小结 目的：数据库设计规范化的目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新数据. 原则:遵从概念单一化“一事一地”原则,即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念单一化。 方法：将关系模式投影分解成两个或两个以上的关系模式。 要求：分解后的关系模式集合应当与原关系模式“等价”，即经过自然连接可以恢复原关系而不丢失信息，并保持属性间合理的联系。 注意： 一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间,避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上,并不一定要求全部模式都达到3NF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。在关系数据库中，除了函数依赖之外还有多值依赖，连接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。 1。5 Oracle体系结构 Oracle是全球最大的关系型数据库和信息管理软件供应商，Oracle公司一直在数据库领域扮演着领头羊的角色。其数据库产品以运行稳定、性能卓越而著称于世,赢得了众多厂商和企业的青睐。 1.5.1 Oracle产品的突出特点 支持大数据库、多用户的高性能的事务处理 遵守数据库存取语言、操作系统、用户接口和网络通讯协议的工业标准 优秀的安全控制和完整性控制 支持分布式数据库和分布式处理 具有可移植性、可兼容性和可延续性 对象关系型数据库系统等 1.5。2 Oracle server Oracle server发展经历了主机系统C/S体系结构-N-层体系结构。Oracle server是第一个面向对象的关系型数据库管理系统，从Oracle8i开始通过引入对象类型，实现了面向对象的支持。 在讨论Oracle server之前我们需要区分Oracle server和Oracle database： Oracle server由实例(INSTANCE）和数据库（DATABASE）组成：Oracle实例是一组内存结构和一组后台进程的集合。 Oracle实例： 1.内存结构总称SGA(系统全局区）并且主要包括： 数据高速缓存 重做日志缓冲区 共享池 2。后台进程主要有：SMON、PMON、DBWR、CKPT、LGWR等。 图解如下：ORACLE SERVER 实例 SGA（内存结构组） 后台进程组 0001 黎明 程序员 2000.00 苏州市0002 枭雄 软件工程师 1500。00 上海市0003 王丽 项目经理 8000。00 苏州市0004 里程 总经理 10000.00 北京市 重做日志文件控制文件数据文件 图17：ORACLE SERVER概图 数据库：数据库用于存放数据，以供用户访问，由一组操作系统文件组成（数据文件、控制文件、重做日志等）. 1。5。3 Oracle数据库物理结构 大家都知道数据库数据的变化（如：INSERT增加数据,UPDATE修改数据）即：数据变化和事务变化，需要永久或暂时的存储到OS文件中,供以后查询分析，这就要求数据库有相应的物理文件来存储数据,就好像工厂生产出的产品，无论以后怎么销售货物，都需要用仓库来存放。那么Oracle数据库中有哪些物理文件来保存数据和事务的变化呢？这里我们主要讲解如下用来存储的物理文件。 数据文件（DATABASE FILE）:顾名思义，数据文件就是用于存储数据库数据的文件，在数据文件中存储着用户数据（表、索引等）、数据字典以及回滚段数据等。Oracle数据库至少包含一个数据文件，并且数据文件是表空间的物理组成元素，一个表空间可以包含多个数据文件，表空间我们在以后的章节会讲到；Oracle为数据文件以。dbf结尾。数据文件有两个文件号：绝对文件号和相对文件号,绝对文件号是数据文件在数据库中的唯一标识；相对文件号是数据文件在表空间的唯一标识。数据文件由后台进程DBWR进程写入。 图解如下： 数据库 逻辑组成 表空间二表空间一 物理组成（数据文件）SYSTEM表空间 图1-8:ORACLE 物理结构和逻辑结构关系图 重做日志文件（REDO LOG）:重做日志文件是用于记录数据库变化的物理文件，其目的是为了在出现意外时恢复Oracle数据库,数据库至少要包含两个重做日志文件组，并且这些日志文件组需要循环使用：重做日志由LGWR写入. 重做日志文件组使用规则如下：如果两个日志文件组，当第一个日志文件组写满后，Oracle自动进行日志切换，并且把日志写入第二个日志组；当第二个日志组写满以后会再次切换到第一个Oracle日至文件组，并且把日志写入第一个日志组，依此类推。 下图为三个日志文件组. 日志组一日志组二日志组三 图19 重做日志组工作原理图 控制文件（CONTROL FILE）：控制文件是记录和维护数据库结构的重要文件。Oracle数据库至少包含一个控制文件，一般情况下，实例和数据库是一一对应关系，Oracle数据库正是通过控制文件在实例和数据库之间建立关联关系的,当启动Oracle Server时，系统会根据初始化参数定位控制文件，然后根据控制文件打开所有的数据文件和重做日文件。 控制文件记录如下信息： 数据文件的位置和大小； 重做日志文件的位置和大小； 数据库的创建时间； 日志序列号 参数文件：Oracle数据库实例是由一组内存结构和后台进程组成，而内存结构究竟有多大，后台进程数等都是通过参数进行定义的，安装好的数据库由一组默认的参数组成数据库参数文件，数据库的使用者可以对其进行调整，这些参数总共有200多个，Oracle9i参数文本文件以.ora结尾，Oracle9i以后由文本参数文件创建生成二进制SPFILE参数文件，同时支持动态修改Oracle数据库参数，无须重启系统。 常用基本的参数有： db_name 数据库名 Instance_name 数据库实例名 control_files 控制文件列表 db_block_size 数据库块大小 db_cache_size 数据库数据缓冲区大小shared_pool_size共享池大小log_buffer 日志缓冲区大小等 1.5.4 Oracle数据库逻辑结构