0

场景：我为用户导出了 3 种利用率指标。在我的应用程序中，使用他的登录历史记录、用户拨打的客户电话次数、用户执行的状态更改次数来跟踪用户活动。

所有这些信息都保存在我的应用程序数据库中的 3 个不同的表中，例如 UserLoginHistory、CallHistory、OrderStatusHistory。每个用户所做的所有操作与日期时间信息一起存储在这 3 个表中。

现在我正在尝试创建一个报告数据库，以帮助我生成用户的整体利用率。基本上，报告应该在一段时间内向我展示每个用户：

  1. 用户名
  2. 角色
  3. 登录次数
  4. 通话次数
  5. 进行的状态更新次数

现在我正在设计我的事实表。我应该如何为这种情况创建一个事实表？我应该创建一个包含行的单个事实表，在粒度日期级别（在我的 DimDate 表级别）捕获所有这些详细信息，还是 3 个不同的事实表并将它们关联起来？

我上面描述的 2 个选项没有说服力，我正在寻找更好的设计。谢谢。

4

1 回答 1

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 分钟）就足够了。

然后，如果他们需要获取更详细的信息，您可以随时深入查询原始表。好消息是，当您深入到该级别时，您应该只需要查询一小组行（例如特定用户名只需几个小时），并且您的数据库应该能够处理它。

于 2015-03-16T16:42:21.593 回答