问题标签 [degenerate-dimension]

我有一个要发布的 SQL Server 2008 SSIS/SSAS 数据仓库多维数据集，在这个多维数据集中我有以下内容：

对于上述内容，我为维度/事实数据引用设置了主 (PK) / 代理 (SK) 键。

我还想包括诸如Order Number或Transaction Number在我看来适合事实表的内容，因为每条记录的订单号都不同。如果我要创建一个订单号维度，它没有多大意义，因为我将拥有与事实一样多的订单号。

现在，当我加载我的事实数据时，我在维度上进行了多次查找以获取代理键，然后我传入事实数据并在我加载我的事实数据时还包括这些订单号和交易号varchar列，但它们无法使用因为它们不是你可以聚合的东西，所以它们不会出现在我的 SSAS 中，只有数字数据类型的列用于事实表（总收入、总收入等）。

我可以做些什么来让使用 Cube 进行过滤的任何人都可以使用这些内容吗？

我有一个包含 40 列的数据表。我需要的一切都在里面。
我想知道我是否可以单独在这个表上构建一个数据立方体。

我怎么能对立方体说这些是维度，这些是度量？

能告诉我过程吗？

我有 HouseNo、Date、Time、IndoorTemp、OutdoorTemp、Relay 等列。

所有这些数据都在一个表中。我想构建一个多维数据集，其中尺寸为 HouseNo，Date。

该表有一个复合主键。它由（房屋编号，日期，时间）组成

我有一个收集性能指标并将它们存储在数据集市中的应用程序。然后，我使用 Mondrian 对数据进行分析和临时探索。我每天收集大约 5e6 行，METRIC 表的总大小约为 300M 行。

我们根据与 SLA 的指标比较为我们的数据“着色”。颜色正好有 5 个不同的值。例如，当我们执行简单的 MDX 查询以获取特定日期范围（例如 1 天）的数据颜色分布时，我们会看到如下查询：

2014-06-11 23:17:08,042 调试 [sql] - 223: SqlTupleReader.readTuples [[Color].[Color]]: 执行 sql [select "METRIC"."COLOR" as "c0" from "METRIC"" METRIC”组按“METRIC”。“COLOR”按“METRIC”排序。“COLOR”ASC NULLS LAST] 2014-06-11 23:17:58,747 DEBUG [sql] - 223: , exec 50704 ms

为了提高性能，数据集市包含小时和天级别的聚合表，并且两个聚合表都包含 COLOR 列。

我知道蒙德里安非常依赖底层数据库的性能，但真的没有办法调整它。我可以在 COLOR 上创建索引（因为索引的完整扫描将比表的完整扫描稍微快一些），但是在 300M 行表上创建具有 5 个不同值的索引似乎很愚蠢。day 聚合表有大约 500K 行，并且对这个表执行几乎相同的查询会明显更快，但 Mondrian 似乎总是针对这些维度查询使用基本事实表。

我的问题是，有没有办法避免这个查询？如果我无法避免，是否可以让 Mondrian 使用聚合表进行此类查询？我已经在这个维度/层次结构的单个级别中指定了 approxRowCount，并且消除了类似的查询来获取值的计数。我还没有深入了解 Mondrian 的来源，以确定是否有可能使用聚合表，或者我是否有一些配置阻止了它。

编辑澄清：

我可能没有很好地提出我的问题——让我试着澄清一下。我的 MDX 查询类似于：

我可以看看这个并手写一个 SQL 查询来回答这个查询

数据库在大约 100 毫秒内扫描大约 4K 行来回答这个查询。Mondrian 需要几分钟来回答查询，因为它执行了几个不直接回答 MDX 查询的查询，而是获取有关维度的信息。在上述情况下，数据库必须扫描 300M 行，用时 50 秒，才能返回有 5 种可能的颜色。如果颜色在正常维度表中，则只有 5 行，但在退化维度中，可能有数百万行。

所以我的问题是：

a）有没有办法告诉蒙德里安退化维度的值并避免这些查询？

b) 有没有办法让蒙德里安从聚合表中回答这些查询？

有没有替代事实关系的方法？如何摆脱退化的维度/事实关系？

我看到这个问题的不同暗示答案。可以使用单个“平面”事实表来简单地引用蒙德里安模式中的不同列吗？

我正在引入 mdx 语言，但遇到了一个问题。我想总结街道的长度（DimStreet）从维度作为计算成员在多维数据集中具有层次结构日期到日期级别（例如：）[DimDate].[Alldate].[Day]我在 SQL 中完成以更好地理解：

以下是我的查询：

其中，btype 是退化维度。当我在 CDE 上执行此查询时 .. 有时我得到java.lang.nullpointerexception，行为非常随机。通常，它会给出结果，对于默认负载，它总是会产生积极的结果。但是对于 date range change ，我随机得到了异常。

我的 fact_table 结构有 5 个正常维度和 3 个退化。

同时，我还观察到，如果在查询中添加更多颗粒，则不再出现异常。但是添加它并不能满足我所需的结果。

是否与退化维度概念或高基数问题有关

In my fact table (from PostgreSQL) i have a timestamp that looks like this:

2016-07-01

How can i use this timestamp to show a Year/Month/Quarter/Day dimension? A Mondrian 4 Schema example would be helpfull.

I don't want to use a extra time table or something like that. Just the timestamp.

我有一个多面体，面点（对于每个面）基本上是共面的，但 CGAL 说它们不是，这是有道理的，因为这些点是从文件中读取的，并且只有 14 个有效数字，所以它们不会完全共面. 有没有办法在假设面点共面时考虑容差，以免出现 1e-17 阶的某些体积的镶嵌？例如，如何告诉 CGAL 说 (0, 0.0000) 和 (1, 0.0001) 在同一行？甚至可能吗？

目前，我只是在计算体积后忽略了条子，并得到了一个不错的非退化 tets 的三角剖分（当然，根据 CGAL 标准，由此产生的船体不会是凸的），我将其用作在多面体上集成功能的分区。如果这是最快的方法，我很高兴，是吗？我正在使用 EPIC 内核。

感谢任何提示或参考，因为我对 CGAL 相当陌生。谢谢。

我有一个零售销售系统，想使用 ralph kimball 的 Dimensional Modeling 创建一个数据仓库。

我有一个简单的order fact table那个措施order quantity和order dollar amount。从我在书中和互联网上读到的内容来看，这是事实表上的order number一个退化维度。

然后order fact table有一个status，最初我认为它是一个流程，所以我想到了累积的快照事实表。一切都很好，直到我意识到这status实际上不是一个流程，它是一个标签，因此订单可以将状态从“a”更改为“b”，然后再次更改为“a”。我的情况更糟，因为order fact tableis 现在有 3 种状态需要跟踪其更改。所以我认为累积的快照事实表在这里不起作用。

我的尝试是创建 4 个事实表，order order status a order status b order status c. 每个新订单都会在表中创建一行，order并在每个订单中创建一行作为初始状态order status。然后通过在 中创建一个新行来完成对状态的每次更改order status。

由于order status表与表相关order，因此我需要这 3 个order status表来引用order表。怎么做？使用相同的order number（退化维度）就足够了吗？我认为一致性维度也可以解决这个问题，但是这些维度行会像order表格一样增长。对此有什么想法吗？