問題タブ [temporal-database]

一時的な認識をクラスにできるだけ直接統合する方法を探しています。私は、株価のように時間とともに大きく変化するデータを扱っているため、これにはおそらく注意が必要であり、「関心の分離」を確実にするために 1 か所で処理する必要があります。

時系列データ/データベースで同様の経験をしたことがありますか?

何を読む/知ることをお勧めしますか?

(私の計算の「地平線」を構成する指定された日付にスコープを取得するために、TimeSlice(date) 計算式ビルダーの周りに私の計算をラップすることを考えています。

EclipseLinkを使用してJPA2にテンポラルテーブルを実装する方法を知りたいです。時間的とは、有効期間を定義するテーブルを意味します。

私が直面している問題の1つは、参照テーブルの性質上、主キーに有効期間が含まれているため、参照テーブルが参照テーブル（一時テーブル）に対する外部キー制約を持たなくなることです。

• エンティティの関係をどのようにマッピングしますか？
• それは、私のエンティティがそれらの有効な時間のエンティティとの関係をもはや持つことができないことを意味しますか？
• これらの関係を初期化する責任は、ある種のサービスまたは特殊なDAOで手動で行う必要がありますか？

私が見つけた唯一のものは、これを処理するDAOFusionと呼ばれるフレームワークです。

• これを解決する他の方法はありますか？
• このトピックに関する例またはリソース（時制データベースを備えたJPA）を提供していただけますか？

これは、データモデルとそのクラスの架空の例です。これは、時間的な側面を扱う必要のない単純なモデルとして始まります。

最初のシナリオ：非時間モデル

データモデル：

チーム：

プレイヤー：

テストクラス：

ここで、チームとプレーヤーが特定の時点でどのようにいたかを履歴に残すように求められます。そのため、追跡するテーブルごとに期間を追加する必要があります。それでは、これらの時間列を追加しましょう。から始めPlayerます。

2番目のシナリオ：時間モデル

データ・モデル：

ご覧のとおり、主キーを削除して、日付（期間）を含む別のキーを定義する必要がありました。また、テーブル内で繰り返すことができるようになったため、一意の制約を削除する必要がありました。これで、テーブルに現在のエントリと履歴を含めることができます。

Teamを一時的にする必要がある場合、状況はかなり醜くなります。この場合、Playerテーブルが必要とする外部キー制約を削除する必要がありますTeam。問題は、JavaとJPAでそれをどのようにモデル化するかです。

IDは代理キーであることに注意してください。ただし、サロゲートキーには日付を含める必要があります。含めない場合、同じエンティティの複数の「バージョン」を（タイムライン中に）保存することはできません。

SQL2011 仕様で定義されている PERIOD 列が完璧なソリューションであるプロジェクトがあります。残念ながら、この機能をサポートしていないデータベースとして MSSQL 2008R2 (またはおそらく MSSQL 2012) を使用せざるを得ません。

現在 MSSQL にある SQL2011 の PERIOD 機能に似た独自の機能はありますか? そうでない場合、それに似たものを実装しようとする最善の方法についてのアドバイスはありますか?

私は現在、データの非常に大きな割合が一時的なものであるデータベースを作成しようとしています。これを行うための多くのテクニック（ほとんどは6nfの正規化を含む）を読んだ後、アンカーモデリングに遭遇しました。

私が開発していたスキーマは、特にユースケース（時間データ+既知の未知数）が非常に似ているため、アンカーモデリングモデルに非常に似ていたため、完全に採用したいと思っています。

私が抱えている2つの最大の問題は、このアプローチの欠点を詳しく説明しているものが見つからないことと、戦争の物語や落とし穴の制作にこのアプローチを使用している組織への言及が見つからないことです。

ここにいる誰かが、いくつかのネガティブ（ポジティブは研究論文とそのサイトで非常によく宣伝されているため）と、それを本番環境で使用した経験について簡単に説明するのに十分な知識があるかどうか疑問に思います。

明確にするために、私がアジャイルと言うとき、アジャイル開発プロセスのことを意味しているわけではありません。つまり、新しいオブジェクト属性を追加および管理できる、進化するデータ モデルです。

ユーザーがデータ入力用の新しいコンテンツ フォームを作成できるようにする Web アプリケーションの課題に取り組もうとしています。このフォームは、追加のフィールドを追加 (または場合によっては変更) することで進化 (おそらくバージョン管理) できます。これ自体は単純明快です。各ユーザーのコンテンツ フォームには、読み取り/書き込みを処理する動的に作成されたビューとトリガーがあり、コンテンツ フォームの構造が変更されると、基になるテーブルが動的に作成されます。データ入力ではトリガーを使用して書き込みを行い、ビューを使用して読み取りを行います。

私がアドバイスを求めているのは、この種の課題に役立つ既存のデータベース モデリング手法またはデータベース タイプがあるかどうかです。アプリケーションには、変更の追跡、履歴の表示、根本的に異なるコンテンツ フォーム間の移行などに関するより多くの要件があります。おそらく、いくつかの複雑な認証ベースの Web アプリケーションの表示も同様に追加されるでしょう。

私はAnchor Modelingを詳しく調べました。これにはバイテンポラル モデリングの側面があり、その 6NF によってアジャイルなスキーマ開発が可能になりますが、適切に開発されたモデルから SQL スクリプト、コンテンツを進化させることができる Web アプリケーションに移行する方法が明確ではありません。データ。たぶん私はそれを間違って見ているかもしれませんが、アンカーモデルのトリガーやビューを変更したくないので、オンデマンドで拡張できるモデルを作成できるとは思いません. 変更を安全に行うには、モデリング ツールが必要です。

利用可能な NoSQL データベースのいくつかをさらに調査する必要があります。MongoDBは、そのドキュメント指向のストレージで非常に興味深いようです。

これらのツールまたは説明したデータ モデリングの課題に関するアドバイスや経験は大歓迎です。事前にご回答いただきありがとうございます。

リビジョン、または行のスナップショット (およびそれらの関係) をデータベースに保持するための適切なプロセスを探しています。

たとえば、eコマースプラットフォームを考えてみましょう-

• 顧客が注文を作成します。注文は、請求先住所と配送先住所に関連付けられています。
• この顧客は、プロファイルのアドレス帳の住所を変更します。
• 元の注文の住所は変更しないでください。

いくつかの概念を見てきました。1 つはテーブルの複製、もう 1 つはテンポラル データベース、もう 1 つはリビジョン ID とアクティブ フラグの保持です。

私のアプリケーションに最適/最適な解決策を誰も私に教えてくれないことを感謝していますが、それは意見などに開かれた問題であるため、誰かがおそらく比較によって利点/欠点を実証できることを望んでいました. SO に関する多くの質問と、さまざまな実装に関するかなりの数の記事を読みましたが、それぞれのアイデアを実際に比較したり、最適な場所を示したりするものはありません。以下に、それぞれの概念についての私の理解を概説します。

テーブルの複製

スナップショットを作成する必要があるデータに関連する行に情報を格納します。つまり、オンライン ストアの注文テーブルの列に住所を保持します。

利点

• データは明確に関連するテーブルに分割され、結合などは必要ありません。
• 以下の概念で必要とされるように、アクティブな行のみを選択する必要はありません。
• 行にタイムスタンプが付けられていると仮定すると、テンポラル データベースの利点のほとんどが維持されます。

短所

• 複製
  • スキーマの (複数のテーブルがリビジョンをアップしている場合に特に問題があります)
  • ORM を使用する場合のモデルの。
  • スナップショット ピースのデータが変更されておらず、再利用されている場合のデータの。つまり、10 回の注文が行われた場合、アドレスは 11 回 (注文 + 現在) 保存されます。
• 関連するテーブルへの挿入を処理するために必要な追加のコード。

テンポラル データベース/アクティブまたは現在の行フラグ

「時間認識」のデータベース行。つまり、そのコンテキストは 2 つの日時の間の時間です。データは、時間コンテキストがテンポラル テーブルの時間コンテキストの間にある場合に結合できます。

利点

• スキーマまたはモデルの重複はありません。変更は 1 か所で行われます。
• ORM モデルは、新しい行の作成、アクティブとしてのマーク付けなどをシームレスに処理できます。
• 変更が行われていない行は複製されません。つまり、1 つのアドレスへの 10 の注文は、アドレスを 1 回保存します。

短所

• join/where 句で「アクティブな」行を選択する必要があるため、クエリがより複雑になります。
• テーブルは、定期的に選択/呼び出されない履歴データでいっぱいになります。

一時的に変更された列のみを保存します。

すべてのテーブルへの変更を追跡するテーブルを用意し、それが関連する行と、それが時間的に有効な時期を記録します。

利点

• 変更されていないデータが複製されないため、リビジョンに関して最適化されたストレージ。

短所

• 列のバージョンを他のデータと組み合わせるには、はるかに複雑なクエリを実行します。

SOに関する次の質問とこれらの他のリソースをすでに見ました

編集: この投稿に特定の DBMS のタグを付けていない理由は、理想的にはプラットフォームとして可能な限り多くのプラットフォームで動作するコンセプトを望んでいるためです。現時点では DBMS に依存せず、抽象化レイヤーにより MySQL と動作できます。 MSSQL ですが、将来的には他のものもサポートする予定です。

• リビジョン用のデータベース設計?
• ファウラーの時間式のリレーショナル スキーマ
• テキスト改訂のためのデータベース設計
• リレーショナル オブジェクトのリビジョンを効率的に保存する
• ページの変更履歴を保持します。SOがリビジョンに対して行うのと少し似ています
• データベースに履歴を保持する
• http://en.wikipedia.org/wiki/Temporal_database
• http://www.simple-talk.com/sql/database-administration/database-design-a-point-in-time-architecture/

私は一時的なデータベースを持っており、以下に関してデータを平均したいと考えていました: `

例えば：

13 = 観測期間 12:41 ～ 13:40。予想された結果：

コードは、(HH-1):41 から HH:40 の瞬時値を減算する必要があります。

サンプルデータ：

さらに、date_time 列はタイムスタンプ形式です。平均は移動平均であってはならず、単純平均に興味があります。

Coloroaldo によって提案されたコード:

時制データベースがあり、次の時系列のデータを使用して、時系列データの平均関数を介して時制集計を実行したいと思います。

また、上記の値は瞬時値です。

サンプルデータ：

そして期待される結果：

時間平均0:00=（-1.68 + -1.64 + -1.87 + -1.90 + -2.18 + -1.86）/ 6

サンプリング頻度が 2 分のテンポラル データベースがあり、1 日の瞬時値を 00:00、01:00、02、... 23 として抽出したいと考えています。
だから、私は値の平均から平均値を取得したいと思います:

HH-1:58、HH:00、および HH:02 = HH 時の平均

また

HH-1:59、HH:01、および HH:03 = HH 時の平均

サンプルデータ1:

期待される結果：

午前 0 時の場合:

(-1.92+-1.64+-1.76)/3

サンプルデータ2:

予想された結果：

(-2.01+-1.52+-1.48)/3

時制データベースがあり、5分前と5分後のHH瞬時値ごとに平均関数で集計したいと思います。データサンプリングの頻度は2分で、データにはタイムスタンプと温度列が含まれます。まず、コードは00、01、02、03、... 24から瞬時値を抽出してから、瞬時時間の前の2つの観測値と後の2つの観測値を適用する必要があります。さらに、dbでは、分が奇数である場合と偶数である場合があります。つまり、HH-1：59とHH：00の両方があります。平均値は、5つの値の平均から得られます。date_time列の形式はタイムスタンプです。さらに、コードは複数日のデータを処理できる必要があります。

サンプルデータ：

推測される結果：

16時の時間平均は：5.7 = 5.36 + 5.80 + 6.06 + 5.70 + 5.58

このコードを試しましたが、正しく機能しません。