为什么我们需要时态数据库？

Question

我正在阅读有关时态数据库的内容,看起来它们已经建立了时间方面.我想知道为什么我们需要这样的模型？

它与普通的RDBMS有何不同？我们不能有一个普通的数据库,即RDBMS,并说有一个触发器,它将时间戳与发生的每个事务相关联吗？可能会有性能损失.但我仍然对在市场上具有强大案例的时态数据库持怀疑态度.

目前的任何数据库都支持这样的功能吗？

Answer 1

考虑你的预约/日记日记 - 从1月1日到12月31日.现在我们可以在任何一天查询日记中的约会/日记条目.此排序称为有效时间.但是,通常不会按顺序插入约会/条目.

假设我想知道4月4日我日记里的约会/参赛作品.也就是说,4月4日我日记中存在的所有记录.这是交易时间.

鉴于可以创建和删除约会/条目等.典型的记录具有覆盖条目的期间的开始和结束有效时间以及指示条目出现在日记中的期间的开始和结束交易时间.

当日记可能经历历史修订时,这种安排是必要的.假设在4月5日我意识到我在2月14日的约会实际上发生在2月12日,即我在我的日记中发现错误 - 我可以纠正错误,以便更正有效的时间图片,但现在,我的查询是什么在4月4日的日记中是错误的,除非,约会,条目的交易时间也被存储.在那种情况下,如果我在4月4日查询我的日记,它将在2月14日显示约会,但如果我在4月6日查询它将在2月12日显示约会.

时间数据库的这种时间旅行特征使得可以记录关于如何在数据库中纠正错误的信息.这对于记录何时进行修订的数据的真实审计图片是必要的,并且允许关于如何随时间修改数据的查询.

大多数商业信息应该存储在这个双时态方案中,以便提供真实的审计记录并最大化商业智能 - 因此需要在关系数据库中提供支持.请注意,每个数据项在二维时间模型中占据(可能无界)方格,这就是人们经常使用GIST索引来实现双时态索引的原因.这里的问题是GIST索引真的是为地理数据设计的,而时态数据的要求有些不同.

PostgreSQL 9.0排除约束应该提供组织时间数据的新方法,例如事务和有效时间PERIOD不应该重叠相同的元组.

Answer 2

时间数据库通常通过具有一些固定的时间标度(例如秒或甚至毫秒)来有效地存储数据的时间序列,然后仅存储测量数据中的变化.RDBMS中的时间戳是每次测量的离散存储值,这是非常低效的.时态数据库通常用于SCADA等实时监控应用程序.一个完善的系统是来自OSISoft(http://www.osisoft.com/)的PI数据库.

Answer 3

据我了解(并且过度简化),时态数据库记录有关数据何时有效以及数据本身的事实,并允许您查询时间方面.您最终会处理"有效时间"和"交易时间"表,或涉及"有效时间"和"交易时间"方面的"双时表".你应该考虑阅读这两本书中的任何一本:

• Darwen,Date和Lorentzos" 时间数据和关系模型 "(绝版),
• (以极其不同的极端)" 在SQL中开发面向时间的数据库应用程序 ",Richard T.Snodgrass,Morgan Kaufmann Publishers,Inc.,San Francisco,July,1999,504 + xxiii pages,ISBN 1-55860-436- 7.这已经绝版了,但在他的网站cs.arizona.edu上以PDF格式提供(所以谷歌搜索让它很容易找到).

Answer 4

时态数据库通常用于金融服务行业.一个原因是很少(如果有的话)允许删除任何数据,因此记录上的ValidFrom - ValidTo类型字段用于指示记录何时正确.

Answer 5

除了“我可以用它做什么新事物”之外，考虑“它统一了哪些旧事物？”可能会有所帮助。时态数据库代表了“普通”SQL 数据库的特殊概括。因此，它可以为您以前看似无关的问题提供统一的解决方案。例如：

• Web 并发当您的数据库具有允许多个用户执行标准创建/更新/删除 (CRUD) 修改的 Web UI 时，您必须面对并发 Web 更改问题。基本上，您需要检查传入的数据修改是否不会影响自该用户上次看到这些记录以来发生更改的任何记录。但是，如果您有一个时态数据库，它很可能已经将诸如“修订 ID”之类的东西与每条记录相关联（由于难以使时间戳唯一且单调递增）。如果是这样，那么这将成为一种自然的“内置”机制，用于防止在数据库更新期间破坏其他用户的数据。
• 法律/税务记录法律系统（包括税务）比大多数程序员更重视历史数据。因此，您经常会找到有关发票模式的建议，并警告您小心删除记录或以自然方式规范化——这可能导致无法回答基本的法律问题，例如“忘记他们当前的地址，地址是什么？你把这张发票寄到 2001 年？” 有了时态框架基础，这些问题的所有阴谋（它们通常是拥有时态数据库的中途步骤）都会消失。您只需使用最自然的模式，并在有意义时删除，因为您知道您始终可以返回并准确回答历史问题。

另一方面，时间模型本身完成了修订控制的一半，这可能会激发进一步的应用。例如，假设您在 SQL 之上滚动您自己的临时工具并允许分支，就像在修订控制系统中一样。即使是有限的分支也可以很容易地提供“沙箱”——随意使用和修改数据库的能力，而不会对其他用户造成任何可见的变化。这使得在复杂数据库上提供高度逼真的用户培训变得容易。

使用简单的合并工具进行简单的分支也可以简化一些常见的工作流程问题。例如，非营利组织可能有志愿者或低薪工人进行数据输入。为每个工作人员提供自己的分支可以让主管在将其合并到“普通”用户可以看到的主分支之前，轻松地审查他们的工作或对其进行增强（例如，去重）。分支机构还可以简化权限。如果用户仅被授予使用/查看其独特分支的权限，则您不必担心防止所有可能的不需要的修改；您只会合并有意义的更改。