1 つの認知番号が、複数の項目から構成されていることが多い。
　そういう コード 体系は、1970 年代の コード 体系である。すなわち、データ に アクセス する テクニック として、キー と レコード という技術 （レコード・アット・ア・タイム） しかなかった時代において、データ に対する アクセス を効率化するために導入されていた テクニック である。

　そういう コード 体系の典型的な例として、たとえば、品目番号が 34桁であって、最初の 2桁が 「製品・半製品」 を示す コード であったとする。そして、事業が拡大するにつれて、対象品目が 100種類を超えたとすれば、キー として固定されている 2桁──「99」 まで扱うことができるが──に対して、データ の並びを崩さないために、「A1」 という値を使わざるを得ない。だが、「A1」 という コード は、いったい、エンドユーザ にとって、どういう意味があるのか。

　認知番号は、原則として、（「桁溢れ」 しないような） 無意味な連番であるほうがよい。
　ただ、データ を使う エンドユーザ にしてみれば、認知番号の値を一目観れば、データ の中味が直ぐに判断できるほうが仕事をしやすい、と考えるのは当然である。たとえば、商品番号として、「0001」 と記述されているよりも、（シリーズ Ｔ のなかで、2003 年に製造された、オプション A を装備したことを示すために）「T03-OPA」 としたほうが、商品の中味を直ぐに判断することができる。

　したがって、今後も、複合 キー の考えかたは、根強く遺ると思われる。
　ただし、コード 体系を変更したほうが良いと判断される （いくつかの） コード について、DA （Data Analyst） は、問題点と改善案を　エンドユーザ　に提言したほうがよい。

　
● 事業の前提

　以下を前提とする。

　　（1） 商品を中継ぎする仕事 （コーディネータ） をしている。
　　（2） 営業部がある （認知番号は営業部 コード）。
　　（3） 取引先には、以下の 2つがある。
　　　　　　- 受注先 （認知番号は受注先 コード）
　　　　　　- 注文先 （認知番号は注文先 コード）
　　（4） 受注先かつ注文先はない。
　　（5） 営業部は受注先から受注して、注文先に注文する。
　　（6） 受注番号は複合 キー である。 （営業部＋年度＋連番）
　　（7） 注文番号は複合 キー である。 （営業部＋年度＋連番）
　　（8） 受注と注文の関係は 「1-対-複数」 である。
　　（9） 受注する営業部と注文する営業部は、それぞれ、相違する営業部である。

　
● データ 構造

　事業を記述する基本的な データ 構造は、以下のようになる。

　　　営業部
　　　{ 営業部 コード、営業部名称、・・・ } [ R ]

　　　受注先
　　　{ 受注先 コード、受注先名称、・・・ } [ R ]

　　　注文先
　　　{ 注文先 コード、注文先名称、・・・ } [ R ]

　　　受注
　　　{ 受注番号、受注先 コード (R)、営業部 コード (R)、受注日、受注数、・・・ } [ E ]

　　　注文
　　　{ 注文番号、注文先 コード (R)、営業部 コード (R)、受注番号(R)、注文日、注文数、・・・ } [ E ]

　
● データ 構造の検討 （その 1）

　さて、Ｔ字形 ER手法の ルール どおりに記述した （前述した） データ 構造では、以下の点が論点となる。

　　（1） 1 つの受注 データ のなかで、同じ値の営業部 コード が 2つある。
　　（2） 1 つの注文 データ のなかで、同じ値の営業部 コード が 2つある。

　そうなった原因は、受注番号および注文番号が、それぞれ、複合 キー になっていて、（複合 キー が） 営業部 コード をなかにふくんでもっているからである。
　それを正すために、まず、データ 構造を以下のように修正する。

　　　営業部
　　　{ 営業部 コード、営業部名称、・・・ } [ R ]

　　　受注先
　　　{ 受注先 コード、受注先名称、・・・ } [ R ]

　　　注文先
　　　{ 注文先 コード、注文先名称、・・・ } [ R ]

　　　営業部. 受注先. 対照表 （「受注」 を示す）
　　　{ 営業部 コード (R)、受注先 コード (R)、受注日、受注数、連番、・・・ } [ 対照表 ]

　　　営業部. 注文先. 対照表 （「注文」 を示す）
　　　{ 営業部 コード (R)、注文先 コード (R)、注文日、注文数、連番、・・・ } [ 対照表 ]

　　　営業部. 受注先. 注文先. 対照表 （「受注」 と 「注文」 の対応を示す）
　　　{ 営業部 コード (R)、受注先 コード (R)、営業部コード(R)、注文先 コード (R)、・・・ } [ 対照表 ]

　
　ただし、この構造では、受注および注文は、受注先および注文先という アカウント 制のなかで トータル として把握できるが、トランザクション 単位の対応ができない。

　
● データ 構造の検討 （その 2）

　そこで、次ぎに、（複合 キー がふくんでもっていた 「連番」 に着目して） データ 構造を、以下のように修正する。

　　　営業部
　　　{ 営業部 コード、営業部名称、・・・ } [ R ]

　　　受注先
　　　{ 受注先 コード、受注先名称、・・・ } [ R ]

　　　注文先
　　　{ 注文先 コード、注文先名称、・・・ } [ R ]

　　　受注
　　　{ 連番 （受注番号）、受注先 コード (R)、営業部 コード (R)、受注日、受注数、・・・ } [ E ]

　　　注文
　　　{ 連番 （注文番号）、注文先 コード (R)、営業部 コード (R)、連番 (R) [受注番号 (R) ]、注文日、注文数、・・・ } [ E ]

　
　以上の構造から判断できる点は、それぞれの 「連番」 が、受注番号および注文番号であればよいのであって、受注番号および注文番号を複合 キー にする意味がない、ということである。言い換えれば、複合 キー のなかにふくまれていた受注番号および注文番号は、計算の集計に使われる キー にすぎない。

　Ｔ字形 ER手法では、「まず、技術 （ルール） どおりに」 記述すれば、コード の矛盾が露呈されるしくみになっている。そして、問題点が炙りだされたなら、改善案を考えればよい。DA は、以上の検討のなかで認識した コード 体系の変更を エンドユーザ に提言すればよい。

　なお、最終的な データ 構造は、以下のように、「概念的な スーパーセット」 を記述しておけば、もっと、事業を理解しやすい記述になる。

　　　営業部
　　　{ 営業部 コード、営業部名称、・・・ } [ R ]

　　　取引先[ 概念的 スーパーセット ]
　　　　｜
　　　　×
　　　　│
　　　　├受注先 { 受注先 コード、受注先名称、・・・ } [ R ]
　　　　│
　　　　└注文先 { 注文先 コード、注文先名称、・・・ } [ R ]

　　　受注
　　　{ 連番 （受注番号）、受注先 コード (R)、営業部 コード (R)、受注日、受注数、・・・ } [ E ]

　　　注文
　　　{ 連番 （注文番号）、注文先 コード (R)、営業部 コード (R)、連番 (R) [ 受注番号 (R) ]、注文日、注文数、・・・ } [ E ]