【问题标题】:Combine multiple outrigger tables into one?将多个支腿表合二为一?
【发布时间】:2017-06-07 18:07:52
【问题描述】:

我有一个维度表和几个支腿。

create table dimFoo (
    FooKey int primary key,
    ......
)

create table triggerA (
    FooKey int references dimFoo (FooKey),
    Value varchar(255),
    primary key nonclustered (FooKey, Value)
)

create table triggerB (
    FooKey int references dimFoo (FooKey),
    Value varchar(255)
    primary key nonclustered (FooKey, Value)
)

create table triggerC (
    FooKey int references dimFoo (FooKey),
    Value varchar(255)
    primary key nonclustered (FooKey, Value)
)

这些支腿表是否应该合并到一张表中?

create table Triggers (
    FooKey int references dimFoo (FooKey),
    TriggerType varchar(20), // triggerA, triggerB, triggerC, etc....
    Value varchar(255),
    primary key nonclustered (FooKey, TriggerType, Value)
)        

【问题讨论】:

  • 我想了解他们为什么是支腿。它们看起来像与维度表本身一对一的文本字段(在 FooKey 上键入),因此听起来它们应该只是在维度表中作为列。
  • 每个 foo 有很多文本项。这是多对一的关系。
  • 那么,如果这些表上有 PK,它会在 fookey + 值上吗?
  • 是的,没错。
  • 组合起来后,它开始看起来更像一个事实表。

标签: sql data-warehouse dimensional-modeling


【解决方案1】:

为了满足这种情况,例如对于可能有多种爱好的客户的 dimCustomer,典型的 Kimball 方法是在维度(dimCustomer 和 dimHobby)之间使用桥接表。

This link 总结了桥接表如何解决此问题以及可能更适合您的替代方案。

在不了解您的特定场景的更多信息的情况下,包括业务需求是什么、您拥有多少这些值类型、各种值类型和值的“统一”程度以及您将用于访问的 BI 技术数据,很难给出一个明确的答案,你是否应该将这些桥合并成一个满足各种多对多的超级桥。以上都在一定程度上影响了答案。

通常,“通用表”方法在后台管理中比在分析中呈现更有用。我的默认方法是使用特定的桥接表,直到/除非从 ETL 的角度来看这变得无法管理,或者从用户查询的角度来看它变得更加复杂。我不希望从一开始就“优化”到组合表。

如果您的情况超出通常的规范(根据您的示例,您是三个还是十个?),组合可能是个好主意。这将使它更像是一个没有事实的事实,维度为 dimCustomer、dimValueType 和 dimValue,并且将是一个完全合理的解决方案。

【讨论】:

  • 在我的例子中,爱好只是一个文本字符串,我不想为它创建维度 dimHobby。 Etl 将用于确保 hobby 的值是有效的。
  • 至于您是否“应该”将它们结合起来,当然,这是否有助于您更好地管理它或使其更易于理解。如果没有,请不要:-)
猜你喜欢
  • 2019-09-30
  • 2015-01-08
  • 1970-01-01
  • 2019-11-06
  • 2016-03-18
  • 2010-12-15
  • 2020-12-08
  • 2017-02-26
  • 1970-01-01
相关资源
最近更新 更多