在数据仓库中表示时间间隔的最佳做法是什么？

Question

特别是我正在处理类型2 缓慢变化的维度,并且需要表示特定记录活动的时间间隔,即对于每个记录我有一个StartDate和一个EndDate.我的问题是关于是否使用闭合([StartDate,EndDate])或半开([StartDate,EndDate))间隔来表示这一点,即是否包括间隔中的最后日期.举一个具体的例子,说记录1从第1天到第5天是活跃的,从第6天开始记录2变得活跃.我是否将记录1的EndDate设为等于5或6？

最近我开始思考半开放区间最好基于Dijkstra:为什么编号应该从零开始,以及Python中的数组切片和range()函数的约定.在数据仓库上下文中应用它我会看到半开区间约定的优点如下:

• EndDate-StartDate给出记录活动的时间
• 验证:下一条记录的StartDate将等于上一条记录的EndDate,该记录易于验证.
• 未来打样:如果我后来决定将我的粒度从每日更改为更短的时间,那么切换日期仍然保持精确.如果我使用一个封闭的间隔并将EndDate存储为午夜的时间戳,那么我将不得不调整这些记录以适应这种情况.

因此,我倾向于采用半开区间法.然而,如果有一些广泛采用的使用闭区间方法的行业惯例,那么我可能会倾向于顺其自然,特别是如果它是基于实现这种系统的实际经验而不是我的抽象理论.

提前感谢任何见解或评论.

Answer 1

我已经看到了使用中的封闭版和半开放版.出于你所说的理由,我更喜欢半开放.

在我看来,半开放版本使预期的行为更清晰,更"安全".谓词(a <= x <b)清楚地表明b意图在区间之外.相反,如果您使用闭合间隔并在SQL中指定(x BETWEEN a AND b),那么如果某人不明智地使用一行的结尾作为下一行的开头,则会得到错误的答案.

使最新结束日期默认为DBMS支持的最大日期,而不是null.

Answer 2

一般来说,我同意David的回答(已投票),所以我不会重复这些信息.除此之外:

你真的是半开([StartDate,EndDate])

即使在"半开放"中,也存在两个错误.一个是直接规范化错误,当然会实现您在讨论中识别的重复数据,可以作为派生数据使用,并且应该将其删除.

• 对我来说,Half Open是(StartDate)
• EndDate派生自下一行.
• 这是最好的做法
• 它不是常见的用法,因为(a)这些天常见的实现者并不知道,(b)他们太懒,或者不知道如何编写必要的简单子查询
• 它基于经验,在大型银行数据库中

有关详细信息,请参阅此

链接到最近非常相似的问题和数据模型

回应评论

您似乎明显偏爱使用自然,有意义的键进行标准化设计.是否有理由在报告数据仓库中偏离这一点？我的理解是,专用于代理键和重复列(例如EndDate)的额外空间是提高查询性能的折衷.但是,您对缓存利用率和增加的磁盘IO的一些评论让我对此提出质疑.我对你的意见非常感兴趣.

1. 是.绝对.任何理智的人(不是从wiki学习计算机科学)都应该质疑.它完全违背了物理定律.

2. 你能理解很多人,在不理解规范化或数据库(你需要5NF)的情况下,会产生非标准化的慢速数据堆,而他们着名的借口(由"大师"编写)是"为了性能而非规范化"吗？现在你知道那是排泄物.

3. 那些相同的人,没有理解规范化或数据仓库(你需要6NF),(a)创建数据库的副本和(b)各种奇怪和精彩的结构来"增强"查询,包括(c)更多的重复.猜猜他们的借口是什么？"为了表现而非正常化".

   • 它是犯罪,"大师"并不是更好,他们验证它.

   • 我会说那些"大师"只是"大师",因为它们提供了伪科学基础,证明了大多数人的非科学性.

   • 错误的信息不会通过重复而变得更真实,而且上帝知道他们无限地重复它.

4. 简单的事实(对于那些使用(1)(2)(3)证明数据仓库合理性的人而言,并不复杂)是6NF,正确执行,是数据仓库.我以仓库的速度从相同的数据提供数据库和数据仓库.没有第二个系统; 没有第二个平台; 没有副本; 没有ETL; 没有保持副本同步; 没有用户必须去两个来源.当然,它需要技巧和对性能的理解,以及一些特殊的代码来克服SQL的限制(你不能在DDL中指定6NF,你需要实现一个目录).

   • 当纯规范化结构已具有完整的Dimension-Fact功能时,为什么要实现StarSchema或SnowFlake.
     .

5. 即使你没有这样做,如果你只是做了传统的事情,并将数据库ETL到一个单独的数据仓库系统,在其中,如果你消除了重复,减少行大小,减少指数,当然它会运行得更快.否则,它违背了物理定律:胖人比瘦人跑得快; 一匹牛跑得比马快.

   • 公平地说,如果你没有标准化结构,那么请帮忙.所以他们提出了StarSchemas,SnowFlakes和各种Dimension-Fact设计.

请理解,只有不合格的,经验丰富的人才会相信所有这些神话和魔法.受过教育的有经验的人有他们来之不易的真理,他们不雇用巫医.那些"大师"只能证明胖子因为天气或星星而没有赢得比赛; 任何东西,但是这将解决问题的东西.有些人因为我是直接的而得到他们的短裤,我告诉胖人减肥; 但他们感到沮丧的真正原因是,我刺穿了他们珍爱的神话,这使他们有理由变胖.人们不喜欢改变.

• 一件事.是否有理由偏离.规则不是黑白的; 它们不是孤立的单一规则.有思想的人必须一起考虑所有这些; 根据上下文优先考虑它们.您将找不到我的数据库中的所有Idiot密钥和零Idiot密钥,但每个Id密钥都经过仔细考虑和证明.

  • 无论如何,使用最短的密钥,但使用有意义的关系密钥而不是代理项; 当钥匙变得太大而无法携带时使用代理.

  • 但永远不要从代理人开始.这严重妨碍了您理解数据的能力; 规范化; 建模数据.

    • 这里有一个问题/答案◀(很多!),这个人被困在这个过程中,甚至无法识别基本的实体和关系,因为他Id在开始时就把所有东西都放在了钥匙上.在第一次迭代中,没有讨论就解决了问题.
      .
• 好的,另一件事.学习这门课程,获得经验,并进一步了解自己.但是,即使灯亮了,也不要试图教它或转换别人,而且你很渴望.特别是如果你很热情.为什么？因为当你质疑一个巫医的建议时,整个村庄都会因为你正在攻击他们珍爱的神话,他们的安慰而诽谤你; 你需要我的经验来指导巫医(只需在评论中检查他的证据!).给它几年时间,获得真正来之不易的体验,然后再接受它们.

如果您有兴趣,请按照这个问题/答案 ◀进行几天,这将是如何遵循IDEF1X方法,如何公开和提炼这些标识符的一个很好的例子.