Loading article…
時間データベースには、時間インスタンスに関連するデータが保存されます。時間データ型が提供され、過去、現在、未来の時間に関連する情報が保存されます。時間データベースは、単一時間、2 つの時間、または 3 つの時間のいずれかになります。
より具体的には、時間的な側面には通常、有効時間、トランザクション時間、および/または決定時間が含まれます。
- 有効時間とは、現実世界で事実が真実である期間またはイベント時間です。
- トランザクション時間とは、事実がデータベースに記録された時間です。
- 決定時刻は、事実について決定が行われた時刻です。有効な時刻に関する決定の履歴を保持するために使用されます。
種類
単一時間
単一時間データベースには、有効範囲またはシステム時間範囲のいずれかの 1 つの時間軸があります。
二時間的
バイテンポラル データベースには 2 つの時間軸があります。
- 有効時間
- 取引時間または意思決定時間
三時間的
3 段階データベースには 3 つの時間軸があります。
- 有効時間
- 取引時間
- 決断の時
このアプローチでは、さらなる複雑さが生じます。
時間データベースは、現時点で真実であると考えられる事実のみを保存する 現在のデータベース(現在利用可能なデータベースと混同しないでください)とは対照的です。
特徴
時系列データベースは、以下の機能の1つ以上を提供することで、時系列データの管理とアクセスをサポートします。[1] [2]
- 終わりのない期間（無限または永遠）を表す機能を含む期間データ型
- 有効期間とトランザクション期間の属性およびバイテンポラル関係を定義する機能
- システム管理トランザクション時間
- 重複しない期間制約を含む時間主キー
- 重複しない一意性と参照整合性を含む時間的制約
- 期間の自動分割と結合による一時レコードの更新と削除
- 現在の時間、過去または将来の時点、または期間にわたる時間クエリ
- 期間を問い合わせるための述語。多くの場合、アレンの間隔関係に基づく。
歴史
SQLの開発と実際のアプリケーションでのそれに伴う使用により、データベース ユーザーは、キー フィールドに日付列を追加すると、いくつかの問題が発生することに気付きました。たとえば、テーブルに主キーといくつかの属性がある場合、履歴変更を追跡するために主キーに日付を追加すると、意図したよりも多くの行が作成されることがあります。行をこのように追跡する場合、削除も別の方法で処理する必要があります。1992 年にこの問題は認識されましたが、標準データベース理論はまだこの問題を解決できるレベルに達しておらず、当時新しく公式化されたSQL-92 標準も解決できていませんでした。
リチャード・スノッドグラスは1992 年に、SQL のテンポラル拡張機能をテンポラル データベース コミュニティで開発することを提案しました。この提案に応えて、1992 年版の SQL 標準 (ANSI X3.135.-1992 および ISO/IEC 9075:1992) の拡張機能を設計する委員会が結成されました。TSQL2 として知られるこれらの拡張機能は、1993 年にこの委員会によって開発されました。[3] 1993 年後半、スノッドグラスは、この作業を、データベース言語 SQL の米国標準を担当するグループである ANSI 技術委員会 X3H2 (現在は NCITS H2 として知られています) に提出しました。予備的な言語仕様は、1994 年 3 月の ACM SIGMOD レコードに掲載されました。この仕様に対する応答に基づいて言語に変更が加えられ、TSQL2 言語仕様の最終版が 1994 年 9 月に公開されました[4]
TSQL2の一部を新しいSQL標準SQL:1999 、いわゆるSQL3に組み込む試みがなされた。TSQL2の一部はSQL3の新しいサブ標準ISO/IEC 9075-7、いわゆるSQL/Temporalに組み入れられた。[3] TSQL2のアプローチはChris DateとHugh Darwenから厳しく批判された。[5] temporalサポートを担当していたISOプロジェクトは2001年末に中止された。
2011 年 12 月現在、ISO/IEC 9075、データベース言語SQL:2011パート 2: SQL/Foundation には、テーブル定義に「アプリケーション期間テーブル」(有効時間テーブル)、「システム バージョン テーブル」(トランザクション時間テーブル)、「システム バージョン アプリケーション期間テーブル」(バイテンポラルテーブル) を定義するための句が含まれています。TSQL2 の提案と SQL:2011 で採用されたものとの実質的な違いは、SQL:2011 の処理には非表示の列がなく、間隔用の新しいデータ型もないことです。代わりに、日付スタンプ(DS) または日付タイムスタンプ(DTS) を持つ 2 つの列を宣言を使用して結合できますPERIOD FOR。もう 1 つの違いは、TSQL2 の議論の多い (プレフィックス) ステートメント修飾子が、一連のテンポラル述語に置き換えられたことです。[1]
SQL:2011標準のテンポラル データベースに関連するその他の機能には、自動期間分割、テンポラル主キー、テンポラル参照整合性、Allen の区間代数を使用したテンポラル述語、およびタイムスライスおよびシーケンス クエリがあります。
例
例として、架空の人物、ジョン・ドウの次の短い伝記を考えてみましょう。
- ジョン・ドウは、1975年4月3日、スモールビルに住むジャック・ドウとジェーン・ドウの息子として、メディシン郡のキッズ病院で生まれました。ジャック・ドウは、1975年4月4日、スモールビル市役所で誇らしげに長男の出生届を出しました。ジョンは陽気な少年として成長し、優秀な学生となり、1993年に優秀な成績で卒業しました。卒業後、彼はビッグタウンに一人暮らしを始めました。1994年8月26日に引っ越しましたが、住所変更を正式に登録するのを忘れていました。季節の変わり目になって初めて、母親が登録しなければならないことを思い出させ、彼は数日後の1994年12月27日に登録しました。ジョンには前途有望な未来がありましたが、彼の物語は悲劇的に終わります。ジョン・ドウは、2001年4月1日に誤ってトラックにひかれました。検死官は、まさにその日に彼の死亡日を報告しました。
非一時データベースの使用
John Doe の生涯を現在の (非一時的) データベースに保存するには、テーブル を使用しますperson (name, address)。 (簡略化するために、は の主キーnameとして定義されます。)
person
ジョンの父親は、1975 年 4 月 4 日にジョンの出生を公式に報告しました。この日に、スモールビルの職員がデータベースに次のエントリを追加しました: Person(John Doe, Smallville)。日付自体はデータベースに保存されないことに注意してください。
卒業後、ジョンは引っ越しますが、新しい住所を登録するのを忘れました。データベース内のジョンのエントリは、1994-12-27 に彼が最終的に報告するまで変更されませんでした。ビッグタウンの役人がデータベース内の彼の住所を更新しました。personテーブルには、現在 が含まれていますPerson(John Doe, Bigtown)。スモールビルに住んでいるジョンの情報は上書きされているため、データベースからその情報を取得できないことに注意してください。1994-12-28 にデータベースにアクセスした役人には、ジョンがビッグタウンに住んでいることが伝えられます。より技術的に言えば、データベース管理者が1994-12-26 にクエリを実行した場合、結果は になります。2日後に同じクエリを実行すると、 になります。
SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'SmallvilleBigtown
彼が亡くなるまで、データベースには彼がビッグタウンに住んでいたと記録されていました。2001 年 4 月 1 日に、検死官はデータベースから John Doe のエントリを削除しました。その後、上記のクエリを実行しても結果はまったく返されません。
単一の軸を使用する: 有効時間またはトランザクション時間
有効時間とは、現実世界で事実が真実である時間です。有効時間は、過去、現在の時間、または将来に発生する可能性があります。
上記の例では、有効期間を記録するために、テーブルにとpersonの 2 つのフィールドが追加されています。これらは、人の住所が現実世界で有効な期間を指定します。1975 年 4 月 4 日に、ジョンの父親は息子の出生を登録しました。その後、職員がデータベースに新しいエントリを挿入し、ジョンが 4 月 3 日からスモールビルに住んでいると記載します。データは 4 日に挿入されましたが、データベースではその情報は 3 日から有効であると記載されていることに注意してください。職員はまだジョンが別の場所に移動するかどうか、またいつ移動するかを把握していないため、フィールドは無限大(∞)に設定されています。データベースのエントリは次のとおりです。
valid_fromvalid_tovalid_to
1994 年 12 月 27 日、ジョンは 1994 年 8 月 26 日から住んでいるビッグタウンの新しい住所を報告しました。この事実を記録するために、新しいデータベース エントリが作成されました。
元のエントリはPerson (John Doe, Smallville, 1975-04-03, ∞)削除されませんが、valid_to属性が更新され、John が 1994 年 8 月 26 日に Smallville での生活を中止したことがわかったことが反映されます。データベースには、John Doe のエントリが 2 つ含まれるようになりました。
ジョンが亡くなると、データベース内の現在のエントリが更新され、ジョンはもうビッグタウンに住んでいないことが示されます。データベースは次のようになります。
有効時間とトランザクション時間の2つの軸を使用する
トランザクション時間は、データベース エントリが正しいと認められた期間を記録します。これにより、特定の時点のデータベースの状態を示すクエリが可能になります。トランザクション時間は、過去または現在の時点までしか発生しません。トランザクション時間テーブルでは、レコードが削除されることはありません。新しいレコードのみを挿入でき、既存のレコードは、トランザクション終了時間を設定して、最新ではないことを示すことで更新できます。
上記の例でトランザクション時間を有効にするには、Person テーブルに と という 2 つのフィールドを追加しますtransaction_from。transaction_toここで、 はtransaction_fromトランザクションが行われた時間、 はtransaction_toトランザクションが置き換えられた時間です (まだ置き換えられていない場合は無限大になることがあります)。これにより、テーブルはバイテンポラル テーブルになります。
データベースに保存されている人物の住所が間違っている場合はどうなるでしょうか? 職員が誤って間違った住所や日付を入力したとしたらどうでしょうか? あるいは、何らかの理由で人物が住所について嘘をついたとしたらどうでしょうか。誤りが発見されると、職員はデータベースを更新して記録された情報を修正します。
たとえば、1995 年 6 月 1 日から 2000 年 9 月 3 日まで、ジョン・ドウはビーチーに引っ越しました。しかし、ビーチーの法外な居住税の支払いを避けるため、彼は当局にそのことを報告しませんでした。その後の税務調査で、2001 年 2 月 2 日に、彼が実際にその期間ビーチーにいたことが発覚しました。この事実を記録するには、ビッグタウンに住んでいるジョンに関する既存のエントリを 2 つの別々のレコードに分割し、ビーチーでの彼の居住を記録する新しいレコードを挿入する必要があります。データベースは次のようになります。
しかし、これでは、データベースが彼が 1995-06-01 から 2000-09-03 の間にビッグタウンに住んでいたと主張した記録は残っていません。これは、監査上の理由から、または役人の税務調査の証拠として使用する上で重要な情報かもしれません。エントリが直接変更または削除されることはないため、トランザクション時間によってデータベース内のこの変化する情報をキャプチャできます。代わりに、各エントリは、入力されたときと置き換えられた (または論理的に削除された) ときを記録します。データベースの内容は次のようになります。
データベースには、現実世界で起こったことだけでなく、さまざまな時期に公式に記録された内容も記録されます。
有効時間、決定時間、トランザクション時間の3つの軸を使用する
決定時間は、データベースエントリが正しいと受け入れられる時間を記録するためのトランザクション期間の代替手段です。これにより、データベースへの事実のコミットに遅延があった場合でも、特定の時点で公式に認められた事実を示すクエリが可能になります。決定時間のサポートにより、履歴全体が保存され、更新中に情報が失われるのを防ぎます。[6]
決定期間は、過去またはトランザクション時間までしか発生しません。トランザクション時間テーブルと同様に、レコードが削除されることはありません。新しいレコードのみを挿入でき、既存のレコードは、決定終了時間を設定して、最新ではないことを示すことで更新できます。
決定時間を有効にするには、データベース テーブルにdecision_fromと という2 つのフィールドを追加しますdecision_to。ここで、decision_fromは決定が行われた時間、 は決定が置き換えられた時間 (まだ置き換えられていない場合は無限大になることがあります) です。トランザクション時間と組み合わせると、テーブルは 3 段階テーブルになります。以下は、1964 年から 1976 年の米国大統領選挙decision_toの間に発生した実際のイベントの一覧です。
この例では、決定時刻と、データがデータベースにコミットされるトランザクション時刻の間に、一定の 7 日間の遅延があると想定されています。これらの条件を考慮すると、1976 年の選挙後にデータベースには次の情報が含まれていることになります。
上記の 7 日間遅延された表を考慮すると、「1977 年 1 月 1 日の有効期間に大統領と副大統領は誰だったか」という質問 (7 日間遅延を考慮すると 1976 年 12 月 25 日のデータが提供される可能性があります) は次のようになります。
- ニクソン/アグニュー、決定時間と取引時間を1972-11-14とした場合
- ニクソン/(空席) 決定時間と取引時間を1973-10-17とした場合
- ニクソン/フォード、決定時間と取引時間を1974-08-08とした場合
- フォード/(空室) 決定時刻1974-08-08と取引時刻現在の場合
- フォード/ロックフェラーは、現在の意思決定時間と取引時間を使用する場合
バイテンポラルモデリング
バイテンポラル モデルには、有効時間とトランザクション時間の両方が含まれます。これにより、履歴情報とロールバック情報の両方が提供されます。履歴情報(例: 「1992 年に John はどこに住んでいましたか?」) は、有効時間によって提供されます。ロールバック (例: 「1992 年に、データベースは John がどこに住んでいたと認識していましたか?」) は、トランザクション時間によって提供されます。これらの例の質問に対する回答は同じではない可能性があります。データベースは 1992 年以降に変更されている可能性があり、クエリによって異なる結果が生成されることがあります。
1 つのファクトの有効時間とトランザクション時間は同じである必要はありません。たとえば、18 世紀に関するデータを格納する一時データベースを考えてみましょう。これらのファクトの有効時間は 1701 年から 1800 年の間です。トランザクション時間は、ファクトがデータベースに挿入された時間 (たとえば 1998-01-21) を示します。
スキーマの進化
難しい問題は、進化するスキーマの下でのトランザクション時間データベースでのテンポラルクエリのサポートです。完璧なアーカイブ品質を実現するためには、データが最初に登場したスキーマバージョンでデータを保存することが非常に重要です。しかし、属性値の履歴を書き換える最も単純なテンポラルクエリでさえ、各スキーマバージョンで手動で書き換える必要があります。MediaWikiの場合のように、数百に及ぶ可能性があります。[7]このプロセスは、ユーザーにとって特に負担が大きいでしょう。提案されている解決策は、自動クエリ書き換えを提供することです。[8] [9]これはSQLや同様の標準の一部ではありません。
スキーマ進化の複雑さを最小限に抑えるアプローチは次のとおりです。
- 半構造化データベース/ NoSQLデータベースを使用すると、属性データのモデリングの複雑さが軽減されますが、複数の時間軸を処理する機能は提供されません。[10]
- 属性の半構造化データと時間軸の構造化データの両方を保存できるデータベースを使用する（例： SnowflakeDB、PostgreSQL）
注目製品への実装
次の実装は、リレーショナル データベース管理システム (RDBMS) で時間的な機能を提供します。
- MariaDBバージョン10.3.4では、「システムバージョンテーブル」としてSQL:2011標準のサポートが追加されました。 [11]
- Oracle Database – Oracle Workspace Manager は、アプリケーション開発者と DBA が同じデータベース内のデータの現在のバージョン、提案されたバージョン、および履歴バージョンを管理できるようにする Oracle Database の機能です。
- PostgreSQLバージョン9.2では、pgFoundryのテンポラル拡張のすべての機能を実装できるネイティブの範囲データ型が追加されました。[12] [13] PostgreSQLの範囲型は、多数のネイティブ演算子と関数によってサポートされています。
- Teradataは2つの製品を提供しています。Teradataバージョン13.10とTeradataバージョン14には、TSQL2 [14]に基づくテンポラル機能がデータベースに組み込まれています。
- IBM Db2バージョン10では、 SQL:2011標準[1]の時間的機能に基づいた「タイムトラベルクエリ」 [2]と呼ばれる機能が追加されました。
- Microsoft SQL Serverは、 SQL Server 2016の機能としてテンポラルテーブルを導入しました。この機能については、Microsoftの「Channel 9」Webサイトのビデオで説明されています。[15]
次のような時間的機能を提供する非リレーショナル NoSQL データベース管理システム:
- TerminusDBは、バージョン管理、タイムトラベルクエリ、差分機能をネイティブにサポートするフル機能のオープンソース グラフデータベースです。デルタエンコーディングと簡潔なデータ構造に基づく不変のレイヤーアーキテクチャを備えています。[16]
- MarkLogicはバージョン8.0でバイテンポラルデータのサポートを導入しました。有効時間とシステム時間のタイムスタンプはJSONまたはXMLドキュメントに保存されます。[17]
- SirixDB は、読み取り/書き込みパフォーマンスのバランスを取り、書き込みピークを生じさせないスライディング スナップショットと呼ばれる新しいバージョン管理アルゴリズムにより、(現在のところ) XML および JSON ドキュメントのスナップショットをバイナリ形式で非常に効率的に保存します。タイム トラベル クエリは、差分機能と同様にネイティブにサポートされています。
- XTDB (旧称 Crux) は、半不変の Kafka ログから取り込まれたトランザクションとドキュメントに対して、ポイントインタイムのバイテンポラルDatalogクエリを提供します。ドキュメントは自動的にインデックス化され、スキーマを定義する必要なく、エンティティ - 属性 - 値モデルインデックスが作成されます。トランザクション操作は、有効な有効時間を指定します。トランザクション時間は Kafka によって割り当てられ、一貫性のある読み取りによる水平方向のスケーラビリティを実現します。
- RecallGraph は、 ArangoDB上に構築された、ポイントインタイムのユニテンポラル (トランザクション時間) グラフ データベースです。ArangoDB の Foxx Microservice サブシステム上で実行されます。インターフェイスの多くの部分でVCSのようなセマンティクスが採用されており、トランザクションイベント トラッカーによってサポートされています。バイテンポラル性は、開発ロードマップの項目の 1 つとしてリストされています。
- Datomicは「ACIDトランザクション、柔軟なスキーマ、[...] データログクエリ、完全なデータ履歴、SQL分析サポートを提供する分散データベースです。」データに加えられたすべての変更について、責任のあるトランザクションとそれが起こった時点を記録します。[18]
時系列データベースはデータバージョン管理の最も初期の形態の一つであり、現代のデータバージョン管理システムの開発に影響を与えました。[19]
代替案
ゆっくり変化する次元を使用して、時間的な関係をモデル化できます。
さらに読む
- CJ Date、Hugh Darwen、Nikos Lorentzos (2002)。『Temporal Data & the Relational Model、第 1 版(The Morgan Kaufmann Series in Data Management Systems)』、Morgan Kaufmann、第 1 版、422 ページ。ISBN 1-55860-855-9 。
- Joe Celko (2014)。Joe Celko の SQL for Smarties: 高度な SQL プログラミング(Morgan Kaufmann データ管理シリーズ)、Morgan Kaufmann、第 5 版。ISBN 978-0-12-800761-7。—特に第 12 章と第 35 章では、時間に関する問題について説明します。
- Snodgrass, Richard T. (1999)。「SQL での時間指向データベース アプリケーションの開発」(PDF)。 (4.77 MiB ) (Morgan Kaufmann データ管理システムシリーズ); Morgan Kaufmann; 504 ページ; ISBN 1-55860-436-7
参照
参考文献
- ^ abc Kulkarni、Krishna、Jan-Eike Michels。「SQL のテンポラル機能: 2011」。ACM SIGMOD Record 41.3 (2012): 34-43。
- ^ ab Saracco, Cynthia M.; Nicola, Matthias; Gandhi, Lenisha (2012 年 4 月 3 日). 「A matter of time: Temporal data management in DB2 10」. IBM . 2012 年 10 月 25 日時点のオリジナルよりアーカイブ。2020年 10 月 27 日閲覧。
- ^ スノッドグラス、1999年、9ページ
- ^ Richard T. Snodgrass . 「TSQL2 Temporal Query Language」。www.cs.arizona.edu。アリゾナ大学コンピュータサイエンス学部。2009年7 月 14 日閲覧。
- ^ Hugh Darwen、CJ Date、「TSQL2 アプローチに基づく提案の概要と分析」、Date on Database: Writings 2000-2006、CJ Date、Apress、2006 年、481-514 ページ
- ^ Mario A. Nascimento、Margaret H. Eich、「時間データベースにおける決定時間」、第 2 回時間表現と推論に関する国際ワークショップの議事録、1995 年、157-162 ページ
- ^ スキーマ進化ベンチマーク - スキーマ進化
- ^ Hyun J. Moon、Carlo A. Curino、Alin Deutsch、C.-Y. Hou および Carlo Zaniolo (2008)。スキーマ進化の下でのトランザクション時間データベースの管理とクエリ。Very Large Data Base VLDB。
- ^ Hyun J. Moon、Carlo A. Curino、Carlo Zaniolo (2010)。進化するスキーマを持つトランザクション時間 DB のスケーラブルなアーキテクチャとクエリ最適化。SIGMOD。
- ^ Anthony B. Coates (2015)。銀行がバイテンポラリティを重視する理由。MarkLogic World 2015。
- ^ 「システムバージョン管理テーブル」。
- ^ Paquier, Michael (2012 年 11 月 1 日). 「Postgres 9.2 のハイライト: 範囲型」。Michael Paquier - 日本を拠点とするオープンソース開発者。2016 年 4 月 23 日時点のオリジナルよりアーカイブ。
- ^ Katz, Jonathan S. 「Range Types: Your Life Will Never Be The Same」（PDF） 。 2014年7月14日閲覧。
- ^ Al-Kateb、Mohammed 他「Teradata における時間クエリ処理」EDBT/ICDT '13 2013 年 3 月 18 ～ 22 日、ジェノバ、イタリア
- ^ SQL Server 2016 の Temporal 、 2019 年 7 月 19 日に取得
- ^ "terminusdb/terminusdb-server". GitHub . 2020年9月4日閲覧。
- ^ ブリッジウォーター、エイドリアン（2014年11月24日）。「データは良いが、『双方向バイテンポラル』データはもっと良い」フォーブス。
- ^ 「Datomicデータモデル：時間モデル」。2024年4月29日。
- ^ バルドワジ、アナント;バタッチャージー、スーヴィク。チャヴァン、アミット。デシュパンデ、アモル。エルモア、アーロン J.マッデン、サミュエル。パラメスワラン、アディティヤ G. (2014-09-02)。 「DataHub: 大規模な共同データ サイエンスとデータセット バージョン管理」。arXiv : 1409.0798 [cs.DB]。
外部リンク
ウィキメディア・コモンズには、時間データベースに関連するメディアがあります。
- 「TimeCenter ホーム」。TimeCenter。アリゾナ大学コンピューターサイエンス学部。2020 年 2 月 24 日時点のオリジナルよりアーカイブ。
- RDF における時間関係
- RDF トリプルの時間的範囲
- IBM DB2 10（z/OS 用）
- ランディ・ワイスとトム・ジョンストンによる「Time and Time Again」シリーズの記事
- マーティン・ファウラー著「時間的パターン」