数据仓库 - 营业时间

Posted 2023-03-29

【中文标题】数据仓库 - 营业时间

【英文标题】：Data Warehouse - business hours

【发布时间】：2009-01-19 21:49:08

【问题描述】：

我正在开发一个数据仓库，最终需要我根据工作时间创建报告。目前，我的时间维度以小时为单位。我想知道是否应该修改时间维度以包含“营业时间”的位字段，还是应该在分析结束时为其创建某种计算度量？有什么例子会超级壮观？

【参考方案1】：

使用位（或什至另一列）来指定一个小时在存储时是否为营业时间。否则，当您更改营业时间时，您将无法重现历史报告。

【参考方案2】：

您的所有销售数据是否都在同一时区？例如，您是否跟踪不同时区的网点或不同时区的最终用户的销售情况？如果是这样，您可能希望在销售事实表中为“营业时间”创建该位字段，因为对于不同时区的用户和商店来说，动态计算该位字段将非常困难。

另外，您只想计算一次 - 在将销售导入数据仓库时 - 因为此数据不太可能经常更改。你不会说，“这个促销过去是在营业时间，但现在不是了。”

【参考方案3】：

营业时间是业务规则，因此它们将来可能会改变

将营业时间表示为基本时间和持续时间，例如StartTime 0900，Duration 9.5 小时，这样你可以轻松更改间隔，根据不同的营业时间做假设场景，营业时间可以跨越日期线而不复杂查询

当然，所有日期时间都应该是 GMT (UTC)，从不当地时间，以避免夏令时的复杂性

编辑：我想我误解了这个问题，您的数据已经精确到小时......不，我认为我的答案是正确的，但是增加了工作时间间隔的有效开始日期和结束日期。这将允许粒度在未来发生变化，同时仍保留历史

【参考方案4】：

我不确定这是否有帮助，但我会使用 UCT 来存储所有时间，然后有一个开始和结束时间来指定营业时间。设置完成后，这将是一个简单的If (SpecificHour >= BusinessStartingHour) And (SpecificHour <= BusinessEndingHour) Then ... 操作。

【讨论】：

感谢您的反对票，我讨厌成为 smarta$$，但您应该在采取此类行动之前检查 UTC 的定义。 UTC 比较实际上会考虑日期、闰年、时区等因素。

在您的伪代码中，如果 BusinessStartingHour 类似于“8”（上午 8 点），那么您遇到了午夜问题。如果您的评论似乎暗示 BusinessStartingHour 类似于“1232402400”（美国东部标准时间今天凌晨 4 点），那么您必须每天计算不同的时间戳 [每天两次]。

这就是我的暗示。但是，我认为计算会比为存储在数据库中的每个时间戳添加一点（或全新的列）更有效。但是，我可能是错的。我想我只是个 UTC 瘾君子 ;)

+1 以获得有用的答案，即使不完全正确 @[Sparr]：请注意，否决的答案是无用的答案，而不是不完整的答案；-) @[hmcclungiii]：如果您使用 StartHour 和持续时间然后午夜问题消失

@[Sparr]：但感谢您评论您为什么投反对票，这是一件很棒的事情！

【参考方案5】：

如果您使用 Microsoft PerformancePoint 2007，您可以使用不同的选项进行测试。您可以修改维度并将结果输出到图表、数据透视表、其他报告工具等中。

http://office.microsoft.com/en-us/performancepoint/FX101680481033.aspx

【参考方案6】：

“营业时间”会随着时间而改变吗？我想我是在问每一行是否需要与营业时间标志相关联，或者仅让报告本身（或某些参考）表决定该交易是否发生在营业时间就足够了。

在其他条件相同的情况下，我可能会让报告为您完成，而不是标记行，但如果营业时间随时间变化，您必须标记行以确保您的历史数据保持正确。

【参考方案7】：

我认为这是一个判断调用...取决于性能测试、系统使用等。就我个人而言，我可能会创建一个索引字段来保存一个标志，以便处理逻辑以确定什么是并且不是预先的工作时间（即加载数据时）。如果做得正确（同样，取决于具体的用法），我认为您可能也可以获得性能提升。