问题标签 [temporal-database]

我正在寻找一种将时间意识尽可能直接地整合到我的课程中的方法。我处理的是随时间变化很大的数据，比如股价，所以这可能需要一些注意，并在一个地方处理以确保“关注点分离”。

您在时态数据/数据库方面有类似的经验吗？

你可以推荐阅读/了解什么？

（我正在考虑将我的计算包装在 TimeSlice(date) 计算表达式构建器中，以便将检索范围限定到构成我计算的“范围”的指定日期。像

我想知道如何使用 EclipseLink 在 JPA 2中实现临时表。我所说的时间是指定义有效期的表格。

我面临的一个问题是引用表不能再对被引用表（临时表）有外键约束，因为被引用表的性质现在它们的主键包括有效期。

• 我将如何映射我的实体的关系？
• 这是否意味着我的实体不再与那些有效时间实体有关系？
• 现在初始化这些关系的责任是否应该由我在某种服务或专门的 DAO 中手动完成？

我发现的唯一东西是一个名为DAO Fusion的框架来处理这个问题。

• 有没有其他方法可以解决这个问题？
• 您能否提供有关此主题的示例或资源（带有时态数据库的 JPA）？

这是一个数据模型及其类的虚构示例。它从一个不需要处理时间方面的简单模型开始：

第一种情况：非时间模型

数据模型：

团队：

播放器：

测试类：

现在您被要求保留团队和玩家在某个时间点的历史记录，因此您需要为每个要跟踪的表添加一个时间段。所以让我们添加这些时间列。我们将从Player.

第二个场景：时间模型

数据模型：

如您所见，我们必须删除主键并定义另一个包含日期（句点）的主键。我们还必须删除唯一约束，因为现在它们可以在表中重复。现在该表可以包含当前条目以及历史记录。

如果我们还必须使 Team temporal 变得非常难看，在这种情况下，我们需要删除Playertable 必须的外键约束Team。问题是您将如何在 Java 和 JPA 中对其进行建模。

请注意，ID 是代理键。但是现在代理键必须包含日期，因为如果不包含日期，则不允许存储同一实体的多个“版本”（在时间轴期间）。

我有一个项目，其中 SQL2011 规范中定义的 PERIOD 列是完美的解决方案。不幸的是，我被迫使用 MSSQL 2008R2（或者可能是 MSSQL 2012）作为我的数据库，它不支持此功能。

是否有任何类似于当前在 MSSQL 中的 SQL2011 中的 PERIOD 功能的专有功能？如果没有，对于尝试实现类似的东西的最佳方法有什么建议吗？

我目前正在尝试创建一个数据库，其中很大一部分数据是临时的。在阅读了许多这样做的技术（大多数涉及 6nf 标准化）后，我遇到了Anchor Modeling。

我正在开发的模式与锚建模模型非常相似，特别是因为用例（时间数据 + 已知未知数）非常相似，以至于我很想完全接受它。

我遇到的两个最大问题是，我找不到任何详细说明这种方法的负面影响的东西，而且我找不到任何关于在生产中使用它来制作我需要注意的战争故事和陷阱的组织的参考资料。

我想知道这里是否有人足够熟悉来简要阐述一些负面因素（因为积极因素在研究论文及其网站中得到了很好的宣传），以及在生产环境中使用它的任何经验。

需要明确的是，当我说敏捷时，我并不是指在敏捷开发过程中。我的意思是一个不断发展的数据模型，可以添加和管理新的对象属性。

我正在尝试解决一个 Web 应用程序挑战，它允许用户为数据输入创建新的内容表单，可以通过添加（或可能修改）其他字段来改进（可能版本化）。这本身就是一种直截了当。每个用户的内容表单都会有一个动态创建的视图和触发器来处理读/写，并且当对内容表单结构进行更改时，将动态创建基础表。数据输入将仅使用触发器进行写入，而视图将用于读取。

我正在寻找的建议是，是否存在有助于应对此类挑战的现有数据库建模技术或数据库类型。该应用程序将对更改跟踪、历史查看、完全不同的内容形式之间的迁移等有更多要求。可能还会在顶部添加一些基于授权的复杂 Web 应用程序查看。

我仔细研究了Anchor Modeling，虽然它具有双时态建模方面，并且它的 6NF 允许敏捷模式开发，但不清楚如何将它从开发良好的模型转换为 SQL 脚本，再到可以演变内容的 Web 应用程序数据。也许我看错了，但我不想修改 Anchor 模型中的任何触发器或视图，而且我认为我不能用它创建一个可以按需扩展的模型。将需要建模工具来安全地进行更改。

我仍然需要更多地研究一些可用的 NoSQL 数据库。MongoDB的面向文档的存储看起来非常有趣。

任何有关这些工具或所描述的数据建模挑战的建议或经验都将非常受欢迎！感谢您提前提供任何答案。

我正在寻找一个合适的过程来保存数据库中行（及其关系）的修订或快照。

以电子商务平台为例-

• 客户创建订单。订单与帐单地址和送货地址相关联。
• 所述客户然后在他们的个人资料中更改他们的地址簿中的地址。
• 原始订单的地址不应更改。

我看过一些概念，一个是重复表，另一个是临时数据库，另一个是保留修订 ID 和活动标志。

虽然我很感激没有人能真正告诉我最好/最适合我的应用程序的解决方案，因为这是一个开放的意见等问题，我希望有人能够通过比较来证明优点/缺点。我已经阅读了很多关于 SO 的问题，以及一些关于各种实现的文章，但没有人真正比较每个想法或指出它们最适合的地方。下面我概述了我对每个概念的理解。

重复表

将信息存储在与需要与之生成快照的数据相关的行中。即在在线商店的订单表的列中保留地址。

好处

• 数据被分割成明确相关的表，不需要连接等。
• 无需按照以下概念的要求仅选择活动行。
• 假设行带有时间戳，则保留时态数据库的大部分好处

缺点

• 复制
  • 模式（当多个表向上修订时特别有问题）
  • 使用 ORM 时的模型。
  • 如果快照片段数据没有更改并且被重用，则数据的数量。即下单10次，地址存储11次（订单+当前）
• 处理插入相关表所需的额外代码。

时态数据库/活动或当前行标志

“时间感知”的数据库行，即它们的上下文是两个日期时间之间的时间。可以在时间上下文位于时态表之间的位置连接数据。

好处

• 没有模式或模型的重复。在一处进行的更改。
• ORM 模型可以无缝地处理新行的创建、标记为活动等。
• 不复制未进行更改的行。即 10 个订单到 1 个地址存储一次地址。

缺点

• 查询变得更加复杂，因为连接/where 子句需要选择“活动”行。
• 表格被未定期选择/调用的历史数据堵塞。

仅存储更改的列，时间。

有一个表来跟踪所有表的更改，并注意它所涉及的行以及它在时间方面何时有效。

好处

• 在修订方面优化存储，因为未复制未复制的未更改数据。

缺点

• 将列的版本与其他数据结合起来的查询要复杂得多。

我已经在 SO 上查看了以下问题，以及这些其他资源

编辑：我没有用特定的 DBMS 标记这篇文章的原因是我希望这个概念尽可能多地与平台一起工作，目前是 DBMS 独立的，抽象层允许它与 MySQL 和MSSQL，但希望将来会支持其他人。

• 用于修订的数据库设计？
• Fowler 时间表达式的关系模式
• 文本修订的数据库设计
• 以有效的方式存储关系对象的修订
• 保留页面更改历史记录。有点像 SO 对修订所做的
• 在数据库中维护历史
• http://en.wikipedia.org/wiki/Temporal_database
• http://www.simple-talk.com/sql/database-administration/database-design-a-point-in-time-architecture/

我有一个时态数据库，我想对以下方面的数据进行平均：`

例如：

13 = 观察期 12:41 至 13:40。预期成绩：

代码应从 (HH-1):41 中减去 HH:40 的瞬时值。

样本数据：

此外 date_time 列是时间戳格式。平均线不应该是移动平均线，我对简单平均线很感兴趣。

Coloroaldo 提出的代码：

我有一个时间数据库，我想通过使用以下时间序列中的数据通过时间序列数据的平均函数执行时间聚合：

此外，上述值是瞬时值。

样本数据：

和预期结果：

每小时平均 0:00 = (-1.68+-1.64+-1.87+-1.90+-2.18+-1.86)/6

我有一个采样频率为 2 分钟的时态数据库，我想将瞬时每小时值提取为每天 00:00、01:00、02、... 23。
所以，我想从平均值中得到平均值：

HH-1:58、HH:00 和 HH:02 = HH 点钟的平均值

或者

HH-1:59、HH:01 和 HH:03 = HH 点钟的平均值

样本数据1：

预期结果：

对于 00 午夜：

(-1.92+-1.64+-1.76)/3

样本数据2：

预期成绩：

(-2.01+-1.52+-1.48)/3

我有一个时间数据库，我想通过平均函数聚合每个 HH 瞬时值，前 5 分钟和后 5 分钟。数据采样频率为 2 分钟，数据包括时间戳和温度列。首先，代码应该从 00, 01, 02, 03, ... 24 中提取瞬时值，然后在瞬时时间之前应用 2 次观察和之后的 2 次观察。此外，在 db 中，有时分钟是奇数，有时是偶数。因此，我们同时拥有 HH-1:59 和 HH:00 。平均值取自 5 个值的平均值。date_time 列的格式是时间戳。此外，代码应该可以处理多天的数据。

样本数据：

预期成绩：

16 点钟的小时平均值为：5.7=5.36+5.80+6.06+5.70+5.58

我已经尝试过这段代码，但它不能正常工作。