Question

我对BI开发/数据仓库有点新意，但我正面临着旧的缓慢变化的维度困境。我已经阅读了很多关于类型和理论的内容，但是我发现，对于这些实现来说，最常见的SELECT查询几乎没有找到。

我会让我的例子变得简单。假设您有四个销售原因，东，西，北和南。您有一组销售人员可以进行日常销售，并且（可能每年一次）重新分配一个新的区域。

因此，您将拥有以下原始数据：

name; sales; revenue; date
John Smith; 10; 5400; 2015-02-17

你每天都有这样的数据。

您最初可能还有如下所示的维度表：

name; region
John Smith; East
Nancy Ray; West
Claire Faust; North

因此，销售总监想知道2015年5月东部地区的月销售收入。您将执行查询：

SELECT region, month(date), sum(revenue)
from Fact_Table inner join Dim_Table on name = name
where region = East and date between ....
[group by region, month(date)]

你明白了。让我们忽略我使用自然键而不是代理整数键;我明确使用代理键。

现在，显然，销售人员可能会在年中移动地区。或月中旬。因此，您必须创建一个SCD类型才能运行此查询。就我个人而言，Type 2最有意义。所以说你实现了。假设John Smith于2015年5月15日从东部地区改为西部地区。您实施下表：

name; region; start_date; end_date
John Smith; East; 2015-01-01; 2015-05-15
John Smith; West; 2015-5-15; 9999-12-31

现在，销售总监提出了同样的问题。东部2015年5月的总销售收入是多少？或者，全年按地区显示总数。你将如何构建查询？

SELECT region, month(date), sum(reveneue)
from Fact_Table inner join Dim_Table
on name = name
and date between start_date and end_date
group by region, month(date)

这会给出正确的结果吗？我想这可能 - 我的问题可能更符合---好吧现在假设你在Fact表中有100万条记录......这种内部联接会非常低效，还是有更快的方法来实现这个结果？

将SCD（如地区）直接写入“非规范化”状态会更有意义吗？事实表---当尺寸发生变化时，或许更新一周或两周的事实记录＆＃39;地区追溯？

Answer 1

如果您的业务需求具有Region-＆gt; Seller的层次结构，则您的概念是正确的，如示例所示。

当前查询的性能可能具有挑战性，但通过使用适当的维度键和属性可以提高性能。

使用包含date-＆gt; Month的日期维度层次结构，您将能够避免范围查询。

在两个维度中使用整数，代理，密钥，您的索引性能将得到改善。

一百万行很小，任何有能力的DBMS都不会出现性能问题：）

慢慢改变维度 - 确切的SQL查询实现以检索正确的数据

1 个答案: