テンポラル データベースについて読んでいましたが、時間の側面が組み込まれているようです。なぜそのようなモデルが必要なのだろうか？
通常の RDBMS との違いは何ですか? 通常のデータベース、つまり RDBMS を使用して、発生する各トランザクションにタイムスタンプを関連付けるトリガーを使用することはできませんか? パフォーマンスが低下する可能性があります。しかし、テンポラル データベースが市場で確固たる地位を築いているかどうかについては、まだ懐疑的です。
現在のデータベースのいずれかがそのような機能をサポートしていますか?
1 月 1 日から 12 月 31 日までの予定/日誌を考えてみましょう。これで、任意の日の予定/日誌エントリのダイアリーをクエリできます。この順序付けを有効時間と呼びます。ただし、予定/エントリは通常、順番に挿入されません。
4 月 4 日の日記にどのような予定/エントリがあったか知りたいとします。つまり、4月4日の日記にあったすべての記録です。これが取引時間です。
予定/エントリを作成したり削除したりできると仮定すると、典型的なレコードには、エントリの期間をカバーする開始および終了の有効時間と、エントリがダイアリーに表示された期間を示す開始および終了のトランザクション時間があります。
これ は 日記 の歴史 的 修正が 必要 な 場合 に 必要 で ある。4 月 5 日に、2 月 14 日に行った予定が実際には 2 月 12 日に行われたことに気付いたとします。つまり、日記に誤りがあることを発見しました。誤りを訂正して、有効な時間の画像を訂正することができます。 4 月 4 日のダイアリーでは、予約/エントリのトランザクション時間も保存されていない限り、間違っています。その場合、4 月 4 日の時点でダイアリーをクエリすると、2 月 14 日に予定があったことが示されますが、4 月 6 日の時点でクエリを実行すると、2 月 12 日の予定が表示されます。
このテンポラル データベースのタイム トラベル機能により、データベース内のエラーの修正方法に関する情報を記録できます。これは、改訂がいつ行われたかを記録し、時間の経過とともにデータがどのように改訂されたかに関するクエリを可能にする、データの真の監査状況に必要です。
ほとんどのビジネス情報は、真の監査記録を提供し、ビジネス インテリジェンスを最大化するために、このバイテンポラル スキームに格納する必要があります。したがって、リレーショナル データベースでのサポートが必要になります。各データ項目は、2 次元時間モデルで (場合によっては無制限の) 正方形を占めることに注意してください。これが、GIST インデックスを使用してバイテンポラル インデックス作成を実装することが多い理由です。ここでの問題は、GIST インデックスが実際には地理データ用に設計されており、時系列データの要件が多少異なることです。
PostgreSQL 9.0 の除外制約は、時間データを編成する新しい方法を提供する必要があります。たとえば、トランザクションと有効な時間の PERIOD が同じタプルに対して重複してはなりません。
テンポラル データベースは、通常、一定のタイムスケール (秒やミリ秒など) を設定し、測定データの変化のみを保存することで、時系列のデータを効率的に保存します。RDBMS のタイムスタンプは、測定ごとに個別に格納された値であり、非常に非効率的です。テンポラル データベースは、SCADA などのリアルタイム モニタリング アプリケーションでよく使用されます。確立されたシステムは、OSISoft ( http://www.osisoft.com/ ) の PI データベースです。
私が理解しているように (そして非常に単純化しすぎています)、テンポラル データベースは、データ自体と同様にデータが有効であった時期に関する事実を記録し、時間的な側面についてクエリを実行できるようにします。「有効時間」と「トランザクション時間」のテーブル、または「有効時間」と「トランザクション時間」の両方の側面を含む「バイテンポラル テーブル」を扱うことになります。次の 2 冊の本のいずれかを読むことを検討してください。
テンポラル データベースは、金融サービス業界でよく使用されます。理由の 1 つは、データを削除することはほとんど (たとえあったとしても) 許可されないため、レコードの ValidFrom - ValidTo タイプのフィールドを使用して、レコードがいつ正しかったかを示すことです。
ウィキペディアの記事を読む以外に? 「監査ログ」または同様のトランザクション ログを維持するデータベースには、「一時的」であるといういくつかの特性があります。誰が、誰に対して、いつ、何をしたかについての質問への回答が必要な場合は、テンポラル データベースの適切な候補が得られます。
ちょっとした更新ですが、Temporal データベースは SQL Server 2016 に導入されます。
カスタム メソッドで構成するのではなく、テンポラル データベースが必要な理由と、SQL Server がそれを効率的かつシームレスに構成する方法についての疑問をすべて解消するには、Channel9.msdn の詳細なビデオとデモをご覧ください: https://channel9 .msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016
MSDN リンク: https://msdn.microsoft.com/en-us/library/dn935015(v=sql.130).aspx
現在、SQL Server 2016 の CTP2 (ベータ 2) リリースでは、それで遊ぶことができます。
SQL Server 2016 でテンポラル テーブルを使用する方法については、このビデオを確認してください。
GPS 位置情報を数秒ごとに記録する単純なテンポラル データベースを想像してみてください。このデータを圧縮する機会は非常に多く、通常のデータベースではすべての行のタイムスタンプを保存する必要があります。大量のスループットが必要な場合、データが一時的なものであり、行の更新と削除が必要ないことを知っていると、プログラムは典型的な RDBMS で継承された多くの複雑さを取り除くことができます。
それにもかかわらず、テンポラル データは通常、通常の RDBMS に格納されるだけです。たとえば、PostgreSQL にはいくつかの一時的な拡張機能があり、これによりこれが少し簡単になります。
テンポラル データベースについての私の理解では、特定の種類のテンポラル情報を格納することを目的としています。標準の RDBMS でそれをシミュレートできますが、それをサポートするデータベースを使用することで、多くの概念の組み込みイディオムがあり、クエリ言語はこれらの種類のクエリ用に最適化される可能性があります。
私にとって、これは RDBMS ではなく GIS 固有のデータベースを操作することに少し似ています。ありふれた RDBMS で座標を押し込むこともできますが、適切な表現 (たとえば、グリッド ファイルを介して) を使用する方が高速であり、トポロジなどの SQL プリミティブを使用すると便利です。
学術データベースといくつかの商用データベースがあります。Timecenter にはいくつかのリンクがあります。