절의 이해


개요

태스크

관련 응용프로그램

Tivoli Change Management 관리

개요

절이란?

Tivoli Change Management에서, 규칙 정의 절은 다음으로 구성됩니다.
구성요소 설명
테이블 규칙 정의에 포함할 필드(속성)를 포함하는 Tivoli Change Management 데이터베이스 테이블명.
속성 규칙 정의에 포함할 데이터를 포함하는 데이터베이스 필드.
연산자 규칙에 대해 선택 기준을 지정하기 위해 사용하는 <, >, =, <=, >=, <> 연산자 중 하나.
규칙에서 선택사항을 판별하기 위해 사용하는 실제 필드 값.

예를 들어, 다음 절은 Status_ID 필드가 완료된 값을 포함하는 모든 CHANGE 테이블 지정합니다.

Change:Status_ID=completed

정의 절이 표시될 때, 테이블명과 속성을 구분하는 콜론과 함께 표시됩니다. 값 상자에서 콜론은 사용하지 마십시오.


태스크

절 구성 다음 연산자를 사용하여 단일 절을 결합하고 복잡한 룰 절 정의를 작성할 수 있습니다.
  • And

두 개의 절을 함께 링크하려면 And 연산자 단추를 사용하십시오. 액세스된 데이터는 두 조건을 만족시켜야 합니다. 첫번째 페이지를 삽입하고 두 번째 절을 삽입하기 전에 And 단추를 선택하십시오. 다음 예제에서, And 연산자의 사용은 완료된 상태이고 이벤트 날짜가 1999년 3월 31일 이전인 변경사항을 지정합니다.

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

  • Or

두 개의 절을 함께 링크하려면 Or 연산자 단추를 사용하십시오. 데이터는 두 절 중 하나를 만족시킬 수 있습니다. 첫번째 절을 삽입하고 나서 두 번째 절을 삽입하기 전에 Or 단추를 선택하십시오. 다음 예제에서, Or 연산자의 사용은 완료된 상태이거나 이벤트 날짜가 1999년 3월 31일 이전인 변경사항을 지정합니다.

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

  • Not

절의 참 또는 거짓 상태를 역으로 하려면 절 앞에 Not 연산자를 사용하십시오. 예를 들어, 다음 절에서 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

  • 괄호 사용

목록에서 절 이전에, 이후에, 또는 연산자와의 사이에 괄호를 삽입하려면 괄호 단추를 사용하십시오. 계산 순서를 제어하기 위해 수학적 명령문에 괄호를 사용하는 것처럼, 여기에서 괄호를 사용하여 절이 해석되는 순서를 제어합니다.

다음 예제에서, 괄호는 두 개의 변경 그룹(이벤트 날짜가 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. 사용자 위치에서의 조건에 따라, 나머지 두 조건은 어느 순서로든지 정의될 수 있지만, 대다수의 변경 비용이 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