基本上我们正在为我们的软件构建一个报告仪表板。我们正在为客户提供查看基本报告信息的能力。数据仓库 - 随时间储存独特数据
例子：（我已经删除了我们的实际系统的复杂性了这个例子中的99％，因为这应该还是跨越什么，我试图做得到）
一个例子指标是.. 。在特定时间段内查看的独特产品的数量。也就是说，如果5个产品在一个月的过程中被客户每次查看100次。如果您运行该月份的报告，则应该仅查看所查看产品的数量为5。
对于如何在任何时间范围内查询数据以及如何返回所查看产品的唯一数量，有何建议？为了这个例子...可以说有一条规则是应用程序不能直接查询源表，我们必须将摘要数据存储在不同的数据库中并从那里查询。
作为一个附注，我们有很多其他度量标准，我们正在存储，我们存储每天聚合。但是由于唯一性问题，这个特定的度量标准是不同的。
我个人认为这是不可能的。我们目前的解决方案是，我们提供4个预先计算的时间范围，其中受指标影响的指标可用。如果您使用自定义时间范围，则该指标不再可用，因为我们没有预先计算的数据。
你的问题是你试图改变事实表的粒度。这是无法完成的。
你最好的选择是我认为你现在正在做的事 - 在一天，一周和一个月的谷物中定义聚合事实表以支持你的性能约束。
您可以简单地通过建议您的用户这将比标准聚合速度更慢来解决自定义时间范围。例如，想知道的在星期二销售的独特的产品计数，用户可以写这样的查询，在一些性能损失为代价的：
select distinct dim_prod.pcode
,count(*)
from fact_sale
join dim_prod on dim_prod.pkey = fact_sale.pkey
join dim_date on dim_date.dkey = fact_sale.dkey
where dim_date.day_name = 'Tuesday'
group by dim_prod.pcode
查询也对每天汇总，而不是被写入事实上，因为它会扫描更少的数据，它会运行得更快，甚至可以满足您的需求
根据您提供的信息，我认为您试图衡量'一个月内查看的独特产品数量（例如）'。
不确定您是否使用Kimball方法来设计您的事实表。我相信在Kimball方法中，建议您积累快照事实表以满足这样的要求。
我可能会宣讲到转化（在这种情况下道歉），但如果没有，那么我会放你走，通过下面的链接，专家已经详细解释这一概念： http://www.kimballgroup.com/2012/05/design-tip-145-time-stamping-accumulating-snapshot-fact-tables/
我也有包括来自金博尔另一链路，这解释了不同类型的事实表的详细：
http://www.kimballgroup.com/2014/06/design-tip-167-complementary-fact-table-types/
希望有所详细解释的概念。更乐意回答任何问题（给我最大的能力）
干杯 尼西
我想知道......而不是保存汇总数据的其他地方，怎么样界定返回的计数VIEW项目（或任何摘要数据）并在视图上应用日期范围过滤器？或者甚至更好...定义一个存储过程，该存储过程根据源数据上的日期范围（作为参数传递）应用SELECT语句。 – Sparrow
我们需要预先分析并存储这些数据，因为我们正在运行数百万行数百万行，所以每次客户运行报表时都要随时生成此数据将需要很长时间。在客户端基础上，只需要几秒钟，这并不坏。但是这些数据也被用于基准测试（将一个客户端与其他客户端进行比较），当一次为成千上万的客户端运行时，需要很长的时间才能实时计算。使用我们的预制数据库，其他度量标准只需要几分之一秒的时间来汇总数千个客户端。 – chadwin
您正在使用哪种数据仓库方法，Inmon或Kimball？ – Eli