数据仓库中的代理键与复合键

时间:2014-05-14 06:32:59

标签: data-warehouse

在数据仓库(DW)中,我们有维度和事实表。维度键作为外键迁移到事实表中,因此事实表在该表中形成复合主键。当然,有时不需要所有外键来创建唯一的主键,因为在大多数情况下,唯一性是由很少的外键定义的。

但是,我想知道为什么事实表没有代理键作为主键,比如维度表?首先,当在DW中索引主键(非聚集索引 - 某种最佳实践)时,最好在索引中有一列,还是五列?我知道DW系统并不关心索引预留的磁盘数量,但每次对我来说都是合理的代替密钥而不是复合外键。

有人可以解释为什么这不是标准做法吗?

2 个答案:

答案 0 :(得分:0)

数据仓库与以后加载数据和访问数据的能力同样有效。 正如罗尼斯所解释的那样;我们很少需要能够在事实表中引用复合键的组合来进行任何操作; 在加载时,如果我们有一个主键,那么加载需要更长的时间,如果我们需要通过主键访问记录就可以了。否则这是浪费时间。

考虑以下事实

CustomerId
Date
PartId
NumberofOrders
OrderQuantity
InvoiceAmount

键是CustomerId,Date,PartId

拥有密钥组合的附加记录不会影响对此事实表进行的任何分析,因此拥有主密钥可能是多余的。

考虑以下事实

CostCenterId
DivisionId
Month
DepartmentId
OpeningBalance
Credits
Debits

有两种类型的设计是可能的;一个是当你想要这个组合只有一个记录时;在这种情况下,您将定义主键

另一种设计也是可能的; 在每个月的月初创建期初余额记录 处理事务时,将期初余额填充为零 在这种情况下,您可以拥有多条记录

最重要的是确保您有可管理的记录数量进行汇总,更加重视确保您的加载速度更快。

希望这能解释不使用主键的设计趋势

答案 1 :(得分:0)

取决于最常用的报告/应用程序使用案例。在大多数数据仓库中,您最终都将暗表中的代理键用作FK。实际上,出于完全有效的原因,您可能有重复的(部分行)。因此,除非确实需要,否则通常不定义PK。

根据您的RDBMS技术及其在索引,PK /主索引方面的功能,您将定义最适合您的数据仓库的最佳PDM(物理数据模型)。例如,在Teradata中,我会在事实表中定义一个主索引(而不是PK),该索引可以满足我的目的,并且那里可能没有完整的复合键。在事件事实表或网络活动事实表中,我们将每个事件记录为事务,EVENT ID将作为主要索引就足够了,以确保数据的最佳分配以实现更好的性能。如果大多数报告用例基于客户ID或产品ID或站点ID或经常使用的任何ID查询此表,则可以定义单独的索引来优化报告。然后,您可以在这样的ID上定义相似的索引,只要它存在于其他事实或维度中就可以为您提供最佳的访问路径。

这在很大程度上取决于您的用例,rdbms功能和访问路径设计,以巧妙地定义PDM。

如果有代理键,请在Managing surrogate keys in a data warehouse

处以我的帖子为指导。