codeforeasier的博客

图中填充红色的部分标识是新加的列，尤其是桥接表中 Sales 的红色部分相当于是给原有模型添加了额外的两条连接（Sales直连Countries和ProductLines），这样做有利于多粒度的分析（另见〖上图中的后两个转换手段则是 USS 对 Targets 表与 Clients、Products 两维表连接的解决办法，即使用所谓的。这样最终得到的模型方案能够同时用于解决多种需求，不管是跨表的联合分析，还是不同粒度的分析需求，都能由这一个模型解决。蓝色的部分则标识是合并已有列生成的技术列（单一外键）。

的数据仓库中，一张维表被多张事实表所引用（有外键）是十分普遍的情况，这是合理的因为维度共用说明维度一致，这是数据仓库具备整合性的核心。图中虽然看上去只有 5 条连接线，但这个中心幅射结构实际一共暗藏着 10 条线（C₅²），可以满足所有可能的取数需求，并且还不存在两可路径。对范围内的表绘制分析模型图（设计数据模型）的过程，正是选择连接路径的过程，如果有两可路径存在，就可能出现不同用户设计的数据模型不同。多条可选路径的存在的负面影响，一是维护难度增加（不同用户可能选择不同路径），二是。

当然，这样的模型图不一定都是呈树形结构的，其中也可能有小闭环的出现（比如图中的 OrderDetails 也可能还存在直接指向 Categories 的箭头）。“两张表之间只有唯一的一条路径”意味着两张表之间只有唯一的连接方式，这样就无须担心选择了错误的连接方式并且保证了结果的唯一性，因为两可的连接方式可能会导致意想不到的不一致的结果的出现。当然，存在闭环不意味着就要从物理表的层面去消除闭环（比如删除其中一张表的外键），这种做法可能会导致信息丢失，况且多路径本身有用的，是可用于校验数据、提升分析性能的。

【代码】关于JSON的“裂缝陷阱”（数据建模-USS）

对两张或多张表进行连接时，由于多数情况下连接字段并非都是主键，因而实际连接时往往不是（one-to-one）的，而通常是（many-to-one）甚至（many-to-many）的。多对一只会导致出现数据发散，而多对多会导致同时出现数据发散。在传统的数据处理模式下，除非有特殊需要，一般也都会尽量避免出现多对多的连接情况，因而多对一是大多数场景下的情况不过由于（比如维度字段）在数据分析中通常只作为分析维度，在聚合过程中会被分组机制自动去重，因而非度量数据的发散不会导致数据结果有问题。然而。

有的业务需求需要联合使用多张事实表才能实现，这时通常会出现直接或间接多对多的连接情况，而多对多是必然会出现数据发散现象的。下面以 UserSkills、UserLanguages 以及 Users 三张表来演示间接的多对多情况：假如有业务需求：①从会Python的员工中找出English最好的那个；②所有会Python的员工的平均English评分多少。

当然，最终将它们连接成一张大表时，不可避免地会出现同样。

（Unified Star Schema）由 Francesco Puppini（弗朗切斯科·普皮尼）在他于 2020 年推出的与 Bill Inmon 合著的一书中提出。以早期的电话拨号服务来比喻，业务人员相当于电话用户，传统的服务方式是应用层的数据开发人员充当电话接线员，用户通过接线员去实现拨号；而 USS 的作用就是实现用户自助拨号，其中桥接表就相当于电话交换机，交换机会自动寻址自动拨号而不再需要接线员。

统一星型模式中所谓的“”（fan trap）是指两张表进行左连接时，副表中度量数据的发散现象，如果副表度量字段发散了且被用于聚合计算，那么很可能会得到错误的数据结果。下面以 Shipments 和 Sales 两个表为例进行演示：按中的概念，Shipments 和 Sales 这两张表一般都被视作是，不过在 USS 这里无需区分，只需要关心一张表有没有主键（没有主键的话，构建桥接表时需要额外创建技术主键）。假如有两个分析需求：①从产品维度（ProductID）查看已下单产品的发货情况；