2003年 5月 1日 「相違の サブセット」 の実装形 （その 1） >> 目次 （作成日順）
　　●　QUESTION 　　ヌル （null） を回避して 「相違の サブセット」 を実装するにはどうすればよいか。
　　▼　ANSWER 　　サブセット を、それぞれ、実装して、上位の セット （認知番号のみ） も実装すればよい。
2008年 5月16日 補遺 　



　サブセット の実装形としては、以下の 2つがある。

　（1） サブセット をべつべつに実装する。
　（2） サブセット を集成して上位の セット として実装する。

　「原則的には」 相違の テーブル は、それぞれ、べつべつに実装する。
　すなわち、テーブル （サブセット） のなかに null がないようにして実装する。

　そして、もし、RDB が 「inverted 式」 の indexing を搭載しているのであれば、「キー を使った join をすれば、」 物理的な 2つのテーブル を、あたかも、論理的に 1つの テーブル のように扱ってくれる。 （「ベーシックス」 の 3月 16日更新 「indexing （VSAM 式と inverted 式）」 を参照されたい。）

　ただし、こういう プロダクト は大型汎用機の環境のなかで 1つしかない （DATACOM/DB という プロダクト です）。DB2 も ORACLE も、「inverted 式」 の indexing を搭載していない。DB2 や ORACLE のように、「VSAM 式」 の indexing を搭載している プロダクト では、以下の 2つの やりかた をすることが多い。

　（1） 2つの テーブル （サブセット） を、それぞれ、べつべつに実装して、上位の セット も実装する。
　　　上位の セット には、それぞれの サブセット の identifier を実装する。

　（2） サブセット を上位の セット に集成して 1つの テーブル として実装する。ただし、null が起こる。

　（1） の やりかた は、null を避けて テーブル を実装できるし、（データ の冗長にはなるが）上位 テーブル がそれぞれの サブセット に対して 「索引き」 として作用するので、上位の テーブル とそれぞれの サブセット を 「INDEX-only」 を使えば、驚異的な パフォーマンス も実現できる。上位 テーブル の実装は 「データ の冗長」 になるが、それでも、null を回避して── null を判断する 「if」 の アルゴリズム を作成しないようにして──驚異的な パフォーマンス を実現するほうが得策だという判断である。小生の クライアント では、DA および DBA は、ほとんどすべて、そういう やりかた をしている。

　（2） の やりかた は、null が起こる。
　しかし、いっぽうで、サブセット を、それぞれべつべつに アクセス するために 「null-key」 を 2つ用意する。
　たとえば、取引先 entity のなかの アトリビュート として 「解散日」 を例にすれば、以下の 3つの indexing を生成する。

　　（2）-1　（解散日が ヌル である） active な取引先用の indexing [ null-key ]
　　（2）-2　（解散日が充填されている） 過去の取引先用の indexing [ null-key ]
　　（2）-3　 取引先の全体を対象にした indexing [ 一般キー ]

　この措置は、「たまに」 やることがある。ただ、小生の クライアント は、この やりかた を嫌っていて、（1） をやっている [ 小生もそう指導している ]。

　null を回避する最大の理由は── null が理論的に不整合である点を除いても [ すなわち、意味論的に、null は 「多義 （undefined と unknown） になるという点を除いても ] 実装上の論点を言えば──以下の点にある。

　「アルゴリズム の I/O 化」 ができない （！）

　言い換えれば、null を認めてしまうと、null を判断するために、（作成しなくともよいはずの） 「if」 の アルゴリズム を作成しなければならないし、多量 データ および多量 トランザクション に対して （「INDEX-only」 の I/O を前提にした） 「驚異的な」 パフォーマンス を保証できない。

　或る クライアント では、かって、null を認めて作成された 4,800 ステップ の プログラム が、「nested-IF」 が皆無の 800 ステップ にまで アルゴリズム が簡略化された例がある。それほどの 「驚異的なちがい」 が出る。当然ながら、パフォーマンス も、桁違いになる。（DB2 を使ったが、） null のない サブセット では、10,000,000 件の データ （10本以上の テーブル） を join しても 「瞬き （1 秒） の」 パフォーマンス を実現している。

　（データ 圧縮をやっていないなら、null があっても） パフォーマンス は低下することはないが、多量 データに対して （「INDEX-only」 の I/O を前提にした） 「驚異的な」 パフォーマンス を実現することができない。
　したがって、null は理論点な論点からも実装形の観点からも認めてはいけない。

[ 注意 ]
　「null は アルゴリズム のなかでも不整合であることを証明しなさい」 という宿題を小生から提示されている DA たちは、以上の論点が宿題の ソリューション ではない点に注意されたい。小生が宿題として提示したのは、「アルゴリズム の観点から判断しても null は破綻することを立証しなさい」 ということですから、null を対象としている アルゴリズム が完全性を保証していないことを立証してください。

　


[ 補遺 ] （2008年 5月16日）

　2 値論理を前提にすれば、ヌル （null） は、そもそも、「値」 ではないのだから、ヌルを対象にして 「等号 （＝）」 を使うことはできないでしょうね。ヌル のことを 「null-value」 というふうに言うこともあるので、慣例として 「ヌル 値」 という言いかたをしますが──小生も、「ヌル 値」 と言うこともありますが──、ヌル は、構文論上、「値なし」 のことです。あるいは、意味論上、「多義 （undefined および unknown）」 です。「undefined」 は、「定義されていない」 ということで、数学的には、「部分関数」 の外 （そと） にある、ということで、「unknown」 は、「部分関数」 の範囲内にあるかもしれない値だが、「未知数」 という意味です。すなわち、ヌル は、「付値されない （無意味）」　か 「値があるのだが、付値できない （有意味）」 という いずれかの意味です。

　コッド 関係 モデル は、セット 概念と第一階述語論理を前提にして、「直積集合」 を使って、「テーブル」 を作成しますが、「直積集合」 を選択公理 （あるいは、整列集合） の観点からみれば、それぞれの 「空でない」 集合 （セット） を前提にしています。したがって、テーブル 構造では、column として、メンバー を列挙する際に、「いくつかの （∃x）」 の メンバー が ヌル であることは整列集合に違反します。もし、ヌル を認めるのであれば、コッド 氏が提示したように、4 値論理 { true, false, applicable, unapplicable } を使わなければならないでしょう。
　しかしながら、現実には、SQL で 4 値論理を使って プログラム を作成しているとは想像しがたい。

　もし、3 値論理 ｛真、偽、ヌル｝ を使って、SQL プログラム を作成しているのであれば、ヌル に対して、「not」 や 「if」 を使うことが妥当でないことは明らかでしょう。というのは、ヌル の論理的否定は、ヌル になるから [ 「赤本」 81 ページ 参照 ]。したがって、「not exit」 とか 「not in」 を使えば、「想定外の （unexpected）]　の結果が出てきます。ちなみに、ロジック では、「not」 のことを 「¬」 として記述し、「if」 のことを 「→」 で記述します。ヌル に対して 「if」 （p → q） を使えば、仮言 [ p → q ] （p ならば q） は、ブール 代数では、「¬p ∨ q」 （p でないか、または、q） となるので、p が ヌル であれば、¬p も ヌル になってしまいます。

　「真」 概念には、「（導出的な） L-真」 と 「（事実的な） F-真」 があります。「L-真」 は、構文論上の概念で、「真とされる」 集合を前提にして、文法に従って導かれる構成で、俗に言えば、「不意打ち・飛躍がない」 ということです。「F-真」 は、意味論上の概念で、語彙および文が、現実的事態に対応しているということです──この 「F-真」 が 「真理条件」 と云われている概念です。モデル では、語彙は、ロジック で使う語彙 （OR、AND、NOT、IF や クラス 概念など） と 「観察述語」 から構成されます。「観察述語」 というのは、「観察可能な特徴」 を記述した語であって、「観察可能な特徴」 とは、物理的対象の性質・関係が、適当な条件の下で、与えられた事態の中に現れるか現れないか、という点を直接の観察によって確かめられることを云います。つまり、「観察述語」 とは 「観察可能な特徴」 を指示する語彙です。

　「経験論的な言語 L」 というのは、ロジック の語彙・公理を前提にして、事実的対象の観察可能な特徴を記述した言語 （モデル） です。TM （Ｔ字形 ER手法の改良版） は、「経験論的な言語 L」 の規約を守っています──ただし、文法に関しては、ロジック の公理系を使わないで、（関係の対称性・非対称性を考慮した） 独自の文法を使っていますが。

　TM は、2 値論理 （｛真、偽｝ の ふたつの値） を前提にした モデル です。したがって、ヌル を認めていない。
　ひとつの個体 （entity） のなかで ヌル が生じるのであれば──つねに付値されるか、つねに ヌル のときには──、構文論上、まず、サブセット にするのが基本ですが、たとえば、データ 入力では、かならず入力しなければならない （mandatory） 項と、入力が任意である （optional） 項がありますが、「任意な入力」 には──付値されることもあれば、ヌル になることもあるときには──、「みなし概念」 を使います。TMD （TM Diagram） 上、任意の項は、「みなし概念」 を使って、「個体 （entity）」 から外します。「みなし概念」 は、そもそも、意味論上、「個体」 に対して適用される概念ですが、構文論上、ヌル がでる項に対しても使っています。したがって、「個体」 のなかに、つねに現れる性質と、そうでない性質を切り離しています。それが 「観察述語 （あるいは、観察可能な特徴）」 という意味です。

　なお、「みなし概念」 で外だしされた 「任意の入力項」 は、使用する データベース の性能を考慮して──たとえば、optimizer が 「INDEX-only」 を外してしまうとか、join の対象になる テーブル 数に制限があるとか──、派生元の 「個体」 のなかに返して実装することもあります [ それは、データベース が粗悪なのであって、モデル のせいではないので、念のため （笑）]。 　




　 << もどる HOME すすむ >>
　 データ解析に関するＦＡＱ