数据库设计关联关系表的意义是什么？

概述数据库设计关联关系表，目的是承载"数据建模"的"数据结构"部分。 "数据建模"的第二个部分，是"数据 *** 作"。即对存量和流

数据库设计关联关系表，目的是承载"数据建模"的"数据结构"部分。

"数据建模"的第二个部分，是"数据 *** 作"。即对存量和流量业务数据的各种业务处理和存储。

这部分早期是通过存储过程以及数据库自身的功能来约束，比如,自定义函数，存储过程等。随着程序越来越复杂，在工业界实践中，"数据 *** 作"这部分逐渐从数据库系统中剥离，通过程序来实现。

实际上，有些数据结构，甚至也剥离出来通过配置文件的形式存在了。

所以，"数据结构"的设计，必须结合"数据 *** 作"的程序实现方式，不是完全按照范式的规定来的。

范式是什么？(normal form),就是规范化的样式，是一些要求和建议性的规则，俗话就是这样做最合理。

当然也有别的理。范式不是必须实现的标准。随着 *** 作数据的程序各异和世界的发展，数据结构的设计也必然多种多样。

但是，在关系数据建模中，有一些是不变的。那就是，抛开所有的业务细节和 *** 作要求，

1，表都是实体的集合

2，实体有唯一标识

3，实体之间是有联系的，而联系通过关系表示

对于关系，只有三种就可以充分表达。即  一：一，一：多，多：多

至此，我们就明白关系表的意义就是，仅通过这3种关系，就可清晰的表示所有的表数据结构。

那么这三种关系，是如何在关系数据库中实现的？

思路很简单，就是将主键，当做一个维度。通过维度建立坐标系来表示点。

在本文的例子中，员工ID是个主键。所以员工表是个一维空间。部门ID是个主键，部门表也是个以维空间。员工和部门，在各自的一维空间中独立存在。此时是没有关系存在的。

如果要有关系，这两个主键所代表的字段，为简单起见，假设出现在同一个表:"员工+部门"表中。

(通过中间实体间接关联情况，是基于简单的演变，这里只考虑基本模式)

考虑最简单情况，员工ID+部门ID构成联合主键。

可见，此时该表是个二维空间，所以表达的关系是个多：多的关系。

那么如何表示一：多关系？

首先必须确定一，因此这个空间必须是个一维空间。

假设是员工空间，那么员工ID就是唯一的主键。此时，部门ID作为一个属性介入这个世界，可以看做有无数个平行的员工ID维度线，而员工实体，就通过升维散落到这些平行线上。但这些员工实体，投影到某个具体的员工ID维度线上时，又是不重合的。

这样，就实现了一：多的关系。

即同一个部门(注意这里的表达，这里的一是部门)，在这个维度线上，有很多个员工ID实体。

可想而知，部门ID，不必须是外部主键。也就是说，不是必须有个部门表。因此这里的部门ID,完全可以换位部门的名称。

至此知道，关系仅仅是数量层面的一种现象，实际的约束是要结合业务才能正确解释。

这种做法，和原来的员工表有冗余模式，因此通常就收敛到在员工表中，嵌入部门ID的方式。

至于一：一的关系，只需要在一：多的基础上，要求多字段的属性为unique即可。

当然unique,也可通过程序来控制。用程序也是一种很常见的表示方式。

至于原来的员工表，和现有的关系表，对于员工来说，也是个一对一关系。但这种关系，是通过数据来表达，也就是程序来保证的。同样的情况还有表的垂直切分。

下面回到问题上来。

1，两种方案都可以表达员工和部门的关系。

2，方案1，在数据关系上，仅仅是一对多。

3，方案2，在数据关系上，其实是多对多。兼容了一对多的情况。

因此，方案2的扩展性显然要更加强。这里不能用范式或反范式来下结论。因为部门和员工的关系，可能以后真的就成了多对多。何况还有程序中的数据 *** 作也表达了数据关系，因此仅仅通过数据表的结构，不能简单的得到反范式的结论。

更进一步，在考虑到性能时，有时反范式也是需要的。

比如员工部门表独立出来，可以进行表缓存，甚至进一步加载到缓存数据库中。这样员工登录时，系统可快速根据部门情况决定其权限。如果员工表非常大，每次都要进行关联查询无疑是增加了数据库的压力。这是常见的空间换时间的打法。

 

 

总结

以上是内存溢出为你收集整理的数据库设计关联关系表的意义是什么？全部内容，希望文章能够帮你解决数据库设计关联关系表的意义是什么？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。