レコード タイプは、 特定タイプの変更依頼のフォーマットです。リレーショナル データベースのテーブルと大筋では似ています。 各レコード タイプは、1 つのタイプの変更依頼を収集できるデータを定義します。 個々の変更依頼に関する情報をレコード、変更依頼に関するデータの個々の部分をフィールドと呼びます。
各レコード タイプは専用の状態モデル、フォーム、フックに関連付けられており、 それらが総合的にそのタイプの変更依頼で使用するデータの収集と表示を制御します。
バージョン 7.0 のデータベースでは、より多くのレコードを保管できるようになりました。ただし、 それ以前のバージョンの Rational® ClearQuest® クライアントでは、 前の限度より上のデータベース識別子 (DBID) を持つレコードを表示できません。詳細については、「レコードの操作」を参照してください。
Rational ClearQuest クライアントのバージョンを確認する方法の詳細については、 『Rational ClearQuest API リファレンス』の「クライアント バージョン の確認」を参照してください。
状態ありと状態なしの 2 つの タイプのレコード タイプがサポートされます。
状態ありレコード タイプは、 ユーザー アクションの結果として一連のステータスまたは状態 (Submitted、Assigned、Resolved など) の中で 状態が遷移するレコード タイプです。
状態なしレコード タイプは、データを保持しますが、状態は変化しないレコード タイプです。例として、User、Project、Customer などがあります。状態なしレコード タイプに 実行できるアクションは Submit、Modify、Delete、Import のみです。
状態ありレコードは 1 つ以上の状態なしレコードを参照できます。 たとえば、ユーザーは Defect (状態ありレコード タイプ) を Project (状態なしレコード タイプ) に 割り当てることができます。
状態なしレコード タイプをスキーマに追加する場合は、1 つ以上のフィールドを 一意のキーとして設定する必要があります。Rational ClearQuest ソフトウェアは、 このキーを使用して個々の変更依頼を追跡します。
Rational ClearQuest ソフトウェアは、 History、Attachments、Groups、Users の 4 つの状態なしシステム レコード タイプを 保守します。システム レコード タイプは、削除できません。
特定のレコード タイプを作成した後で、それをほかのタイプに 変更することはできません。すなわち、状態なしレコード タイプを状態ありレコード タイプに変更することはできず、 その逆もできません。
レコード タイプには、 それぞれの表示名とデータベース ID があり、それらを使用してレコードを取得できます。
表示名は、レコードの種類 (状態あり または状態なし) が同じものの中で一意です。
ClearQuest レコードのデータベース ID (DBID) は、 レコードの内部 ID です。DBID は、ユーザー データベース内の各レコードに 順に割り当てられる固有の数値です。詳細については、「レコードの操作」を参照してください。
ClearQuest API を使用する「レコードの検索」ユーティリティの実装については、Rational ClearQuest API リファレンスの「GetEntityDefOfDbId」メソッドまたは「GetEntityDefofName」メソッドを参照してください。
スキーマには複数のレコード タイプを格納することができます。 たとえば、1 つのスキーマで Software Enhancements 用と Hardware Enhancements 用に別個のレコード タイプを使用できます。 また、Issues、Problem Reports、Change Requests、Defects、Enhancement Requests 用に 異なるレコード タイプを設定することもできます。
変更依頼のタイプごとに異なるプロセス モデルがある場合、 または異なるデータを追跡する場合は、別個のレコード タイプを作成してください。 たとえば、組織がソフトウェア拡張とハードウェア拡張とで異なるプロセス モデルを使用する場合、 それぞれのレコード タイプを作成してください。 一方、ソフトウェア拡張とハードウェア拡張とで使用するプロセス モデルが同じ場合、 拡張の種類を指定するフィールドがある Enhancements レコード タイプを 1 つ作成してください。
どのレコード タイプを作成するかは慎重に検討してください。 レコード タイプの数を増やすことで、プロセス モデルの種類も豊富にすることができますが、 反面、管理が複雑になり、多数の変更依頼を受け容れるクエリーやレポートの作成が 難しくなります。また、先のことを考えた計画も必要です。2 つのタイプの変更依頼が、 現在は同じプロセス モデルを使用できても、将来的にモデルが変更されることが予想される場合、 後で分割するより、最初から 2 つのレコード タイプを作成しておくほうが簡単です。
同様に、リレーショナル データベースを設計するときに発生する同じような 問題についても考慮してください (または、こうした問題に詳しいデータベース管理者の支援を 受けてください)。たとえば、Defects レコード タイプに、登録者、登録者の電子メール アドレス、登録者の電話番号を 組み込むのではなく、Defects レコード タイプには登録者のみを組み込み、Submitters レコード タイプを 追加で作成するようにします。この方法だと、ユーザーは障害を登録するとき、 ユーザー名を入力するだけで済みます。 その後は、REFERENCE フィールドを使用して、Defect と Submitter のレコード タイプ間にリンクを作成し、 登録者の電子メール アドレスと電話番号をフォームとレポートに組み込むことができます。 「レコードのリンクによる親/子階層の作成」を参照してください。