레코드 유형은 특정 변경 요청 유형에 대한 형식입니다. 관계형 데이터베이스의 테이블과 매우 유사합니다. 각 레코드 유형은 특정 변경 요청 유형에 대해 수집할 수 있는 데이터를 정의합니다. 개별 변경 요청에 대한 정보는 레코드에 호출되고 변경 요청에 대한 개별 단위의 데이터는 필드에 호출됩니다.
각 레코드 유형은 해당 변경 요청 유형의 데이터 보기와 콜렉션을 공동으로 제어하는 고유한 상태 모델, 양식 및 후크와 연관됩니다.
버전 7.0 데이터베이스는 레코드를 추가로 저장할 수 있습니다. Rational® ClearQuest 클라이언트는 이전 한계보다 큰 데이터베이스 ID(DBID)가 있는 레코드를 표시할 수 없습니다. 자세한 정보는 레코드에 대한 작업을 참조하십시오.
Rational ClearQuest 클라이언트의 버전 확인에 대한 자세한 정보는 Rational ClearQuestAPI 참조 페이지에서 클라이언트 버전 확인을 참조하십시오.
두 레코드 유형 지원: State-based 및 Stateless
State-based 레코드 유형은 일련의 상태(예제: Submitted, Assigned 및 Resolved)를 통해 사용자 조치의 결과로 이동됩니다.
Stateless 레코드 유형에는 데이터가 포함되어 있지만 상태를 변경시키지 않습니다. 예제에는 사용자, 프로젝트 및 고객의 레코드 유형이 포함되어 있습니다. Stateless 레코드 유형에는 제출, 수정, 삭제 및 가져오기 조치만 수행할 수 있습니다.
State-based 레코드는 하나 이상의 Stateless 레코드를 참조할 수 있습니다. 예를 들어, 사용자가 결함(State-based 레코드 유형)을 프로젝트(Stateless 레코드 유형)에 할당 할 수 있습니다.
Stateless 레코드 유형을 스키마에 추가하는 경우 하나 이상의 필드를 고유 키로 설정해야 합니다. Rational ClearQuest 소프트웨어는 이 키를 사용하여 이 유형의 개별 레코드를 식별합니다.
Rational ClearQuest 소프트웨어는 네 가지의 Stateless 시스템 레코드 유형(History, Attachments, Groups 및 Users)을 유지보수합니다. 시스템 레코드 유형은 삭제할 수 없습니다.
특정 레코드 유형을 작성한 다음 이를 다른 유형으로 변경할 수 없습니다. 즉, Stateless 레코드 유형을 State-based 레코드 유형으로 변경하거나 그 반대로 변경할 수 없습니다.
레코드 유형에는 레코드를 검색하는 데 사용할 수 있는 데이터베이스 ID 및 표시 이름이 있습니다.
표시이름은 일종의 (State-based 또는 Stateless) 레코드 내에서 고유합니다.
ClearQuest 레코드의 데이터베이스 ID(DBID)는 레코드의 내부 ID입니다. DBID는 사용자 데이터베이스의 각 레코드에 순서대로 지정된 고유한 숫자입니다. 자세한 정보는 레코드에 대한 작업을 참조하십시오.
ClearQuest API를 사용한 "레코드 찾기" 유틸리티 구현에 대한 정보는 Rational ClearQuest API 참조 페이지에서 GetEntityDefOfDbId 또는 GetEntityDefofName 메소드를 참조하십시오.
하나의 스키마에 여러 레코드 유형이 포함될 수 있습니다. 예를 들어, 스키마에서 Software Enhancements 및 Hardware Enhancements에 대한 별도 레코드 유형을 사용할 수 있습니다. 또는 Issues, Problem Reports, Change Request, Defects 및 Enhancements Requests에 대한 다양한 레코드 유형이 포함될 수 있습니다.
변경 요구 유형에 서로 다른 프로세스 모델이 있거나 서로 다른 데이터를 추적하는 경우 독립 레코드 유형을 작성하십시오. 예를 들어, 조직에서 소프트웨어 개선사항 및 하드웨어 개선사항에 대해 다른 프로세스 모델을 사용하면 각각에 해당하는 레코드 유형을 작성하십시오. 또는 소프트웨어 및 하드웨어 개선사항의 프로세스 모델이 같으면 개선사항 유형을 지정하는 필드가 있는 Enhancements 레코드를 작성하십시오.
작성할 레코드 유형을 주의 깊게 고려하십시오. 레코드 유형이 많아질수록 프로세스 모델에 더 많은 변형을 캡처하게 됩니다. 따라서 관리하기가 복잡해지고 다수의 변경 요청이 포함된 조회 및 보고서를 빌드하기도 어려워집니다. 또한 향후의 요구에 대비해야 합니다. 즉, 두 가지 변경 요청 유형의 프로세스 모델이 동일하지만 모델 변경을 예상할 수 있는 경우 나중에 레코드 유형을 분할하는 것보다 처음부터 두 가지 레코드 유형을 작성하는 것이 바람직합니다.
또한 관계형 데이터베이스 디자인 시 발생하는 동일한 문제도 고려해야 합니다. 이러한 문제와 관련하여 데이터베이스 관리자에게 문의할 수도 있습니다. 결함 레코드 유형에 제출자, 제출자의 이메일 주소, 제출자의 전화번호를 포함하는 대신 사용자의 모든 정보가 포함된 제출자 레코드 유형을 작성할 수 있습니다. 이와 같이 접근하면 결함을 제출할 때마다 사용자 이름만 입력하면 됩니다. 그런 다음, REFERENCE 필드를 사용하여 결함 레코드 유형과 Submitter 레코드 유형 간의 링크를 작성하여 양식 및 보고서에 제출자의 이메일 주소와 전화번호를 포함할 수 있습니다. 레코드를 링크하여 상위/하위 계층 구조 작성을 참조하십시오.
각 스키마에는 기본 레코드 유형이 필요합니다. 기본 레코드 유형은 State-based 또는 Stateless입니다. 기본 레코드 유형은 해당 유형의 레코드를 제출하기 위해 Rational ClearQuest 클라이언트에 바로 가기 단추를 작성하는 데 사용됩니다. 기본 레코드 유형은 다른 레코드 유형이 지정되지 않은 경우에 사용됩니다.