時態數據
時態數據
傳統資料庫例如關係資料庫描述數據進入資料庫時所反映現實世界當前狀態。當這種狀態發生改變時需要通過合適的更新（插入、刪除和修改）再反映到資料庫當中，這種更新通常發生後，原先的狀態就“自然”消失。對於許多套用系統來說，只保存當前狀態是不夠的。例如銀行系統、人事系統和醫療系統等等，它們都需要著力維護相關的歷史數據信息。需要顯式表示和管理與時間相關的數據就是時態信息。時態數據的形式特徵是其由不顯含時間的數據和相應的時間標籤組成，而本質是需要將數據本身與特定的時間例如數據的生命周期等緊密結合，時間的處理和數據的管理相融相合，是數據與其相關時間的整合體，因此，常規資料庫就不能有效進行時態數據的管理。當然也可以在常規資料庫框架內通過應用程式來管理時態數據，但相應應用程式會相當複雜，也容易出錯，同時也加重時態數據用戶的負擔。
時間標籤
時態數據中數據由於其採用數據模型的不同而不同，例如採用關係模型、對象模型和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）。歷史資料庫記錄現實世界在有效時間點處或有效時間期間內的事件和狀態變化。有效時間對事物的描述簡潔直觀、容易理解。
事務時間
事務時間（Transaction Time）是指對給定資料庫對象進行數據操作例如插入、刪除或修改的時間，是一個事實進入並存儲於資料庫當中的時間。事務時間記錄對資料庫更新的各種操作歷史，對應於現有事務或現有資料庫狀態變遷的歷史。例如，數據錄入資料庫的時間，對其進行查詢的時間，對其進行刪除或修改的時間。 事務時間對應於現有事務或現有資料庫的狀態變遷歷史，獨立於相應實際套用，用戶不能對事務時間進行任何處理。資料庫中數據錄入、修改和刪除的時間由系統時鐘決定，每次更新後數據不可再予以改變，因此，事務時間也稱為系統時間（system time）。處理事務時間的方法是存儲所有資料庫的狀態，即處理一個事務之後就存儲一種資料庫狀態。任何對數據的更新只能對最後一個狀態進行，但可查詢任意一個狀態。事務時間有如下主要特點：
•事務時間的值由系統時鐘給出，獨立於套用，不允許用戶對事務時間進行任何修改。
•事務時間不能晚於當前時間，它反映資料庫實際操作的時間，不能表示未來時間。
支持事務時間的資料庫稱為回滾資料庫（Rollback Database）。回滾資料庫記錄資料庫的自身變化，實現方式是沿著事務時間軸記錄數據狀態，按照事務時間排序，保留所有狀態的演變歷史。回滾資料庫可被看作是只能追加記錄的資料庫，不能用來記錄資料庫的未來狀態。
時態資料庫
時態資料庫的分類基礎是數據的時間維度。
快照資料庫
快照資料庫（Snapshot Database）以在特定時刻瞬間快照建立模型。現實世界是變化的，快照資料庫可以反映其某一個瞬間的情況。快照資料庫無法表示屬性與時間的關係，沒有維護狀態變遷的能力，只進行當前資料庫狀態的查詢和更新，不能進行以往歷史數據的查詢，而且隨著時間演進，其更改的歷史數據將會丟失。它也不能進行含有時間因素的推理。快照資料庫實際上是一種非時態資料庫，它反映數據的當前狀態，時間推移將導致資料庫狀態不斷改變，新狀態將覆蓋舊的狀態。 快照資料庫由靜態的二維關係表組成，分別是屬性維和元組維。資料庫狀態變遷由事務實現，一旦事務提交，其狀態變遷就立即生效，原來資料庫狀態也就完全丟失。
快照資料庫中無法表示屬性與時間的關係，沒有維護狀態變遷的能力，不能夠進行與時間相關的任何工作，快照資料庫無法回答以下一些問題。
•“raul何時當的講師？（如果他現在是副教授）”（歷史查詢）
•“2006年9月18日的記錄中，Green的職務是什麼？”（歷史查詢）
•“在過去的3年裡，該大學有多少人從副教授提升為正教授？”（趨勢查詢）
•“明年，Raul還會成為正教授么？”（未來查詢）
•“jones上個月被提升為副教授”（記錄更新）
快照資料庫狀態之間轉變的確切時刻是發生在Commit的時刻。這種資料庫稱為“快照資料庫”，意思是它只把握資料庫的當前的一個快照狀態，“快照”狀態是隨著時間在不斷改變的。這裡所說的“快照”和關係資料庫中的“快照”的概念不同：關係資料庫中快照是為了處理的需要（比如年底結帳的需要）對某個時刻（12月31日23時59分59秒）資料庫中的數據進行獨立的數據備份。而這裡使用的“快照”只是指資料庫只保留一個資料庫狀態（通常是當前狀態）的性質。 從時態資料庫的觀點來看，快照資料庫不區分事務時間和有效時間。快照資料庫中的基本假定是：存儲在系統中的元組一定是現實世界中的有效事實。
回滾資料庫
回滾資料庫(Rollback Database)支持事務時間，它按事務時間進行編址，保存過去每次事務提交，狀態演變之前的狀態。回滾資料庫由三維的回滾關係組成，在屬性維和元組維的基礎上增加了事務時間維，因此可看作一個按時間編址的瞬象序列。每一個時間點都對應於一個二維快照資料庫。 回滾資料庫不足之處主要有下述幾點：
回滾資料庫按照事務時間編址，記錄資料庫狀態變遷的歷史，而不是現實世界變化的歷史。現實世界中元組屬性在某個時間點（屬性的有效時間）變化了，但因為資料庫在這個時間點沒有執行事務，即資料庫事務時間沒有改變，此時，元組時變屬性的改變在資料庫中沒有體現出來。
過去元組的錯誤不可更正，只能查看。當人們發現元組有錯誤時，如果此事務已經提交，用戶就無能為力，只能是等待下次系統的事務時間進行新的改動。但改動的只是提交前的數據，即最近一個事務時間點的數據，此前的狀態不能再改變。
回滾資料庫冗餘較多。在前一個事務時間內提交的數據，即使在下一個事務時間沒有數據改變或者改變很小時，也需進行所有數據的重新輸入及儲存，由此帶來較大的數據冗餘，這種情況在進行小的時變時更加突出。
1.回滾資料庫按照事務時間編址，記錄資料庫狀態變遷的歷史，而不是現實世界變化的歷史。現實世界中元組屬性在某個時間點（屬性的有效時間）變化了，但因為資料庫在這個時間點沒有執行事務，即資料庫事務時間沒有改變，此時，元組時變屬性的改變在資料庫中沒有體現出來。
2.過去元組的錯誤不可更正，只能查看。當人們發現元組有錯誤時，如果此事務已經提交，用戶就無能為力，只能是等待下次系統的事務時間進行新的改動。但改動的只是提交前的數據，即最近一個事務時間點的數據，此前的狀態不能再改變。
3.回滾資料庫冗餘較多。在前一個事務時間內提交的數據，即使在下一個事務時間沒有數據改變或者改變很小時，也需進行所有數據的重新輸入及儲存，由此帶來較大的數據冗餘，這種情況在進行小的時變時更加突出。
時態數據查詢語言
目前，時態數據查詢語言主要由下述三種類型。
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類：
快照關係：其特點是沒有時間標籤。
有效時間狀態關係，其說明語句為AS valid[state]。其中state是默認值，選和不選具有同樣效果，即表示相應關係是有效時間狀態關係。
有效時間事務關係，其說明語句為AS VALID EVENT，表示事件發生在某一時刻，而此時有效時間為時刻集合。
事務時間關係 其表示語句為AS TRANSACTION，說明該關係中只具有事務時間。
雙時態狀態關係 其說明語句為as valid[state] and transaction，其中有效時間為狀態發生保持的時間期間。
雙時態事件關係 其說明語句為as valid event and TRANSACTION。和雙時態狀態關係不同，其中有效時間描述的是關係表示的事件發生時刻的集合。
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
TempDBhttps://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提供統一的圖形化界面供用戶輸入語句、查看語句執行結果和中間結果，以及檢測語句執行時的可能出錯信息。
時態資料庫套用模式
按照是否處理時態屬性，套用系統可以分為傳統套用系統（非時態套用系統）和時態套用系統。時態資料庫套用模式就是在在時態套用系統系統提供時態數據處理的技術方式。根據系統處理時態屬性方式與能力，時態資料庫套用模式又可分為下述三中情形：
完全時態套用模式 這是一種基於時態資料庫系統開發的套用系統，提供完全的時態數據處理支持，其特徵是系統底層使用時態資料庫管理系統TDBMS。目前還沒有TDBMS的商業化產品，而且各個主流資料庫管理系統也沒有支持時態數據管理的功能。
嵌入式時態套用模式 通過一些時態處理開發工具即時態中間件實現套用系統中時態數據處理功能，其特徵是系統底層採用傳統DBMS。開發此類模式需要時態處理工具軟體支持。
混合式時態套用模式 通過將時態數據處理技術與套用信息技術結合實現套用系統對時態屬性操作的支持，其特徵是系統底層也是採用傳統DBMS，目前大多數時態套用都屬於這種模式 。
1.完全時態套用模式 這是一種基於時態資料庫系統開發的套用系統，提供完全的時態數據處理支持，其特徵是系統底層使用時態資料庫管理系統TDBMS。目前還沒有TDBMS的商業化產品，而且各個主流資料庫管理系統也沒有支持時態數據管理的功能。
2.嵌入式時態套用模式 通過一些時態處理開發工具即時態中間件實現套用系統中時態數據處理功能，其特徵是系統底層採用傳統DBMS。開發此類模式需要時態處理工具軟體支持。
3.混合式時態套用模式 通過將時態數據處理技術與套用信息技術結合實現套用系統對時態屬性操作的支持，其特徵是系統底層也是採用傳統DBMS，目前大多數時態套用都屬於這種模式 。
