2002年10月 1日 同一の サブセット と相違の サブセット >> 目次 (作成日順)
  ● QUESTION   同一の サブセット と相違の サブセット では、なぜ、記述方法はちがうのか。
  ▼ ANSWER   null に注意するため。
2007年10月16日 補遺  



 サブセット の記述は、同一の サブセット では 「=」 を使い、相違の サブセット では 「×」 を使う。
「同一」 とか 「相違」 というのは、DA (Data Analyst) が、作図中、すでに認知しているので、強いて、べつべつの記号を使わなくてもよいのではないか、という疑問があるかもしれない。

 べつべつの記号を使う理由は、「null」 に対して注意を促すためである。
 (数学の関数を使っている) データ・モデル では、モデル のなかで、「null」 は起こり得ない(!)

 コッド 博士 (Codd, E.F.) は、1970年代に、セット・アット・ア・タイム 法を考えて、[ キー (indexing) および レコード を使った mechanism とはちがう --物理的には、ポインター を使わない--] データ 構造として テーブル 構造を使い、テーブル に対して column 単位の アクセス 手法 (RDB) を提示した。
 セット・アット・ア・タイム 法の根底の思想が 「直積集合」 である。

 コッド 博士は、1980年代後半に、「SQL の致命的な欠点 (Fatal Flaws)」 という論文を公にして、IBM 社の SQL が (2値 ロジック [ 真と偽のふたつの値 ] を前提にしていて) 「maybe (null)」 を扱っていないと非難した。「null」 は多義 (unknown と undefined) なので、コッド 博士は、4値 ロジック [ 真・偽・unknown・undefined ] を使った。

 たとえば、直積集合 R (a, b) において、以下を考えてみる。
 (1) a は、従業員番号の集合 {01, 02, 03, 04} のなかの任意の メンバー とする。
 (2) b は、部門 コード の集合 { A, B } のなかの任意の メンバー とする。

 (a, b) は 「tuple (集合)」 である。
 [ 空集合ではない ] いくつかの集合のなかから、それぞれ、1つずつ メンバー を選んできて並べたら、1つの集合になる--この考えかたを「選択公理」という--。この並べられた集合のことを 「tuple」 という。
   R (Relation) は 「関数」 である。「tuple」 を形成するための--選ばれたそれぞれの メンバー を並べるための [ 順序対を形成するための ]--「関数」である。

 たとえば、従業員番号の集合から 01 を選んで、部門 コード の集合から A を選んで、以下のような tuple (順序対) を生成する (つまり、従業員 01 は部門 A に配属されている)。

  R (01, A).

 同様にして、従業員 02 は部門 B に配属され、従業員 03 は部門 A に配属されている、とすれば--従業員 03 が、従業員 01 と同じ部門 A に配属されているので、部門 A は 全射である点に注意されたい--、以下のような順序対が生成される。

  R (02, B).
  R (03, A).

 さて、ここまで示せば、セット・アット・ア・タイム 法が、column 単位に アクセス する理由を理解できるでしょう。すなわち、従業員番号の column にある値 (メンバー) は従業員番号の集合 (セット) から選択され、部門 コード の column にある値 (メンバー) は部門 コード の集合 (セット) から選択されている。それぞれの column (メンバー) は、それぞれの集合 (セット) から選択され、こういう column 単位の アクセス のことを セット・アット・ア・タイム (set-at-a-time)--セット 単位の縦列の アクセス--という。
 ちなみに、セット は、「ドメイン (domain)」という言いかたをする

 さて、従業員番号 04 は、「どの部門にも配属されていない」 とする。

  R (04, null).

 つまり、従業員番号 04 は、この リレーション (関数) では充足的ではないことになる(!)
 なぜなら、「null」 を部門 コード の集合から選択することはできないから。
 そもそも、部門 コード の集合を生成するときに、述語論理 f (x) を使って、「共通の述語 (性質)」 の モノ を集めて セット を生成しているのだから--「置換公理」 を前提にしているのだから--、[ 空集合でないかぎり、] 集合のなかには 「null」 は起こり得ない。

 以上にようにして、データ・モデル のなかでは--少なくとも、述語論理と集合論を使った データ・モデル のなかでは--、「null」 は 「致命的な欠点」 になる。したがって、「null」 に対しては、「適切な」 措置を施さなければならない。もし、「null」 を認めるのであれば、コッド 博士が示したように 4値 ロジック を使わなければならない。しかし、実地の システム 作りでは、はたして、プログラム を4値 ロジック で作成しているかしら。

 それを注意するために、T字形 ER手法では、サブセット (部分集合) を生成するときに、「相違」 の サブセット を意識的に生成するようにしている。

 
[ 注意 ]

 上述した従業員 モデル では、部門 コード を、タプル のなかで、あたかも、直積集合のように扱っているが、正確に言えば、部門 コード は、包摂関係のなかで挿入される コード である。Null を、単純に示すために、正確性を犠牲にして、部門 コード (R) を使ったので、ご了承ください。  

 



[ 補遺 ] (2007年10月16日)

 「null」 に関しては、以下の 2つの対応のいずれかを導入するしかないでしょうね。

 (1) 「null」 を認めないで、2値 ロジック を使う。
 (2) 「null」 を認めて、4値 ロジック を使う。

 構文論上、「null」 を認めて 3値 ロジック を使うことは、「null」 の使いかた次第では、unexpected な アウトプット がでる危険性を孕んでいます。というのは、3値 ロジック では、null の論理的否定 (¬ null) は、null として扱われるので、もし、アルゴリズム のなかで、「¬ null」 がでてくる文があれば、思わぬ事態に陥ります。

 TM は、2値 ロジック を前提にしているので、null を排除しています。
 もし、null を認めるのであれば、null は、意味論上、多義 (unknown と undefined) なので、指示規則に従って、値 (意味) を一意にするためには、4値 ロジック を使うのが整合的でしょうね。しかし、はたして、実地の システム 作りで、4値 ロジック を使い切れるのかしら。




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