1

ERP データベースに販売注文の履歴情報がありません。販売注文を含むテーブルがあります。販売注文が承認されると、請求書に変換され、記録された販売注文は削除されます。

必要な情報のみを含む履歴テーブルを ERP にコーディングできます。これはデータ ウェアハウスによって解決されるべきものだと思いました (これも個人的な興味によるものです)。

日付ごとにどれだけの注文があるかを確認したい。たとえば、月ごとの合計金額が XXX の平均 X 件の注文があることを確認したいと考えています。

「有効期限」と「期限まで」の列をどこに追加するかを考えました。そこから私はブロックされています。私のイニシャルはどこでSCDを使用するかですが、私が理解しているように、主キーでそれを行うことはできません。

新しいファクト テーブルを作成する必要がありますか (ERP データベースで行うように) ? 販売注文テーブルからの挿入トリガーまたは削除トリガーにも何かをプログラムしたくありません。1 日の終わりに販売注文テーブルをクリーンアップします。夜間にデータ ウェアハウスを更新するときに更新する必要があります。この場合、注文が承認されないことや、関係のない記録を保存することを考慮する必要はありません。

4

1 に答える 1

0

私が収集できる限り、あなたは悪いデータ モデルに苦しんでいます。

場合

販売注文表があります。このテーブルのレコードは保持されず (たとえば、ステータスが変更されたり、「順序付けられた」テーブルに単純にコピーされたりします)、削除されます。

これが最初の間違いです。

次に、削除トリガーをリッスンしたくないと言います。残念ながら、私が理解している限り、削除は毎日発生する可能性があります。したがって、販売注文テーブルからデータを収集するジョブは、少なくとも承認が非常に迅速に行われる場合、毎分実行する必要があります。これも疑わしい設計上の決定です。

アプローチ

個人的には、DWH から始めません。挿入トリガーが発生したときに新しい売上データを入力する単純なジョブから始めます。これは、時間の経過とともにデルタ チェックのコストが高くなるためです。

そして、このテーブルにすべての情報が含まれていれば、データ分析に使用できます。

質問

ただし、注文がキャンセルされた場合のプロセスも特定する必要があります。これらの注文が承認されたからではなく、キャンセルされたために削除されたことをどのように知ることができますか?

プロセスの段階でより明確な概念があれば、DWH などでデータを使用するのがより簡単になります。しかし、DWH でさえ、少なくともステータスの変化に対して事前にプロセスが明確に定義されていなければ役に立ちません。

于 2016-09-14T15:48:38.247 に答える