モノ は 「高次の構成物」 である。したがって、モノ を 「定義することができない （定義不能である）」。
　　腕時計を例にすれば、「製品としての時計全体」 を モノ と看過すこともできるし、時計を 「構成するそれぞれの部品」 を モノ として認知することもできるし、極度な言いかたをすれば、モノ の認知は 「無限小」 に収束して、量子や波動ということもできる。

　事業過程 （購買過程・生産過程・販売過程・財務過程・労務過程および経営管理過程） のなかで モノ が扱われているが、管理対象として どういう モノ を認知しているか、という点は、事業過程のなかで使われている 「コード 体系」 を解析すれば、ほぼ、見て取ることができる。

　事業過程のなかで、これ以上に解体して管理しなくてもよい単位 （独立の単位--not organized） は、たとえ、物理的には、もっと解体することができるとしても、認知の単位として 「打ち止め（bring to a close [an end]）」 された最小限の単位は 「独立した モノ」 として扱われることになる。したがって、「独立した モノ」 として管理対象になっている モノ には 「単一 （one and only, not organized） の」 管理番号 （個体指示子） が付与される。ゆえに、そういう モノ を認知する番号は 「複合 キー」 にはなり得ないはずである。なぜなら、「複合 キー」 は 「構成物」 を示して、（「複合 キー」 を使って記述されている モノ が） もっと解体できることを明示しているから。

　単独の モノ （entity） は、以下の 2種類に類別される。
　（1） resource
　（2） event

　単独の モノ （entity） は、単独の （one and only、not organized） 番号を使って認知される。
　そして、構成物は 「対照表」 を使って記述される。

　「対照表」 には、以下の 2つの性質がある。
　（1） 擬似 event （「DATE」 を仮想することができる）
　（2） validation-rule （「DATE」 を仮想することができないが、「構成」 を記述する）

　実際の例では、事業過程のなかで最小限の単位である モノ が 「複合 キー」 を使って記述されていることが多い。たとえば、品目番号が 24桁を使って記述されている例がある。そして、その 24桁は、以下のように構成されていた。

　｛製品・半製品区分コード（2桁）, 連続番号（10桁）, 追番（4桁）, 倉庫コード（3桁）,...｝

　以上の構成が論点となるのは、（単独の認知番号として付番された） 「品目番号」 自体が 「複合 キー」 を使った 「構成物」 である、という点である。すなわち、品目番号自体が 「対照表」 としてしか記述できない、という点である。これは矛盾である （「論理的な矛盾」 でもあるし、経営戦略 （環境適応力）から観ても不適切である）。

　言い換えれば、「DATE （組立日）」 を仮想することができる擬似 event として記述される 「対照表」 を使って （品目という） 「resource」 を記述するか、あるいは、（実装しても良いし、実装しなくてもよい、という性質の） 「構成」 を使って （品目という） 「resource」 を記述する、という事態になるので 「論理的な矛盾」となる。

　また、たとえば、経営戦略の観点から、商品戦略として 「多品種少量」 生産を狙ったとき、扱う商品が 100種類以上になったら、製品・半製品区分 コード が 2桁では 100種類 （3桁） に対応することがむずかしい-- SE は、「マスター・キー の構成」 を崩すことを怖れて、値 99 の次の値として （アルファベット を使って） 「a1」 などという--たとえ、「並び」 が保証されても--およそ、意味のない 「奇妙な」 対応をするかもしれない （苦笑）。

　品目は製造の中核にある 「resource」 である。それが 「複合 キー」 でしか記述できない、という点は、（「論理」 という観点からも 「経営戦略」 という観点からも） 不適切な コード である。
　とすれば、そういう不適切な コード を適切な コード に改善したほうがよい。

　ただし、品目番号が 「複合 キー」 だから駄目だ、と単純に断言するような DA （Data Analyst） は落第である。「複合 キー」 になっている理由を （エンドユーザ に対して） 以下のように質問できる力量が DA には欲しい。

　（1） この品目は構成部品であると同時に サービス 品でもある、という扱いはされているのか。
　　　（同じ連続番号の品目が、製品・半製品区分 コード を使って、構成品と サービス 品に区分されているのか。）

　（2） サービス 品は独立需要として扱われているのかどうか--独立需要として扱われているはずである。

　（3） 構成部品であれば、同じ品目を （色などが違うために） 追番を使って、べつべつの MRP 対象としているかどうか。

　（4） 品目の連続番号と倉庫コードの間には 「1-対-1」 の関係が成立しているのか。
　　　（或る品目は、かならず、或る倉庫に搬入されるのか--言い換えれば、他の倉庫には搬入されないのか。）
　　　たとえば、品目の 0000000001 は、倉庫 A にしか搬入されない （倉庫 B には搬入されない）のか。

　（5） もし、品目と倉庫の間に、以上のような関係が成立しないのであれば、
　　　或る品目が複数の倉庫で受払されるのなら、品目を倉庫の間で移動したら 「振替」 として扱うのかどうか。

　などなど。

　コード から以上の諸点を読み取ることができる。
　以上の細かな諸点を一人の SE が業務分析しながら捕捉しようとしても無理であろう。
　しかし、実際に使われている データ は 「意味を語っている」。
　「データ に訊け」 というのが 「コード 解析」 である。

　こういう点を解析するということが、「データ 解析」 が 「データ 設計」 とはちがう、という点である。