Ｔ字形 ER手法のことをいえば、僕は、SDLC （System Development Life Cycle） のなかに生じている--「分析」 と 「設計」 のあいだに生じている--「溝」 を排除して、RAD 形態のなかで、なんとか、1つの モデル を使って、「分析」 と 「設計」 を融合できないか、と考えていました。

　Ｔ字形 ER手法は、当初、「resource」 概念 と 「event」 概念を、「最適な キー 設計」 として導入しました。すなわち、「最小 （数） の キー を使って最大の パフォーマンス を実現する」 ことを狙っていました--Ｔ字形 ER手法の起点は、コッド 関係 モデル だったので。

　しかし、そういう考えかたをして、コード 体系 （のなかに記述されている単独の [ 1つの データ 項目として記述されている ] 番号 ・コード--たとえば、商品 コード とか受注番号とか） を アクセス・キー として使ったら、キー と コード 体系が、かならずしも、対応していないという壁にぶつかりました。
　というのは、コード は、（個体を認知するために、） 認知番号として使われていることもあれば、「入力の簡便性」を配慮して導入されていることもある、という事態がわかってきたからです。しかも、コード 体系の コード が、かならずしも、キー （primary-key） として、データ を一意にしないこともある。

　さらに、コード （の中身） の構成が、1970年代に導入されたまま--つまり、V-SAM 用のアクセス・キー （構造化概念のなかで組まれた キー） であって--、関係 モデル には、かならずしも、適合しない 「索引 （indexing）」 であることも、わかってきたのです。

　1つの手法 （Ｔ字形 ER手法） を使って、概念設計・論理設計・物理設計の 「溝」 を排除しようとしたら--すなわち、データ 構造が、事業の中身を記述するようにしたら--、しまいには、「マスター・キー （一意性を検証する キー） を捨てなければならない」 という所まで至りました。「マスター・キー を捨てなさい」 ということを、僕が セミナー のなかで言うと、往々にして、真意を誤解されるのですが、「RDB 用の primary-key は、概念設計のなかでは、足手まとい となる」 ようです。

　
　（2004年 9月23日）