避免数据发散（数据建模-USS）

对两张或多张表进行连接时，由于多数情况下连接字段并非都是主键，因而实际连接时往往不是一对一（one-to-one）的，而通常是多对一（many-to-one）甚至多对多（many-to-many）的。多对一只会导致副表出现数据发散，而多对多会导致主副两张表同时出现数据发散。

在传统的数据处理模式下，除非有特殊需要，一般也都会尽量避免出现多对多的连接情况，因而多对一是大多数场景下的情况

不过由于非度量数据（比如维度字段）在数据分析中通常只作为分析维度，在聚合过程中会被分组机制自动去重，因而非度量数据的发散不会导致数据结果有问题。然而度量数据（比如事实字段）作为分析的观测值，聚合过程中没有额外的机制进行甄别去重，若在连接的过程中发散将大概率会导致数据结果出现问题。

因而在多对一的连接情况下，若副表中存在度量数据，那么该度量数据将会出现发散，这也就是 USS 中指出的所谓的“风扇陷阱”（fan trap）。

虽然多对一情况下副表的度量数据发散了，但如果实际的分析需求中并没有用到它们，那么存在这个发散也没有关系，这也是传统数据处理手段中常用左连接的原因（副表只用来取非度量数据）

虽然专业的开发人员都会尽量避免直接的多对多连接方式，但有时候为解决业务需求必须要这样做（比如合并两张事实表比照明细）；或者多对多的情况也可能是意外间接地出现，比如三张表“多·一·多”的连接场景，这也就是 USS 中指出的所谓的“裂缝陷阱”（chasm trap）。

以上各式各样的数据发散“陷阱”都能够被基于桥接表的统一星型模式（USS）所解决，并且还能带来易用、高性能、低维护等附加优点。

避免数据发散（USS）

• 避免“风扇陷阱”（数据建模-USS）
• 关于JSON的“风扇陷阱”（数据建模-USS）
• 避免“裂缝陷阱”（数据建模-USS）
• 关于JSON的“裂缝陷阱”（数据建模-USS）