项目开发中,在进行数据库表结构设计时,会根据业务需求及业务模块之间的关系,分析并设计表结构。由于业务之间相互关联,所以各个表结构之间也存在着各种联系。
多表关系:
一对多(多对一) 一对一 多对多
多表关系
一对多
-
场景:部门与员工的关系(一个部门下有多个员工)。
-
部门管理的页面原型:
-
员工管理的页面原型:
由于一个部门下,会关联多个员工。 而一个员工,是归属于某一个部门的 。那么此时,我们就需要在 emp
表中增加一个字段 dept_id
来标识这个员工属于哪一个部门,dept_id
关联的是 dept
的 id
。 如下所示:
上述的 emp
员工表的 dept_id
字段,关联的是 dept
部门表的 id
。部门表是一的一方,也称为父表,员工表是多的一方,称之为子表。
问题:一对多的表关系,在数据库层面该如何实现 ?
在数据库表中多的一方,添加字段,来关联一的一方的主键 。
多表问题分析
问题
表结构创建完毕后,我们看到两张表的数据分别为:
我们看到,在3号部门下,是关联的有7个员工。 当删除了3号部门后,数据变为:
3号部门被删除了,但是依然还有7个员工是属于3号部门的。 此时:就出现数据的不完整、不一致了。
分析
可以在创建表时或表结构创建完成后,为字段添加外键约束。 具体语法如下:
-- 创建表时指定
create table 表名(字段名 数据类型,...[constraint] [外键名称] foreign key (外键字段名) references 主表 (字段名)
);
-- 建完表后,添加外键
alter table 表名 add constraint 外键名称 foreign key (外键字段名) references 主表(字段名);
也可以直接在图形化界面工具中设置,更简单。
具体的例子:
解决方式1:通过SQL语句操作
-- 修改表: 添加外键约束
alter table emp add constraint fk_dept_id foreign key (dept_id) references dept(id);
解决方式2:图形化界面操作
在左侧菜单栏,在emp表上右键,选择 modify Table... (old UI)
当我们添加了外键之后,再删除ID为3的部门,就会发现,此时数据库报错了,不允许删除。
外键约束(foreign key):保证了数据的完整性和一致性。
外键约束:让两张表的数据建立连接,保证数据的一致性和完整性。
对应的关键字:foreign key
物理外键与逻辑外键
-
物理外键
-
逻辑外键
-
概念:在业务层逻辑中,解决外键关联。
-
通过逻辑外键,就可以很方便的解决上述问题。
-
在现在的企业开发中,很少会使用物理外键,都是使用逻辑外键。 甚至在一些数据库开发规范中,会明确指出禁止使用物理外键 foreign key
一对一
一对一关系表在实际开发中应用起来比较简单,通常是用来做单表的拆分,也就是将一张大表拆分成两张小表,将大表中的一些基础字段放在一张表当中,将其他的字段放在另外一张表当中,以此来提高数据的操作效率。
一对一的应用场景: 用户表(基本信息+身份信息)
-
基本信息:用户的ID、姓名、性别、手机号、学历
-
身份信息:民族、生日、身份证号、身份证签发机关,身份证的有效期(开始时间、结束时间)
如果在业务系统当中,对用户的基本信息查询频率特别的高,但是对于用户的身份信息查询频率很低,此时出于提高查询效率的考虑,我就可以将这张大表拆分成两张小表,第一张表存放的是用户的基本信息,而第二张表存放的就是用户的身份信息。他们两者之间一对一的关系,一个用户只能对应一个身份证,而一个身份证也只能关联一个用户。
那么在数据库层面怎么去体现上述两者之间是一对一的关系呢?
其实一对一我们可以看成一种特殊的一对多。一对多我们是怎么设计表关系的?是不是在多的一方添加外键。同样我们也可以通过外键来体现一对一之间的关系,我们只需要在任意一方来添加一个外键就可以了。
一对一 :一对一,其实是一种特殊的一对多。在任意一方添加外键,关联另外一方的主键,
并且设置外键为唯一的(UNIQUE)
多对多
多对多的关系在开发中属于也比较常见的。比如:学生和老师的关系,一个学生可以有多个授课老师,一个授课老师也可以有多个学生。在比如:学生和课程的关系,一个学生可以选修多门课程,一个课程也可以供多个学生选修。
案例:学生与课程的关系
关系:一个学生可以选修多门课程,一门课程也可以供多个学生选择
实现关系:建立第三张中间表,中间表至少包含两个外键,分别关联两方主键
数据库中如何体现多对多的表关系?
多对多 :需要建立一张中间表,中间表中有两个外键字段,分别关联两方的主键。