句の理解


概説

タスク

組み込み先

Tivoli Change Management 管理

概説

句とは?

Tivoli Change Management では、ルール定義の句は次のものから構成されます。
コンポーネント 説明
テーブル ルール定義に組み込みたいフィールド (属性) を含む Tivoli Change Management データベース・テーブルの名前。
属性 ルール定義に組み込みたいデータを含むデータベース・フィールド。
演算子 ルールの選択基準を指定するために使用する<、>、=、<=、>=、および <> 演算子の 1 つ。
ルールで選択するかどうかを決定するために使用する実際のフィールド値。

たとえば、次の句は、Status_ID フィールドに完了した値が含まれているすべての CHANGE テーブル・レコードを指定します。

Change:Status_ID=completed

定義句が表示される時には、その句は、テーブル名と属性を区切るコロンを伴って現れます。「値」ボックスではコロンを使用しないでください。


タスク

句の構成 次の演算子を使用して単一の句を結合し、包括的なルール定義を作成することができます。
  • And

「And 演算子」ボタンを使って 2 つの句を連結します。アクセスされるデータは、両方の条件に一致しなければなりません。「And」ボタンは、最初の句を挿入した後、2 番目の句を挿入する前に選択します。次の例では、And 演算子を使用すると、完了状況であり、1999 年 3 月 31 日以前のイベント日付の変更が指定されます。

Change:Status_ID=completed AND Change_History:Event_Date < 03/31/99

  • Or

「Or 演算子」ボタンを使って 2 つの句を連結します。データは、いずれかの句に一致します。「Or」は、最初の句を挿入した後、2 番目の句を挿入する前に選択します。次の例では、Or 演算子を使用すると、完了状況であるか、1999 年 3 月 31 日以前のイベント日付の変更が指定されます。

Change:Status_ID=completed OR Change_History:Event_Date < 03/31/99

  • Not

「Not 演算子」ボタンは、句の True または False 状況を逆にするために、句を挿入する前に使用します。たとえば、次の句で Not 演算子を使用すると、完了状況以外のすべての変更が指定されます。

NOT Change:Status_ID=Completed

これは、次の句と同等です。

Change_Status_ID<>completed

Not 演算子は、And および Or 演算子と一緒に使用することができます。次の例では、完了状況であり、1999 年 3 月 31 日以降のイベント日付のすべての変更が指定されます。

Change:Status_ID=completed AND NOT Change:Event_Date<03/31/99

  • 括弧の使用

リスト中の句と演算子の前、後、または間に括弧を挿入するには、括弧ボタンを使用します。数学的なステートメントで括弧を使用して計算の順序をコントロールするように、ここで括弧を使用して句が解釈される順序をコントロールします。

次の例では、変更の 2 つのグループ (1999 年 3 月 31 日以前のイベント日付をもつ完了変更と 1999 年 3 月 31 日より後のイベント日付をもつ保管変更) に適用されるルールを定義するために括弧が使用されています。

(Change:Status_ID=completed AND Change_History:Event_Date<03/31/99) OR (Change:Status_ID=saved AND Change_History:Event_Date>03/31/99)

句の最適化

Tivoli Change Management は、実行時に句を評価する時に次の論理を使用します。
  1. すべての条件が And で結合されている (Or 結合がない) 場合には、最初の条件が False と評価されると、評価ルーチンはすぐに終了し、全体条件として False を戻します。条件は、左から右に評価されます。
  2. すべての条件が Or で結合されている (And 結合がない) 場合には、最初の条件が True と評価されると、評価ルーチンはすぐに終了し、全体条件として True を戻します。条件は、左から右に評価されます。
  3. 句で And および Or 条件が使用された場合には、全体的な True / False 解決を決定するために句全体が評価されなければなりません。

この評価論理を使用すると、実行時パフォーマンスに直接的な影響を及ぼすルールの句の定義を最適化することができます。すべて And で結合された複数の条件をもつ句がある場合には、評価で False となる可能性が一番高い条件を句条件の左端で定義すると、このようにしないとその後の条件を評価するために使用されることになる処理時間の節約になります。

たとえば、次のことを想定します。

  1. ルール句が Change:Status_ID が完了しているか、Change:Cost が 100 より大きいか、さらに Change:Category がソフトウェアであるかどうかを検出するように定義されています。

    この句のパフォーマンスを最適化するには、Status_ID の評価が最初に定義されます。それは、(他のすべての変更トランザクションと比較して) 相対的に少ない数の評価だけで Status_ID が完了と評価されるためです。
  1. 場所の条件によっては、残り 2 つの条件はどの順序でも定義できますが、変更コストのほとんど 100 以下であり、変更のほとんどがカテゴリー・ソフトウェアであるものと想定します。これらの前提に基づくと、最適のルール定義は次のようになります。

    Change:Status_ID = completed AND Change:Cost > 100 AND Change: Category = software
  2. しかし、ルール句が上記の条件のいずれかを検出するように定義されている場合には、条件の順序付けは逆になります。ルール句の中で True と評価される可能性が一番高い条件を最初に定義すると、早く終了できるという論理の利点を生かすことができます。

    Change:Category = software OR Change:Cost > 100 OR Change:Status_ID = completed