web-dev-qa-db-ja.com

使用されたプロシージャフィールドの保存

私は本番作業（特にラボテスト）用のデータベースを作成しています。

ほとんどのWorkは本番用であるため、そのProcedureのProductに従って厳密に実行されます。それ自体で、これは簡単にモデル化できます。 Workは、作業の実行方法が含まれているため、Procedureを参照します。

Example Schema
Work:      Work_id, Procedure_id, {other non-relevant fields}
Procedure: Procedure_id, Product_id, Machine_id, Material_id, RunMinutes

2つの例外（オーバーライドと特別なテスト）により、設計が非常に複雑になります。

質問：以下の2つの例外を考えると、各Procedureに実際に使用されたWorkフィールドをどのように保存する必要がありますか？

例外-オーバーライド：

必要な機器やコンポーネントが利用できない場合があります。このような場合、マネージャーは同等の代替品の1回限りのオーバーライドを承認できます。例：

  1. マシンXが壊れていました。 Workを手動で実行します。
  2. マテリアルYが不足しました。代わりにマテリアルZを使用してください。
  3. 実行時間を45分に保つ

データベースは、Workが実際にどのように実行されたかをキャプチャする必要があります。

3つの可能なオプションがあります。

オプション1：ローカルに保存：Workは元のProcedureを参照します。各Workは、変更を含め、使用されたProcedureフィールドもローカルに保存します。これにより多くの重複が作成されますが、Workごとにローカルの「スナップショット」があります。

Example Schema
Work_id | Procedure_id    | Machine | Material | RunMinutes
1       | 1               | By-Hand | Z        | 45  

Procedure_id | Product_id | Machine | Material | RunMinutes
1            | 1          | X       | Y        | 45

オプション2：シングルユース手順：元のProcedureが新しいProcedureにコピーされ、非アクティブとしてマークされ、オーバーライドで変更されます。次に、Workは新しいProcedureを参照します。これにより、Workが実行された方法のWork.Procedure_idが維持されます。

Example Schema
Work_id | Procedure_id
1       | 2

Procedure_id | Product_id| Active| Machine | Material | RunMinutes
1            | 1         | Y     | X       | Y        | 45
2            | 1         | N     | By-Hand | Z        | 45

オプション3：オーバーライドとして保存：WorkはProcedureを指し、オプションでProcedureOverrideテーブルを指します。 Procedureの各フィールドについて、オーバーライドがある場合はそれを使用し、そうでない場合はProcedure値を使用します。

Example Schema 
Work_id| Procedure_id| Override_id
1      | 1           | 1

Procedure_id| Product_id| Machine | Material | RunMinutes
1           | 1         | X       | Y        | 45

Override_id             | Machine | Material | RunMinutes
1                       | By-Hand | Z        | NULL  

Query: ActualWork
Work_id   |Procedure_id | Machine | Material | RunMinutes
1         |             | By-Hand | Z        | 45

例外-特別なテスト：

非標準的な作業（研究開発など）の場合、特定のProcedureはありません。この場合も、データベースはWorkが実際にどのように実行されたかをキャプチャする必要があります。

2つのオプションが表示されます（上記のそれぞれのオプションと同等）

オプション1：ローカルに保存：各Workは、使用されたすべてのProcedureフィールドをローカルに保存します。ユーザーは各フィールドに値を入力する必要があります。

オプション2：シングルユース手順：新しいProcedureが作成され、非アクティブとしてマークされ、ユーザーによって入力されます。次に、Workは新しいProcedureを参照します。これにより、Workが実行された方法のWork.Procedure_idが維持されます。

ただし、非標準のProcedureには実際の（現実の）Workはありません。

database-designnormalizationbest-practicesdenormalization
2
Steven

したがって、これは主に適切なデータの正規化に関する質問のようです。

データの正規化を念頭に置いて、オプション1を簡単に除外できます。ご提案のとおり、データは明らかに正規化されておらず、繰り返されます。

オプション3は、ドメインをキャプチャしていない現在のスキーマを処理するためのハックのように見えます。このようなハックを実装する必要がある場合は、間違いなく再設計の時期です。

これでオプション2が表示されます。3つのオプションのうち、これが最適のようです。ただし、スキーマはさらに適切な正規化が可能であるように思われます。ドメインについて詳しく知らなくても、Machine、Material、RunTimeの間にはおそらく何らかの機能依存性があると思います。または、製品IDが含まれる場合もあります。もちろん、これらの4つの値すべてが他の値に影響を与えることなく自由に異なる場合は、スキーマ最適化のこの領域は無視できます。

プロシージャテーブルに機能依存性が存在しない場合は、オプション2で提案されているように、カスタム作業をキャプチャするための新しい「非アクティブ」プロシージャを備えたスキーマが全体として最良の選択であるように見えます。

2
Apneal

特定の作業/手順のペアに対して複数の例外が発生する可能性があり、各例外によって1つ以上の異なる手順フィールドが変更される可能性があると想定しています。

確かに各変更を独自の行に保存することはできますが（「オーバーライド」）、「現在の」設定または履歴ビューを取得しようとするクエリは複雑になります（特に、現在の設計（提示されているように）は複雑になるため）変更が適用された順序を示す手段がないようです）。

提供された情報のみに基づいて、私はおそらく典型的な履歴/監査ソリューションを選択します：

  • 作業と手順の間の1-1の関係を維持する

  • 例外が必要な場合は、Procedureを新しい値で更新します

  • procedureのトリガーは、古いレコードを監査/履歴テーブル（Procedure_histなど）に書き込みます。同じ列に加えて、順序を指定するための1つの追加列（seq_no、modification_datetimeなど）があります。

  • 現在の作業/手順の構成を確認したい場合は、作業と手順に参加します。例：

    選択... 
作業からw 
手順p 
に参加w.Procedure_id = p.Procedure_id

  • 履歴/監査ビューを表示する必要がある場合は、Procedure_histテーブルを、おそらく外部結合としてプルできます。例：

    select ... 
 from Work w 
 join Procedure p 
 on w.Procedure_id = p.Procedure_id 
 left 
 join Procedure_hist h 
 on w.Procedure_id = h.Procedure_id

これは、オプション＃2のわずかなバリエーションです。はい、それはデータの重複を意味しますが、コーディング（更新、取得）も簡単になり、将来の保守が少し簡単になる可能性があります（特に誰かがあなたの後ろに来てシステムを保守する場合）。 [K.I.S.S.原則が思い浮かびます。]

ユースケース、アップストリーム/ダウンストリームの要件などについて詳しく知らなくても、同じWork-Procedure-Procedure_histの関係で特別なテストを維持することが理にかなっているのかどうかを確認したいと思います。

作業（または手順？）が標準の場合か特殊な場合かを指定するフラグを追加できます。

モデルに影響を与える可能性のあるその他の考慮事項は、作業手順です。厳密に1対1の関係であるか、多対1 /多対多の関係が存在する可能性があります。例：

  • 単一の手順をさまざまな作業で（再）使用できますか？

  • 1つの作業を複数の手順に分割できますか？

2
markp-fuso

コンセプト

[〜＃〜] lims [〜＃〜] システムを構築しようとしているようです。

私が遊んだものには、2セットのテーブルが含まれていました。

  • 1セットのテーブルには、「実行する予定の内容」が含まれています。

  • 別のテーブルセットには、「実際に行われたこと」が含まれています。

2セットのテーブルはほとんど同じです。

このスキーマ設計により、通常のWorkの実行による変更に加えて行われた追加のProcedureをキャプチャできます。

例

Procedureのステップ3でマシンBを使用する必要があるとします。マシンBが壊れています。マネージャーがマシンAの使用を承認した後、Actual Work Doneのエントリは、マシンBではなくマシンAがステップ3に使用されたことを反映します。auditテーブルは通常、マネージャーの承認への参照とともに含まれます。

R＆Dの実行は、R＆D Procedureに属します。マネージャーの承認なしに、任意のWorkをActual Work Doneテーブルに追加できます。これらは、ユーザーにWorkの値を手動で入力させる必要があります。

システムキャリブレーションの実行は、キャリブレーション手順に属します。スタートアップの実行、「この100万ドルのおもちゃのしくみを見せびらかそう」の実行、「マシンに何かが詰まっているので、クリアされるまでブランクを実行しましょう」の実行についても同じことが言えます。

オフィシャルランはスムーズに動作します。公式実行とR＆D実行の主な違いは、次のとおりです。公式実行では、ユーザーが入力する必要のあるフォームのWorkごとに正しいパラメーターが入力されます。これにより、ユーザーは値を調整できます。 100％同一ではありませんでした。例-規定の1.000mgのNaClの代わりに1.001mgのNaClを使用しました。

結論

全体として、これはオプション1のバリエーションです。

2
Michael Kutz