Entity は、{ 主題, 条件₁,・・・. 条件_n } として記述されます。
　「主題」 相互間の制約・束縛は 「対照表」 として TMD に現れますが、「条件」 相互間の制約・束縛は TMD 上の現れません── 「主題」 相互間の関係を網羅的に検証するのが 「『関係』 の検証表」 で、「条件」 相互間の制約・束縛を網羅的に検証するのが 「アトリビュート・リスト」 です。

　モデル は、次の 2つの要件を満たしていなければならない。

　　（1） 妥当な構造

　　（2） 真とされる値

　「妥当な構造」 は、「論理」 に従って作図された無矛盾な構造です。その 「論理」 として、「関係」 文法が用意されています。そして、その 「関係」 を網羅的に検証するのが 「『関係』 の検証表」 です──以前は、「リレーションシップ の検証表」 と云っていたのですが、（「関係」 は 「関数」 として記述されるので、） リレーションシップ という言いかたを止めました （関数として記述される 「関係」 は リレーション と云います）。この 「関係」 は、「主題」 相互間の関係です。したがって、「妥当な構造」 は、「関係」 が網羅されていないければならないでしょう。

　いっぽうで、「条件」 相互間の制約・束縛が存します。たとえば、{ 受注番号,・・・, 受注日, 受注数 } と { 契約番号,・・・, 契約日, 契約数 } において、受注数 ＜ 契約数 もしくは 受注数 ＞ 契約数 などの事態が起こるかどうかの検証をしなければならないでしょう──前者の場合には、複数の受注を 1つの契約で扱うのか [ したがって、リレーション の対応が 「複数-対-１」 になって、対応表を生成するのかを確認しなければならない ]、後者の場合は、「受注残」 をいかにして扱うか [ 同一の契約番号とするのか、違う契約番号であれば、「契約」 の再帰表を生成するのか ] を確認しなければならないでしょう。あるいは、受注数および契約数に下限・上限を設けているかどうかも確認しなければならないし、受注日 ≦ 契約日 も確認しなければならないでしょう。この様な 「条件」 相互間の検証をおこなうのが 「アトリビュート・リスト」 です。「アトリビュート・リスト」 は、「真とされる値」 を実現するための制約・束縛を検証する リスト です。「アトリビュート・リスト」 には、その他にも、データ の属性 [ 英文字か数値、桁数、数値なら小数点の有無・± の有無など ]、lock の定義、計算式などを定義します。「アトリビュート・リスト」 は、「妥当な構造 （TMD）」 ができた後に作成します。時に、「アトリビュート・リスト」 を作成していて （「条件」 の制約・束縛を確認していて）、TMD が修正される事も起こります。