因为我们计划将数据从Teradata迁移到Google Cloud(Bigquery(。 在Teradata中，我们拥有主要和外部等关键概念，借助这些关键，我们能够定义维度和事实之间的关系。
例如，假设我有 3 个维度表和一个事实数据表，如下所示。
D1 D2 D3
F1
借助 Teradata 中的键或索引，我们可以从事实表中获取数据。
当来到 Bigquery 时，我们没有任何像键或索引这样的概念，那么我们将如何 定义维度和事实之间的关系
注意：如果没有主键或索引概念，我们将如何消除重复项
主键、事实和维度是上一代数据仓库需要依赖的性能概念。
例如，在 Teradata 中，需要一个主索引键来在节点之间分发数据。此分布将是以后启用快速执行查询的关键 - 但在 BigQuery 世界中，不需要节点之间的这种预先计划的分布。
事实、维度、星型模式、OLAP 立方体也是如此......它们存在的主要原因是以后通过限制可以查询的内容和维度来启用更快的查询。使用BigQuery，您无需担心这一点。
与其划分为正常形式，不如拥有一个将所有维度都合并到 BigQuery 中的平面表。任意 JOIN 也会很快 - 但平面表和嵌套数据在这里很容易处理。
现在您不受旧技术需求的限制 - 删除重复项成为一种不同类型的操作。
想想当涉及到SCD1和SCD3时，你如何处理那个平面表。
对于这两个，您需要在目标平面表上运行更新或从头开始生成新的平面表，而不是仅更新维度表。
当前一代的DWH不像旧的DWH那样保持一致性和历史数据。当前一代仍然可以做平面表的唯一原因是因为他们要么考虑不可变的数据，要么不遵循一致性规则。一旦数据再次增长基础设施和这些建模方式，这将在几年内结束，我们将再次回到维度模型。如果您处理 PB 的数据，您不会一遍又一遍地重新加载该数据，因此您尝试将其拆分为增量批次，拆分不可变的不可变，即事实和维度。
如果您有超过几 TB 的数据，或者您需要每小时加载 DWH，我会一直这样做。如果您的数据低于 1 TB，并且只需要在 DWH 中每天更新，最简单的方法可能是每次都重新加载。