问题标签 [fact-table]

我正在研究用于分析已发布表单数据的星型模式。表单数据将发布到的站点实际上在托管表单的站点之外，因此只有表单中的数据可用。我将提供包含一些额外有用信息的选项，包括隐藏字段、原始推荐人、会话 ID 等。

我将能够使用正则表达式来匹配某些数据类型并将它们提取到特定维度，例如邮政编码。

我有一个解决维度的任意性质的解决方案，它不是一个很好的解决方案，但它会起作用。

我遇到的问题是我不知道我的事实表中会出现什么，它不像我可以聚合一个很好的数值。除了满足这些标准的“是的，有一个表单帖子”这一事实之外。

我想知道我是否以正确的方式处理这个问题？我是否使用了错误的工具来完成这项工作？还是我只是错过了什么？

西蒙。

更多细节：

有两个功能区域，根据标准过滤表单帖子，例如在两个时间戳之间。但就过滤而言，几乎所有东西都可以争夺。选定的表单帖子将用于生成 csv 文件以供导出。

另一个主要领域是分析，研究广告支出转化为客户线索是一个明显的起点。也有点开放式，取决于表单数据。

我正在开发一个报告系统，该系统允许用户任意查询一组事实表，并限制每个事实表的多个维度表。我编写了一个查询构建器类，它根据约束参数自动组装所有正确的连接和子查询，并且一切都按设计工作。

但是，我有一种感觉，我没有生成最有效的查询。在一组具有几百万条记录的表上，这些查询大约需要 10 秒才能运行，我希望将它们降低到不到一秒的范围内。我有一种感觉，如果我可以摆脱子查询，结果会更有效率。

我不会向您展示我的实际架构（这要复杂得多），而是向您展示一个类似的示例，该示例说明了这一点，而无需解释我的整个应用程序和数据模型。

想象一下，我有一个音乐会信息数据库，其中包含艺术家和场地。用户可以任意标记艺术家和场地。所以架构看起来像这样：

很简单。

现在假设我想查询数据库中今天一个月内发生的所有音乐会，所有带有“techno”和“长号”标签的艺术家，在带有“cheap-beer”和“great-mosh-pits”标签的音乐会上表演.

我能想出的最佳查询如下所示：

该查询有效，但我真的不喜欢拥有这些多个子查询。如果我可以完全使用 JOIN 逻辑来完成相同的逻辑，我感觉性能会大大提高。

在一个完美的世界里，我会使用一个真正的 OLAP 服务器。但是我的客户将部署到 MySQL 或 MSSQL 或 Postgres，我不能保证兼容的 OLAP 引擎将可用。所以我坚持使用带有星型模式的普通 RDBMS。

不要太在意这个例子的细节（我的真实应用程序与音乐无关，但它有多个事实表，与我在这里展示的那些有类似的关系）。在这个模型中，'artist_tag' 和 'venue_tag' 表用作事实表，而其他一切都是维度。

重要的是要注意，在这个例子中，如果我只允许用户限制单个艺术家标签或场地标签值，那么查询编写起来要简单得多。只有当我允许查询包含 AND 逻辑时，它才会变得非常棘手，需要多个不同的标签。

所以，我的问题是：您所知道的针对多个事实表编写有效查询的最佳技术是什么？

我注意到多维数据集中使用的事实表实际上是视图。事实上，它们是事实表的模板（我在脚本中注意到“where 1=2”用于事实视图）。

因此，如果使用模板，视图中不会有任何数据（而且我不知道是否可以在视图中插入，因为我在视图中没有插入权限）。

所以，我的问题是：我是否错过了立方体中的某些东西来查看？因为立方体是由一位非常有经验的开发人员设计的，而我只是一名 QA。立方体设计窗格清楚地显示它正在使用模板（如 DSV 设计器中每个矩形对象的黄色标题中所示。它是否可以引用到任何其他表/视图，而不是标题中显示的内容？

一个事实表有 16 个分区。它们全部 16 具有相同的结构和相同的聚合方案。其中 15 个包含数据，而第 16 个不包含数据。

那么，DSV 设计器中的事实表是否只是这些分区之一？（但标题中的名称与其中一个分区匹配）

如果是这样，那么每当我们需要处理不同的分区时，只需在设计器中替换事实表并重新处理即可？

如果度量值组有单个分区，聚合设计为 0%，分区表用作空表（模板），多维数据集浏览器如何仍显示该度量值组中度量值的数据。

仅供参考：分区通常按月创建，如 vw_fact_patronrevenue_2007_1、vw_fact_patronrevenue_2007_2 等，以及不包含数据的模板 (vw_fact_patronrevenue_template)。

但是，对于我遇到的特定度量，只有一个分区，分区表/视图是一个模板。

我有一个维度（SiteItem）有两个重要的事实：

但是，在这个维度中，我有基于属性列的值组（我们称之为组 AboveFoldItems、LeftNavItems、OnTheFlyItems 等），每个组都有更多特定于该组的事实：

下面的事实表模式可以吗？

这似乎有点浪费，因为只有一些列与某些维度键相关（不相关的事实保留为 NULL）。但是……这似乎是一个普遍的问题，所以应该有一个共同的解决方案，对吧？

我必须用 12 次查找维度表来填充 FactTable 以获得 SK，其中 6 次查找不同的 Dim 表，其余 6 次查找相同的 DimTable（类型 II），查找相同的自然键。

前任：

PrimeObjectID => 查找 DimObject.ObjectID => 获取 ObjectSK

并得到了其他相同的列

OtherObjectID1 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID2 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID3 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID4 => 查找 DimObject.ObjectID => 获取 ObjectSK

OtherObjectID5 => 查找 DimObject.ObjectID => 获取 ObjectSK

对于这样的多重查找，我的 SSIS 包中应该如何进行。

现在我正在使用查找 / unionall foreach 查找。有没有更好的方法。

好的，所以我的事实表有这个问题。当在我的事实表上有外键的数据库中的所有其他表上输入新数据时，我需要自动填充它。在我的存储过程中，我编译了我拥有的所有插入语句，最后，因为我还想更新我的事实表，所以我放置了这个查询：

但是，我收到以下消息的错误：

有人可以帮我吗？非常感谢。:)

我的完整程序：

我是数据仓库的新手。首先，我想准确地说，我的数据仓库工具包副本正在发送到我的邮箱（蜗牛邮件：P）。但是我已经用我在网上找到的东西来研究所有这些东西。

然而，我在网上找不到的是，当你在 DW 中似乎有多个事实时该怎么做。在我的情况下（保险），我有不定期发生的退款。一个客户可以在 3 个月内没有，然后在同一个月内有 10 个。另一方面，我有“订阅费”（不知道什么是正确的英文术语，但你明白了），每月或每三个月发生一次。在我看来，这显然是两个截然不同的事实。

这两者在某些维度上是松散耦合的，例如客户或“保险产品”。现在是这两个不同的仓库，我必须在其上生成两个不同的报告，然后将报告连接到 DW 之外？或者有没有办法设计这个来适应一个单一的下降 DW。还是我应该将这两个事实合二为一？那时我可能会失去退款的粒度。

我读过的一些博客说 DW 总是有一个事实表。其他人提到设计带有 S 的事实表的步骤，但没有明确说明它们之间是否存在链接，或者它们只是同一个 DW 项目的不同组件。

有谁知道 DW 设计的那个精确部分的一些参考资料？

想象一下 PostgreSQL 9.0 上具有以下结构的表：

为了简单起见，我只提到一个文本列，实际上它有十几个。该表有 100 亿行，每列有很多重复项。该表是使用 COPY FROM 从平面文件 (csv) 创建的。

为了提高性能，我想转换为以下星型模式结构：

然后，事实表将被替换为如下所示的事实表：

我目前的方法基本上是运行以下查询来创建维度表：

然后创建填充我使用的维度表：

之后我需要运行以下查询：

试想一下，通过将所有字符串与所有其他字符串进行多次比较，我得到的可怕性能。

在 MySQL 上，我可以在 COPY FROM 期间运行存储过程。这可以创建字符串的散列，并且所有后续字符串比较都在散列而不是长原始字符串上完成。这在 PostgreSQL 上似乎是不可能的，那我该怎么办？

示例数据将是一个 CSV 文件，其中包含类似这样的内容（我也在整数和双精度数周围使用引号）：