2003年 8月 1日 null と状態遷移 >> 目次 (作成日順)
  ● QUESTION   null を VE として扱ったら、サブセット にしたほうが良いと言われたが、どうしてか。
  ▼ ANSWER   状態遷移を示す null は、区分 コード と同じである。
2008年 8月16日 補遺  



 以下の データ 構造を前提にする。

 請求
 {請求番号、請求日、請求金額・・・}[ E ]

 請求申請
 {請求番号 (R)、承認申請日、・・・}[ VE ]

 請求承認
 {請求番号 (R)、請求承認日、・・・}[ VE ]

 入金予定
 {請求番号 (R)、入金予定日、・・・}[ VE ]

 
● VE は entity の純度を高めるために導入された。

 承認申請日および請求承認日は、時系列のなかで、null となるのであれば、状態遷移を示している。
 請求承認日が 「任意の入力項目」 であるとは判断しがたい。

 さて、VE は、以下の事態を回避することを目的として使う。

 (1) 1つの resource のなかに、event が混入している。
 (2) 1つの resource のなかに、他の resource が混入している。
 (3) 1つの event のなかに、resource が混入している。
 (4) 1つの event のなかに、他の event が混入している。

 それぞれの具体的な例については、拙著 「T字形 ER による データベース 設計技法」 を参照されたい。
 上述した事態は、いずれも、1つの entity のなかに、ほかの entity が 「混入(contaminated)」 していることを示している。つまり、VE は、entity の純度を高めるために、混入した他の entity (ただし、認知番号が付与されていない状態) を排除するために使う。

 上述した例では、「入金予定」 が、あきらかに、VE として扱われる。

 VE は null を回避するために使う テクニック ではない。ただし、null の起こる アトリビュート が 「フラグ (flag)」 のような性質であれば、entity の純度を高めるために、VE を使うことがある。たとえば、「区分 コード」 とはいっても、「有る・無し」 を示すにすぎない 「flag」 であれば、VE を使う。

 請求
 {請求番号、請求日、請求金額・・・}[ E ]

 請求. 領収書添付
 {請求番号 (R)、領収書添付区分コード}[ VE ]

 [ 領収書添付区分 コード の値は、 「 1 (はい)」 か 「0 (いいえ)」 のいずれかである。]

 
● 状態遷移を示す null は、区分 コード と同じである。

 時系列のなかで null が生じるというのは、状態遷移を示している。
 したがって、状態遷移に対しては、本来、ステータス・コード が付与されていても良い。
 サブセット には実質的 サブセット と形式的 サブセット がある (101 ページを参照されたい)。

 形式的 サブセット は null を扱うために使う。

 したがって、上述の例は、以下のように訂正されなければならない。

  請求 [ E ]
   |
   ×
   │
   ├ 承認申請 { 請求番号、承認申請日 }
   │
   ├ 請求承認 { 請求番号、請求承認日 }
   │
   └ 請求 {請求番号、請求日、請求金額、・・・}

  入金予定
  {請求番号 (R)、入金予定日}[ VE ]

 

 



[ 補遺 ] (2008年 8月16日)

 本 エッセー は、読者の人たちに対して、そうとうに misleading になったようです。というのは、「状態遷移を記述するためには、サブセット を使わなければならない」 という メッセージ になってしまったようです──勿論、そういうふうな意味は、本 エッセー にはなかったのですが、私の綴った文が拙かったために、そういうふうな間違いを導いてしまったのであれば、申し訳ない。

 本 エッセー の趣意を まとめれば、以下の 2点になるでしょう。

 (1) null は、形式的 サブセット として記述する。
 (2) 形式的 サブセット のなかには、通時的(diachronique)に、「状態の推移」を示す サブセット もある。

 サブセット は、原則として、ひとつの セット を共時的(synchronique) に分割・細分した構成です。そして、ひとつの セット を分割・細分するためには、TM では、かならず、「区分 コード」 を前提にしなければならない。言い換えれば、「区分 コード」 は サブセット の必要条件です。この必要条件を明示した サブセット を 「実質的 サブセット」 と云います。

 いっぽう、TM は、「充足」 概念を前提にした 「真理条件」 を 「F-真」 としての判断規準にしています。言い換えれば、TM では、意味論的に多義になる null を認めない──「真理条件」 を問えない状態を認めない。null は、以下の ふたつの 「意味」 があって、意味論的に 「多義」 になります。

 (1) undefined
 (2) unknown

 ただ、ふたつの entity のあいだでは、全射を前提にした写像を考えたほうが、「モデル」 を作るうえでやりやすいので、とりあえず、写像のなかで、すべての値域は 「定義されている」 という前提で──集合 X と集合 Y のあいだで写像があって、f(x) として y が存在するという前提で── 「モデル」 を作りますが、「モデル」 を推敲する際に、「定義されていない」 値(undefined)──すなわち、null が起こる ひとつの現象──に対しては、当然ながら、null を除去します。null を除去するために使う テクニック が本 エッセー で述べた 「形式的 サブセット」 です。null は、まず、「形式的 サブセット」 を使って除去します。

 ただ、定義域があっても、値域を走る値が不明であるような現象 (unknown)──すなわち、null が起こる もうひとつの現象、たとえば、「任意入力」 の項──に対しては、いちいち、サブセット を作らないで、VE として除去することを 「実地の作図では」 認めています。そして、アトリビュート・リスト のなかに、「任意入力」 であることを但し書きすれば、実装形では、VE を もとの entity にもどすことも認めています。ただし、これは、便法であって、本 エッセー のなかで説明したように、VE は、本来、「ほかの entity の性質」 を除去するために導入されたのであって、ひとつの entity の性質に対して使う テクニック ではない点に注意して下さい。




  << もどる HOME すすむ >>
  データ解析に関するFAQ