转换数据的维度是否有技术术语？答案

【问题标题】：Is there a technical term for a dimensions that transforms data?转换数据的维度是否有技术术语？
【发布时间】：2012-07-31 00:14:47
【问题描述】：

是否有专门用于转换数据的维度的术语？

例如，我遇到了一个将日期数据转换为不同表示形式的维度（例如 FY1 等财政年度的缩写和其他表示形式）？

【问题讨论】：

你的问题没有意义。

标签： sql data-warehouse multidimensional-array

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

我想说日期的所有表示都应该永久存储在日历维度中。仓库通常有一个企业层，其中将来自多个系统的数据汇集在一起，符合（以便键和日期等都采用相同的格式）和丰富 - 即我们创建要在日历维度中使用的所有日期表示。然后你有表示层（Kimball），它以故意的方式去规范化以使查询运行得更快。允许我们丰富维度的表是企业层的一部分，而不是表示层，因此根据定义，维度也不是。维度仅位于表示层中。当然是我的意见！

【讨论】：

“企业层”、“Inmon 层”、“运营数据存储”等 :-)

【解决方案3】：

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

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

即：

原始数据的转换，其中数据来自多个对齐来源
原始数据丰富形式的转换（fx 应用层次结构）
等等……

所以说仅转换数据的维度首先是一种描述维度属性的模糊方式，因为它的含义有点不清楚。

但是考虑到这一点，我以这种方式承认您的问题，这让我们问自己：“转换维度”是否可以成为数据仓库中存在的一种新型维度？

好吧，如果您将“转换维度”视为完全从另一个维度派生的维度，不受原始数据的影响，那么“转换维度”的概念会变得更加精确。

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

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

【讨论】：

维度是关于特定度量的相关属性的集合。为什么我要构建一个新维度，其属性完全源自另一个维度，因为所有这些属性根据定义都与它们所派生的值相关！如果您将它们拉出以“正常化”它们，那么您只是雪花，而不是创建新维度。我们不会从我的“PRODUCT”维度派生“PRODUCT TYPE 维度”，我们只是将产品类型属性存储在 PRODUCT dim 上。