数据库设计关系表以承载“数据建模”的“数据结构”部分。
数据建模的第二部分是“数据操作”。 即库存和流量业务数据的各种业务处理和保存。
这一部分曾受到存储过程和数据库本身功能的限制，如自定义函数、存储过程等。 随着程序越来越复杂，在工业界的实践中，“数据操作”这一部分已经从数据库系统中剥离出来，并通过程序来实现。 实际上，一些数据结构是为了以配置文件的形式存在而剥离的。
因此，“数据结构”的设计必须结合“数据操作”的程序实现方式，并不遵循完全归一化的规定。
范式是什么？ (normal form )是一种规范的模式，是一些要求和建议的规则，一般这样做是最合理的。 当然也有别的理由。 范式不是必须实现的标准。 操作数据的过程不同，随着世界的发展，数据结构的设计也必然会变得多种多样。
但是，在关系数据建模中，有一些是不变的。 那就是无视所有业务的详细情况和操作要求，
1、表都是实体的集合
2、实体有唯一标识
3、实体之间存在联系，联系通过关系表示
关于关系，只有三种就可以充分表达。 即一：一、一：多、多：多
到目前为止，我明白了关系表的含义，只有这三种关系才能清楚地表示所有的表数据结构。
那么，这三种关系如何在关系数据库中实现？
想法很简单，就是把主键当成一个维度。 通过维创建坐标系来表示点。
在本文的示例中，员工ID是主键。 所以员工表是一维空间。 部门ID是主键，部门表也是维空间。 员工和部门在各自的一维空间中独立存在。 此时无关紧要。
如果存在关系，为了简单起见，假设这两个主键所表示的字段位于同一个表： '员工部门'的表中。
(通过中间实体的间接关联情况基于单纯的进化，但这里只考虑基本模型)
考虑最简单的情况，员工ID部门ID构成联合主键。
此时，由于该表是二维空间，所以可以看出表现的关系是多：多的关系。
那么，如何表示一)多关系？
首先必须确定1，所以这个空间必须是一维空间。
假设是员工空间，则员工ID是唯一的主键。 此时，部门ID作为一个属性介入这个世界，可以看到有无数平行的员工ID维度，员工实体通过提升维度散落在这些平行线上。 但是，当投影到特定“员工ID”维的联机时，这些员工实体不匹配。
这样，实现了一：多的关系。
也就是说同一个部门(请注意这里的表达。 这里的一个是部门。 )此维线上有许多员工ID实体。
部门ID不必是外部主键。 也就是说，不是必须有部门表。 因此，这里的部门ID可以更改部门的名称。
到目前为止，关系只是数量层面的现象，实际的制约是结合业务正确解释。
由于存在原始员工表和冗馀模式，因此这种方法通常会收敛于在员工表中嵌入部门ID。
对于一对一的关系，基于一对多，只需要要求多字段的属性为unique。
当然，unique也可以用程序控制。 使用程序也是一般的表现。
原始员工表和现有的关系表对员工来说也是一对一的关系。 但是，这种关系是用数据表示的，也就是说，是由程序保证的。 同样的情况下，还有表格的垂直分割。
回到问题吧。
1、两种方案都可以体现员工与部门的关系。
2、方案1在数据关系方面，只是一对多。
3、方案2在数据关系中，其实是多对多。 应对了一对多的情况。
因此，方案2的可扩展性必须明显加强。 在这里不能通过范式或反向范式得出结论。 因为部门和员工的关系，以后可能真的会多对多。 另外，由于程序中的数据操作也表达了数据关系，所以只靠数据表的结构，不能简单地得到逆范式的结论。
另外，考虑性能时，有时也需要反模式。
例如，如果员工部门的表是独立的，也可以进行表缓存，并进一步加载到缓存数据库中。 这样，员工登录时，系统可以根据部门情况快速确定权限。 如果员工表非常大，每次执行相关查询无疑增加了数据库的压力。 这是常见的空间交换方式。
在IT系统服务中，快确实是件好事。