Question

我在数据仓库中有一个典型的事实表-该表具有一些代理键和度量。在数据中，仓库也是查找表-较小的维，其中不保留历史记录。只需代理密钥，业务密钥和一个或两个属性。在事实表加载期间，代理键是从查找表中获取的（联接基于业务键）。因此，基本上在事实加载的某个阶段，我们在事实内部拥有业务密钥，这些业务密钥用于从查找表中获取代理密钥，在该操作之后，业务密钥消失了，例如在数据集市中（出于报告目的），我们可以仅对某些属性使用代理键将查找与事实结合起来。到目前为止，该过程非常简单，因为我们仅使用一个业务密钥来设置属性值。

但是现在在某些情况下，我们应该使用3个或更多。

例如这些是条件：

COLUMN_1 = 'ABC' 
AND COLUMN_2 <> 'Z'
AND COLUMN_3 IN ('1', '2')

COLUMN_1 = 'ABC' 
AND COLUMN_2 <> 'Z'
AND  COLUMN_3 IN ('3', '4', '5')

COLUMN_1 <> 'ABC' OR COLUMN_2 = 'Z'

COLUMN_1，COLUMN_2，COLUMN_3是事实表中显示的业务密钥。可以肯定的是，上述逻辑将应用于查找负载，因此，我们将拥有3个代理键：1、2和3。

但是主要问题是-哪种方法更适合事实表：

要从查找负载到事实负载复制逻辑？更好的性能，但是对于维护而言则更糟（如果将来需要对此进行更改，则需要在两个位置应用更改），并且代理密钥也必须进行硬编码。
将以上条件置于联接条件中吗？显然，维护会更好，但是性能会差很多（事实表每天插入约1亿行）。
或者也许还有另一种解决方案？在源系统中结合以上条件也是一种选择。

欢迎提出所有建议。

Answer 1

过去，我已经多次模拟代理密钥和事实负荷，以我的经验（15年），最好的平衡设计是以下设计：

代理密钥表设计（dim_sgk） Dim_ID BR1_ID1 BR1_ID2 BR1_ID3 BRn_IDx ... Record_Start_dttm

假设您有一个阶段表（stg_tbl），您在其中使用业务密钥src1.col1，src1.col2和src1.col3加载源数据/文件

现在，当您从阶段表中加载代理密钥表时，

Select *
from 
stg_tbl left outer join dim_sgk 
on stg_tbl.src1.col1 = dim_sgk.br1_id1
and stg_tbl.src1.col2 = dim_sgk.br1_id2
and stg_tbl.src1.col3 = dim_sgk.br1_id3
where dim sgk.dim_id is null

并为3个业务密钥的所有唯一组合生成（或基于rdbms技术及其优点/缺点自动生成）代理密钥。

代理键表已刷新一次；您可以通过将源事务表与代理键表连接并沿途拾取代理键（左外部联接）来开始加载事实

我已经将业务密钥作为非pk属性保留在事实表中，仅用于报告目的。无需将代理密钥与事实结合在一起，以后只需要选择业务密钥即可。您可以使用代理键来优化磁盘上数据的联接和分配。但是实际上，尽管将业务密钥作为不可识别的属性，但您会同时兼顾两者。

您应牢记代理密钥的多种原则（错误处理，孤立处理等）。根据您的rdbms技术，可能有必要根据某个索引对表进行分区，这有助于您检索错误/ -1s并将它们重新处理为事实表而不会影响性能。如果您需要进一步了解这项技术，请随时与我联系。很高兴提供帮助。

我针对SGK提出了一个非常详细的指导方针，以解决另一个问题，您可以将其用作参考Managing surrogate keys in a data warehouse

亲切的问候，巴巴尔

数据仓库建模问题

1 个答案: