● 提示されたテーマは ...
今回から、いよいよ、実地に使われているデータを材料にして、Ｔ字形ＥＲ図の読みかたを、佐藤正美が実演する。
なお、今回、最初の 30分ほど、「関係主義と実体主義」について語った。それらが、コッド関係モデルのなかで、どのように適用されているのか、という点を確認して、ＲＤＢ （の index-key） に対して、どのような影響を及ぼすのか、という点を語った。
今回から、「本番システム」の情報を対象とするので、このホームページのような「公」の場--だれでもが、目にすることができる場--では、作図されたデータ構造に対する「読みかた」を、すべて、記載することはしない。データ構造のなかで、「一般化」できる論点のみを、記述の対象とする。
● 関係主義 と 実体主義 ...
実体主義の考えかたは、独立自存する「実体」が、まず、あって、次に、（「実体のあいだ」に、） 「関係」が二次的に成立する、という考えかたである。ただし、ここでいう「実体」とは、「名指し （個体指示子）」が付与されている対象とする。いっぽう、関係主義の考えかたは、「関係」が一次的であって、「実体」は、「関係のなかの変項」にすぎない、という考えかたである。
言い換えれば、実体主義は、個体指示子を付与された実体を、まず、認知して、そのあとで、実体に帰属する性質を記述する。いっぽう、関係主義は、「共通の性質」を括って、個体を指示する。したがって、実体主義は、（実体が、ほかの事態のなかで起こり得たかもしれない「可能性」や、そうなったことの「必然性」をも考慮して、） 「様相の論理学」として体系化されるし、いっぽう、関係主義は、内包 （性質） を使って外延 （集合） を作る「内包・外延の論理学」として体系化される。したがって、「様相の論理学」は、多値 （真・偽のほかに、maybe などの値） を扱い、「内包・外延の論理」は、２値を基礎とすることが多い。
コッド関係モデルは、（直積集合を前提にして、） 以下のような多項関係を考えている。
Ｒ｛ｎ１∈Ｎ１, ｎ２∈Ｎ２,..., ｎｉ∈Ｎｉ, ∧ Ｐ（ｎ１, ｎ２,..., ｎｉ）｝.
Ｒ が「関係」を示し、Ｎ１、Ｎ２、... Ｎｉが「セット」を指示して--コッド関係モデルでは、それらは、属性値集合であるが--、ｎ１、 ｎ２、... ｎｉは「タプル」と云われる。「タプル」のなかに、属性値を代入したのが「テーブル」である。そして、Ｐ（ｎ１, ｎ２,..., ｎｉ）--が「存在性」を示している。すなわち、この世界のなかに、どのような事物が存在するか、という点は、偶然的な事実である。そうであるなら、「すべての ｎ について、Ｎ (ｎ) 」という記述は、ｎ１∈Ｎ１, ｎ２∈Ｎ２,..., ｎｉ∈Ｎｉ と同値にならないので、正確には、「ｎ１∈Ｎ１, ｎ２∈Ｎ２,..., ｎｉ∈Ｎｉ、かつ、ｎ１, ｎ２,..., ｎｉ が すべての モノである」と同値である、と言うことができる。
前述したように、「この世界のなかに、どのような事物が存在するか、という点は、偶然的な事実である。」ということは、多項関係は、すでに、様相を前提にしている。コッド関係モデルは、多項関係式に対して、以下の２つの前提を導入した。
（１） タプルを「真 （ソリューション）」とするために、個体は、すでに、記号化されている。
（２） Ｐ（ｎ１, ｎ２,..., ｎｉ）に対して、null を適用できる。
Null を扱うなら、当然に、多値 （３値あるいは４値）を対象とする--３値論理あるいは４値論理を使うことになる。すなわち、コッド関係モデルは、一見、関係主義のように思われるが、実は、（個体記号化の前提や、多値の導入など） 実体主義を前提にしている、というふうに「解釈できる」。
もし、コッド関係モデルを、「性質を記述すれば、個体を指示できる」というふうに解釈すれば、ＲＤＢでは、index-key として、「unique-key」を考えなくてもよい （任意である）。
いっぽう、コッド関係モデルを、実体主義的に解釈すれば、個体指示子 （primary-key） として、unique-key を使わなければならない （強制である）。
ただし、unique-key （個体指示子） として、どのようなデータ項目を使うのか、という点は、（「無意味な」連続番号とか、「コード体系の管理番号」というような論点を検討しなければならないので、） ここでは、論点にしない。
実際のデータ設計では、どうも、実体主義と関係主義のあいだを、意識的であれ無意識的であれ、往復しているようである。ＴＭは--ＴＭ’ではない点に注意されたい--、実体主義的である。そして、ＴＭ’は、関係主義的である。
● 区分コードの ＶＥ化 ...
まず、以下のように作図されていた構造に対して、「区分コードのＶＥ化」を検討する。
｛発注番号、...｝.
｛発注番号(R)、発注区分コード、発注区分名称｝.
｛発注番号(R)、外販区分コード、外販区分名称｝.
区分コードは、ＴＭでは、「個体の周延」を検証するためのコードである。
したがって、原則として、区分コードを ＶＥとして扱ってはいけない。
発注区分コードは、「案件、発注、キャンセル」という３つの状態を指示する （状態遷移であること） ことが確認された。そして、案件を経由しない発注もあるし、案件が発注にならないまま、キャンセルされる事態があることも確認された。したがって、発注区分コードは、「発注」entity のなかに記述するのが正しい。
１つの entity のなかに、区分コードが、複数、記述されるなら、サブセットは、「階」を形成する。そして、「階」の上下を入れ替えても、「意味」が成立するならば、entity は交叉している状態である。したがって、entity は、周延していない。もし、そうであるならば、いずれかの区分コードは、その entity には帰属しない。
外販区分コードは、発注区分コードに対して、交叉する。したがって、外販区分コードは、発注には帰属しない。外販区分コードが、どの entity に帰属するか、という訂正点は、ここでは、割愛する。
なお、区分コード名称は、Ｔ字形ＥＲ図のなかでは、以下のテーブルを、（ほかのテーブルに対して） リレーションシップを結ばないようにして、図の下のほうに、「名称テーブル」として、一括して記述する。
｛発注区分コード、発注区分名称｝.
｛外販区分コード、外販区分名称｝.
● 「多値の OR 関係」 と 「多値の AND 関係」 ...
以下のように作図されていた構造に対して、「多値の 『AND 関係』」を検討する。
発注 HDR
｛発注番号、運送業者番号(R)、...｝.
発注 DTL
｛発注番号、商品番号(R)、...｝.
運送業者について確認したら、１つの発注に対して、運送業者は、複数 （１社 あるいは ２社のいずれかの状態） になることが確認された--最大数では、２社になる。したがって、まず、運送業者が「多値 (repeating data element)」になると判断して、以下の構造を作る。
発注 HDR
｛発注番号、...｝.
発注 HRD. 運送業者 [ MO ]
｛発注番号(R)、運送業者番号(R)｝.
発注 DTL
｛発注番号、商品番号(R)、...｝.
「多値」では、それぞれの値のあいだに、「OR」関係が成立するのか、あるいは、「AND」関係が成立するのか、という点を確認しなければならない。
運送業者が、２社になるときには、或る運送業者が配送を請け負った際、かならず、「窓口」となる統轄運送業者を記述しなければならない、というルールがあることを確認できた。そして、統轄運送業者と配送運送業者とのあいだには、以下のように、配送運送業者の値 （ｂ とする） がわかれば、統轄運送業者の値 （ａ とする） が「一意に」対応することが確認された。
｛ａ１、ｂ１｝. ｛ａ１、ｂ２｝. ｛ａ２、ｂ３｝. ｛ａ２、ｂ４｝.
したがって、統轄運送業者と配送運送業者とのあいだには、（「多義」--多値の「OR 関係」--ではなくて、） 「再帰」関係が成立するので、以下の構造に変更する。
運送業者
｛運送業者番号、運送業者名称、...｝.
運送業者. 運送業者. 再帰表
｛運送業者番号(R)、運送業者番号(R)｝.
発注 HDR
｛発注番号、運送業者番号(R)、...｝.
発注 DTL
｛発注番号、商品番号(R)、...｝.
次回も、今回のデータ構造を対象にして、「読みかた」を継続する。