我是数据仓库的新手，我有一个带有合同事实表的星型模式。它包含基本的合同信息，如开始日期、结束日期、金额……等。
我必须将这些事实与客户维度联系起来。每个合同最多有 4 个客户。因此，我认为我有两个选择，要么将 4 个客户平铺成一行，例如：
DimCutomers
name1, lastName1, birthDate1, ... , name4, lastName4, birthDate4
我听到的另一个选项是在事实和客户维度之间创建一个桥接表。从而使模型复杂化。
你觉得我应该怎么做？每种解决方案的优缺点是什么？是否有更好的解决方案？
【问题讨论】：
标签： data-warehouse star-schema
我将首先创建一个包含所有客户的客户维度，并且每行只有一个客户。客户维度本身可以成为 CRM 和其他用途的有用工具，这意味着您将拥有一个可靠的客户列表，这使得您随后实施的任何设计都变得更加容易。
之后，这取决于客户与合同之间的关系。我能想到的主要场景是 a) 一份合同有 4 个客户“角色”，b) 一份合同有 1-4 个客户，都具有相同的角色，c) 一份合同有 1-n 个客户，所有客户都具有相同的角色。
场景 A 是每个合同都有 4 个客户角色，例如一个客户要求签订合同，第二个客户签署合同，第三个客户见证合同，第四个客户付款。在这种情况下，您的事实表将有每个合同一行和 4 个客户 ID 列，每个列都引用客户维度：
...
RequesterCustomerID int,
SignatoryCustomerID int,
WitnessCustomerID int,
BillableCustomerID int,
...
当然，如果一位客户既是请求者又是见证人，那么您将在 RequesterCustomerID 和 WitnessCustomerID 中拥有相同的 ID，因为您的客户维度中只有一行给他。这是完全正常的。
场景 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 种方式拆分。在这种情况下，您将别无选择，只能创建某种包含每个合同的特定客户组合的桥接表，因为仅用一个事实和一个维度表无法清晰地表示它。
【讨论】：
任何一种方法都可以，但每种解决方案都有不同的含义。当然，您需要客户和合同表。一个关键问题是：它总是最多四个还是最终会超过这个数量？如果它将保持为 4，那么您可以在合同中拥有一组重复的 4 个客户 ID。这样做的缺点是它是固定的。如果合约没有四个，则有一些空格。但是，如果可能超过 4 个，那么唯一可行的解决方案是使用桥接表，因为在桥接表中您可以通过插入新行来添加更多客户（不更改表结构）。在固定解决方案中，在这种情况下，您通过更改表来添加超过 4 个客户。桥接表是几十年来 ER 建模称为关联实体的一个示例。它是两种解决方案中更灵活的一种。然而，我曾经在一个保证金系统上工作过，其中大额保证金需要五个级别的经理批准。他们告诉我，已经是五个，而且永远是五个。每个审批经理代表不同的组织级别。在这种情况下，我们使用了一组重复的五个经理 ID，每个级别一个，并将它们包含在交易中。因此，了解当前的业务规则和未来的前景非常重要。
【讨论】：