数据库里那些表到底咋联系的，关系模型基础知识简单聊聊

开始）

咱们先从一个最生活化的例子说起，想象一下，你是一个小卖部的老板，你要记账，最开始，你可能就拿个本子，来一个顾客买一样东西，你就记一行：日期，顾客名，商品名，数量，单价,总价。

记了几天，你发现问题了，老顾客“张三”天天来，你每次都得写一遍“张三”这个名字，万一有一次写成了“张山”，以后统计张三总共买了多少钱就麻烦了，还有，“可口可乐”这个商品，你也反复写，价格要是变了，你得把所有记过旧价格的地方都改一遍,这太容易出错了。

这时候，你就需要一个更聪明的记账方法，这个方法的核心思想就是“关系模型”，而那个聪明的“本子”，数据库”，关系模型是几十年前一位叫埃德加·科德的人提出的，他写了一篇非常重要的论文《大型共享数据库的关系模型》,彻底改变了数据管理的方式。

那怎么解决我们小卖部记账的麻烦呢？答案就是：分表。

你别用一个本子记所有事了，你准备三个本子（也就是三张表）：

第一个本子，叫【商品表】。 这个本子只关心商品本身,每一页只记录一种商品的信息，

• 商品编号（给每个商品一个唯一的数字ID，比如可乐是001,雪碧是002）
• 商品名称
• 商品价格

第二个本子，叫【顾客表】。 这个本子只关心顾客,每一页只记录一个顾客的信息，

• 顾客编号（给每个顾客一个唯一的ID，比如张三是1001,李四是1002）
• 顾客姓名
• 顾客电话

第三个本子，叫【订单表】。 这个本子只关心“谁在什么时候买了什么”这件事,它里面这样记：

• 订单编号（每个订单一个唯一号）
• 日期
• 顾客编号（注意，这里不写顾客名字了,只写他在顾客表里的编号1001）
• 商品编号（这里也不写商品名字了,只写商品表里的编号001）
• 购买数量

你看，这样一分,好处立刻就出来了：

1. 数据不重复、不会错：顾客“张三”的名字和电话，只在顾客表里存了唯一的一份，订单表里只用编号1001来指代他，你再也不会把张三的名字写错了，因为他名字只在一个地方存在，商品价格也一样，改价格只需要去商品表里改一次，所有通过商品编号001引用它的订单,自然就相当于用了新价格。
2. 管理方便：你想查所有商品信息，就翻商品表；想查所有顾客信息，就翻顾客表,非常清晰。

这三个本子（表）是怎么“联系”起来的呢？这就是最关键的部分：关系。

在订单表里，有两个非常重要的列：“顾客编号”和“商品编号”，这两个列，就像两根“绳子”：

• 订单表里的“顾客编号”这根绳子，拉拽着顾客表里的“顾客编号”，通过这根绳子，你就能从一笔订单，找到是哪个顾客买的，你在订单表里看到顾客编号是1001，你就可以去顾客表里找到编号为1001的那一页，一看，哦,原来是张三买的。
• 同样，订单表里的“商品编号”这根绳子，拉拽着商品表里的“商品编号”，通过它,你就能知道这笔订单买的是可口可乐还是雪碧。

这种“拉拽”的关系，在数据库里有个专门的名字，叫做“外键”，简单理解就是：一张表（订单表）里的某个字段（顾客编号），是另一张表（顾客表）里的“主键”（就是那个唯一编号）,外键就是用来建立表与表之间联系的桥梁。

这种关系通常有三种类型：

1. 一对一：比如一个公司只有一个CEO，一个CEO也只属于一个公司，这种情况可以放在一张表里，但有时候为了安全隔离等原因，也会分成两张表，通过“公司编号”或“CEO工号”来联系,这种比较少见。
2. 一对多：这是我们例子中最常见的关系。一个顾客可以对应多笔订单（张三今天买可乐，明天买雪碧），但一笔订单只能属于一个顾客（一笔订单不会同时是张三和李四的），顾客表（一方）和订单表（多方）就是典型的“一对多”关系，外键建在“多”的这一方,也就是订单表里。
3. 多对多：这个稍微复杂点，一个订单里可以包含多种商品（张三一次买了可乐、雪碧和薯片），而同一种商品（可乐）又可以被包含在多个不同的订单里，这就是“多对多”关系，处理这种情况，光靠两张表不行了，需要一张额外的、专门的“中间表”（也叫关联表）来记录这种关系，这个中间表可能就叫【订单明细表】，里面记录订单编号、商品编号、以及该商品在本订单中的购买数量，这样，通过中间表，就把“订单”和“商品”之间的“多对多”关系，拆解成了两个“一对多”关系。

数据库里的表，就像是把现实世界中杂乱的信息，分门别类地放进不同的抽屉（表），这些抽屉不是孤立的，而是通过一些编号（主键和外键）巧妙地串联起来，当你需要复杂信息时（列出张三买过的所有商品名称和总金额”），数据库就能沿着这些“关系链”，从顾客表找到订单表，再从订单表找到商品表，把数据像拼图一样组合起来给你看，这就是关系模型的核心魅力：用分解和关联的方法，既保证了数据的一致性和准确性，又提供了强大的数据组合查询能力。 结束）