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

我有一个包含典型的星型架构数据仓库，以及一大堆的代码，做这样的东西（显然大了很多，但这是举例）：典型的Kimball星型模式数据仓库 - 模型视图可行吗？以及如何代码生成

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必须包含唯一的列名，我还担心与优化，如果我表现继续做吧，因为我担心WH中的所有项目在不同的事实和维度ERE条款得到优化，因为认为要横跨整个明星，意见不能被参数（男孩，那不是很酷！）

所以我的问题是 -

这种方法行得通吗？或者它只是一个抽象，会伤害性能，除了更好的语法之外，不会给我任何东西？
考虑到所有适当的PK和FK都存在，对这些视图进行编码的最佳方式是什么？消除重复的列名称（即使稍后需要手动调整视图）？我是否应该写一些SQL将其从INFORMATION_SCHEMA中提取出来，或者有一个很好的示例。

编辑：我已经测试过它，而且性能似乎是相同的，甚至更大的过程 - 甚至在加入多颗，每个使用这些视图。

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

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

来源

2008-09-24 Cade Roux

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

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

来源

2008-09-25 18:36:48

使视图或视图进入一个或多个摘要事实表并实现它。这些只需刷新主事实表时刷新。物化视图的查询速度会更快，如果您有大量可通过摘要满足的查询，则这可能是一个胜利。

如果您有大量摘要或希望对其进行频繁更改，则可以使用数据字典或信息模式视图来生成SQL以创建表。

但是，我猜想你不太可能经常改变它们，所以自动生成视图定义可能不值得麻烦。

来源

2008-09-24 17:24:11 ConcernedOfTunbridgeWells

我没有跟随这 - 如果我压扁全明星成有效的表索引的不同的方式，什么是三维模型摆在首位的地步？ – 2008-09-24 17:55:59

不扁平化，卷起来。如果您要汇总数据，则应考虑实现视图。这会更快。 – ConcernedOfTunbridgeWells 2008-09-24 18:55:21

如果你碰巧使用MS SQL Server中，你可以尝试内联UDF这是接近一个parameterized view，因为它得到。

来源

2009-10-26 15:46:54

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

回答

相关问题