我正在尝试从似乎包含桥接表的 E/R 图(OLTP 系统)构建星型模式。 Order 是一个明显的事实表，而 product 是一个维度表。如果模型需要是星型模式，我看不出如何保留桥接表。如果我需要在模型中保留有关 Channel 的信息，您将如何处理这种关系？
最佳答案
这取决于您打算如何使用该模型。
如果您只需要回答有关现有订单的产品和 channel 问题，那么您可以完全避免使用桥接表，因为可以通过事实表(“订单”)解决 channel 和产品之间的 M2M 关系:
这种设计的(巨大)优势在于它的简单性和易用性 - 它对最终用户来说非常直观。它也很快。
该模型的缺点是它对订单的依赖。如果订单不存在(即事实表中没有订单)，那么您将无法回答有关产品和 channel 关系的问题(例如，“按指定 channel 显示所有产品”)。如果此类问题不重要，您只需分析现有订单，请保持简单。
如果您确实需要在没有现有订单的情况下分析产品与 channel 的关系，那么事情就更复杂了。一种方法是添加桥接表，如下所示:
这种设计的优点是无论订单如何， channel -产品关系始终可用。按产品分析订单也(仍然)很简单。缺点是现在很难按 channel 分析订单，因为您现在必须通过桥接表。例如，在 Power BI 等最终用户工具中，您需要使“红色”连接成为双向连接，以启用从 channel 维度通过桥接到产品维度的过滤器传播。当然，这是可行的，但最终用户现在必须知道他们在做什么——这不再简单了。
另一种设计使用“无事实”事实表:
在这里，您可以轻松查询没有订单的 channel -产品关系(通过事实表产品- channel ，本质上显示关系状态)，也可以轻松地按产品和 channel 查询订单。您还可以“钻取”这种结构来回答有关没有现有订单的产品的各种复杂问题。尽管如此，这样的设计还是不如第一个设计直观。
关于database - 如何处理星型模式中的桥接表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54392376/