对于转换数据的维度,是否有技术术语?

时间:2012-07-31 00:14:48

标签: sql data-warehouse multidimensional-array

是否存在仅仅转换数据的维度的术语?

例如,我遇到了一个维度,它将日期数据转换为不同的表示形式(例如财政年度的缩写,如FY1和其他表示形式)?

3 个答案:

答案 0 :(得分:3)

在某种意义上,所有维度都是数据“转换”的结果,即使它只是将多个关系表反规范化为具有重复属性的宽维表。

在日期维度中多次表示日期是一种很好的做法。它允许您存储财政日历(5-4-4财政周等)的内容,这些内容可能因组织而异,并且不易使用公式创建。使用此维度,您可以根据特定属性构建聚合(按财务月报告和按月历月报告)等。

是的,该日期的所有属性可能在DATETIME类型中“隐含”,但它使得更易于维护的查询和使用数据的业务用户更容易根据该日期提供多个属性。

答案 1 :(得分:2)

我要说日期的所有代表都应永久存储在日历维度中。仓库通常有一个企业层,其中数据从多个系统汇集在一起​​(使得密钥和日期等都具有相同的格式)并且丰富 - 即我们创建要在日历维度中使用的日期的所有表示。然后你有了表示层(Kimball),它以有意的方式去规范化,使查询运行得更快。允许我们丰富维度的表是企业层的一部分,而不是表示层,因此根据定义,不是维度。尺寸仅位于表示层中。我当然是我的意见!

答案 2 :(得分:1)

数据仓库解决方案中的所有维度基本上都存在,因为最终用户希望能够根据该维度做出决策。
(在实践中,最终用户可能会根据多个维度的组合做出决定。)

最终数据仓库解决方案中的维度本身就是大数据转换过程的结果。

即:

  • 转换原始数据,其中数据来自多个 来源
  • 以丰富原始数据的形式进行转换(fx 应用层次结构)
  • 等......

所以说一个单独转换数据的维度,一开始就是一种描述维度属性的模糊方式,因为它有点不清楚是什么意思。

然而考虑到这一点,我以这种方式承认你的问题,它让我们自问:“转换维度”是否可以成为数据仓库中存在的一种新维度?

如果你认为你的“转换维度”是一个完全来自另一个维度的维度,没有原始数据的影响,那么“转换维度”的概念会变得更加精确。

因此,在您的情况下,将日期数据转换为不同表示的维度可以正确地称为“转换维度”。

有关数据仓库中维度表类型的更全面列表,请查看以下问题:
What are the types of dimension tables in star schema design?