场景：我为用户推导出了3种利用率指标。在我的应用程序中，使用他的登录历史记录，用户进行的客户呼叫数量，用户执行的状态更改次数来跟踪用户活动。
所有这些信息都保存在我的应用程序数据库中的3个不同的表中，如UserLoginHistory，CallHistory，OrderStatusHistory。每个用户所做的所有操作都与DateTime信息一起存储在这3个表中。
现在我正在尝试创建一个报告数据库，它将帮助我生成用户的整体利用率。基本上，报告应该在一段时间内向每个用户显示：
现在我正在设计我的事实表。我该如何为这种情况创建Fact表？我是否应该创建一个包含行的事实表，在粒度日期级别（在我的DimDate表级别）或3个不同的事实表中捕获所有这些细节并将它们联系起来？
我上面描述的两个选项并不令人信服，我正在寻找更好的设计。感谢。
答案 0 :(得分：2)
根据经验，当您的报告使用具有相同粒度（Number of Logins Made, Number of Calls Made, Number of Status updates Made）的不同事实/指标（UserName, Role, Day/Hour/Minute）时，您将它们放在同一个事实表中，以避免昂贵连接。
由于很多原因，这并不总是可行，但你的情况在我看来有点不同。
您有三个包含用户活动的表，可能存储有关登录，调用和状态更新的更多详细信息。您的报告所需的是一个表格，其中包含您的指标以及根据您所需的时间粒度汇总的值。
假设您需要在当天级别的报告，您需要一个这样的表：
Day UserID RoleID #Logins #Calls #StatusUpdate
20150101 1 1 1 5 3
20150101 2 1 4 15 8
如果明天业务需要按小时报告，您需要：
DayHour UserID RoleID #Logins #Calls #StatusUpdate
20150101 10:00AM 1 1 1 2 1
20150101 11:00AM 1 1 0 3 2
20150101 09:00AM 2 1 2 10 4
20150101 10:00AM 2 1 2 5 4
然后日级表将类似于第二级的聚合（按天）版本。 DayHour属性是第一天的孩子。
如果您需要细微的细节，请按照粒度进行调整。
您也可以直接从分钟级别的汇总表开始，但我会仔细检查业务需求，通常一小时（或15分钟）就足够了。
然后，如果他们需要获取更详细的信息，您可以随时深入查询原始表格。好的一点是，当您钻到该级别时，您应该只需要一小组行来查询（例如，对于特定的UserName只需几个小时），并且您的数据库应该能够处理它。