关系模型被广泛应用于数据处理和数据存储，尤其是在数据库领域，现在主流的数据库管理系统几乎都是以关系数据模型为基础实现的。
关系数据模型基于关系这一数学概念。接下来解释关系数据模型中的术语和相关概念。
我们使用一个分公司-员工关系的例子。假设有一个大型公司在全国都有分公司，每个员工属于一个分公司，一个分公司有一个经理。
由行和列构成的二维结构，对应关系数据库中的表，如分公司表和员工表。
注意，这种认识只是我们从逻辑上看待关系模型的方式，并不应用于表在磁盘上的物理结构。表的物理存储结构可以是堆文件、索引文件或哈希文件。
- 堆文件是一个无序的数据集合
- 索引文件中表数据的物理存储顺序和逻辑顺序保持一致
- 哈希文件也称为直接存取文件，是通过一个预先定义好的哈希函数确定数据的物理存储位置
由属性名称和类型名称构成的顺序对。对应关系数据库中表的列，如地址（Variable Characters）是公司表的一个属性。
在关系数据模型中，我们把关系描述为表，表中的行对应不同的记录，表中的列对应不同的属性。
属性可以以任何顺序出现，而关系保持不变，也就是说，在关系理论中，表中的列是没有顺序的。
表示属性的取值范围。每一个属性都有一个预定义的值的范围。域描述了属性所有可能的值。
如下表列出了分公司-员工关系的一些属性域。
关系中的一条记录，对应关系数据库中的一个表行。
元组可以以任何顺序出现，而关系保持不变，也就是说，在关系理论中，表中的行是没有顺序的。
一系列规范化的表的集合。
关系表有如下属性：
● 每个表都有唯一的名称。
● 一个表中每个列有不同的名字。
● 一个列的值来自于相同的属性域。
● 列是无序的。● 行是无序的。
1）超键
一个列或者列集，唯一标识表中的一条记录。
2）候选键 ing
仅包含唯一标识记录所必需的最小数量列的超键。 表的候选键有三个属性：
● 唯一性：在每条记录中，候选键的值唯一标识该记录。
● 最小性：具有唯一性属性的超键的最小子集。?
● 非空性：候选键的值不允许为空。
在我们的例子中，分公司表编号是候选键，如果每个分公司的邮编都不同，那么邮编也可以作为分公司表的候选键。一个表中允许有多个候选键。
3）主键
唯一标识表中记录的候选键。主键是唯一、非空的。没有被选为主键的候选键称为备用键。
对于例子中的分公司表，分公司编号是主键，邮编就是备用键，而员工表的主键是员工编号。
主键的选择在关系数据模型中非常重要，很多性能问题都是由于主键选择不当引起的。
在选择主键时，我们可以参考以下原则：
- 主键要尽可能地小。
- 主键值不应该被改变。主键会被其他表所引用。如果改变了主键的值，所有引用该主键的值都需要修改，否则引用就是无效的。
- 主键通常使用数字类型。数字类型的主键要比其他数据类型效率更高。
- 主键应该是没有业务含义的，它不应包含实际的业务信息。**无意义的数字列不需要修改，因此是主键的理想选择。**大部分关系型数据库支持的自增属性或序列对象更适合当作主键。
- 虽然主键允许由多列组成，但应该使用尽可能少的列，最好是单列。
4）外键
一个表中的一个列或多个列的集合，这些列匹配某些其他（也可以是同一个）表中的候选键。
注意外键所引用的不一定是主键，但一定是候选键。
当一列出现在两张表中的时候，它通常代表两张表记录之间的关系。
如：分公司表的分公司编号和员工表的所属分公司。它们的名字虽然不同，但却是同一含义。
分公司表的分公司编号是主键，在员工表里所属分公司是外键。
所以主键所在的表被称为父表，外键所在的表被称为子表。
关系数据模型有两个重要的完整性规则：实体完整性和参照完整性。在定义这些术语之前，先要理解空值的概念。
表示一个列的值目前还不知道或者对于当前记录来说不可用。
空值是处理不完整数据或异常数据的一种方式。空值与数字零或者空字符串不同，零和空字符串是值，但空值代表没有值。因此，空值应该与其他值区别对待。
空值具有特殊性，当它参与逻辑运算时，结果取决于真值表。Oracle的非、与、或逻辑运算真值表。
举例，如果一个分公司的经理离职了，新的经理还没有上任，此时公司经理列对应的值就是空值。
1）实体完整性
在一个基本表中，主键列的取值不能为空。
基本表指命名的表（就是一般我们定义的表），记录物理地存储在数据库中，与之对应的是视图。
视图是虚拟的表，它只是一个查询语句的逻辑定义，其中并没有物理存储数据。
2）参照完整性
如果表中存在外键，则外键值必须与主表中的某些记录的候选键值相同，否则外键的值必须为空。
如：员工表中的所属分公司是外键。该列的值要么是分公司表的分公司编号列中的值，要么是空（如新员工已经加入了公司，但还没有被分派到某个具体的分公司时）。
业务规则的例子包括属性域和关系完整性规则。属性域用于约束特定列能够取的值。
- DDL是Data Definition Language的缩写，意为数据定义语言，用于定义数据库结构和模式。典型的DDL有create、alter、drop、truncate、comment、rename等。
- DML是Data Manipulation Language的缩写，意为数据操纵语言，用于检索、管理和维护数据库对象。典型的DML有select、insert、update、delete、merge、call、explain、lock等。
- DCL是Data Control Language的缩写，意为数据控制语言，用于授予和回收数据库对象上的权限。典型的DCL有grant和revoke。
- TCL是Transaction Control Language的缩写，意为事务控制语言，用于管理DML对数据的改变。它允许一组DML语句联合成一个逻辑事务。典型的TCL有commit、rollback、savepoint、set transaction等。
关系数据模型的规范化是一种组织数据的技术。规范化方法对表进行分解，以消除数据冗余，避免异常更新，提高数据完整性。
先看一个不规范化的例子：
- 修改异常：上表中张三有两条记录，因为他隶属两个部门。如果我们要修改张三的地址，必须修改两行记录。假如一个部门得到了张三的新地址并进行了更新，而另一个部门没有，那么此时张三在表中会存在两个不同的地址，导致了数据不一致。
- 新增异常：假如一个新员工加入公司，他正处于入职培训阶段，还没有被正式分配到某个部门，如果deptNo字段不允许为空，我们就无法向employee表中新增该员工的数据。
- 删除异常：假设公司撤销了D3这个部门，那么**在删除deptNo为D3的行时，会将李四的信息也一并删除。**因为他只隶属于D3这一个部门。
规范化是通过应用范式规则实现的。最常用的范式有第一范式（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两个表，如下图：
把传递依赖的这几列放到一起，进一步减少数据冗余。
在关系数据模型设计中，一般需要满足第三范式的要求。
满足3NF的表，重点在于一个表良好的主外键设计。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。
三范式要有一定的度
我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。而如果连接的表过多，会影响查询的性能。
关键的问题是要依据业务需求，仔细权衡数据查询和数据更新的关系，制定最适合的规范化程度。
还有一点需要注意的是，不要为了遵循严格的规范化规则而修改业务需求。
关系数据模型可以提供高性能的数据更新操作，能很好地满足事务型系统的需求，这点毋庸置疑。但是对于查询与分析密集型的数据仓库系统还是否合适呢？
对这个问题的争论由来已久，基本可以分为Inmon和Kimball两大阵营，Inmon阵营是应用关系数据模型构建数据仓库的支持者。
Inmon方法是以下面这些假设的成立为前提的:
- 假设数据仓库是以企业为中心的，初始的数据能够为所有部门所使用。而最终的数据分析能力是在部门级别体现，需要使用数据集市对数据仓库中的数据做进一步处理，以便为特定的部门定制它们。
- 数据仓库中的数据不违反组织制定的任何业务规则。
- 必须尽可能快地把新数据装载进数据仓库，这意味着需要简化数据装载过程或减少数据的装载量。
- 数据仓库的建立必须从一开始就被设计成支持多种BI技术，这就要求数据仓库本身所使用的技术越通用越好。
- 假设数据仓库的需求一定会发生变化。它必须能完美地适应其数据和数据结构的变化。
基于这些假设，使用关系数据模型构建数据仓库的优势和必然性就比较明显了。
1．非冗余性
数据冗余越少，需要装载的数据量就越少，装载过程就越快。数据仓库的数据源一般是事务型系统，这些系统通常是规范化设计的。如果数据仓库使用相同的数据模型，意味着数据转换的复杂性可能会降低，同样可以加快数据装载速度。
2．稳定性
由于数据仓库的需求会不断变化，我们需要以一种迭代的方式建立数据仓库。
关系数据模型的通用性
众所周知，组织中最经常变化的是它的处理过程、应用和技术，如果依赖于这三个因素中的任何一个建立数据模型，当它们发生改变时，肯定要对数据模型进行彻底修改。为了避免这个问题，关系数据模型的通用性正是用武之地。
变化合并ing(how)
另一方面，由于变化不可避免，数据仓库模型应该能比较容易地将新的变化合并进来，而不必重新设计已有的元素和已经实现的实体。
3．一致性
数据仓库模型最本质的特点是保证作为组织最重要资源的数据的一致性，而确保数据一致性正是关系数据模型的特点之一。
4．灵活性
该模型支持由组织制定的政策和约定的规则，同时为数据集市分析数据提供了更多的灵活性，使得数据库存储以及数据装载方面也是最有效的。当然，关系数据模型的缺点也很明显，它需要额外建立数据集市的存储区，并增加相应的数据装载过程。
参考：《Hadoop构建数据仓库实战》
