データ モデルでキャプチャされた現実の時間的側面を考慮することは、有効な時間とトランザクション時間のディメンションを明確に区別することから始める必要があると思います。細かい粒度の時間でキャプチャされた「事実」の複数のソースを考慮しない限り、「CEO」状態を1つの一般的な時間次元状態「いつ」と一緒に持つ「ある時点」のCEOによるアプローチの例で十分ですスケール。それ以外の場合は、S&P 500 インデックスの値とその構成銘柄の価格の間など、株価とその関係についての質問で言及した問題に目を向けると、これら 2 つの次元を区別して内部データ状態に取り込むことから逃れることはできません。: S&P 500 インデックスの値は、ある有効な時点で構成銘柄の価格を収集し、(瞬間的ではない) 重み付けと計算を実行して、後のトランザクション時間でインデックス値を計算する必要があるため、あるトランザクション時間に関してのみ意味があります。実際、これは有効な時間の過去の瞬間の値です。
または、あなたの例にとどまるとしても、過去のある時点でのあなたの対応をいつでも監査するようにコンプライアンス部門から要求されたと想像してください。言い換えれば、あなたの時間指定子
historicalDate(date: <time expression>)
より一般的なケースの特定のバリアントです
historicalDate(date: <valid time expression>,
asOf: <transaction time expression>)
historicalDate(Today() - 1yr)
実際には
そうですhistoricalDate(Today() - 1yr, Now())
が、原則的にはそうかもしれません
historicalDate(Today() - 1yr, Now() - 20days)
バイテンポラルにデータを処理することは、計算式などの特定の言語メカニズムを介してデータを飼いならすための短い万能レシピを与えるほど単純な問題ではありません。いくつかの読書をすることは間違いなく良い考えです。この件に関して私が推薦できる本は何かと尋ねられた場合、私の答えはManaging Time in Relational Databasesです。それ以外の場合は、徹底的な調査が必要な場合は、従来
の SQLおよびテンポラル データとリレーショナル モデルでの時間指向データベース アプリケーションの開発を検討することもできます。 .
他の誰かが、リレーショナル ベースの永続化メカニズムの外部で一時的なデータ状態を処理する方法を教えてくれるかもしれませんが、私自身の経験はそのようなものに限られています。