0

我是数据仓库的新手，我有一个带有合同事实表的星型模式。它包含基本的合同信息，如开始日期、结束日期、金额……等。

我必须将这些事实与客户维度联系起来。每个合同最多有 4 个客户。所以我认为我有两个选择，或者我将 4 个客户扁平化为一排，例如：

DimCutomers

name1, lastName1, birthDate1, ... , name4, lastName4, birthDate4

我听到的另一个选择是在事实和客户维度之间创建一个桥接表。从而使模型复杂化。

你觉得我应该怎么做 ？每种解决方案的优点/缺点是什么，是否有更好的解决方案？

4

2 回答 2

3

我将首先创建一个包含所有客户的客户维度，并且每行只有一个客户。客户维度本身可以成为 CRM 和其他用途的有用工具，这意味着您将拥有一个单一、可靠的客户列表，这使得您随后实施的任何设计都变得更加容易。

之后，这取决于客户与合同之间的关系。我能想到的主要场景是 a) 一份合同有 4 个客户“角色”，b) 一份合同有 1-4 个客户，都具有相同的角色，c) 一份合同有 1-n 个客户，都具有同样的角色。

情景 A 是每个合同有 4 个客户角色，例如，一个客户请求合同，第二个签署合同，第三个见证合同，第四个支付合同费用。在这种情况下，您的事实表将有每个合同一行和 4 个客户 ID 列，每个列都引用客户维度：

...
RequesterCustomerID int,
SignatoryCustomerID int,
WitnessCustomerID int,
BillableCustomerID int,
...

当然，如果一个客户既是请求者又是见证人，那么您将在两者中拥有相同的 ID，RequesterCustomerID因为WitnessCustomerID您的客户维度中只有一行供他使用。这是完全正常的。

场景 B 是所有客户都有相同的角色，例如每个合同有 1-4 个签署者。如果签署人的数量永远不会超过 4，并且如果您非常有信心这将“始终”正确，那么简单的解决方案也是在事实表中为每个合约设置一行，其中 4 列引用客户维度：

...
SignatoryCustomer1 int,
SignatoryCustomer2 int,
SignatoryCustomer3 int,
SignatoryCustomer4 int,
...

即使大多数合同只有 1 或 2 个签署者，在表中使用 2 个不太常用的列也没有太大的危害。

场景 C 是一份合同有 1-n 个客户，其中 n 是一个变化很大的数字，甚至可能非常大（集体诉讼？）。如果您在一份合同上有 50 个客户，那么向事实表添加 50 列将变得难以管理。在这种情况下，我将添加一个名为ContractCustomers或任何将事实表与客户维度联系起来的桥接表。这不像其他解决方案那样“简洁”，但是纯星型模式无论如何都不能很好地处理这样的 n:m 关系。

也可能有更复杂的情况，您将场景 A 和 C 混合在一起：合同有 3 个请求者、5 个签署者、2 个见证人，并且账单在请求者之间以 3 种方式拆分。在这种情况下，您将别无选择，只能创建某种包含每个合同的特定客户组合的桥接表，因为仅用一个事实和一个维度表无法清晰地表示它。

于 2013-04-04T17:09:45.763 回答
0

无论哪种方式都可以工作，但每种解决方案都有不同的含义。当然，您需要客户和合同表。一个关键问题是：它总是最多四个还是最终会超过这个数量？如果它将保持为 4，那么您可以在合同中拥有一组重复的 4 个客户 ID。这样做的缺点是它是固定的。如果合约没有四个，则有一些空格。但是，如果可能超过 4 个，那么唯一可行的解​​决方案是使用桥接表，因为在桥接表中您可以通过插入新行来添加更多客户（不更改表结构）。在固定解决方案中，在这种情况下，您通过更改表来添加超过 4 个客户。桥接表是几十年来 ER 建模称为关联实体的示例。它是两种解决方案中更灵活的一种。然而，我曾经在一个保证金系统上工作过，其中大额保证金需要五个级别的经理批准。他们告诉我，已经是五个，而且永远是五个。每个审批经理代表不同的组织级别。在这种情况下，我们使用了一组重复的五个经理 ID，每个级别一个，并将它们包含在交易中。因此，了解当前的业务规则和未来的前景非常重要。

于 2015-08-06T18:06:16.610 回答