時間資料庫

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

時態資料

1.1 時態資料

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

1.2 時間標籤

時態資料中資料由於其採用資料模型的不同而不同，例如採用關係模型、物件模型和 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）：某一天中某一秒的一個部分，通常認為是一微秒。

時態資料庫

資料是資料內涵的重要部分。關係資料庫中資料的語義考慮是其中資料間關聯的基礎，例如關係資料庫中關係模式設計（規範化）就是關係資料語義探討的基本體現。同樣需要考慮時態資料中涉及到時間的語義。這在時態資料系統中，也稱為資料的時間維度。

2.1 資料的時間維度

在時態系統中，通常考慮得是時間元素的一個集合，而且根據實際應用情形，需要討論時間元素集合的特定語義，根據應用中實際要求，通常需要研究使用者定義時間維度、有效時間維度和事務時間維度等三種基本語義情況。

2.1.1 使用者自定義時間

使用者自定義時間（User-defined Time）是使用者根據自身需要或理解而定義的時間，這種時間的屬性值一般是時間點，其語義由使用者本身予以解釋。系統通常將基於使用者定義時間的時間域與其他一般屬性域等同看待，相應操作與對普通字串操作沒有本質差別。例如，“生日” 可能不是一種標準資料型別，但使用者可以根據需要定義一個具有 “生日” 資料型別的屬性，相應元組中對應的該屬性的值為 “1985-10-21”，那麼這就是一種使用者自定義時間。系統通常不會對其進行特別處理，使用者自定義時間的提供和更新都由使用者自身完成。

在傳統資料庫系統中，系統通常都支援使用者自定義資料型別，允許使用者在原有系統資料型別的基礎上建立自身所需要的資料型別，其中也包括使用者子定義時間資料型別。在建立或更新資料時，使用者自定義資料型別和其他標準資料型別一樣被使用者使用。與傳統資料庫系統情形類似，時態資料庫系統不對使用者自定義時間進行任何特殊處理，不提供專門的語言支援。使用者自定義時間值完全依賴於實際應用，由使用者和系統以常規方式存取。

2.1.2 有效時間

有效時間（Valid Time）是指一個物件（事件）在現實世界中發生並保持的那段時間，或者該物件在現實世界中為真的時間。

有效時間可以是單一的時間點，單一的時間區間，或者是時間點的有限集合或時間區間的有限集合，或者是整個時間域。也就是說，一條記錄的屬性取值可以在任意的時間點，任意的時間區間內為真。與使用者自定義時間不同，當查詢語句被檢測到存在有效時間時態語義時，相應有效時間透過資料庫系統進行解釋。有效時間可以被更新，有效時間的建立和更新由使用者自身完成。

有效時間有如下兩個主要特點：

有效時間值的含義依賴於具體應用，取值是否有效由具體應用場合而定，即涉及到（時態）資料約束問題；
有效時間一般具有過去時間、現在時間和未來時間的基本語義。

支援有效時間資料庫通常稱為歷史資料庫（Historical Database）。歷史資料庫記錄現實世界在有效時間點處或有效時間期間內的事件和狀態變化。有效時間對事物的描述簡潔直觀、容易理解。表 1 是一個有效時間的例子。

表 1 一個包含有效時間的歷史關係

從表 1 可知 John 身份變動歷史，透過增加起始有效時間（Starting Valid Time）和終止有效時間 (Ending Valid Time) 2 個屬性列來記錄資料的有效時間。但增加兩個欄位並不意味就可從傳統關係資料管理系統變為歷史資料管理系統。作為一個時態 DBMS，必須支援時態資料定義語言 (TDDL) ，時態資料操作語言 (TDML) ，時態查詢語言 (Temporal Query Language) 和時態約束 (Temporal Constraints)。

2.1.3 事務時間

事務時間（Transaction Time）是指對給定資料庫物件進行資料操作例如插入、刪除或修改的時間，是一個事實進入並存儲於資料庫當中的時間。事務時間記錄對資料庫更新的各種操作歷史，對應於現有事務或現有資料庫狀態變遷的歷史。例如，資料錄入資料庫的時間，對其進行查詢的時間，對其進行刪除或修改的時間。

事務時間對應於現有事務或現有資料庫的狀態變遷歷史，獨立於相應實際應用，使用者不能對事務時間進行任何處理。資料庫中資料錄入、修改和刪除的時間由系統時鐘決定，每次更新後資料不可再予以改變，因此，事務時間也稱為系統時間（system time）。處理事務時間的方法是儲存所有資料庫的狀態，即處理一個事務之後就儲存一種資料庫狀態。任何對資料的更新只能對最後一個狀態進行，但可查詢任意一個狀態。事務時間有如下主要特點：

事務時間的值由系統時鐘給出，獨立於應用，不允許使用者對事務時間進行任何修改。
事務時間不能晚於當前時間，它反映資料庫實際操作的時間，不能表示未來時間。

支援事務時間的資料庫稱為回滾資料庫（Rollback Database）。回滾資料庫記錄資料庫的自身變化，實現方式是沿著事務時間軸記錄資料狀態，按照事務時間排序，保留所有狀態的演變歷史。回滾資料庫可被看作是隻能追加記錄的資料庫，不能用來記錄資料庫的未來狀態。

2.2 時態資料庫

時態資料庫的分類基礎是資料的時間維度

2.2.1 快照資料庫

快照資料庫（Snapshot Database）以在特定時刻瞬間快照建立模型。現實世界是變化的，快照資料庫可以反映其某一個瞬間的情況。快照資料庫無法表示屬性與時間的關係，沒有維護狀態變遷的能力，只進行當前資料庫狀態的查詢和更新，不能進行以往歷史資料的查詢，而且隨著時間演進，其更改的歷史資料將會丟失。它也不能進行含有時間因素的推理。快照資料庫實際上是一種非時態資料庫，它反映資料的當前狀態，時間推移將導致資料庫狀態不斷改變，新狀態將覆蓋舊的狀態。

快照資料庫由靜態的二維關係表組成，分別是屬性維和元組維。資料庫狀態變遷由事務實現，一旦事務提交，其狀態變遷就立即生效，原來資料庫狀態也就完全丟失。

圖 1 表示了快照資料庫的特性。

快照資料庫中無法表示屬性與時間的關係，沒有維護狀態變遷的能力，不能夠進行與時間相關的任何工作，快照資料庫無法回答以下一些問題。

“raul 何時當的講師？（如果他現在是副教授）”（歷史查詢）
“2006 年 9 月 18 日的記錄中，Green 的職務是什麼？”（歷史查詢）
“在過去的 3 年裡，該大學有多少人從副教授提升為正教授？”（趨勢查詢）
“明年，Raul 還會成為正教授麼？”（未來查詢）
“jones 上個月被提升為副教授”（記錄更新）

快照資料庫狀態之間轉變的確切時刻是發生在 Commit 的時刻。這種資料庫稱為 “快照資料庫”，意思是它只把握資料庫的當前的一個快照狀態，“快照” 狀態是隨著時間在不斷改變的。這裡所說的 “快照” 和關係資料庫中的 “快照” 的概念不同：關係資料庫中快照是為了處理的需要（比如年底結帳的需要）對某個時刻（12 月 31 日 23 時 59 分 59 秒）資料庫中的資料進行獨立的資料備份。而這裡使用的 “快照” 只是指資料庫只保留一個數據庫狀態（通常是當前狀態）的性質。

從時態資料庫的觀點來看，快照資料庫不區分事務時間和有效時間。快照資料庫中的基本假定是：儲存在系統中的元組一定是現實世界中的有效事實。

2.2.2 回滾資料庫

回滾資料庫 (Rollback Database) 支援事務時間，它按事務時間進行編址，儲存過去每次事務提交，狀態演變之前的狀態。回滾資料庫由三維的回滾關係組成，在屬性維和元組維的基礎上增加了事務時間維，因此可看作一個按時間編址的瞬象序列。每一個時間點都對應於一個二維快照資料庫。

回滾資料庫不足之處主要有下述幾點：

回滾資料庫按照事務時間編址，記錄資料庫狀態變遷的歷史，而不是現實世界變化的歷史。現實世界中元組屬性在某個時間點（屬性的有效時間）變化了，但因為資料庫在這個時間點沒有執行事務，即資料庫事務時間沒有改變，此時，元組時變屬性的改變在資料庫中沒有體現出來。
過去元組的錯誤不可更正，只能檢視。當人們發現元組有錯誤時，如果此事務已經提交，使用者就無能為力，只能是等待下次系統的事務時間進行新的改動。但改動的只是提交前的資料，即最近一個事務時間點的資料，此前的狀態不能再改變。
回滾資料庫冗餘較多。在前一個事務時間內提交的資料，即使在下一個事務時間沒有資料改變或者改變很小時，也需進行所有資料的重新輸入及儲存，由此帶來較大的資料冗餘，這種情況在進行小的時變時更加突出。

2.2.3 歷史資料庫

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

表 2 快照資料庫

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

表 3 新增有效時間的資料庫

對於上述問題 ——“Jhon 5 年前是不是講師？”。假如現在是 2003 年，那麼可知 5 年前，即 1998 年 Jhon 已經不是講師，而是副教授。

從這個例子可以看到，加入了有效時間的歷史資料庫可以大大增加系統包含的資訊量，方便人們對資訊的處理。

2.2.4 雙時態資料庫

回滾資料庫和歷史資料庫各具優點，因此，可以設計一種資料庫，使它既支援事務時間又支援有效時間，這就是雙時態資料庫（Bitemporal Database）。雙時態資料庫集成了前三種類型資料庫的基本功能特性，儲存了資料庫和現實世界兩者發展的歷史。

雙時態資料庫由時態關係組成，其時態關係是一個四維結構。其中兩維是屬性和元組，另外兩維是事務時間和有效時間，一個時態關係可以看成是一個歷史關係的序列。對時態關係的一個回滾操作則是選取了一個特定的歷史關係，可對該歷史關係進行查詢。而每一個事務則引起一個新的歷史關係的建立。雙時態資料庫如圖 2 所示。

圖 2 雙時態資料庫

雙時態關係的一種實現方法就是組合回滾資料庫和歷史資料庫成為新的資料庫。

圖 3 是一個元組的四個歷史資料庫中的有效時間片斷組合。我們只是在原來的三維結構的基礎之上加了第四維有效時間維，使得資料庫變為四個維結構，元組維和屬性維與原來無異，故不在此給出。

圖 3 雙時態資料庫的兩個時間維

只要在事務維中任意擷取事務時間點就可以找到相應的元組的有效時間段，不同的事務時間點對應不同的有效時間段（一般是這樣的，當然也有有效時間段是一樣的不同事務時間點，如事務時間點 T1 和 T2 的有效時間段是一樣的）。

可以看出，在事務時間軸上，取不同的時間點，就產生不同的歷史資料庫，我們可以對上圖中的對應於四個事務時間點 T1，T2，T3，T4 的歷史資料庫進行查詢操作。當然圖中所示的只是一個元組的四個歷史資料庫中的有效時間片斷組合，對於其他元組的情況可以類似的進行推理，而後，這些元組組合到一起即形成了四個不同的歷史資料庫。

所以，這四個歷史資料庫也可以成為是快照歷史資料庫，說是快照，是因為這四個資料庫是分別是四個事務時間的快照；說是歷史資料庫，是因為每個資料庫裡面的紀錄是歷史資料庫屬性的，記載的是現實元組的真實變化的時間，而非資料庫狀態變化的時間，我們可以在這四個資料庫裡面進行增加、改正、刪除及查詢的工作。

在雙時態資料庫中，我們可以在當前時間對以前的事務時間 T1 時的該元組屬性或有效時間進行改動。例如，可以在 T4 時間對 T1 時的歷史快照資料庫進行修改，透過改變有效時間區間 t1，t2 和 t3 為 t1 和 t3。可使得在 T1 時的快照歷史資料庫中的元組屬性（時間屬性）得到了改變。但原先事務時間不能改動，只是增加了一個新的紀錄，該記錄的事務時間是 T4，記錄內容是把原來的有效時間進行了改變。

由此可見，雙時態資料庫具有回滾資料庫和歷史資料庫的特性，在儲存資料庫變遷歷史的同時，也儲存了現實世界的真實的資料屬性，真正體現了對資料時態屬性的全面支援。當然，時態資料庫是以犧牲大容量的儲存空間為代價的，對雙時態資料庫的儲存進行最佳化是時態資料庫研究的一個重要工作。

時態資料查詢語言

目前，時態資料查詢語言主要由下述三種類型。

3.1 TempSQL

TempSQL 是在 1985 年由 S.Gadia 和 S.Nair 提出，作為一種類 SQL 的時態資料庫查詢語言，TempSQL 引入了雙時態機制，資料庫可以對資料本身歷史（有效時間）、對資料進行插入、刪除和更新等的歷史（事務時間）、資料庫和使用者出錯的歷史等進行管理。TempSQL 保持時態資料與靜態資料的無縫連線，而將快照資料看做是時間標籤為 now,now 的一個特例。

在 TempSQL 中，元組中主鍵屬性（例如學生資訊元組中的學號屬性）不能隨時間變化，而非主鍵屬性（例如學生元組中 “住址”、“年齡” 和 “聯絡方式” 等屬性）在不同時間內可以有不同取值。

3.2 TQuel

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

3.3 TSQL2

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

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

時態資料庫管理系統

4.1 TDBMS 基本組成

傳統資料庫管理系統（DBMS）具有支援時間和日期的資料型別，但不能直接支援和管理時態資料，關於時態方面的操作需要由另行編寫的應用程式完成。時態資料庫管理系統（TDBMS）具有提供時態資料操作和支援時態資料管理的基本功能。

一個 TDBMS 需要具有下述子系統：

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

4.2 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 的支援。

4.3 TempDB

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

4.3.1 TempDB 與 TimeDB 具有下述共同之處

全面支援有效時間

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

暫不支援事務時間

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

4.3.2 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 提供統一的圖形化介面供使用者輸入語句、檢視語句執行結果和中間結果，以及檢測語句執行時的可能出錯資訊。

時態資料庫應用模式

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

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