制約データベース


8

私は制約プログラミングの背後にある直感を知っているので、制約ソルバーを使用したプログラミングを実際に経験したことはありません。一貫性のあるデータとして定義することを達成できるようになるのは、別の状況だと思いますが。

環境:

ETLサーバーに実装する一連のルールがあります。これらのルールは次のいずれかです。

  • 一列に作用します。
  • 行間、1つまたは異なるテーブルでの動作。
  • 2つの実行間で同じように動作します(すべてのデータ、または最後のn回の実行に対して同じ制約を維持する必要があります)。

3番目のケースは、2番目のケースとは異なります。2番目のケースが成立するときに成立しますが、明確に定義された実行数の場合です。これは、1回の実行(1つのファイル)またはその間の(1からn(前の)またはすべてのファイル)に適用できます。

技術的にはETLを考案したため、2つの実行の間にメモリはありません:2つのファイル(ただし、これは再考されます)

3番目の種類のルールを適用するには、ETLにメモリが必要です(データをETLでバックアップすることになると思います)。または、ある時間枠の後でデータベース全体を無限に再チェック(ジョブ)することで、データベースに到達するデータは、必ずしも3番目の種類のルールを時間内に満たす必要はありません。

例:

継続的に流れるデータがありますが、制約されたデータベース全体に制約を適用します。翌日、たとえば1か月のバックアップまたは修正データを受け取ります。この時間枠では、これだけの制約が満たされるようにしたいと考えていますデータベース全体を気にせずに実行(この時間枠)。将来の実行では、過去のデータを気にせずにすべてのデータを以前と同様に制約する必要があります。時相論理に適合する他のルールを想像できます。

現時点では、最初の種類のルールのみが実装されています。私が考えた方法は、以前に基づいた一貫性を参照するフラグを使用してすべてのデータ(制約された列のみ、おそらくハッシュ値で)をバックアップする(あらゆる種類のMySQL、PostgreSQL、MongoDBなどの)縮小データベースを用意することです一種のルール。

質問:このプロセスを容易にする解決策/概念の代替案はありますか?

するために、説明クックプログラミング言語で、一連のルールと次のアクションの例:

run1 : WHEN tableA.ID == tableB.ID AND tableA.column1 > tableB.column2
       BACK-UP 
       FLAG tableA.rule1
AFTER run1 : LOG ('WARN')

run2 : WHEN tableA.column1 > 0
       DO NOT BACK-UP 
       FLAG tableA.rule2
AFTER run2 : LOG ('ERROR')

:制約プログラミングは理論的には組み合わせ問題を解決するためのパラダイムですが、実際には問題の開発と実行を高速化できます。これは、制約を解決する問題とは異なると思います。最初の目的は解決前に制約を最適化することではないため、おそらくデータドメインを制限することもありません。主な関心事は、データ受信にルールを適用し、いくつかの基本的なアクションを実行することです(行の拒否、行の受け入れ、ロギング...)。

これが非常に広範な質問ではなく、これが正しい場所であることを本当に望みます。

回答:


3

私は思った以上のことを達成するための洗練された解決策を見つけました。データの整合性のチェックについて話します。どうやらこれは私たちがテスト駆動型データ分析と呼ぶものです

したがって、この実装により、PythonとPandasにバインドされましたが、幸いなことに、それだけではありません。MySQL、PostgreSQL ...テーブルでデータの整合性をチェックすることもできます。

私が考えていなかったプラスは、サンプルデータに基づいてルールを推測できることです。これはルールの設定に役立ちます。そこにあるのはこのためですtdda.constraints.verify_dftdda.constraints.discover_df

私が読んだ限りでは、最後の(n)個のファイルの(弱い)整合性をチェックするソリューションは提案されていません。バッチファイルの一貫性と呼ぶことができると私が考えたことは、すべてのデータではなく、いくつかの実行(最後のn回の実行)のルールを満たすことだけを保証します。それは単一のファイルに対してのみ機能し、連続して到着する(n)個のファイルを条件付けできるように、より高いレベルの配線が必要です。

詳細:https : //tdda.readthedocs.io/en/latest/constraints.html#module-tdda.constraints

assertCSVFilesCorrect ディレクトリ内の一連のファイルをチェックします。Pandasデータフレームなどでも同様です。

公式ドキュメントから:

tdda.constraintsライブラリは、(Pandas)DataFrameから制約を検出し、JSONとして書き出し、データセットが制約ファイルの制約を満たすことを確認するために使用されます。また、さまざまなリレーションデータベースのテーブルもサポートしています。制約を検出および検証し、失敗したレコードを検出するためのコマンドラインユーティリティもあります。

ps:私はまだ他のソリューションを受け入れています。これがETLソリューションのユースケースだと想像して私に知らせてください。

また、レスポンスをさらに充実させるためのバウンティを開きます。


2

SQLを調べることもできますtransactions。トランザクションは1つ以上のステートメントで構成され、単一のユーザーまたはアプリケーションによる実行を要求されます。データベースのデータを読み取ったり、変更したりできます。

START TRANSACTION
Do DB stuff, check if constraints are violated
COMMIT

特定の制約を指定してROLLBACK、これらの制約の1つに違反した場合に使用できます。ロールバックは開発者が明示的にコーディングできますが、システムからスローすることもできます。(たとえば、開発者が明示的に処理していないエラーが発生したとき、またはトリガーを実行したとき)。トランザクションは互いに邪魔にならない場合があります。それらは「分離された」方法で実行する必要があります。いくつかの並行トランザクションは、いくつかの(指定されていない)順序で順次実行される同じトランザクションと同じ結果をデータに生成する必要があります。最新のすべてのDBMSはトランザクションに関してACIDプロパティを保証するため、トランザクションの実行は信頼できるため、データベースの状態に不整合があってはなりません。

これがあなたの言っていることかどうかはわかりませんが、おそらく役立つでしょう。


ストリームを制約するためのより流暢な方法を探していました。私の場合、トランザクションには、データの到着時間を制限するためのコーディングが必要です。それにもかかわらず、それはSQLの世界で最も人気のある方法のようです。
Curcuma_19年

1
そうですか。私は、現在データベースにあるデータよりも緩やかな方法で新しいデータストリームを制約する流暢な方法について聞いたことがありません。AFAIK(少なくともSQLシステムでは)、制約プログラミングを1回処理し、それが正しく行われていることを確認して、再度心配する必要がないようにします。その後、データベースは既に整合性が取れており、データベースに新しいデータが入力されると、制約が自動的にチェックされ、処理されます。n個の新しい項目が入力されたときに、データベース全体の整合性を確認する必要はありません。n個の新しいアイテムについてのみ制約がチェックされます
Psychotechnopath
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.