问题标签 [fact-table]

我正在尝试微调查询并希望得到一些反馈。我有一个job_fact仓库表，其中包含作业的最终事件 ( final_event_type) 的计量单位。我正在尝试对将给我一个成功/失败比率的事实进行查询。这是我到目前为止所拥有的：

此查询仅在两行结果中为我提供原始成功和失败值：

有谁知道是否有办法a）在一条线上获得结果，b）能够计算两者之间的比率（例如失败百分比）。我假设有人会告诉我，我最好为此编写一个程序，但如果可能的话，我想避免它。我知道有一种优雅的方法可以做到这一点，但我猜我今天缺少我的 sql-foo。

我正在运行 PostgreSQL 9.0.1。感谢您提供的任何帮助。

更新

根据选择的答案（来自@Ronnis），这是我的最终查询，以防您想知道：

我的数据仓库中有一些实体：

1. Person - 具有 personId、dateFrom、dateTo 和其他可以更改的属性，例如姓氏、出生日期等 - 缓慢变化的维度

2. 文档- documentId、编号、类型

3. 地址- addressId、城市、街道、房屋、公寓

(Person and Document) 之间的关系是一对多的，(Person and Address) 是多对多的。

我的目标是创建可以回答我们以下问题的历史事实表：

1. 哪些人在指定日期住在指定地址？

2、指定地址在指定时间间隔内有哪些居民历史？

这不仅是针对 DW 设计的，而且我认为这是 DW 设计中最难的事情。

例如，personId=1 的 Brown 小姐、documentId=1 和 documentId=2 的文档从 01/01/2005 到 02/02/2010 一直居住在 addressId=1 的地址，然后移动到 addressId=2 的地址。从 2010 年 2 月 3 日到当前日期（NULL？）。但自 2006 年 4 月 5 日起，她已将姓氏更改为格林夫人，自 2007 年 6 月 7 日以来，她的第一个 documentId=1 文档更改为 documentId=3。自 2010 年 2 月 3 日至今，具有 personId=2、documentId=4 的 Black 先生一直居住在 addressId=1。

我们查询问题 2（其中 addressId=1，时间间隔是从 2000 年 1 月 1 日到现在）的预期结果必须如下：

行：

我有一个想法用复合键（personId、documentId、addressId、dateFrom）创建事实表，但我不知道如何加载这个表，然后用这个结构得到预期的结果。

我会很高兴得到任何帮助！

嗨，我是数据仓库的新手，对于家庭作业，请让我实现逻辑设计、物理和实现。您将如何在数据仓库中对此进行建模：

我希望设计一个数据仓库，它给出与棒球联盟相关的统计数据的答案

对于玩家

进攻性：

• 击球手要击球多少次。

•得分多少。

•多少安打，双打和三打。

•打了多少本垒打。

•许多打点。

•许多基于球

防守方面：

▪ 多少出局，双打需要

▪ 有多少次助攻

▪ 有多少错误导致或投手：

▪ 输了多少场比赛

▪ 赢了很多场比赛

▪ 保存了多少游戏

▪ 有多少完整的游戏线索

▪ 有多少游戏已开始多次出现白化

▪ 多少安打、接连击、接三连击、接全垒打

至于球员的数据，重要的是这可以看作是赛季，有没有人知道DW设计的那个精确部分的一些参考资料？有任何想法吗？

非常感谢。

如何存储不包含任何事实的记录？例如，假设一家商店想要计算有多少人进入了商店（并且他们获取了进入商店的每个人的信息）。在仓库中，我猜会有不同属性的维度表“Person”，但事实表会是什么样子？它会只包含外键吗？

我看到在事实表中插入一行和一行最后更新的字段很重要。但是我找不到任何标准的数据仓库或说明这是一件好事的参考资料。我不确定这是否是因为这是一种不好的做法；如果是这样，为什么会这样？如果是因为数据大小，我认为完整日期字段只有 8 个字节。

任何帮助是极大的赞赏！！！

我希望有人可以在“维度使用”选项卡下解释“事实关系类型”的适当使用。是否只是从事实表中创建一个维度来访问事实表本身的属性？

提前致谢！

我正在尝试建立一个数据集市。

我有很多维度和几个衡量标准 - 事实。每一项措施都与业务的各个维度相关联。有一种标准方法是，将有一个包含所有措施的大事实表。

但我有一个想法：如果我为每个度量都有单独的事实表怎么办？它将对数据库性能、解决方案可扩展性等产生什么影响？

编辑::: 在真正复杂的企业环境中，将有基于 olap 多维数据集的巨大解决方案。所以首先需要的是易于扩展和维护，然后是性能

我正在尝试在我的数据库中创建一个事实表，因此我需要插入很多外键。尝试插入特定外键时出现以下错误：

外键 '%.*ls' 的引用列列表中的列数与引用表 '%.*ls' 中主键的列数不匹配。

我不明白为什么会收到此错误，因为 fkey 具有相同的数据类型。

谢谢！！

我正在使用 SQL Server 2008 和 Analysis Services 创建一个仓库。我已经设法创建和填充维度表，但是我在编写用于加载事实表的 SQL 时遇到了很多麻烦。一方面，我不确定如何使用维度表中的 PK 加载事实表的键。我尝试编写一个包含一系列 JOIN 的查询来获取我想要的键和度量，但是语句变得如此复杂以至于我迷路了。

这是我必须使用的星型模式：

http://i.imgur.com/C3DGj.png

我究竟做错了什么？我有一种感觉，我错过了一些非常基本的东西，但我对此还很陌生，而且我在网上找到的大部分信息似乎都是使用我没有安装的 SSIS 来处理的。

任何帮助，将不胜感激。

对于我正在开发的星型模式，我在决定特定维度中应该包含哪些内容以及事实表中应该包含哪些内容时遇到了一些麻烦。

例如，假设该项目正在为一家物业管理公司跟踪房屋。各种日期、承租人、合同等维度都相当简单。对于房子，无论数据位于何处，我们都希望跟踪当前所有者、当前租户、当前租赁合同，以及邻域、地址、当前租金价格、当前市场价值等信息. 请注意，所有者、租户和合同本身就是维度（邻居和地址也可能是维度，但我不太关心这些）。

许多关于房屋的数据将用于过滤查询，或用于多维数据集的行和列标题。其中一些仅作为辅助信息需要，逐个查看，而不是汇总。

鉴于数据，以及我需要用它做什么，我有（至少）三个选择：

• DimHouse：房子表是一个维度，有很多属性，在事实表中可能看起来更好，但是由于它们是用于浏览和过滤的，所以它们需要在这里。当前租户等属性将需要雪花/支腿。
• FactHouse：拥有与其他事实表连接的房屋信息的累积快照，可能使用修剪过的 DimHouse 作为桥梁。这对我来说似乎很奇怪，但它把看似事实的东西放在了事实表中。
  • 将当前所有者、当前承租人等放入相关事实表中，然后将这些事实作为所有者/承租人/等保持最新。改变（也很奇怪，但会让我们保持在星型模式的土地上）。

所以我一直在走维度路线。它让我有些心痛，但它达到了目标。我只想知道是否有更好的方法来组织数据。我不介意冗余（例如具有相似数据的事实表和维度表）或雪花，如果它们有意义并且是做事的最佳方式（对于“最佳”值）。