時間的パターン

時間の次元

上記で説明したように、時間はモデリングにおいて非常に困難な概念です。しかし、時間的モデルの最も厄介な側面については省略してきました。私たちは皆、ひどいSF小説からだけでも、時間が4次元であることを学びました。問題は、これが間違っているということです。

この問題を説明する最良の方法は、例を挙げることだと思います。従業員が1月1日から1日あたり100ドルのレートを持っていることを知っている給与計算システムがあると想像してください。2月25日に、このレートで給与計算を実行します。3月15日に、2月15日付けで従業員のレートが1日あたり211ドルに変更されたことを知ります。2月25日のレートは何だったかと尋ねられた場合、何と答えるべきでしょうか？

ある意味では、それがレートだったと今では知っているので、211ドルと答えるべきです。しかし多くの場合、2月25日にレートが100ドルだったと考えていたことを無視することはできません。結局のところ、その時に給与計算を実行しました。私たちは小切手を印刷し、彼に送り、彼はそれを現金化しました。これらはすべて、彼のレートがいくらであったかに基づいて発生しました。税務当局が2月25日の彼のレートを尋ねた場合、これは重要になります。

実際には、私たちにとって重要なディンスデールの給与レートの2つの履歴が実際にあると考えることができます。私たちが今知っている履歴と、2月25日に知っていた履歴です。実際、一般的に、過去の毎日に対するディンスデールの給与レートの履歴だけでなく、ディンスデールの給与レートの履歴の履歴があると言えます。時間は4次元ではなく、4次元と5次元なのです！

私は最初の次元を実際の時間、つまり何かが起こった時間と見なしています。2番目の次元は記録時間、つまり私たちがそれを知った時間です。何かが起こると、常にこれら2つの時間が付随します。ディンスデールの昇給の実際の日は2月15日で、記録日は3月15日でした。同様に、ディンスデールの給与レートは何だったかと尋ねるときは、実際に2つの日付（記録日と実際の日付）を指定する必要があります。

私たちは、2つの次元をこのように考えることができます。実際の履歴は、実際の時間を遡るものです。現在の実際の履歴を見ると、ディンスデールの給料は2月15日まで100ドルで、その時点で211ドルに上がったことがわかります。ただし、これは記録時間における今日の実際の履歴です。2月25日の実際の履歴を見ると、ディンスデールは1月1日から100ドルで支払われ、211ドルはまったく関係していませんでした。記録時間の毎日（厳密には時間点）には、実際の履歴があります。私たちが真実だと思っていたことがもはや真実ではないことを知るにつれて、これらの履歴は異なります。

別の角度から見ると、実際の履歴の毎日には、記録履歴があると言うことができます。記録履歴は、その日についての知識が時間の経過とともにどのように変化したかを教えてくれます。したがって、実際の時間の2月25日には、3月15日までディンスデールの給料は100ドルで、その時点で211ドルに達したという記録履歴があります。

さらに例を掘り下げてみましょう。3月26日の給与計算で対応する調整を行ったと仮定します。4月4日になって、従業員の以前の情報が間違っており、2月15日に実際にはレートが255ドルに変更されていたと伝えられます。ここで、「2月25日の従業員のレートは何だったか？」という質問にどう答えるでしょうか？

私は、経験豊富な開発者がこの種の事態に直面したときに、頭を抱えてしまうのを見てきました。しかし、すべてが2つの次元の概念に帰着すると気づけば、物事ははるかに単純になります。これを視覚化する1つの方法は、以前のテーブルを拡張することです。

現在の実際の履歴（つまり、レコード日が今日である実際の履歴）を見ると、Dinsdaleの給与は1月1日から100ドルで、2月15日に255ドルに上がったと言うでしょう。現在の実際の履歴では、211ドルのレートは一度も発生しません。それは決して真実ではなかったからです。3月26日の実際の履歴を見ると、Dinsdaleの給与は2月15日まで100ドルで、そこから211ドルに上がったことがわかります。3月26日の実際の履歴では、255ドルのレートはまだ知らなかったため、発生しませんでした。

2月25日の記録履歴についても考えてみましょう。この記録履歴では、レートは3月15日に211ドルに変更されるまで（その日は）100ドルだったと示しています。その後、4月4日に再び255ドルに変更されました。

2つの次元について理解すると、問題を考えるのがはるかに簡単になりますが、この種のものを実装する必要があると思うと恐ろしくなります。幸いなことに、実装に関しては問題を簡略化できるいくつかの方法があります。

最初の簡略化は、監査ログを使用してこれらの変更に対処するのが難しくないということです。必要なのは、各エントリでログにレコード日と実際の日付の両方を記録することだけです。この単純な作業だけで、両方の次元でログを有効に保つのに十分であり、片方の次元しか気にしない場合でも、実行する価値があると私は信じています。

2番目の簡略化は、多くの場合、モデルに両方の次元を処理させたくないということです。ここで重要なのは、モデルにどちらがあり、監査ログにどちらを残しているかを知ることです。

時間の経過とともに物事がどのように変化したかを知りたいものの、変更を知った時期を気にしない履歴を保持したい場合、それは実時間的であると言うでしょう。したがって、従業員の住所の記録を保持する場合、それを実時間的なプロパティとして保持することを選択するかもしれません。オンラインクエリを支援するための情報システムの場合、データベースにアクセスするときは通常、実際の履歴について知りたいので、これはうまく機能します。

記録時間的な事実は、オブジェクトの状態に基づいて請求書を作成するようなシステムがある場合に現れます。これらのことは、請求書がどのように計算されたかについての質問につながり、請求書が計算されたときにオブジェクトの状態が何だったかを知る必要が出てきます。記録時間的な事実は、多くの場合、ソフトウェアのバージョン管理システムと比較でき、「4月1日のこのファイルはどのようなものだったか？」を遡って確認できます。

もちろん、両方の次元を一度に必要とするときもあります。これらは二時間的事実と呼ばれます。基本的に、二時間的な情報には常に両方の日付が必要です。

二時間性は完全な解決策ですが、それを回避する方法を常に考える価値があります。例として、請求書の計算があります。請求書がなぜそのようになったのかを知りたい場合、1つの可能性は完全に二時間的なデータベースを持つことです。ただし、請求書を計算するときに計算の詳細なトレースを保存する方が多くの場合優れています。それは、二時間的なオブジェクトモデルよりもはるかに単純な方法で要件を満たします。

時間的レコードの更新

これまで、情報の更新ではなく、情報へのアクセスという観点から時間的な情報についてのみ説明してきました。更新をどのように許可するかによって、さらに多くの決定が導かれますが、その多くには役立つ簡略化が含まれます。

一般的に、時間記録を変更するのは非常に面倒です。従業員のレートが2月15日から4月15日まで211ドルだった場合、完全に一般的な更新では、開始日、終了日、および値の任意の組み合わせを変更できます。クライアントが時間的な情報がどのように機能するかについて多くを知る必要があるため、このインターフェースを提供するのは面倒です。

最初の簡略化は、加算的な変更のみがある場合です。加算的な変更は常に記録の最後に追加されます。加算的な変更の例は、「2月15日から従業員のレートを211ドルにする」です。最初は、データの一部をミックスから削除しているだけのように見えますが、結果として更新が大幅に簡略化されます。実際に行われる更新のほとんどは加算的であるため、クライアントを大幅に簡略化できます。さらに、加算的な更新の組み合わせで変更を加えることができます。これにより、複雑な履歴を持つオブジェクトではひどく混乱する可能性がありますが、このプロパティを使用すると、加算的なインターフェイスのみをサポートすることで、単純な履歴を持つオブジェクトを簡略化できます。

2番目の簡略化は、現在の更新のみを許可することです。現在の更新では、今日有効な日付でのみ記録を変更できます。一般に、加算的な変更でさえ、過去または未来の任意の日付で発生する可能性があります。現在の変更では、日付情報がまったく必要ないため、完全に非時間的な更新のインターフェースを持つことができます。

現在の更新は信じられないほど優れているように見えます。現在の更新でのみ更新する場合、なぜ時間的な情報が必要なのでしょうか？ここでの朗報は、記録時間的な情報は現在の更新でのみ更新できるということです。記録時間的な情報への遡及的な変更は記録の整合性を損なうだけでなく、実際時間的な次元で処理できない遡及的な変更が必要な状況はありません（詐欺が要件の1つでない限り）。これは、1つの次元全体に非表示の更新があることを意味するため、大きな一歩です。更新時ではなく、クエリ時に記録時間を気にするだけで済みます。

その他の資料

これは複雑な分野であるため、人々がこれらの問題を検討するにつれて、他の著作も生まれています。この分野の最も包括的な扱いは、Snodgrassです。彼の作品はリレーショナルデータベースに基づいており、本のほとんどはSQLでこれらの問題を処理する方法に基づいています。ただし、問題は同じです。さらに、彼が行うコメントや使用する用語の多くは、時間的データベースに関する今後のSQL標準の資料と同じです。この本は現在絶版ですが、Richard Snodgrassの出版ページからPDFを入手できます。

用語の問題は、私がまだ完全には満足していない問題の1つです。彼は私と同じ2つの次元を使用していますが、彼の用語は異なります。私が実時間と呼んでいるものを彼は有効時間と呼び、私が記録時間と呼んでいるものを彼はトランザクション時間と呼んでいます。これらのパターンの初期バージョンでは、私は彼の用語に従っていましたが、多くの人がこれらの用語は非常に理解しにくいと言っていました。その結果、私は別の用語を使用することにしました。もう1つの違いは、時間の経過とともに変化するテーブルを彼がシーケンス化と呼んでいることです。もちろん、オブジェクトは時間的な目的だけでなく、常にシーケンスを使用するため、私は時間の経過とともに変化するものを時間的と呼んでいます。

[Anderson]は、時間的なパターンの最高のコレクションの1つです。繰り返しますが、私はアイデアを略奪しましたが、一部の用語を変更しました。私はエディションではなく、バージョンという用語を使用して、ある期間中のプロパティまたはオブジェクトの値を示しました。彼の変更ログおよび関連付け履歴パターンは、時間的プロパティと同じです。私は、2つのアンダーソンパターンの違いを実装の問題と見なしています。彼の自己履歴パターンは、時間的オブジェクトと同じです。

また、同じPLoPD 4の本には、アンディ・カールソンが私とシャロン・エステップと共同で書いた論文[Carlson et al]があります。これは、時間的プロパティとスナップショットの以前の説明を示しています。また、現在有効性の使用と見なしている時間的関連付けパターンについても言及しています。

PLoPにも提出されましたが、現時点では公開されていないのは、[Arnoldi et al]です。これは、私がここのパターンで（少なくともまだ）十分に調査していない、いくつかの興味深いアイデアを紹介しています。

[Anderson]と[Arnoldi et al]の両方が、時間的記録へのインデックスとして機能するために、タイムポイント以外のオブジェクトを使用することを検討しています。[Anderson]は（単一時間的な）イベントを使用し、[Arnoldi et al]はパースペクティブを使用します。これは基本的に2つのタイムポイントを1つのオブジェクトに結合したものです。これらのアプローチの両方に言えることはありますが、タイムポイントを使用することで必要なもののほとんどが実現でき、説明が簡単だと感じているため、ここでは使用していません。