关系型数据库理论基础范式

实体与实体之间的关系有以下三种：
! 一对多
指一个实体中有且只有一条记录与另一个实体中的多条记录对应。如图1-1
中，一个工作岗位可以有多个雇员，一个部门也可以有多个雇员。我们一般把“一”
方称作父表，而把“多”方称作子表。图中的符号是一种比较常见的表示一对多关系
的方法，另外一种也经常使用的表示方法如图1-2所示：

! 一对一
指一个实体中的记录与另一个实体的记录处于一对一的关系。
. 4 . 
! 多对多
指一个实体中的记录与另一个实体的记录是多对多的关系。比如雇员与地址
之间的关系就可能是一种多对多关系，因为一个雇员可能有多个地址，而一个地址
也可能对应多个雇员。对于这种关系，在进行数据库逻辑模型设计时，一般要进行
分解处理，即分解成两个一对多的关系。

1.2 键的定义
在一个实体中，存在一些能唯一标识该实体中各个记录的属性(或属性组合)， 这些属性被称作键(Key)。真正被挑选出来唯一区分各记录的属性称为主键(Primary 
Key，缩写为PK)，其它未被选中的键称为候选键(Alternate Key，缩写为AK)。例 如在雇员表中，一般可以把雇员编号选作主键。
一个实体中的哪些属性可以是主键，这与具体的系统和业务规则有关。举例
来说，如果一个公司内没有重名的雇员，则将其姓名当作主键也未尝不可。一般来
讲，主键属性必须满足以下三个条件： ! 必须能唯一区分各数据记录，即不能有重复值
! 不可以是空值 ! 其值很少发生变化
前面两个条件很容易理解，对第三个条件可以举个例子来说明。如在雇员表 中，使用雇员编号作为主键。假设某个雇员进公司时编号为1000，几年后他升为主
管，将其编号改为2000。这样就可能产生这样的问题：当我们寻找编号1000的雇员
信息时，只能发现他以前的记录，而找不到他的当前情况；同样，寻找编号2000的
雇员时，只有现在的信息而没有以前的记录。因此，最好的办法是不要改动雇员编
号，或者选用其他候选键作为主键。

由于实体与实体之间存在的关系，引出了另外一个概念：外键(Foreign Key，
缩写为FK)。所谓外键，是指一个实体(子表)的一个属性，而这个属性正好是另一
个实体(父表)的主键。如图1-3中的雇员表，部门编号(Department_Number)与工作 编号(Job_Code)分别是部门表和工作表的主键，因此被称为外键。很显然，外键只 有透过实体之间的关系才能体现出来。利用主键与外键，可以保证各个实体之间的
参照完整性

1.3 范式理论
为了描述一个企业或机构的业务运行方式，我们要建立相应的E-R图。在选择 实体和实体的属性、定义它们之间的关系时，是不是可以随意而为呢？显然不是。
一个设计不好的关系模型可能会产生很多的问题，如过多的冗余、数据不一致、插 入与删除异常等。
为了能正确地描述和处理这些问题，在关系数据库理论的发展过程当中，逐 渐形成并完善了所谓的范式理论，它是数据库逻辑模型设计的基本理论。首先来看
几个基本概念。

第一范式(The First Normal Form) (The First Normal Form) 
在一个关系中，如果每个属性的值唯一而不具有多义性，则称它符合第一范
式。 举例来说，在一个描述雇员的关系中，如果用一个属性来记录某个雇员加入
或者离开公司的日期，显然就不符合这个条件。

第二范式(The Second Normal Form) (The Second Normal Form) 
如果一个关系符合第一范式，并且每个非主属性完全依赖于整个主键，而非
主键的一部分，则称它符合第二范式。 当多个属性组成复合主键时，要特别注意这个条件。


第三范式(The Third Normal Form) (The Third Normal Form) 
如果一个关系符合第二范式，并且每个非主属性不能依赖于其它关系中的属
性(因为这样的话，这种属性应该归到其它关系中去)，则称它符合第三范式。

1.4 逻辑模型与物理模型
逻辑模型主要是依据业务规则建立的，为了清晰地反映企业操作模式，我们
建立的逻辑模型一般应满足第三范式。而把一个逻辑模型在一个平台上实施时，就
变成了物理模型。由于技术上的一些限制，在一些系统中常常不得不对逻辑模型作
不规范化处理(De-Normalize)

举例来说，在数据仓库中经常要用到多表的连接操作，而表的连接是比较耗
系统资源的。为了避免或减少表的连接操作，一些数据库系统常常不得不把两个或
多个表合并起来，这实际上就是一种不规范化处理。

1.5 1.5 1 索引
索引是物理模型中的一个概念，利用索引，可以直接存取表中的某一条记录
而不需要搜索整个表。因此，索引提供了一条更快速访问数据记录的途径。 当在数据库中针对某个表创建一个索引时，系统将根据此索引建立一个相应
的子表。相对原来的表(主表)而言，子表要小得多。它将存储索引的值以及一个与
此索引对应的数据记录在主表中的存储位置，这好比一个指向数据记录物理位置的 指针，如图1-5所示。因此，当搜索一条数据记录时，如果有相应的索引，则只要
在索引子表中找到与此索引值匹配的记录，就找到了数据项在主表中的物理存储位
置，这样不需要搜索整个主表就能迅速定位数据记录了。显然，建立索引需要占用 额外的存储空间；另外，索引子表是由系统自动维护的，当主表的数据记录发生变
化时，系统要自动更新索引子表的相应记录，从而占用系统资源。这就是使用索引
的代价。

在Teradata数据库管理系统中，它使用一个所谓的主索引进行数据的分配，而
主索引是没有子表的，不占用额外的存储空间，也不需要专门的维护。因此，
Teradata中的索引有主次之分，只有次索引才有相应的子表。有关Teradata中主次索
引的用法和原理在第四和第五章中会有详细的讨论，这里只介绍一下它们的种类和
定义。
我们已经谈到，主键与外键是数据库逻辑模型中的定义，而索引则存在于物
理模型中。Teradata中又把索引分为主索引和次索引，主索引不一定就对应主键。 选择主索引的基本原则是：尽量选择那些访问频率高的属性作为主索引。举例来
说，在雇员表中，如果经常根据姓名来查找数据，则应选择姓名而不是雇员编号作
为主索引。