●　コッド正規形 （第三正規形）

　コッド 正規形では、関数従属性が、推移従属性として作用しないのが第三正規形である。

　　　　　　　関数従属性　　　推移従属性
　　　　　　┌＜１対１＞┐　┌＜１対１＞┐
　　　　　　│　　　　　↓　│　　　　　↓
　　　┌──┴───┬───┴──┬──────┐
　　　│　　キー　　│　　属性　　│　　属性　　│　　第三正規形
　　　├──────┼──────┼──────┤
　　　│　　　ａ　　│　　　ｂ　　│　　　ｃ  　│　　｛ａ, ｂ｝.　｛ｂ, ｃ｝.
　　　│　　　　　　│　　　　　　│　　　　　　│
　　　└──────┴──────┴──────┘

　
　たとえば、以下を考えてみる。

　｛従業員番号、従業員名称、・・・、部門 コード、部門名称｝.

　この形では、以下の関数従属が成り立っている。

　（1） 従業員番号 --> 従業員名称、・・・、部門 コード、部門名称
　（2） 部門 コード --> 部門名称

　
　したがって、第三正規形は、以下のようになる。

　｛従業員番号、従業員名称、・・・、部門 コード （R）｝.
　｛部 門コード、部門名称｝.

　なお、従業員 タプル のなかの部門 コード は、「外来 キー （foreign-key）」 である。

　
●　みなし entity （推移従属性の除去）

　さて、以上の考えかたを応用して、以下の例を考えてみる。

　｛受注番号、受注日、受注数、・・・、直送先名称、直送先住所｝.

　
　なお、直送先名称 （の値） は 「一意」 である、とする （primary-key として使う、とする）。
　コッド 正規形では、（推移従属性に従って、） 以下のように、タプル は分割される。

　｛受注番号、受注日、受注数、・・・、直送先名称 （R）｝.
　｛直送先名称、直送先住所｝.

　
　TM では、以下のような構造になる。

　｛受注番号、受注日、受注数、・・・｝.
　｛受注番号 （R）、直送先名称、直送先住所｝.

　
　コッド 正規形では、直送先住所は、一度、記録されたら、重複は起こらないが、TM では、（みなし entity として扱っているので、） 直送先名称・直送先住所は、受注番号のつど、記録されることになる。もし、直送先住所を、つど、入力することを回避して、つねに、名称 ファイル あるいは 「resource」 として扱いたいのであれば、代替的な認知番号として継承している 「受注番号 （R）」 に対して、（同意された）「認知番号」 を──たとえば、「直送先 コード」とか──付与するように問うのが TM の考えかたである。

　TM が、「みなしentity」 の認知番号として、もとの entity の認知番号を継承した理由は、つねに、個体の 「認知」──つまり、コード 体系のなかで、同意された 「認知」──を問うためである。もし、直送先名称を、認知番号の代用とすることが同意されているなら──言い換えれば、直送先 コード の代わりとして、直送先名称を使うのであれば──、TM でも、文法に従って、以下の構造となる。

　｛受注番号、直送先名称 （R）、受注日、受注数、・・・｝. [ E ]
　｛直送先名称、直送先住所｝. [ R ]

　
●　推移従属性 と 個体の認知

　TM は、以下の点を、体系の起点としている。

　Entity である ＝ _Df 認知番号が付与されている対象である。