文章目录
一. 关系数据模型中的结构
关系数据模型基于关系这一数学概念。接下来解释关系数据模型中的术语和相关概念。
我们使用一个分公司-员工关系的例子。假设有一个大型公司在全国都有分公司，每个员工属于一个分公司，一个分公司有一个经理。
1．关系
由行和列构成的二维结构，对应关系数据库中的表，如分公司表和员工表。
注意，这种认识只是我们从逻辑上看待关系模型的方式，并不应用于表在磁盘上的物理结构。表的物理存储结构可以是堆文件、索引文件或哈希文件。
2．属性
由属性名称和类型名称构成的顺序对。对应关系数据库中表的列，如地址（Variable Characters）是公司表的一个属性。
3．属性域
表示属性的取值范围。每一个属性都有一个预定义的值的范围。域描述了属性所有可能的值。
如下表列出了分公司-员工关系的一些属性域。
4．元组
关系中的一条记录，对应关系数据库中的一个表行。
元组可以以任何顺序出现，而关系保持不变，也就是说，在关系理论中，表中的行是没有顺序的。
5. 关系数据库
一系列规范化的表的集合。
6．关系表的属性
关系表有如下属性：
7．关系数据模型中的键
1）超键
2）候选键 ing
仅包含唯一标识记录所必需的最小数量列的超键。 表的候选键有三个属性：
在我们的例子中，分公司表编号是候选键，如果每个分公司的邮编都不同，那么邮编也可以作为分公司表的候选键。一个表中允许有多个候选键。
3）主键
唯一标识表中记录的候选键。主键是唯一、非空的。没有被选为主键的候选键称为备用键。
主键的选择在关系数据模型中非常重要，很多性能问题都是由于主键选择不当引起的。
在选择主键时，我们可以参考以下原则：
4）外键
一个表中的一个列或多个列的集合，这些列匹配某些其他（也可以是同一个）表中的候选键。
注意外键所引用的不一定是主键，但一定是候选键。
当一列出现在两张表中的时候，它通常代表两张表记录之间的关系。
所以主键所在的表被称为父表，外键所在的表被称为子表。
二. 关系完整性
关系数据模型有两个重要的完整性规则：实体完整性和参照完整性。在定义这些术语之前，先要理解空值的概念。
1．空值（NULL）
表示一个列的值目前还不知道或者对于当前记录来说不可用。
空值具有特殊性，当它参与逻辑运算时，结果取决于真值表。Oracle的非、与、或逻辑运算真值表。
举例，如果一个分公司的经理离职了，新的经理还没有上任，此时公司经理列对应的值就是空值。
2．关系完整性规则
1）实体完整性
在一个基本表中，主键列的取值不能为空。
2）参照完整性
如果表中存在外键，则外键值必须与主表中的某些记录的候选键值相同，否则外键的值必须为空。
3．业务规则
业务规则的例子包括属性域和关系完整性规则。属性域用于约束特定列能够取的值。
4．关系数据库语言
三. 规范化
关系数据模型的规范化是一种组织数据的技术。规范化方法对表进行分解，以消除数据冗余，避免异常更新，提高数据完整性。
先看一个不规范化的例子：
规范化是通过应用范式规则实现的。最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。
1）第一范式（1NF）表中的列只能含有原子性（不可再分）的值。
上例中张三有两个手机号存储在mobile列中，违反了1NF规则。为了使表满足1NF，数据应该修改为如下表所示。
2）第二范式（2NF）
第二范式要同时满足下面两个条件：
部分依赖的例子：
员工表的一个候选键是{id, mobile, deptNo}，而deptName依赖于{deptNo}，同样name仅依赖于{id}，即一行中存在两个依赖，因此不是2NF的。
为了满足第二范式的条件，需要将这个表拆如下四个表：
3）第三范式（3NF）
第三范式要同时满足下面两个条件：
例如，员工表的province、city、district依赖于zip，而zip依赖于（员工）id，换句话说，province、city、district传递依赖于（员工）id，违反了3NF规则。
为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表，如下图：
把传递依赖的这几列放到一起，进一步减少数据冗余。
在关系数据模型设计中，一般需要满足第三范式的要求。
三范式要有一定的度
四. 关系数据模型与数据仓库
关系数据模型可以提供高性能的数据更新操作，能很好地满足事务型系统的需求，这点毋庸置疑。但是对于查询与分析密集型的数据仓库系统还是否合适呢？
对这个问题的争论由来已久，基本可以分为Inmon和Kimball两大阵营，Inmon阵营是应用关系数据模型构建数据仓库的支持者。
Inmon方法是以下面这些假设的成立为前提的:
基于这些假设，使用关系数据模型构建数据仓库的优势和必然性就比较明显了。
参考：《Hadoop构建数据仓库实战》