「TMの会」 プログラム このウインドウを閉じる
/ 2005年 5月25日 / 

 

 ● 提示されたテーマは ...

 今回から、いよいよ、実地に使われているデータを材料にして、T字形ER図の読みかたを、佐藤正美が実演する。

 なお、今回、最初の 30分ほど、「関係主義と実体主義」について語った。それらが、コッド関係モデルのなかで、どのように適用されているのか、という点を確認して、RDB (の index-key) に対して、どのような影響を及ぼすのか、という点を語った。

 今回から、「本番システム」の情報を対象とするので、このホームページのような「公」の場--だれでもが、目にすることができる場--では、作図されたデータ構造に対する「読みかた」を、すべて、記載することはしない。データ構造のなかで、「一般化」できる論点のみを、記述の対象とする。

 
 ● 関係主義 と 実体主義 ...

 実体主義の考えかたは、独立自存する「実体」が、まず、あって、次に、(「実体のあいだ」に、) 「関係」が二次的に成立する、という考えかたである。ただし、ここでいう「実体」とは、「名指し (個体指示子)」が付与されている対象とする。いっぽう、関係主義の考えかたは、「関係」が一次的であって、「実体」は、「関係のなかの変項」にすぎない、という考えかたである。

 言い換えれば、実体主義は、個体指示子を付与された実体を、まず、認知して、そのあとで、実体に帰属する性質を記述する。いっぽう、関係主義は、「共通の性質」を括って、個体を指示する。したがって、実体主義は、(実体が、ほかの事態のなかで起こり得たかもしれない「可能性」や、そうなったことの「必然性」をも考慮して、) 「様相の論理学」として体系化されるし、いっぽう、関係主義は、内包 (性質) を使って外延 (集合) を作る「内包・外延の論理学」として体系化される。したがって、「様相の論理学」は、多値 (真・偽のほかに、maybe などの値) を扱い、「内包・外延の論理」は、2値を基礎とすることが多い。

 
 コッド関係モデルは、(直積集合を前提にして、) 以下のような多項関係を考えている。

  R{n∈N, n∈N,..., n∈N, ∧ P(n, n,..., n)}.

 R が「関係」を示し、N、N、... Nが「セット」を指示して--コッド関係モデルでは、それらは、属性値集合であるが--、n、 n、... nは「タプル」と云われる。「タプル」のなかに、属性値を代入したのが「テーブル」である。そして、P(n, n,..., n)--が「存在性」を示している。すなわち、この世界のなかに、どのような事物が存在するか、という点は、偶然的な事実である。そうであるなら、「すべての n について、N (n) 」という記述は、n∈N, n∈N,..., n∈N と同値にならないので、正確には、「n∈N, n∈N,..., n∈Nかつ、n, n,..., n が すべての モノである」と同値である、と言うことができる。

 前述したように、「この世界のなかに、どのような事物が存在するか、という点は、偶然的な事実である。」ということは、多項関係は、すでに、様相を前提にしている。コッド関係モデルは、多項関係式に対して、以下の2つの前提を導入した。

 (1) タプルを「真 (ソリューション)」とするために、個体は、すでに、記号化されている。
 (2) P(n, n,..., n)に対して、null を適用できる。

 
 Null を扱うなら、当然に、多値 (3値あるいは4値)を対象とする--3値論理あるいは4値論理を使うことになる。すなわち、コッド関係モデルは、一見、関係主義のように思われるが、実は、(個体記号化の前提や、多値の導入など) 実体主義を前提にしている、というふうに「解釈できる」。

 もし、コッド関係モデルを、「性質を記述すれば、個体を指示できる」というふうに解釈すれば、RDBでは、index-key として、「unique-key」を考えなくてもよい (任意である)。
 いっぽう、コッド関係モデルを、実体主義的に解釈すれば、個体指示子 (primary-key) として、unique-key を使わなければならない (強制である)。
 ただし、unique-key (個体指示子) として、どのようなデータ項目を使うのか、という点は、(「無意味な」連続番号とか、「コード体系の管理番号」というような論点を検討しなければならないので、) ここでは、論点にしない。

 実際のデータ設計では、どうも、実体主義と関係主義のあいだを、意識的であれ無意識的であれ、往復しているようである。TMは--TM’ではない点に注意されたい--、実体主義的である。そして、TM’は、関係主義的である。

 
 ● 区分コードの VE化 ...

 まず、以下のように作図されていた構造に対して、「区分コードのVE化」を検討する。

  {発注番号、...}.

  {発注番号(R)、発注区分コード、発注区分名称}.

  {発注番号(R)、外販区分コード、外販区分名称}.

 
 区分コードは、TMでは、「個体の周延」を検証するためのコードである。
 したがって、原則として、区分コードを VEとして扱ってはいけない。

 発注区分コードは、「案件、発注、キャンセル」という3つの状態を指示する (状態遷移であること) ことが確認された。そして、案件を経由しない発注もあるし、案件が発注にならないまま、キャンセルされる事態があることも確認された。したがって、発注区分コードは、「発注」entity のなかに記述するのが正しい。

 1つの entity のなかに、区分コードが、複数、記述されるなら、サブセットは、「階」を形成する。そして、「階」の上下を入れ替えても、「意味」が成立するならば、entity は交叉している状態である。したがって、entity は、周延していない。もし、そうであるならば、いずれかの区分コードは、その entity には帰属しない。

 外販区分コードは、発注区分コードに対して、交叉する。したがって、外販区分コードは、発注には帰属しない。外販区分コードが、どの entity に帰属するか、という訂正点は、ここでは、割愛する。

 なお、区分コード名称は、T字形ER図のなかでは、以下のテーブルを、(ほかのテーブルに対して) リレーションシップを結ばないようにして、図の下のほうに、「名称テーブル」として、一括して記述する。

  {発注区分コード、発注区分名称}.

  {外販区分コード、外販区分名称}.

 
 ● 「多値の OR 関係」 と 「多値の AND 関係」 ...

 以下のように作図されていた構造に対して、「多値の 『AND 関係』」を検討する。

  発注 HDR
  {発注番号、運送業者番号(R)、...}.

  発注 DTL
  {発注番号、商品番号(R)、...}.

 運送業者について確認したら、1つの発注に対して、運送業者は、複数 (1社 あるいは 2社のいずれかの状態) になることが確認された--最大数では、2社になる。したがって、まず、運送業者が「多値 (repeating data element)」になると判断して、以下の構造を作る。

  発注 HDR
  {発注番号、...}.

  発注 HRD. 運送業者 [ MO ]
  {発注番号(R)、運送業者番号(R)}.

  発注 DTL
  {発注番号、商品番号(R)、...}.

 
 「多値」では、それぞれの値のあいだに、「OR」関係が成立するのか、あるいは、「AND」関係が成立するのか、という点を確認しなければならない。

 運送業者が、2社になるときには、或る運送業者が配送を請け負った際、かならず、「窓口」となる統轄運送業者を記述しなければならない、というルールがあることを確認できた。そして、統轄運送業者と配送運送業者とのあいだには、以下のように、配送運送業者の値 (b とする) がわかれば、統轄運送業者の値 (a とする) が「一意に」対応することが確認された。

  {a、b}. {a、b}. {a、b}. {a、b}.

 したがって、統轄運送業者と配送運送業者とのあいだには、(「多義」--多値の「OR 関係」--ではなくて、) 「再帰」関係が成立するので、以下の構造に変更する。

  運送業者
  {運送業者番号、運送業者名称、...}.

  運送業者. 運送業者. 再帰表
  {運送業者番号(R)、運送業者番号(R)}.

  発注 HDR
  {発注番号、運送業者番号(R)、...}.

  発注 DTL
  {発注番号、商品番号(R)、...}.

 
 次回も、今回のデータ構造を対象にして、「読みかた」を継続する。

 

ページのトップ
 
  このウインドウを閉じる