典型的 Kimball 星型模式数据仓库 - 模型视图可行吗？以及如何编写代码

Question

我有一个数据仓库，其中包含典型的星型模式，以及一大堆执行此类操作的代码（显然要大得多，但这只是说明性的）：

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

我正在考虑用视图替换它（例如MODEL_SYSTEM_1），这样它就变成了：

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

但是视图 MODEL_SYSTEM_1 必须包含唯一的列名，如果我继续这样做，我还担心优化器的性能，因为我担心 WHERE 子句中的所有项目都跨越不同的事实和维度得到优化，因为视图将跨越一整颗星，并且视图不能参数化（男孩，那不是很酷！）

所以我的问题是 -

1. 这种方法是否可行，或者它只是一种抽象，会损害性能并且除了更好的语法之外没有给我任何东西？

2. 在所有适当的 PK 和 FK 都已就位的情况下，对这些视图进行代码生成、消除重复的列名（即使稍后需要手动调整视图）的最佳方法是什么？我应该只写一些 SQL 将其从 INFORMATION_SCHEMA 中提取出来，还是已经有一个很好的例子可用。

编辑：我已经对其进行了测试，即使在更大的进程上，性能似乎也是一样的 - 甚至加入了多个星，每个星都使用这些视图。

自动化主要是因为数据仓库里面有很多这样的star，设计者已经做好了FK/PK，但是我不想把所有的表或者文档都挑一遍.我编写了一个脚本来生成视图（它还生成表格的缩写），它可以很好地从INFORMATION_SCHEMA 自动生成骨架，然后可以在提交视图创建之前对其进行调整。

如果有人想要代码，我可以在这里发布。

Answer 1

1. 我已经在我负责的几个数据仓库中使用了这种技术。在运行基于视图的报告与直接使用表格方法时，我没有注意到任何性能下降，但从未进行过详细分析。

2. 我使用 SQL Server 管理工作室中的设计器创建了视图，但没有使用任何自动化方法。我无法想象架构变化如此频繁，以至于无论如何自动化它都是值得的。您可能会花费与首先将所有表格拖到视图上一样长的时间来调整结果！

要消除歧义，一个好的方法是在列名前加上它所属的维度的名称。这对报告编写者和运行临时查询的任何人都有帮助。

Answer 2

将一个或多个视图制成一个或多个汇总事实表并将其具体化。这些仅在刷新主事实表时才需要刷新。物化视图的查询速度会更快，如果您有很多可以通过摘要来满足的查询，这可能是一个胜利。

如果您有大量此类摘要或希望经常更改它们，您可以使用数据字典或信息架构视图生成 SQL 来创建表。

但是，我猜您不太可能经常更改这些内容，因此自动生成视图定义可能不值得麻烦。

Answer 3

如果您碰巧使用 MS SQL Server，您可以尝试一个内联 UDF，它尽可能接近 parameterized view。