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中的所有项目跨越不同事实和维度的子句得到优化，因为视图将跨越整个星，并且视图不能被参数化（男孩，不会那么酷！）

所以我的问题是 -

这种方法是否正常，或者它只是一种会损害性能的抽象，并且除了语法更好之外不会给我任何东西？
考虑到所有适当的PK和FK到位，对这些视图进行代码生成的最佳方法是什么，消除重复的列名称（即使稍后需要手动调整视图）？我应该编写一些SQL来将其从INFORMATION_SCHEMA中拉出来，还是已经有一个很好的例子。

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

自动化主要是因为数据仓库中有很多这样的星星，设计师已经正确完成了FK / PK，但我不想挑选所有表格或文档。我编写了一个脚本来生成视图（它还生成表的缩写），它可以很好地从INFORMATION_SCHEMA自动生成框架，然后可以在提交视图创建之前进行调整。

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

Answer 1

我在我照看的几个数据仓库中使用过这种技术。我没有注意到在基于视图和表直接方法运行报表时性能下降，但从未进行过详细分析。
我使用SQL Server管理工作室中的设计器创建了视图，并没有使用任何自动化方法。我无法想象模式经常变化，无论如何自动化它都是值得的。您可能会花费很长时间来调整结果，因为它首先将所有表拖到视图上！

要消除歧义，一个好的方法是在列名前面加上它所属的维度的名称。这对报表编写者和运行即席查询的任何人都很有用。

Answer 2

将视图或视图放入一个或多个摘要事实表中并实现它。只有在刷新主事实表时才需要刷新这些内容。物化视图的查询速度会更快，如果您有很多可以通过摘要满足的查询，这可能是一个胜利。

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

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

Answer 3

如果您碰巧使用MS SQL Server，您可以尝试使用与parameterized view接近的内联UDF。

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

3 个答案: