Oracle Database 是目前企业级应用中最成熟、最稳定、也是使用最广泛的关系型数据库之一。
Oracle的发展史也很长久，在此不做赘述。
关系型数据库的基本理论
关系型数据库
关系型数据库 是建立在关系模型基础上的数据库 ，借助与集合代数等数学概念和方法来处理数据库中的数据，现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。
关系模型 以二维表来描述数据。在关系模型中，每张表有多个字段列和记录行，每个字段列有固定的类型属性。关系模型中，数据结构简单、清晰，具有很高的数据独立性，因此是目前主流的数据库数据类型。
在关系数据模型中，关系可以看做是行与列交叉组成的二维表格，表中的行成为元组 ，可以用来标识实体集中的一个实体。表中列称为属性，给每一列起个名称即为属性名，表中的属性名不能相同。列的取值范围称为域 ，同列拥有相同的域，不同的列也可以拥有相同的域。表中任意两行（元组）不必相同。能唯一标识表中不同行的属性或属性组（即多个属性的组合）成为主键或复合主键。
关系与传统的二维表格数据文件具有类似之处，但它们又有区别。严格说，关系是一种规范化的二维表格，它具有如下性质：
- 属性值具有原子性，不可分解。
- 没有重复的元祖，即没有重复的行。
- 理论上没有行序，但在使用时有时可以有行序。
在关系型数据库中，关键码是关系模型的一个非常只能重要的概念，它通常是行（元组）的一个或几个列（属性），如果键是由一个列组成的，则称之为唯一键，如果是由多个列（属性）组成的，则称之为复合键。键的主要类型如下： - 超键：在一个关系中，能唯一标识元组的属性或属性集称为关系的超键。
- 候选键：如果一个关系中有多个候选键，则选择其中的一个键为关系的主键。用主键可以实现关系定义中"表中任意两行不能相同"的约束。
- 外键：如果一个关系R中包含了另一个关系A的主键所对应的属性组T，则称此属性组T为关系R的外键，并称关系A为参照关系，关系R为依赖关系。
关系型数据库的E-R模型
在舌尖关系型数据库时，首先耀为其建立逻辑模型。关系型数据库的逻辑模型可以通过实体和关系组成的图形来表示，这种图形就成为E-R图，它将现实世界中的实体与实体之间的联系转换为逻辑模型。使用E-R图形表示的逻辑模型称为E-R模型，一个标准的E-R模型有实体、属性、联系三部分组成。
1. 实体和属性
实体是一个数据对象，是指客观存在并可以相互区分的事物，每个实体由一组属性来表示，具有相同属性的实体组合在一起就构成实体集------实体的集合，而实体则是实体集中的一个特例。
在E-R模型中，实体用矩形表示，矩形内注明实体的命名。实体名常用以大写字母开头的有具体意义的英文名词来表示，联系名和属性名也采用这种方式。
2. 联系
在实际应用中，实体之间是存在联系的，这种联系必须在逻辑模型中表现。在E-R模型中，联系用菱形表示，菱形框内写明联系名，并用连接线将有关实体连接起来，同时在连接线的旁边标注上连接的类型。；两个实体之间的联系类型可以分为以下3类：
- 一对一：若对与实体A中的每一个实体，在实体B中最多有一个实体与之相关，反之亦然，则实体集A与实体集B具有一对一的联系，可标记联系为1:1。
- 一对多：若对应实体集A中的每一个实体，在实体集C中有多个实体与之相关，反之，对于实体集C中的每一个实体，实体集A中最多有一个实体与之相关，则称实体集A与实体集C具有一对多的联系，可标记联系为1：n。
- 多对多 ：若对于实体集A中的每一个实体，在实体集D中有多个实体与之相关，反之亦然，则实体集A与实体集D具有多对多的联系，可标记为m：n。
关系型数据库的设计范式
在数据库中，数据之间存在着密切联系，关系型数据库由相互联系的一组关系组成，每个关系包括关系模式和关系值两方面。关系模式是对关系的抽象定义，给出关系的具体结构；关系值是关系的具体内容，反应关系在某一时刻的状态。一个关系包含许多元组（记录行），每个元组都是符合关系模式结构的一个具体值，并且都分属于相应的属性。
规范化是把数据库组织成在保持存储数据完整性的同时最小化冗余数据的结构的过程，规范化的数据库必须符合关系模型的范式规则。
范式可以防止使用数据库时出现不一样的数据，并防止数据丢失。关系模型的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）、第六范式（6NF）和BCNF范式等多种。通常数据库只需满足前三个范式即可。
1.第一范式（1NF）
第一范式是第二范式和第三范式的基础，是最基本的范式。第一范式包括下列知道原则：
- 数据组的每个属性只可以包含一个值。
- 关系中的每个数组必须包含相同数量的值。
- 关系中的每个数组一定不能相同。
在任何一个关系数据库中，第一范式是对关系模式的基本要求，不满足第一范式的数据库不是关系型数据库。
如果数据表中的每一个列都是不可再分割的基本数据项------同一列中不能有多个值，那么就称此数据表符合第一范式，由此可见第一范式具有不可再分割的原子特性。
在第一范式中，数据表的每一行只包含一个实体的信息，并且每一行的每一列只能存放实体的一个属性。
如果数据表中的列信息都符合第一范式，那么在数据表中的字段都是单一的、不可再分的。
如下表是一个不符合第一范式的学生信息表：
| 学号 | 姓名 | 性别 | 年龄 | 班级 |
|---|---|---|---|---|
| 9527 | 小明 | 男 | 20 | 计算机系三班 |
在此表中，班级列下信息包含了两个属性信息，不符合第一范式。
以下为正确形式。
| 学号 | 姓名 | 性别 | 年龄 | 系别 | 班级 |
|---|---|---|---|---|---|
| 9527 | 小明 | 男 | 20 | 计算机系 | 三班 |
第二范式（2NF）
第二范式是在第一范式的基础上建立起来的，即满足第二范式需要先满足第一范式。
第二范式要求数据库表中的每个实体（即各个记录行）可以被唯一地区分。
为区分各行记录，通常需要为表设置一个区分列，用以存储各个实体的唯一标识，也就是主关键字或者主键。
第二范式要求实体的属性完全依赖于主关键字，即不能存在仅依赖于主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新实体，新实体与原实体之间是一对多的关系。
以员工工资表为例：
(员工编码、岗位) --> （决定） （姓名、年龄、学历、基本工资、绩效工资、奖金）
上述决定关系中，可以进一步拆分成下面两种关系：
(员工编码) --> (决定) （姓名、年龄、学历）
(岗位) --> (决定) (基本工资)
第三范式（3NF）
第三范式是在第二范式的基础上建立起来的，即满足第三范式需要先满足第二范式。
第三范式要求关系表不存在非关键字列对任意候选关键字列的传递函数依赖。 也就是说，第三范式要求一张关系表中不包含已在其他表中包含的非主关键字信息。
简单举例：
(员工编码) --> (决定) (员工姓名、年龄、部门编码、部门经理)
上述关系符合第二范式，但不符合第三范式，因为该关系表内部隐含着如下决定关系：
(员工编码) --> (决定) (部门) --> (决定) （部门经理）