「繰返項目」 （Ｔ字形 ER手法では、「データ の多義」 と呼んでいるが） では、「並び」 を示すために 「種別 コード」 を用意しなければならない（89 ページを参照されたい）。

　応用問題として、以下の例 （状態遷移と繰返項目） を考えてみる。

[ 前提 ]
　（1） 受注の 「引合」 を管理している （認知番号は 「引合番号」 である）。
　（2） 受注引合の際に、競合した企業の名称を管理している。競合他社は複数を入力できる。

　引合　｛引合番号、引合日、・・・、 競合他社名称 （1）、 競合他社名称 （2）、・・・｝

　標準形 （正規形） は以下になる。

　引合　｛引合番号、DATE、・・・｝ [ E ]
　引合. 競合他社 ｛引合番号(R)、競合他社名称｝ [ Entity.Role ]

　競合他社は、名称を五十音順に管理してもいいが、「並び」 を実現するために、「競合度合 （競合順序）」 を定義したとする。

　引合　｛引合番号、DATE、・・・｝ [ E ]
　引合. 競合他社 ｛引合番号(R)、競合他社名称、競合順序｝ [ Entity.Role ]

　さて、引合のなかに、「状態遷移」 （初回引合、入札中、稟議中、受注確定など） を管理する区分 コード が用意されていたとする。したがって、「引合」 の アトリビュート の 「DATE」 は、状態遷移のつど、「初回引合日」 とか 「入札日」 とか 「稟議日」 とかが記入されることになる。

　
　競合他社情報を、状態遷移のつど、見直して、競合履歴も記録するとすれば、「Entity.Role」 は、それぞれの サブセット に対して生成されるが、実際の データ として使うときには、「引合番号(R)、競合他社名称、競合順序」 という形では、どの状態遷移のときの競合状態なのかという点がわからない。
　とすれば、状態遷移の区分 コード を 「（D）」 として使うか、、、エレガント ではないわなあ（笑）。

　引合　｛引合番号、DATE、引合状態区分 コード、・・・｝ [ E ]
　引合. 競合他社 ｛引合番号(R)、競合他社名称、競合順序、引合状態区分 コード (D) ｝ [ Entity.Role ]

　そうすれば、「引合番号 (R)、引合状態区分 コード (D)、競合他社名称、競合順序｝ の 「INDEX-only」 を使うことができる。

　競合他社情報を見直すのであれば、「競合見直し日」 を使うのが正論だと思う。

　状態遷移のつど、競合他社情報を見直すのであれば、たまたま、状態遷移した 「DATE」 と 「競合見直し日」 が同じになるが、烈しい競争のなかで、競合他社情報を更新するのであれば、1つの状態遷移のなかでも、競合他社情報を、複数回、見直するようにしておいてもいいのではないでしょうか。

　引合　｛引合番号、DATE、引合状態区分 コード、・・・｝ [ E ]
　引合. 競合他社 ｛引合番号(R)、競合他社名称、競合順序、競合見直し日｝ [ Entity.Role ]

　たとえば、初回引合日から次の状態遷移である稟議日までの間に、競合他社情報を、2回、見直したとすれば、 稟議のときの競合他社情報は、稟議日と同じか内輪で近い日の 「競合見直し日」 を記入された 「Entity. Role」 が状態遷移した 「引合」 に対応する競合情報になる。