Can you summarize the following document?
        
  

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

  時態資料中資料由於其採用資料模型的不同而不同,例如採用關係模型、物件模型和XML模型的時態資料分別稱為時態關係、時態物件和時態XML資料。但無論那種時態資料,其中的時間標籤都會根據情形選用下述的時間表示形式。

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

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

  使用者自定義時間(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表示了快照資料庫的特性。  快照資料庫中無法表示屬性與時間的關係,沒有維護狀態變遷的能力,不能夠進行與時間相關的任何工作,快照資料庫無法回答以下一些問題。  快照資料庫狀態之間轉變的確切時刻是發生在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類:

  

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

  作為時態資料庫“產品化”代表,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 https://web.archive.org/web/20120130015159/http://tempdb.scholat.com/index.asp 是由湯庸教授帶領的“中山大學資料庫與協同實驗室”(現“華南師範大學資訊服務與軟體技術中心”)於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提供統一的圖形化介面供使用者輸入語句、檢視語句執行結果和中間結果,以及檢測語句執行時的可能出錯資訊。

  按照是否處理時態屬性,應用系統可以分為傳統應用系統(非時態應用系統)和時態應用系統。時態資料庫應用模式就是在在時態應用系統系統提供時態資料處理的技術方式。根據系統處理時態屬性方式與能力,時態資料庫應用模式又可分為下述三中情形:
時間資料庫(Temporal database),又稱時間化資料庫或時態資料庫,是內建時間特性的資料庫。時間資料庫搭配使用時間資料模型,以及具有時間版本的結構化查詢語言。