前言

Martin大叔已经指出短时间内，NoSQL生态系统还不够成熟，无法完全替换关系型数据库。

从DB-Engines上看NoSQL型数据库前10才排入2位(MongoDB,Cassandra，观察时间2014.3)。

跟同事笑谈，为什么关系型数据库还这么有生命力的原因是这个是博士干出来的活儿(Doctor Edgar F. Codd)。

鉴于数据是这么重要，甚至数据的存活时间远远比数据应用程序的生命周期要长的多得多；而现在Java信息应用研发动辄要求会什么ORM框架，说明至少存在关系型数据库的模式迁移问题，而理解模式迁移的本质是理解其深层次的数据模型。

基于此考虑，在深入NoSQL生态系统/ployglot persistence之前，有必要对关系理论做一点知识回顾。

Ref: A First Course in Database Systems, J. D. Ullman, J. Widom.

内容

1 基本概念

2 函数依赖

3 关系模式设计

1 基本概念

粗略的讲，关系是一个二维表，下面是Movies关系示例

Movies

--------------------------------------------

title | year | length | filmType

--------------------------------------------

Star Wars | 1977 | 124 | color

Mighty Ducks | 1991 | 104 | color

Wayne's World | 1992 | 95 | color

--------------------------------------------

属性attribute

关系最上一行是属性

Movies: title, year, length, filmType

模式schema

关系名和其属性集合的组合称为该关系的模式

Movies(title, year, length, filmType)

元组tuple

关系中除含有属性名称所在行的其他行称为元组

(Star Wars, 1977, 124, color)

域domain

关系模式要求元组的每个分量具有原子性，即每个分量必须属于某种元素类型，而不是组合类型

域与关系的每个熟悉感相关联，是一个特殊的元素类型

关系

关系是元组的集合

关系实例instace

一个给定关系中元组的集合称为关系的实例

2 函数依赖(functional dependency, FD)

定义

一个关系R上的函数依赖FD(A1A2...An -> B)，是指如果R的两个元组在A1,A2,...,An上值相同，则它们在其他属性分量B上的值也必定相同，叫做A1,A2,...,An函数决定B。

A1A2...An -> B1B2...Bm是{A1A2...An -> Bi}, i=1...m的简写形式

关系的键

属性集合{A1,A2,...,An}是关系R的键，要求：

(1)这些属性函数决定R的其他属性

(2)不存在{A1,A2,...,An}的真子集能函数决定R的其他属性。

超键superkey

包含键的属性集合称为超键

函数依赖推理规则

Armstrong公理

(1)自反(reflexivity), 平凡FD

如果{B1,B2,...,Bm}是{A1,A2,...,An}的子集，则A1A2...An -> B1B2...Bm

(2)增广(augmentation)

如果A1A2...An -> B1B2...Bm，则A1A2...AnC1C2...Ck -> B1,B2...BmC1C2...Ck，对任意属性集合{C1,C2,...,Ck}均成立

(3)传递(transitivity)

如果A1A2...An -> B1B2...Bm, B1B2...Bm -> C1C2...Ck，则A1A2...An -> C1C2...Ck

闭包closure

FD集合S下属性集合{A1,A2,...,An}的闭包是集合B，每一个满足S中所有FD的关系，也同样满足A1A2...An -> B，B记做{A1,A2,...,An}+

闭包算法

计算FD集合S下属性集合{A1,A2,...,An}的闭包X步骤：

(1)X={A1,A2,...,An}；

(2)在S中查找B1B2...Bm -> C，其中B1,B2,...,Bm在X中，但C不在X中，若找到将C加入X；

(3)重复第(2)步；

(4)当不能添加任何属性时，返回X，算法停止。

闭包算法可以正确的推断一个FD是否能从FD集合S中推断出来。

3 关系模式设计

问题的来源：异常anomaly

关系中含有过多信息时产生的问题叫做异常，基本类型有：

(1)冗余redundancy

信息在多个元组中重复

(2)更新异常

修改需要对多个元组同时进行，一旦遗忘某一元组的更新，会产生过期数据

(3)删除异常

删除某一属性值，会造成其他属性值的丢失

范式(normal form, NF)

(1)第一范式1NF

要求每个元组的各分量是原子值

(2)第二范式2NF

允许关系中存在传递FD，不允许有左边是键真子集的非平凡FD存在。

(3)第三范式3NF

若在关系R中存在非平凡FD A1A2...An -> B，也要么{A1,A2,...,An}是超键，要么B属于某个键。

属于某个键的属性常被称为主属性

(4)Boyce-Codd范式，BCNF

关系R满足BCNF当且仅当：若R中非平凡FD A1A2...An -> B(或A1A2...An -> B1B2...Bm)成立，则{A1,A2,...,An}是超键

将关系分解为BCNF的步骤

找出R中违反BCNF条件的非平凡FD A1A2...An -> B1B2...Bm(尽量往右边加入能由A1,A2,...,An决定的属性)，将A1,A2,...,An, B1,B2,...,Bm组织成关系R'，其他属性依次处理。

(5)第四范式4NF

在R中，如果任一非平凡MVD A1A2...An ->-> B1B2...Bm成立时，都有{A1,A2,...,An}是超键

多值依赖(multivalued dependency, MVD)的定义

R中MVD A1A2...An ->-> B1B2...Bm成立是指，若指定R中属性A的值，则存在一组B中的值，这些值独立于R中既不是A也不是B的属性集合的值。

对于R中每个在A上取值相同的元组x、y，能找到满足下列条件的元组z：

1)在A属性上取值与x、y相同；

2)在B属性上取值与x相同；

3)在不同于A和B的其他所有属性上与y相同。

As Bs other

---------------------

x | a1 | b1 | c1

---------------------

|| ||

---------------------

z | a1 | b1 | c2

---------------------

|| ||

---------------------

y | a1 | b1 | c2

---------------------

MVD推理规则

1)平凡依赖规则

如果关系R中存在MVD A1A2...An ->-> B1B2...Bm，则A1A2...An ->-> C1C2...Ck也存在，其中C是B中属性与A中(一个或多个)属性的并；

移走B中属于A的属性也成立。

2)传递规则

如果关系R中存在MVD A1A2...An ->-> B1B2...Bm, B1B2...Bm ->-> C1C2...Ck，则A1A2...An ->-> C1C2...Ck也成立

MVD不遵循分解规则,即关系R中存在A ->-> B C，A ->-> B或A ->-> C不一定存在。

ITPub博客

[NoSQL技术相关]关系数据模型