레코드 유형은 특정 변경 요청 유형에 대한 형식입니다. 이 유형은 관계형 데이터베이스의 테이블과 대략 유사합니다. 각 레코드 유형은 특정 변경 요청 유형에 대해 수집할 수 있는 데이터를 정의합니다. 개별 변경 요청에 대한 정보는 레코드에 호출되고 변경 요청에 대한 개별 단위의 데이터는 필드에 호출됩니다.
각 레코드 유형은 해당 변경 요청 유형의 데이터 보기와 콜렉션을 공동으로 제어하는 고유한 상태 모델, 양식 및 후크와 연관됩니다.
버전 7.0 데이터베이스는 레코드를 추가로 저장할 수 있습니다. Rational® ClearQuest® 클라이언트는 이전 한계보다 큰 데이터베이스 ID(DBID)가 있는 레코드를 표시할 수 없습니다. 자세한 정보는 레코드에 대한 작업을 참조하십시오.
Rational ClearQuest 클라이언트의 버전 확인에 대한 자세한 정보는 Rational ClearQuestAPI 참조 페이지에서 클라이언트 버전 확인을 참조하십시오.
두 레코드 유형 지원: State-based 및 Stateless
State-based 레코드 유형은 일련의 상태(예제: Submitted, Assigned 및 Resolved)를 통해 사용자 조치의 결과로 이동됩니다.
Stateless 레코드 유형에는 데이터가 포함되어 있지만 상태를 변경시키지 않습니다. 예제에는 사용자, 프로젝트 및 고객의 레코드 유형이 포함되어 있습니다. Stateless 레코드 유형에서 수행할 수 있는 조치는 Submit, Modify, Delete 및 Import 조치뿐입니다.
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에 대한 별도 레코드 유형을 사용할 수 있습니다. 또는 Issue, Problem Reports, Change Request, Defects 및 Enhancements Requests에 대한 다양한 레코드 유형이 포함될 수 있습니다.
변경 요구 유형에 서로 다른 프로세스 모델이 있거나 서로 다른 데이터를 추적하는 경우 독립 레코드 유형을 작성하십시오. 예를 들어 조직에서 소프트웨어 개선사항 및 하드웨어 개선사항에 대해 다른 프로세스 모델을 사용하면 각각에 해당하는 레코드 유형을 작성하십시오. 또는 소프트웨어 및 하드웨어 개선사항의 프로세스 모델이 같으면 개선사항 유형을 지정하는 필드가 있는 Enhancements 레코드를 작성하십시오.
작성할 레코드 유형을 주의 깊게 고려하십시오. 레코드 유형이 많아질수록 프로세스 모델에 더 많은 변형을 캡처하게 됩니다. 따라서 관리하기가 복잡해지고 다수의 변경 요청이 포함된 조회 및 보고서를 빌드하기도 어려워집니다. 또한 향후의 요구에 대비해야 합니다. 즉, 두 가지 변경 요청 유형의 프로세스 모델이 동일하지만 모델 변경을 예상할 수 있는 경우 나중에 레코드 유형을 분할하는 것보다 처음부터 두 가지 레코드 유형을 작성하는 것이 바람직합니다.
또한 관계형 데이터베이스 디자인 시 발생하는 동일한 문제도 고려해야 합니다. 이 때 이러한 문제에 대해 잘 알고 있는 데이터베이스 관리자의 도움을 얻을 수 있습니다. 예를 들어, 결함 레코드 유형에 submitter's e-mail address 및 submitter's phone number를 포함하는 대신 결함 레코드 유형에는 submitter만 포함하여 Submitters 레코드 유형을 작성할 수 있습니다. 이와 같이 접근하면 결함을 제출할 때마다 사용자 이름만 입력하면 됩니다. 그런 다음, REFERENCE 필드를 사용하여 결함 레코드 유형과 Submitter 레코드 유형 간의 링크를 작성하여 양식 및 보고서에 제출자의 전자 우편 주소와 전화번호를 포함할 수 있습니다. 레코드를 링크하여 상위/하위 계층 구조 작성을 참조하십시오.