時間數據庫

時間數據庫（Temporal database; TemporalDB），又稱時間化資料庫或時態資料庫，是內建時間特性的資料庫。時間資料庫搭配使用時間資料模型，以及具有時間版本的結構化查詢語言。

時態數據

時態數據

傳統數據庫例如關係數據庫描述數據進入數據庫時所反映現實世界當前狀態。當這種狀態發生改變時需要通過合適的更新（插入、刪除和修改）再反映到數據庫當中，這種更新通常發生後，原先的狀態就「自然」消失。對於許多應用系統來說，只保存當前狀態是不夠的。例如銀行系統、人事系統和醫療系統等等，它們都需要着力維護相關的歷史數據信息。需要顯式表示和管理與時間相關的數據就是時態信息。時態數據的形式特徵是其由不顯含時間的數據和相應的時間標籤組成，而本質是需要將數據本身與特定的時間例如數據的生命周期等緊密結合，時間的處理和數據的管理相融相合，是數據與其相關時間的整合體，因此，常規數據庫就不能有效進行時態數據的管理。當然也可以在常規數據庫框架內通過應用程序來管理時態數據，但相應應用程序會相當複雜，也容易出錯，同時也加重時態數據用戶的負擔。

時間標籤

時態數據中數據由於其採用數據模型的不同而不同，例如採用關係模型、對象模型和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一個包含有效時間的歷史關係

Name	Title	Start of VT	End of VT
John	助教	2003-07-01	2005-09-03
John	講師	2005-09-04	2008-07-22
John	副教授	2008-07-23	Now

從表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. 過去元組的錯誤不可更正，只能查看。當人們發現元組有錯誤時，如果此事務已經提交，用戶就無能為力，只能是等待下次系統的事務時間進行新的改動。但改動的只是提交前的數據，即最近一個事務時間點的數據，此前的狀態不能再改變。
3. 回滾數據庫冗餘較多。在前一個事務時間內提交的數據，即使在下一個事務時間沒有數據改變或者改變很小時，也需進行所有數據的重新輸入及儲存，由此帶來較大的數據冗餘，這種情況在進行小的時變時更加突出。

歷史數據庫

快照數據庫考察特定時刻下現實世界的一個狀態，反應了某一個瞬間的情況。例如圖1是一個快照數據庫的例子。從表2可以知道Peter的一些基本信息。但是，對於 「Peter5年前是否為講師？」 這樣的問題，除非對數據表的結構進行特殊處理，否則將難以得到所需結果。為了解決此類問題，就需引入歷史數據庫。

表2 快照數據庫

No	Name	Birthday	Title
019504478	Peter	1969-6-6	Lecturer
019504479	James	1966-7-8	Prof.
019504480	Bush	1963-8-16	Prof.

歷史數據庫與快照數據庫的主要區別是支持有效時間。在數據庫中添加對有效時間的支持後，就可以把上表改造成新的表如表3所示。

表3 添加有效時間的數據庫

No	Name	Salary	Title	VTs	VTe
019504478	Jhon	3000	Lecturer	1991-07	1994-09
019504478	Jhon	4500	Assiant-Prof.	1994-10	2000-05
019504478	Jhon	8000	Prof.	2000-06	2003-08
019504478	Jhon	8000	President	2003-08	2006-08
019504479	White	5000	Assiant-Prof.	2002-06	2007-09
019504479	White	6500	Prof.	2007-10	NOW

對於上述問題——「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

TempSQL是在1985年由S.Gadia和S.Nair提出，作為一種類SQL的時態數據庫查詢語言，TempSQL引入了雙時態機制，數據庫可以對數據本身歷史（有效時間）、對數據進行插入、刪除和更新等的歷史（事務時間）、數據庫和用戶出錯的歷史等進行管理。TempSQL保持時態數據與靜態數據的無縫連接，而將快照數據看做是時間標籤為[now,now]的一個特例。 在TempSQL中，元組中主鍵屬性（例如學生信息元組中的學號屬性）不能隨時間變化，而非主鍵屬性（例如學生元組中「住址」、「年齡」和「聯繫方式」等屬性）在不同時間內可以有不同取值。

TQuel

TQuel是在1985年由R.Snodgrass提出，是一種基於雙時態的數據庫查詢語言。作為Quel（早期的一種非時態數據庫查詢語言）的時態擴展擴展（同時支持有效時間和事務時間管理，並且認為兩者是相互獨立和彼此正交），TQuel保持了Quel的基本風格，同時引進了各種基本時態關鍵詞，例如as-of，overlap、first，last和endof等

TSQL2

TSQL2是第一個嘗試採用規範標準的時態數據查詢語言，可以看做是SQL-92標準的時態擴充。TSQL2自1994年開始，R.Snodgrass等與ASNI和ISSQL3委員會研究合作，提出了SQL3的時態部分SQL/Temporal，其目標就是將TSQL2作為SQL/Temporal的標準。TSQL2是時態數據庫標準化過程中重要語言。TSQL2時態關係分為如下6類：

1. 快照關係：其特點是沒有時間標籤。
2. 有效時間狀態關係，其說明語句為AS valid[state]。其中state是默認值，選和不選具有同樣效果，即表示相應關係是有效時間狀態關係。
3. 有效時間事務關係，其說明語句為AS VALID EVENT，表示事件發生在某一時刻，而此時有效時間為時刻集合。
4. 事務時間關係 其表示語句為AS TRANSACTION，說明該關係中只具有事務時間。
5. 雙時態狀態關係 其說明語句為as valid[state] and transaction，其中有效時間為狀態發生保持的時間期間。
6. 雙時態事件關係 其說明語句為as valid event and TRANSACTION。和雙時態狀態關係不同，其中有效時間描述的是關係表示的事件發生時刻的集合。

時態數據庫管理系統

TDBMS基本組成

傳統數據庫管理系統（DBMS）具有支持時間和日期的數據類型，但不能直接支持和管理時態數據，關於時態方面的操作需要由另行編寫的應用程序完成。時態數據庫管理系統（TDBMS）具有提供時態數據操作和支持時態數據管理的基本功能。 一個TDBMS需要具有下述子系統：

• 時態數據定義子系統 用來定義（創建、取消和修改）各種時態數據。
• 時態數據操縱子系統 用來控制時態數據的各種基本操作。
• 時態數據查詢子系統 用來查詢各類時態數據並且提供時態語義的支持。
• 時態約束子系統 用來支持數據完整性過程中的各類時間關聯與制約，例如被參照表中主鍵有效時間期間變化時參照表中外鍵的變化等。該子系統的基本功能是保證時態數據的一致性。

TimeDB

作為時態數據庫「產品化」代表，TimeDB由A. Steiner於1998年開發的一個時態數據庫管理系統 http://www.timeconsult.com/software ，最新版本是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

TempDB https://web.archive.org/web/20120130015159/http://tempdb.scholat.com/index.asp 是由湯庸教授帶領的「中山大學數據庫與協同實驗室」（現「華南師範大學信息服務與軟件技術中心」）於2002年開發研製。作為國際上第二個和國內首個支持時態數據管理的TDBMS，TempDB在邏輯上使用雙時態數據模型，使用ATSQL2語言，支持電子政務、電子商務、決策支持等信息處理系統中的時態應用；同時，TempDB在技術上基於關係數據庫管理系統MySQL平台、採用JAVA語言進行底層開發，具有較強的可移植性以及部署方便。

TempDB與TimeDB具有下述共同之處

• 全面支持有效時間

TempDB與TimeDB都使用標準化時態查詢語言ATSQL（Applied TSQL）作為數據定義、操作和查詢的語言。ATSQL從語義上全面描述了帶有效時間的數據操作，在技術上兼容標準SQL語言的基本功能。

• 暫不支持事務時間

有效時間和事務時間的正交性，使得ATSQL對這兩方面支持的實現需要分階段處理。處理事務時間和處理有效時間具有較大差異，TempDB和TimeDB現有版本關注於有效時間處理，暫不支持事務時間和雙時態功能。

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提供統一的圖形化界面供用戶輸入語句、查看語句執行結果和中間結果，以及檢測語句執行時的可能出錯信息。

時態數據庫應用模式

按照是否處理時態屬性，應用系統可以分為傳統應用系統（非時態應用系統）和時態應用系統。時態數據庫應用模式就是在在時態應用系統系統提供時態數據處理的技術方式。根據系統處理時態屬性方式與能力，時態數據庫應用模式又可分為下述三中情形：

1. 完全時態應用模式 這是一種基於時態數據庫系統開發的應用系統，提供完全的時態數據處理支持，其特徵是系統底層使用時態數據庫管理系統TDBMS。目前還沒有TDBMS的商業化產品，而且各個主流數據庫管理系統也沒有支持時態數據管理的功能。
2. 嵌入式時態應用模式 通過一些時態處理開發工具即時態中間件實現應用系統中時態數據處理功能，其特徵是系統底層採用傳統DBMS。開發此類模式需要時態處理工具軟件支持。
3. 混合式時態應用模式 通過將時態數據處理技術與應用信息技術結合實現應用系統對時態屬性操作的支持，其特徵是系統底層也是採用傳統DBMS，目前大多數時態應用都屬於這種模式。

參考文獻

• R. Snodgrass, the TSQL2 temporal query language, kliwer academic publishers, 1995
• A. Tensel, J. Cliford, S. Gadia, et al, temporal ddatabases, theory, Design and implementation, the Benjamin cummings publishing, 1993.
• M. Vieira, A C.Costa, H. Madeira, awards timely ACID transactions in DBMS, 12th international conference on database system for advanced applications, 2007, 262-274
• Y. Masunaga New generation database technologies for collaborative work support and Apatio-temporal data management, IETCE transactions on information and systems, 1999, E82D(1),45-53
• Yong Tang, Xiaoping Ye & Na Tang Temporal Information technology and its applications， Springer/TUP, 2010 .7
• 湯庸 時態數據庫導論，北京，北京大學出版社，2004.
• 湯庸、劉海、郭歡、葉小平 TempDB：時態數據管理系統 計算機研究與發展,47（S）,442-445
• 何新貴，唐常傑，特種數據庫技術，北京，科學出版社，2000

外部連結

• TimeCenter Home. TimeCenter. University of Arizona Computer Science. （原始內容存檔於Feb 24, 2020） （英語）. 
• Temporal Relations in RDF
• Temporal Scope for RDF Triples （頁面存檔備份，存於網際網路檔案館）
• IBM DB2 10 for z/OS
• Time and Time Again （頁面存檔備份，存於網際網路檔案館） series of articles by Randy Weis and Tom Johnston
• Temporal Patterns （頁面存檔備份，存於網際網路檔案館） by Martin Fowler