文章目录
一. 关系数据模型中的结构
关系数据模型基于关系这一数学概念。接下来解释关系数据模型中的术语和相关概念。
我们使用一个分公司-员工关系的例子。假设有一个大型公司在全国都有分公司,每个员工属于一个分公司,一个分公司有一个经理。
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构建数据仓库实战》