关系模型的主要概念和规范

大家好,我是一家小报的老板，我们公司主要的业务是找水军给明星洗白或者应他们的要求给他们的竞争对手抹黑。同时我们也是一家科技公司,对于数据仓库技术比较感兴趣。

最近我们接到几个单子，公司一个新员工使用以下格式将其存到数据库的一张表中：

明星事件记录

我一看就知道他想要用关系模型来存储这些数据，在关系模型中，数据的载体叫做关系数据库，数据库由表组成，一张表代表着一种关系，由行和列组成的二维结构。其中一行就是一个元组，一个元组由若干的属性组成，每一个属性对应数据库中的一个列，每一个属性又由属性名和类型组成，属性的取值范围叫做数据域。也就是：

关系模型

能够唯一标致一行的列或者列集合叫做超键，列的个数不限，所以上面（明星姓名，明星事件，水军公司，服务类型，明星身份证）是一个超键，反正列数不限，这一行所有的列也算一个超键，流不流氓，惊不惊喜。

能够唯一标致一行的最小列或列集叫做候选键，这里限制个数了，我们这个表主要是讲谁解决明星什么问题的，候选键为（明星姓名，明星事件，服务类型，水军公司）

主键是唯一的候选键，我们这个表只有一个候选键，所以他就可以是主键，如果有多个候选键，只能选择其中一个作为主键，主键是唯一的。

如果有另外一个表，候选键是身份证，那么本表的身份证就可以是他的外键。外键指可以匹配其他表中候选键的列或列集。

但是仔细看了一下这张表后，我就把新员工叫过来骂了一顿，我问他，kris先生最近天天被黑，young og事件肯定还得找我们洗白，按照他的秉性，我们还会长期合作，我问你，你这么存岂不是每一次他找我们你都要把他的个人信息存一份，你到底学没学过三范式？然后手把手教他使用三范式改造了这张表。

第一范式：表中的列只能含有原子性（不可再分）的值

也就是每个属性的值不可再分，也就是一行中某一列的值即不可以再分成多个行，也不可以再拆分成多个列，这个表示满足的，做的不错。

第二范式：满足第一范式，且任何一列都与表的候选键有完全关系

也就是说，非候选键的部分要完全依赖候选键所有的列，而不是只依赖候选键中的一部分列。我们先看这个表的候选键，候选键已经确定了，其他列我们一个一个看

明星性别只跟明星姓名有关系身份证也只跟姓名有关系工作难度全部列有关系收费跟全部列有关系水军公司跟全部列有关系水军首领只跟水军公司有关系

所以明星性别，身份证，水军首领不应该出现在这个表中

因为第一范式就已经不满足了，所以就不用看第三范式了，我们先对表进行改造

更改后的表如下：

改造后的表已经满足第二范式了，我们再看一下第三范式

第三范式：满足第二范式，表中的每一列必须与候选键直接相关

以上三张表都没有问题，所以改造后的表满足第三范式

新员工五体投地，对我说，给大爷跪了。

话音刚落，警察进来我被带走了，所以你们现在才会听到那么多diss kris的歌。

关系模型的优势

关系模型是Inmon老爷子提出的，在上一篇文章《大话数仓 之 数仓架构》中我们提到，从属数据集市架构加入三范式的规范就成了Inmon数仓架构，这里的关系模型，就是为Inmon数仓服务的，所以它必须满足三范式，否则并不能真正称为关系模型。

那么关系模型有什么好处呢？

关系模型利用三范式的规范将关系拆分为一个一个的实体，每个表表征一个实体，比如说上面三个表分别代表 水军公司处理明星事件实体，明星实体特征实体，水军公司特征实体。通过将数据实体化，可以减少数据冗余（因为每个表关系单一，表之间的关系明确）。增强扩展性（实体可以自由增加，关联关系可以自由改变），因为扩展性增强了，所以稳定性也相应的增强（能够适应不停变化的需求）