Page History
トリガーの考え方
「トリガー」は、フィールド単位またはテーブル単位で、リポジトリに定義します。ある条件下で、データベースに対してある操作を施すと、所定のファンクションが実行される、という機構です。ファンクションが自動的に起動される点が、「トリガー」ならではの特徴です。
[ 
|../../index.htm#lansa/l4wdev04_0170.htm]
現在地:
...
トリガーの考え方
「トリガー」は、フィールド単位またはテーブル単位で、リポジトリに定義します。ある条件下で、データベースに対してある操作を施すと、所定のファンクションが実行される、という機構です。ファンクションが自動的に起動される点が、「トリガー」ならではの特徴です。
例えばある在庫管理システムで、DELETE FROM_FILE(ORDHDR) WITH_KEY(#ORDNUM)というRDMLコマンドにより「注文の取り消し」処理を行うと、所定の「イベント」が発生し、その結果自動的にあるファンクションに「トリガー」がかかります。
注文が取り消されると、具体的には次のような処理が走ることになるでしょう。
処理A | 注文明細の履歴欄に「取り消された」旨の印をつける |
|---|---|
処理B | 貸付残高伝票を印刷する |
処理C | 販売部門に通知する |
このように、トリガー・ファンクションには、業務処理とデータベース・テーブルを直接関連づける働きがあります。所定のイベントが発生すると、自動的にトリガーがかかります。
妥当性の検証と同様、業務ロジックを集中管理するため、LANSAではリポジトリ側でトリガーを管理するようになっています。似たような処理を業務プログラムのあちこちに何度も記述する必要なく、データベース操作を行うアプリケーションすべてに適用されます。
適切に使えば、アプリケーション設計の方法が一変するかも知れません。まずユーザー・インターフェースを設計し、業務処理本体は、妥当性規則やトリガー・ファンクションの形で後から組み込む、という手順も可能になるのです。その結果、より「オブジェクト指向」の考え方に沿った設計になるでしょう。業務処理本体とユーザー・インターフェースを明確に分割する働きが、トリガーにはあるからです。
次のトピックも参照してください。 『LANSA テクニカル リファレンスガイド』の「トリガーの定義
『LANSA テクニカル リファレンスガイド』の「トリガーの定義 」
...
『LANSA テクニカル リファレンスガイド』の「処理条件 」
『LANSA/AD ユーザーガイド』の「トリガー・ファンクション」
...