ER模型和表记录的四种关系

首先我们来说一下关系型数据库的设计规则

• 关系型数据库的典型数据结构就是数据表,这些数据表的组成都是结构化的(Structured)
• 将数据放到表中,表再放到库(数据库)中
• 一个数据库中可以有多个表,每个表都有一个名字,用来标识自己,表名具有唯一性
  • 我们可以这样想,如果一个库中有两个重名的表,那么这个时候这两个表就不能区分了
• 表具有一些特性,这些特性定义了数据在表中是如何存储的,类似于java和Python中的"类"的设计

表与表之间的关系由E - R模型来刻画

• E - R模型中有三个重要的概念: 实体集 ,属性 , 联系集
  • 这里的E - R模型就是entity - relationship模型,也就是 实体 - 联系 模型
  • 一个实体集(class)对应于数据库中的一个表(table),一个实体(Instance)则对应了数据库表中的一行(row),也称为一条记录(record),一个属性(attribute)对应了数据库中的一列(column),也称为一个字段(field)
    • 也就是在数据库中: 一行就是一条记录,一列就是一个字段

表的关联关系(也就是表记录的关系)

表与表之间的数据记录有关系,现实世界中的各种联系都可以使用关系模型来表示

表的关联关系一共可以分为以下四种:

1. 一对一关联(one - to - one)
   • 一对一关联在实际编程中的使用场景并不是很多,因为又一对一关系的多张表可以合并为一张表,但是由于实际需求,可能就会出现可以使用一张表,但是就是要将这一张表创建成为多张表的情况
   • eg: 设计学生表 : 学号 : 姓名 : 手机号 : 班级 : 籍贯 : 紧急联系人 : 身份证号
     • 上面这样的一张学生表我们就可以将其拆成两张表,那么拆分之后的这两张表的记录就是一 一对应的关系,那么我们就可以说这两张表示一对一关联的
     • 拆成如下的两张表:
       • 基础信息表(常用信息) : 学号 , 姓名 , 手机号 , 班级
       • 档案信息表(不常用信息) : 学号 , 身份证号 , 籍贯 , 紧急联系人
   • 那么我们为什么要将一张表拆成两张表?
     • 因为在我们实际表查询的过程中可能某个表有30个字段,但是这个时候如果我们的这30个字段中只有3个常用字段,这个时候如果我们要查询这三个常用字段,那么由于我们在关系型数据库中我们只能是一个字段一个字段的去查找,这个时候查询到记录之后就会将这30个字段全部都查询出来,但是这个时候我们只是需要这个记录中的三个字段,那么除了我们要查找的3个字段之外的字段我们都称之为冗余字段,那么这27个冗余字段会一起加载到内存中去,这个时候系统就需要更多的I/O次数,相应的程序的运行效率也就会下降, 那么这个时候我们就可以将这一个表拆分成为两个表(甚至多个表),一个为常用信息表,一个为不常用信息表,这个时候如果我们查询的时候是查询的常用的字段,就可以在常用信息表中找到,这个时候就不需要使用不常用信息表,那么就提升了程序的运行效率

• 这里我们还有两种一对一关联情况下的建表规则,我们会在约束中讲到

2. 一对多关联(one - to - many)

   • 常见的实际使用场景: 客户表和订单表, 分类表和商品表 , 部门表和员工表

   • eg: 员工表: 员工编号 , 姓名 , … , 所属部门

     ​ 部门表 : 部门标号 , 名称 , … , 简介

• 这里我们对于一对多建表规则也是后面再约束中才讲

3. 多对多关联

   • 要表示多对多的关系,我们必须创建第三个表,该表通常称之为:“联接表”, 联接表将多对多关系划分为两个一对多关系,将这两个表的主键都插入到第三个表中去(也就是插入到我们的联接表中去)

   • eg: 学生信息表 : 一行代表一个学生的信息(学号 , 姓名 , …)

     ​ 课程信息表 : 一行代表一个课程的信息(课程编号 …)
     ​ 选课信息表 : 一个学生可以选多门课,同样的一门课也可以被多名学生选择

     ​

4. 自我引用关系

   • eg: 员工编号 姓名 部门编号 主管编号

     ​ 101 飞飞 30 NULL

     ​ 103 喵喵 30 101

   • 主管也是一个员工,这种情况也称之为自我引用