Page History
...
| Code Block |
|---|
SALARY NEP SALARY すなわち、 SALARYが以前のSALARYと等しくない すなわち、 SALARYが以前のSALARYと等しくない |
これにより、トリガーは、従業員のSALARYが変更された場合のみ、「UPDATE前」にアクティブ化されます。
...
SALARYが変更されるか、従業員が勤務するCOMPANYが変更されたときに、WEEKPAYを再計算する必要がある場合は、代わりに以下のような呼び出しイベントを定義します。
| Code Block |
|---|
SALARY NEP SALARY OR COMPANY NEP COMPANY すなわち、 SALARYが以前のSALARYと等しくない または COMPANYが以前のCOMPANYと等しくない SALARY NEP SALARY OR COMPANY NEP COMPANY すなわち、 SALARYが以前のSALARYと等しくない または COMPANYが以前のCOMPANYと等しくない |
WEEKPAYを必ず再計算する場合は、2つの呼び出しイベントを別々に定義する必要はありません。単純に1つのイベント(条件なし)を定義し、「INSERT前」および「UPDATE前」にトリガーを呼び出すよう指定します。
...
この例には、優れたトリガーの設計と使用のために重要になる要素がいくつか示されています。
- 「カプセル化」原理。WEEKPAYを計算するための「具体的な処理」が、1つのファンクションに「カプセル化」されています。そのため、必要な変更を1箇所で行えます。「カプセル化」原理。WEEKPAYを計算するための「具体的な処理」が、1つのファンクションに「カプセル化」されています。そのため、必要な変更を1箇所で行えます。
- 必要が生じてからの設計。システム設計の初期段階では、WEEKPAYの具体的な処理の存在を定義する必要はありません。また、具体的な処理を想定して全体の設計を進める必要もありません。 逆に言うと、設計工程のどの時点でも、必要になった時点で具体的な中身を決めてよい、ということです。例えば、従業員を作成したり更新したりするアプリケーションが決まっていない段階で、WEEKPAYの具体的な処理を定義する必要はありません。まず、作成/更新アプリケーションを定義し、検査することができます。WEEKPAYの具体的な処理を作成、定義した時点から、既存のアプリケーションの処理に反映されるようになります。
- 再利用可能性。WEEKPAYを計算する具体的な処理は、従業員の詳細を作成または変更するアプリケーションによって自動的かつ暗黙的に再利用されます。トリガーは、通常のNPTデバイスから「従業員データ保守」ファンクションを通して、またはPCアプリケーションからLANSA Open機能を通してアクティブ化される可能性があります。
- 情報隠蔽。WEEKPAYというロジックが存在し、使用されているという事実は、「従業員データ保守」ファンクションを作成するRDMLビルダーからは見えません。また、RDMLビルダーにとっては意味がないものでしょう。
- 「具体的な処理」と「イベント」の分離。トリガー・ファンクションでは、「イベント」が発生したときに何を行うか(すなわち「具体的な処理」)を定義します。
ただし、イベントの発生を検出する必要はありません。
例えば、前に定義したファンクションでは、「週給の計算」という「具体的な処理」を定義しています。
業務上の規則では、新しい従業員が採用された場合、既存の従業員の給与が変更された場合、または既存の従業員が転職した場合に、週給を(再)計算しなければならないことを規定しています。
実際の「イベント」は、LANSAデータ・ディクショナリで定義します。