时间数据库（Temporal database），又称时间化数据库或时态数据库，是内建时间特性的。时间数据库搭配使用时间资料模型，以及具有时间版本的。
传统数据库例如关系数据库描述数据进入数据库时所反映现实世界当前状态。当这种状态发生改变时需要通过合适的更新（插入、删除和修改）再反映到数据库当中，这种更新通常发生后，原先的状态就“自然”消失。对于许多应用系统来说，只保存当前状态是不够的。例如银行系统、人事系统和医疗系统等等，它们都需要着力维护相关的历史数据信息。需要显式表示和管理与时间相关的数据就是时态信息。时态数据的形式特征是其由不显含时间的数据和相应的时间标签组成，而本质是需要将数据本身与特定的时间例如数据的生命周期等紧密结合，时间的处理和数据的管理相融相合，是数据与其相关时间的整合体，因此，常规数据库就不能有效进行时态数据的管理。当然也可以在常规数据库框架内通过应用程序来管理时态数据，但相应应用程序会相当复杂，也容易出错，同时也加重时态数据用户的负担。
时态数据中数据由于其采用数据模型的不同而不同，例如采用关系模型、对象模型和XML模型的时态数据分别称为时态关系、时态对象和时态XML数据。但无论那种时态数据，其中的时间标签都会根据情形选用下述的时间表示形式。
- 时间点（instant）：连续模型中的时间就是在时间轴上实数点；离散模型中的时间点就是时间轴上的一个原子时间间隔，此时，时间点和时间粒度相关。例如当时间粒度为“天”时，2011年3月1日是时间点；而当时间粒度是“秒”时，上述时间点就由系统自动换算为2005年3月1日0时0分0秒。
- 时间期间（period）：给定两个时间点t1和t2（t1≤t2），以t1为始点和以t2为终点的时间期间[t1 , t2]定义为集合{t| t是时间点并且t1≤t≤ t2}。时间点可以看作始点和终点重和的时间区间，此时的时间区间可以理解为延续时间为0的一段时间。在实际应用中，由于需要考虑时间区间兼容时间点的表示和时间区间的比较谓词，一般采用始点封闭，终点开放的“左闭右开”形式。
- 时间区间（interval）：时间区间是指持续的一段时间，其基本特征是表示该段时间的长度。例如：“1 year 3 month”、“30天”、“28个小时”等。在数据库系统内，一般用一个整数表示时间区间。时间区间有时也称为时间跨度（Time Span）。
- 时间元素（periods）：有限个时间期间（可以是时间点）的集合。有时时间元素在英文中也写为time element。时间元素对于正确有效表达复杂数据时间属性有着重要意义。
- 时间戳（timestamp）：某一天中某一秒的一个部分，通常认为是一微秒。
数据是数据内涵的重要部分。关系数据库中数据的语义考虑是其中数据间关联的基础，例如关系数据库中关系模式设计（规范化）就是关系数据语义探讨的基本体现。同样需要考虑时态数据中涉及到时间的语义。这在时态数据系统中，也称为数据的时间维度。
在时态系统中，通常考虑得是时间元素的一个集合，而且根据实际应用情形，需要讨论时间元素集合的特定语义，根据应用中实际要求，通常需要研究用户定义时间维度、有效时间维度和事务时间维度等三种基本语义情况。
用户自定义时间（User-defined Time）是用户根据自身需要或理解而定义的时间，这种时间的属性值一般是时间点，其语义由用户本身予以解释。系统通常将基于用户定义时间的时间域与其他一般属性域等同看待，相应操作与对普通字符串操作没有本质差别。例如，“生日”可能不是一种标准数据类型，但用户可以根据需要定义一个具有“生日”数据类型的属性，相应元组中对应的该属性的值为“1985-10-21”，那么这就是一种用户自定义时间。系统通常不会对其进行特别处理，用户自定义时间的提供和更新都由用户自身完成。 在传统数据库系统中，系统通常都支持用户自定义数据类型，允许用户在原有系统数据类型的基础上建立自身所需要的数据类型，其中也包括用户子定义时间数据类型。在创建或更新数据时，用户自定义数据类型和其他标准数据类型一样被用户使用。与传统数据库系统情形类似，时态数据库系统不对用户自定义时间进行任何特殊处理，不提供专门的语言支持。用户自定义时间值完全依赖于实际应用，由用户和系统以常规方式存取。
有效时间（Valid Time）是指一个对象（事件）在现实世界中发生并保持的那段时间，或者该对象在现实世界中为真的时间。 有效时间可以是单一的时间点，单一的时间区间，或者是时间点的有限集合或时间区间的有限集合，或者是整个时间域。也就是说，一条记录的属性取值可以在任意的时间点，任意的时间区间内为真。与用户自定义时间不同，当查询语句被检测到存在有效时间时态语义时，相应有效时间通过数据库系统进行解释。有效时间可以被更新，有效时间的创建和更新由用户自身完成。 有效时间有如下两个主要特点：
- 有效时间值的含义依赖于具体应用，取值是否有效由具体应用场合而定，即涉及到（时态）数据约束问题；
- 有效时间一般具有过去时间、现在时间和未来时间的基本语义。
支持有效时间数据库通常称为历史数据库（Historical Database）。历史数据库记录现实世界在有效时间点处或有效时间期间内的事件和状态变化。有效时间对事物的描述简洁直观、容易理解。表1是一个有效时间的例子。
表1一个包含有效时间的历史关系
从表1可知John身份变动历史，通过增加起始有效时间（Starting Valid Time）和终止有效时间(Ending Valid Time)2个属性列来记录数据的有效时间。但增加两个字段并不意味就可从传统关系数据管理系统变为历史数据管理系统。作为一个时态DBMS，必须支持时态数据定义语言(TDDL) ，时态数据操作语言(TDML) ，时态查询语言(Temporal Query Language)和时态约束(Temporal Constraints)。
事务时间（Transaction Time）是指对给定数据库对象进行数据操作例如插入、删除或修改的时间，是一个事实进入并存储于数据库当中的时间。事务时间记录对数据库更新的各种操作历史，对应于现有事务或现有数据库状态变迁的历史。例如，数据录入数据库的时间，对其进行查询的时间，对其进行删除或修改的时间。 事务时间对应于现有事务或现有数据库的状态变迁历史，独立于相应实际应用，用户不能对事务时间进行任何处理。数据库中数据录入、修改和删除的时间由系统时钟决定，每次更新后数据不可再予以改变，因此，事务时间也称为系统时间（system time）。处理事务时间的方法是存储所有数据库的状态，即处理一个事务之后就存储一种数据库状态。任何对数据的更新只能对最后一个状态进行，但可查询任意一个状态。事务时间有如下主要特点：
- 事务时间的值由系统时钟给出，独立于应用，不允许用户对事务时间进行任何修改。
- 事务时间不能晚于当前时间，它反映数据库实际操作的时间，不能表示未来时间。
支持事务时间的数据库称为回滚数据库（Rollback Database）。回滚数据库记录数据库的自身变化，实现方式是沿着事务时间轴记录数据状态，按照事务时间排序，保留所有状态的演变历史。回滚数据库可被看作是只能追加记录的数据库，不能用来记录数据库的未来状态。
时态数据库的分类基础是数据的时间维度
快照数据库（Snapshot Database）以在特定时刻瞬间快照建立模型。现实世界是变化的，快照数据库可以反映其某一个瞬间的情况。快照数据库无法表示属性与时间的关系，没有维护状态变迁的能力，只进行当前数据库状态的查询和更新，不能进行以往历史数据的查询，而且随着时间演进，其更改的历史数据将会丢失。它也不能进行含有时间因素的推理。快照数据库实际上是一种非时态数据库，它反映数据的当前状态，时间推移将导致数据库状态不断改变，新状态将覆盖旧的状态。 快照数据库由静态的二维关系表组成，分别是属性维和元组维。数据库状态变迁由事务实现，一旦事务提交，其状态变迁就立即生效，原来数据库状态也就完全丢失。
图1表示了快照数据库的特性。
快照数据库中无法表示属性与时间的关系，没有维护状态变迁的能力，不能够进行与时间相关的任何工作，快照数据库无法回答以下一些问题。
- “raul何时当的讲师？（如果他现在是副教授）”（历史查询）
- “2006年9月18日的记录中，Green的职务是什么？”（历史查询）
- “在过去的3年里，该大学有多少人从副教授提升为正教授？”（趋势查询）
- “明年，Raul还会成为正教授么？”（未来查询）
- “jones上个月被提升为副教授”（记录更新）
快照数据库状态之间转变的确切时刻是发生在Commit的时刻。这种数据库称为“快照数据库”，意思是它只把握数据库的当前的一个快照状态，“快照”状态是随着时间在不断改变的。这里所说的“快照”和关系数据库中的“快照”的概念不同：关系数据库中快照是为了处理的需要（比如年底结帐的需要）对某个时刻（12月31日23时59分59秒）数据库中的数据进行独立的数据备份。而这里使用的“快照”只是指数据库只保留一个数据库状态（通常是当前状态）的性质。 从时态数据库的观点来看，快照数据库不区分事务时间和有效时间。快照数据库中的基本假定是：存储在系统中的元组一定是现实世界中的有效事实。
回滚数据库(Rollback Database)支持事务时间，它按事务时间进行编址，保存过去每次事务提交，状态演变之前的状态。回滚数据库由三维的回滚关系组成，在属性维和元组维的基础上增加了事务时间维，因此可看作一个按时间编址的瞬象序列。每一个时间点都对应于一个二维快照数据库。 回滚数据库不足之处主要有下述几点：
- 回滚数据库按照事务时间编址，记录数据库状态变迁的历史，而不是现实世界变化的历史。现实世界中元组属性在某个时间点（属性的有效时间）变化了，但因为数据库在这个时间点没有执行事务，即数据库事务时间没有改变，此时，元组时变属性的改变在数据库中没有体现出来。
- 过去元组的错误不可更正，只能查看。当人们发现元组有错误时，如果此事务已经提交，用户就无能为力，只能是等待下次系统的事务时间进行新的改动。但改动的只是提交前的数据，即最近一个事务时间点的数据，此前的状态不能再改变。
- 回滚数据库冗余较多。在前一个事务时间内提交的数据，即使在下一个事务时间没有数据改变或者改变很小时，也需进行所有数据的重新输入及储存，由此带来较大的数据冗余，这种情况在进行小的时变时更加突出。
快照数据库考察特定时刻下现实世界的一个状态，反应了某一个瞬间的情况。例如图1是一个快照数据库的例子。从表2可以知道Peter的一些基本信息。但是，对于 “Peter5年前是否为讲师？” 这样的问题，除非对数据表的结构进行特殊处理，否则将难以得到所需结果。为了解决此类问题，就需引入历史数据库。
表2 快照数据库
历史数据库与快照数据库的主要区别是支持有效时间。在数据库中添加对有效时间的支持后，就可以把上表改造成新的表如表3所示。
表3 添加有效时间的数据库
对于上述问题——“Jhon 5年前是不是讲师？”。假如现在是2003年，那么可知5年前，即1998年Jhon已经不是讲师，而是副教授。 从这个例子可以看到，加入了有效时间的历史数据库可以大大增加系统包含的信息量，方便人们对信息的处理。
回滚数据库和历史数据库各具优点，因此，可以设计一种数据库，使它既支持事务时间又支持有效时间，这就是双时态数据库（Bitemporal Database）。双时态数据库集成了前三种类型数据库的基本功能特性，储存了数据库和现实世界两者发展的历史。 双时态数据库由时态关系组成，其时态关系是一个四维结构。其中两维是属性和元组，另外两维是事务时间和有效时间，一个时态关系可以看成是一个历史关系的序列。对时态关系的一个回滚操作则是选取了一个特定的历史关系，可对该历史关系进行查询。而每一个事务则引起一个新的历史关系的建立。双时态数据库如图2所示。
图2 双时态数据库
双时态关系的一种实现方法就是组合回滚数据库和历史数据库成为新的数据库。 图3是一个元组的四个历史数据库中的有效时间片断组合。我们只是在原来的三维结构的基础之上加了第四维有效时间维，使得数据库变为四个维结构，元组维和属性维与原来无异，故不在此给出。
图3 双时态数据库的两个时间维
只要在事务维中任意截取事务时间点就可以找到相应的元组的有效时间段，不同的事务时间点对应不同的有效时间段（一般是这样的，当然也有有效时间段是一样的不同事务时间点，如事务时间点T1 和T2 的有效时间段是一样的）。 可以看出，在事务时间轴上，取不同的时间点，就产生不同的历史数据库，我们可以对上图中的对应于四个事务时间点T1，T2，T3，T4的历史数据库进行查询操作。当然图中所示的只是一个元组的四个历史数据库中的有效时间片断组合，对于其他元组的情况可以类似的进行推理，而后，这些元组组合到一起即形成了四个不同的历史数据库。 所以，这四个历史数据库也可以成为是快照历史数据库，说是快照，是因为这四个数据库是分别是四个事务时间的快照；说是历史数据库，是因为每个数据库里面的纪录是历史数据库属性的，记载的是现实元组的真实变化的时间，而非数据库状态变化的时间，我们可以在这四个数据库里面进行增加、改正、删除及查询的工作。 在双时态数据库中，我们可以在当前时间对以前的事务时间T1时的该元组属性或有效时间进行改动。例如，可以在T4时间对T1时的历史快照数据库进行修改，通过改变有效时间区间t1，t2和t3为t1和 t3。可使得在T1时的快照历史数据库中的元组属性（时间属性）得到了改变。但原先事务时间不能改动，只是增加了一个新的纪录，该记录的事务时间是T4，记录内容是把原来的有效时间进行了改变。 由此可见，双时态数据库具有回滚数据库和历史数据库的特性，在保存数据库变迁历史的同时，也保存了现实世界的真实的数据属性，真正体现了对数据时态属性的全面支持。当然，时态数据库是以牺牲大容量的储存空间为代价的，对双时态数据库的储存进行优化是时态数据库研究的一个重要工作。
目前，时态数据查询语言主要由下述三种类型。
TempSQL是在1985年由S.Gadia和S.Nair提出，作为一种类SQL的时态数据库查询语言，TempSQL引入了双时态机制，数据库可以对数据本身历史（有效时间）、对数据进行插入、删除和更新等的历史（事务时间）、数据库和用户出错的历史等进行管理。TempSQL保持时态数据与静态数据的无缝连接，而将快照数据看做是时间标签为[now,now]的一个特例。 在TempSQL中，元组中主键属性（例如学生信息元组中的学号属性）不能随时间变化，而非主键属性（例如学生元组中“住址”、“年龄”和“联系方式”等属性）在不同时间内可以有不同取值。
TQuel是在1985年由R.Snodgrass提出，是一种基于双时态的数据库查询语言。作为Quel（早期的一种非时态数据库查询语言）的时态扩展扩展（同时支持有效时间和事务时间管理，并且认为两者是相互独立和彼此正交），TQuel保持了Quel的基本风格，同时引进了各种基本时态关键词，例如as-of，overlap、first，last和endof等
TSQL2是第一个尝试采用规范标准的时态数据查询语言，可以看做是SQL-92标准的时态扩充。TSQL2自1994年开始，R.Snodgrass等与ASNI和ISSQL3委员会研究合作，提出了SQL3的时态部分SQL/Temporal，其目标就是将TSQL2作为SQL/Temporal的标准。TSQL2是时态数据库标准化过程中重要语言。TSQL2时态关系分为如下6类：
- 快照关系：其特点是没有时间标签。
- 有效时间状态关系，其说明语句为AS valid[state]。其中state是默认值，选和不选具有同样效果，即表示相应关系是有效时间状态关系。
- 有效时间事务关系，其说明语句为AS VALID EVENT，表示事件发生在某一时刻，而此时有效时间为时刻集合。
- 事务时间关系 其表示语句为AS TRANSACTION，说明该关系中只具有事务时间。
- 双时态状态关系 其说明语句为as valid[state] and transaction，其中有效时间为状态发生保持的时间期间。
- 双时态事件关系 其说明语句为as valid event and TRANSACTION。和双时态状态关系不同，其中有效时间描述的是关系表示的事件发生时刻的集合。
传统数据库管理系统（DBMS）具有支持时间和日期的数据类型，但不能直接支持和管理时态数据，关于时态方面的操作需要由另行编写的应用程序完成。时态数据库管理系统（TDBMS）具有提供时态数据操作和支持时态数据管理的基本功能。 一个TDBMS需要具有下述子系统：
- 时态数据定义子系统 用来定义（创建、取消和修改）各种时态数据。
- 时态数据操纵子系统 用来控制时态数据的各种基本操作。
- 时态数据查询子系统 用来查询各类时态数据并且提供时态语义的支持。
- 时态约束子系统 用来支持数据完整性过程中的各类时间关联与制约，例如被参照表中主键有效时间期间变化时参照表中外键的变化等。该子系统的基本功能是保证时态数据的一致性。
作为时态数据库“产品化”代表，TimeDB由A. Steiner于1998年开发的一个时态数据库管理系统 ，最新版本是2.2版。TimeDB是传统数据库管理系统的前端软件，用户使用ATSQL2语句描述应用中时态操作，然后由TimeDB转换后形成标准SQL语句，这些标准SQL语句传输到后台关系数据库中进行实际数据的操作。TimeDB初步实现了时态查询、时态更新、时态视图和部分时态完整性约束等基本时态功能，同时也兼容非时态数据操作。 TimeDB 1.0版本由Andreas使用SICStus Prolog语言开发，运行在SWI Prolog环境中。 TimeDB 2.0版本使用Java语言开发，具有平台无关特征；基于JDBC访问数据库，可以在IBM Cloudscape、Oracle、Sybase等多种数据库管理系统之上使用；具有较友好的用户界面；优化了辅助表创建过程；具有本地调用接口TDBCI，可供Java应用程序调用以执行ATSQL2语句。 TimeDB 2.1版本开始使用Java SDK 1.4版本，支持Cloudscape 10； TimeDB 2.2版本加入了对Oracle 10g的支持。
TempDB 是由汤庸教授带领的“中山大学数据库与协同实验室”（现“华南师范大学信息服务与软件技术中心”）于2002年开发研制。作为国际上第二个和国内首个支持时态数据管理的TDBMS，TempDB在逻辑上使用双时态数据模型，使用ATSQL2语言，支持电子政务、电子商务、决策支持等信息处理系统中的时态应用；同时，TempDB在技术上基于关系数据库管理系统MySQL平台、采用JAVA语言进行底层开发，具有较强的可移植性以及部署方便。
- 全面支持有效时间
TempDB与TimeDB都使用标准化时态查询语言ATSQL（Applied TSQL）作为数据定义、操作和查询的语言。ATSQL从语义上全面描述了带有效时间的数据操作，在技术上兼容标准SQL语言的基本功能。
- 暂不支持事务时间
有效时间和事务时间的正交性，使得ATSQL对这两方面支持的实现需要分阶段处理。处理事务时间和处理有效时间具有较大差异，TempDB和TimeDB现有版本关注于有效时间处理，暂不支持事务时间和双时态功能。
- 时态完整性
时态完整性分为：时态实体完整性，时态参照完整性和用户定义的完整性三种类型。TempDB和TimeDB只实现了时态实体完整性，而 TempDB中实现了TRICU（Temporal Referential Integrity Constraints and Temporal Update）模型，具有较好的时态完整性约束能力。
- 时态归并操作
时态归并是数据时态处理的基本操作，通常分为运行归并和更新归并两种情形。TimeDB只实现了时态运行时归并功能。而TempDB同时实现了两种归并数。在TempDB数据库中，不会出现时间戳相邻而用户定义属性完全相同的（未可归并）情形。
- 时态变量
时态变量使用对于时态数据库运行效率影响很大。TimeDB并不支持带有时态变量now的时态操作，其中Now仅是当前时间的别名，而TempDB能支持基于Now语义复杂操作，支持不确定时态语义查询。
- 时态语言规范
TempDB和TimeDB都支持ATSQL语言，但对该语言BNF定义存在差异。TimeDB定义了ATSQL2的 BNF语法，但语法模糊性较大。TempDB修正了ATSQL2缺陷，形成更为合理严密的BNF定义，语义处理模块更为清晰规范。
- 体系结构
TimeDB的词法和语法分析采用字符串识别方法，不生成语法树，边解释边执行，效率较为理想，但模块间高，可重用性低。TempDB的词法分析和语法分析独立于其它模块，具有生成语法树、变形语法树、生成底层数据库可执行语句等处理过程。模块之间耦合度低，模块的可重用性高，处理效率稍低。
- 用户界面
TimeDB只提供了图形化的输入界面，用户可在对话框中输入ATSQL语句，但执行结果以文本形式显示在命令行界面中。当表字段增多或字段值较长时易造成显示混乱。TempDB提供统一的图形化界面供用户输入语句、查看语句执行结果和中间结果，以及检测语句执行时的可能出错信息。