数据仓库建模问题

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。

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

• 复制从查找加载到事实加载的逻辑？ 更好的性能，但这对维护来说更糟（如果将来需要更改，则需要在两个地方应用更改），并且代理键也需要硬编码。
• 把以上条件放在join条件中？ 显然，维护会更好，但性能更差（事实表每天插入大约 10 000 000 行）。
• 或者也许有另一种解决方案？ 在源系统中组合上述条件也不是一种选择。

欢迎提出所有建议。

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 技术，根据某个索引对表进行分区可能是有意义的，这有助于您检索错误/-1 并将它们重新处理到事实表中，而不会影响任何性能。 如果您需要了解有关此技术的更多信息，请随时与我联系。 乐于帮助。

我为另一个关于 SGK 的问题整理了一个非常详细的指南，您可以将其用作参考管理数据仓库中的代理键

亲切的问候，巴巴尔