「コード体系」という言葉を拡大解釈すれば、コード体系のない業務をT字形風に書き下すことができる

T字形ER手法では、現場のコード体系に従って、解析の基点となる entity を生成する。
商品コードがあるから、商品というresourceを作るとか。
受注番号があるから、受注というeventを作るとか。
これが、基点となるentityを見出す唯一のルールだったら

現場にコード体系なんてものが無いとき、entityを認知できなくなってしまう

ということが問題になる。
この問題に対する正美氏の回答は、いろいろな記述を総合すると

現状分析なら、みなしentityを使って現実をそのまま記述する
あるべき姿の実装であれば、コード設計のプロがコード体系を設計しつつER図を作成する

ということだと思う。

前者については、みなしentityの導出すらできないほどにコードがまったくない、という場合にやっぱり作図に困るのだが、コード体系を文字通りの意味ととらえず、「現場で認知されている個体識別の手段の体系」なのだと拡大解釈すれば、コードらしきものが見当たらない業務をT字形*風*に書き下すことができる。

resource的なものにコードがない時、名前がコードの役割を果たしている

コード体系がなくても業務が回っているということは、コードがなくても各種resourceの個体識別に支障がないことを示している。
例えば、倉庫が「小樽倉庫」「札幌倉庫」の２個しかない会社で、倉庫コードなんてものを制定せずに、名前で倉庫を識別しているとか。
コードとは「現場で認知されている個体識別の手段」と考えれば、ここでは倉庫名がコードの役割を果たしているといえる。

event的なものにコードがない時、compositeがコードの役割を果たしている

注文番号というものがないECサイトでは、顧客名＋メールアドレス＋注文日付などで注文を特定して、個別の注文への問い合わせに対応しているはずだ。
コードとは「現場で認知されている個体識別の手段」と考えれば、顧客名・メールアドレス・注文日付のcompositeが注文のコードである、といえる。

個体識別されていない情報には、コードを想定できない

identifierに対して多値従属する情報は、業務上レコードを特定する必要がない場合がある。
例えばここで書いた社員メールアドレステーブルなど。
このような情報には拡大解釈したコードを想定することができない。なぜなら、現場で認知されている「個体の識別の仕方」が存在しないから。

だからどうした

T字形ER手法で作図したデータ構造にIDを導入して実装する場合、どの器(=テーブル)に対してIDを振るかを決めなくてはならない。
選択肢は

全ての器にIDを振る
拡大解釈した「コード体系」のコードに対してIDを振る

があり、私は2.の立場を取っている。理由はIDの取り扱い方に不明点がないから。
1.のやり方にするのであれば、delete＆insertしたい情報につけたIDの取り扱い方を考えなくてはならない。それについては別エントリで。