WebSphere 로고 z/OS용 Classic Federation Server, 버전 9.1
WebSphere 로고 z/OS용 Classic Replication Server, 버전 9.1
WebSphere 로고 z/OS용 Classic Data Event Publisher, 버전 9.1
WebSphere 로고 z/OS용 Data Integration Classic Connector, 버전 9.1


변경 캡처를 위한 CA-IDMS 경로 맵핑

변경 캡처용 테이블을 작성할 때, 서브스키마에서 시작 레코드를 선택하고 변경 캡처를 위한 최종 목표 레코드까지 세트 관계를 탐색하여 경로를 맵핑합니다.

맵핑의 세트 탐색 경로는 소유자로부터 구성원 레코드까지만이어야 합니다. 상관 서비스는 관련 정보를 수집할 때 소유자 체인까지의 탐색으로 제한됩니다.

경로의 최종 레코드에 대한 변경만 캡처됩니다. 경로의 다른 레코드에 대한 변경은 해당 레코드에 대한 변경을 캡처하기 위해 별도의 테이블을 맵핑하지 않는 한 무시됩니다. 그러나 관련 레코드의 필드가 데이터베이스 스키마의 변경된 레코드에 컨텍스트를 제공할 때 관련 레코드 맵핑이 필요합니다. 예를 들어, CA-IDMS 스키마에 세트별로 직원 레코드와 관련되는 급여 레코드가 있는 경우, 특정 직원에 대한 SALARY 레코드의 인스턴스를 추가하려면 EMPLOYEE 레코드의 직원 ID가 분산 서비스에 의해 보내지는 메시지에 포함되어야 합니다.

최종 레코드 이외의 레코드에 있는 변경 데이터는 갱신하는 트랜잭션 밖에서 수집됩니다. 이 정보 수집의 대기 시간은 변경 캡처 에이전트가 상관 서비스에 변경을 보내는데 걸리는 시간과 변경을 패키지하고 변경을 분산 서비스로 포워드하는 데 필요한 시간을 합한 값입니다. 관련 변경 데이터 자체가 트랜잭션 및 정보가 분산 서비스로 포워드된 시간 사이에 갱신 또는 삭제되었을 수 있습니다. 따라서 변경되지 않을 관련 레코드에 식별 필드(예: 기본 또는 외부 키)만 맵핑하십시오.

갱신 트랜잭션이 발생하는 시간과 변경이 분산 서비스로 포워드되는 시간 사이에 관련 레코드가 삭제되는 경우, 정보가 사용 불가능함을 표시하기 위해 관련 필드가 SQL NULL로서 분산 서비스로 전달됩니다.

레코드 삭제 시 관련 데이터 정보를 수집하기 위해 응용프로그램 스키마를 수정해야 할 수도 있습니다. 일부 경우에는 CA-IDMS가 레코드 접두부에 소유자 포인터를 보존하지 않으며, 따라서 레코드가 삭제되는 경우 소유자 정보가 사용 불가능합니다. 이러한 경우에 변경 캡처는 지원되지 않습니다.

삭제 목적을 위해 소유자 정보가 필요한 경우 경로에 있는 하나 이상의 세트 정의를 변경하여 소유자 포인터가 레코드 접두부 정보에 유지보수되도록 LINKED TO OWNER문을 포함시켜야 합니다. 스키마 갱신에 대한 자세한 정보는 CA/CA-IDMS 참조 매뉴얼을 참조하십시오.

일부 경우에는 스키마에서 서로 다른 경로를 사용하여 다중 레코드 소유자에서 정보를 수집해야 할 수 있습니다. 변경 캡처가 스키마의 단일 경로에 대해서만 지원되는 경우 다중 경로에서 식별 필드 수집이 단일 테이블 맵핑에서 가능하지 않습니다. 그러나, 분산 서비스로 보내지는 변경 메시지가 데이터베이스의 단일 작업 단위(UOW)를 기초로 하는 경우 변경 캡처를 위해 복수 테이블을 정의할 수 있습니다.

예를 들어, CA-IDMS 직원 데모 스키마에서 직원 레코드에 대한 변경 캡처를 수행하려 하지만 직원이 변경될 때 직원과 연관되는 사무실 코드 및 부서 ID가 둘 다 필요하다고 가정하십시오. 직원이 변경될 때 부서 ID와 사무실 ID를 둘 다 수집하기 위해 경로 DEPARTMENT->EMPLOYEE를 하나의 테이블로, OFFICE->EMPLOYEE를 두 번째 테이블로 맵핑할 수 있습니다. 변경 데이터를 수신하는 응용프로그램은 맵핑된 두 테이블 모두의 정보를 직원 레코드에 대한 변경으로 결합하고 자동으로 두 테이블 맵핑 모두에 대한 변경 메시지를 트리거할 수 있습니다.



피드백

갱신 아이콘 최종 갱신: 2007-07-11