（1） 「情報 （画面、帳票など）」 のなかに明示されている リレーションシップ を記述する。
　　　　（「リレーションシップ の検証表」 のなかに、○ を使って記述する。）

　　（2） ○ の付与されなかった--すなわち、明示されていない──リレーションシップ を検討する。

　　　（2）-1　それらの リレーションシップ は、現実に成立しているのかどうか。

　　　（2）-2　現実に成立していないなら、認知したほうが良いのかどうか。

　
　「明示されている リレーションシップ」 とは、「情報 （画面、帳票など）」 のなかに記述されている認知番号 （××番号、×× コード） を ○ で囲んで──すなわち、entity を示す認知番号を ○ で囲んで──、認知番号を、順次 （上から下へ、左から右へ）、辿ることを云う。たとえば、上述した例では、「顧客番号 → 受注番号 → 品目 コード」 の経路が リレーションシップ を明示的に示している。すなわち、以下の 2つの リレーションシップ が成立している。

　　（1） 顧客と受注。
　　（2） 受注と品目。

　「リレーションシップ の検証表」 は、縦列ごとに検討する。
　たとえば、上述した例では、以下の 3つの縦列を検討することになる。なお、文中、○ が付与されているのは、明示的な リレーションシップ を示している。

　　（1） 顧客 → 顧客、受注 （○）、品目。
　　（2） 受注 → 受注、品目 （○）。
　　（3） 品目 → 品目。

　次に、リレーションシップ の網羅性を検討する。
　すなわち、「情報」 のなかで明示されていない以下の リレーションシップ を検討する。

　　（1） 顧客と顧客の再帰は可能か。
　　（2） 顧客と品目の関係は可能か。
　　（3） 受注と受注の再帰は可能か。
　　（4） 品目と品目の再帰は可能か。

　たとえば、「顧客」 が、もし、法人 （企業組織体） であれば、「顧客と顧客の再帰」 として、本社・支店という構成があるのかどうか、あるいは、「品目」 に対して、「品目と品目の再帰」 として、もし、受注された品目が品切れであれば、代替品目の構成があるのかどうかという点を エンドユーザ に確認すれば良い。

　ちなみに、「リレーションシップ の検証表」 を 「情報 （画面、帳票など）」 ごとに作る理由は、「文脈」 のなかで、リレーションシップ を検討すれば、「意味」 を把握しやすいからである。
　「リレーションシップ の検証表」 の具体的な作成法については、以下の書物を参照されたい。

　　　拙著 「データベース 設計論──Ｔ字形 ER」 （118 ページ）。