問題タブ [temporal-database]

私はこのタスクに頭を悩ませようとしていますが、これを行うための標準的な方法や、役立つライブラリがあるかどうか疑問に思っています。

特定のイベントは、いくつかのデータソースS1...SNで追跡および計測されます。記録される情報は、イベントタイプとタイムスタンプです。同じタイプのイベントが連続して複数発生する場合もあれば、断続的に発生する場合もあります。「欠落」イベントが発生する可能性があります。つまり、ソースの1つがそれを見逃した場合、およびその逆の場合、ソースが「誤検知」を導入した場合です。通常、異なるソースでの同じイベントの観測には時間差があります。この時間差には、ソースの物理的な場所によって一定の要素がありますが、ネットワークの遅延やその他の要因によって変化する要素が含まれる場合もあります。

すべてのソースでの観測を単一の「観測イベント」にグループ化し、欠落イベントと誤検知を検出できるようにするために使用する必要がある最適な最大時間間隔を見つけるアルゴリズムを見つける必要があります。

解決策が本当にアルゴリズムではなく統計分野のどこかにあるのだろうかと思います。任意の入力をいただければ幸いです。

この質問データベースにとらわれないようにするつもりですが、取り組む必要のある興味深い問題があり、提案やフィードバックのためにフロアを開くと思いました。

フィードソースからデータをダウンロードして何らかのデータベースに保存できる必要があります。データを既存のデータにマージし、任意の日付のデータをクエリできる必要があります。私が話したいのは太字の部分です。

基本的に、この問題の要約は、オブジェクトグラフをOLTPデータベースに永続化し、一時的にクエリできるようにする必要があるということです。

1つのテーブルの単純なケースでは、この問題は非常に単純です。レコードの有効な期間を示す日付範囲があり、その範囲を渡して、この時点で有効な行のみを選択します。複数のテーブルがある場合、問題が発生します。

Order-*Itemという2つのテーブルがある場合を考えてみましょう。

注文を照会するとき、日付の変更と同じものをアイテムテーブルに適用できます。すべて順調ですが、注文を変更したい場合はどうなりますか？次に、注文行をコピーし、日付範囲を設定して、新しい行の有効なfromと新しい行の有効なtoがnowに設定されるようにする必要があります。また、アイテムをコピーする必要があります。モデルを変更する場合は、アイテムへの参照をコピーします。

この単純な場合でも、物事は複雑になり始めています。

自己参照オブジェクトグラフがあるため、問題が悪化します。上記のモデルを使用するには、Order- * Item-*Orderがあります。

あなたならどうしますか？行のバージョン管理と一時クエリが必要な場合、データベースをどのように構成しますか？

NoSQL プラットフォーム上に構築されたバイテンポラル データベース (riak など) を実装したことがある人、または知っている人がいるかどうかに興味があります。

この質問は、私の他の質問の 1 つにあるスキーマに関連しています。 基本的に、私のデータベースには、ユーザー、場所、センサーなどを保存しています。これらはすべて、ユーザーがシステム内で編集可能であり、削除可能です。

ただし、アイテムが編集または削除されると、古いデータを保存する必要があります。変更前のデータを確認できる必要があります。

データベースには、「読み値」など、編集できない項目もあります。それらは実際にはログのようなものです。特定のセンサーの読み取り値であるため、読み取り値はセンサーに対してログに記録されます。

読み取り値のレポートを生成する場合、読み取り時の位置またはセンサーの属性を確認できる必要があります。

基本的に、いつでもデータを再構築できるはずです。

さて、私は以前にこれを行ったことがあり、編集可能な各テーブルに次の列を追加することでうまく機能しました。

valid_to = 9999-12-31 23:59:59 の場合、それが現在のレコードです。valid_to が valid_from と等しい場合、レコードは削除されます。

しかし、外部キーの一貫性を強制するために必要なトリガーには決して満足できませんでした。

「PostgreSQL」データベースの拡張機能を使用することで、トリガーを回避できる可能性があります。これにより、「期間」と呼ばれる列タイプが提供され、2 つの日付の間の期間を格納できるようになり、期間の重複を防ぐために CHECK 制約を実行できるようになります。それが答えかもしれません。

別の方法があるかどうか疑問に思っています。

特別な履歴テーブルの使用について言及している人を見てきましたが、ほぼ 1 つのテーブルごとに 2 つのテーブルを維持するという考えはあまり好きではありません (まだ可能性はあるかもしれませんが)。

「最新」ではないレコードの一貫性をチェックしないように、最初の実装を減らすことができるかもしれません。結局のところ、履歴テーブルを使用する人は、それらのテーブルに対して制約チェックを行っていないようです (同じ理由で、トリガーが必要になります)。

これについて何か考えている人はいますか？

PS - タイトルには、監査可能なデータベースについても言及されています。私が言及した前のシステムでは、常に edit_by フィールドがあります。これにより、すべての変更を追跡できるため、誰がレコードを変更したかを常に確認できました。それがどれほどの違いをもたらすかはわかりません。

ありがとう。

軌道表

上記のような軌跡テーブルがあります。結果を取得するために JDBC-SQL を使用した時空間クエリが必要です。

1. 「場所 H から場所 B に移動するすべての OBJID を見つける」
2. 「場所 H から場所 B に移動するユーザーの軌跡をすべて見つけてください」

たとえば、この画像では objid 7 が H から B に移動するため、結果は になります。

出力

これにはSQLクエリが必要です。

時空間データを保持するためのリレーショナル DB テーブルを設計するためのベスト プラクティスに興味があります。具体的には、そのようなテーブルに保持されるデータは、特定の有効期間、ジオメトリ定義、および階層的側面を持つカスタム ジオメトリです (特定のジオメトリは他のジオメトリの子になります)。

誰かがこのテーマに関する優れた資料を教えてくれたり、特定の実装を提案してくれたりしてくれませんか。

ありがとうございました。

過去に NHibernate と EF で大きな成功を収めた私は、バイテンポラル データベース スキーマを使用する新しい Java プロジェクトで Hibernate を使用するようチーム メンバーを説得しようとしています。ただし、これまでバイテンポラル モデルで NHibernate (またはその他の ORM) を使用したことはありません。

バイテンポラル データベース モデルで Hibernate/NHibernate を使用する際に注意すべき落とし穴やアドバイスはありますか?

ありがとう！

私はPostgreSQLデータベースを使用した一時的な集約のためのJava実装に取り​​組んでいます。

私のテーブルはこんな感じ

したがって、この期間を視覚化するには：

私のアルゴリズムは、データの時間的集計を計算するようになりました。例：SUM（）：

得られた結果をテストするために、PostgreSQLを使用してデータを直接クエリしたいと思います。この問題を解決する簡単な方法はまだありません。ただし、同じ結果を得る方法は確かにあります。集計Count、Max、Min、Sum、およびAverageがサポートされている必要があります。私は悪い解決策や遅い解決策を気にしません、それはただうまくいく必要があります。

これまでに見つけた、同様に機能するはずのクエリは次のとおりです。

私の養子縁組は次のようになります。

ただし、エラーが報告されERROR: syntax error at or near "normalize" -- LINE 2: from ( ndbs_10 a normalize ndbs_10 b using() ) ndbsNormました。

誰かがこの問題の解決策を持っていますか？それが機能する限り、上記のクエリに基づく必要はありません。どうもありがとう。

特定の時点で、資産には実効価格があります。資産によっては、週に 1 回、または 1 日 1 回新しい価格になるものがあります。直近の価格が「実効価格」です。

記述された関係を格納するテンポラル テーブルは次のようになります。

データは次のようになります。

の実効価格を照会するのAssetIdは簡単ですが、計算にはかなりの時間がかかります。

データを物理的に保存して、データが変更された場合にのみdbo.AssetPrice実効価格の再計算が必要になるようにするのが理想的です。関連する集計関数はインデックス付きビューでは許可されていないため、インデックス付きビューを作成できないと思います。

テーブルを調整して実効価格 (最新の価格) を非常に迅速に取得するにはどうすればよいですか?

私がエンティティを持っているとしましょう$e。同じエンティティデータであるが別の主キーを持つ別の行として保存する一般的な方法はありますか？

これが必要な理由：ある種の時制データベーススキーマを実装していて、行を更新する代わりに、別のスキーマを作成する必要があります。