130値論理

　リレーショナル・データベースと SQL が、NULL の存在を認めたことによって、3値論理という特異な論理体系を採用することになった、という事情については、これまでにも「3値論理とNULL」や「3値論理 ―― 神のいない論理」で詳しく説明してきましたので、皆さんよくご承知のことと思います。ご承知でない方はLet's リンク先を読みましょう。

　それらの記事でも少し触れましたが、コッドはもともと、NULL をさらに適用不能（Inapplicable）と不明（Unknown）の二つに分けた4値論理を採用するのがベストだと考えていました。今では3値論理が定着したため、半分忘れられたエピソードですが、真理表で表すとこんな感じです。

x	NOT x

t	f
a	a
i	i
f	t

AND	t	a	i	f

t	t	a	i	f
a	a	a	i	f
i	i	i	i	f
f	f	f	f	f

OR	t	a	i	f

t	t	t	t	t
a	t	a	a	a
i	t	a	i	f
f	t	a	f	f

　いやあ、凄いですね。真理値3つのお手玉でも十分苦労しているのに、4つも渡された日にはとても扱える代物ではない、というのが大多数の人の感想でしょう。コッドの4値論理が選ばれなかった理由も、端的に複雑さのわりに実用的なメリットに欠けると判断されたからです。決して理論的に破綻しているとか、矛盾が起こるということはないのですが、ここまでかっとんでると凡人はついていけない。

　どれぐらい複雑になるか、ちょっと具体的に見てみましょう。n値論理において定義可能な論理演算の種類は、1項演算なら、真理値の数の冪乗に比例して増加します。例えば、2値論理なら、2² = 4、3値論理なら、3³ = 27、4値論理なら、4⁴ = 256 種類。2項演算の場合は、さらに累乗がかぶるので、とんでもない数になります。

**多値論理における演算の複雑さ**
	1項演算	2項演算

2値論理	4	16
3値論理	27	19,683
4値論理	256	4,294,967,296
・・・	・・・	・・・・・・
n 値論理	nⁿ	n^n²

　こうして具体的な数字を見ると、「ちょっとコッド先生の話には乗れませんなあ」という気分にもなるでしょう。

　しかし、とりあえずそういう夢のない話はおいといて、純粋に意味論の問題として考えた場合、一体、NULLというのは何種類あるのでしょう？また、どういう風に分類するのが適切なのでしょう？

　面と向かってこう訊かれると、なかなかすぐには答えられません。NULL というのは、私たち人間が「分からない」とか「意味不明」とレッテルを貼ってやりすごしている者たちをごった煮にした大鍋みたいなものなので、その蓋を開けるとえらいことになります。NULL の分類をするとはひとえに、「名づけられぬものたち」の分類に手を挑むことを意味するのです。

　その観点から見ると、コッドの提案した二種類の区別は、議論のとっかかりとしては有用です。私たちはテーブル設計の時、失われたデータを何でも NULL の大鍋へ放り込んでしまいますが、少なくとも NULL という概念が複合的なものである、ということは明らかです。

　私の体重は、読者の皆さんには分かりません。私は人間ですから「体重」という属性を持つことは間違いありませんが、しかしそれは現時点では不明です。一方、テレビや自動車などの「性別」や「虫歯の本数」という属性も、同様に NULL ですが、しかしそれは、値が分からないからではありません。無生物について性別云々することが意味をなさないからです ―― このようなコッドの議論は、非常に明晰で説得的です。

　SQLには、NULL という概念の得体の知れなさにつけこんで、厄介な問題を全てNULLへ押し付けてしまおうとする、困った傾向があります。例えば、外部結合の結果によっても NULL が生じますが、この場合は、設計時点で生じる NULL とは異なる意味を持ちます。そのため、外部結合の際に生じる NULL には、普通の NULL とは異なる専用のマークを使うべきだと主張する人もいます。理屈上は、筋の通った主張ではあります ―― 例によって実用的かどうかは別問題ですが。また、CUBE や ROLLUP オプション付きの集約を行ったときも、超集合行に NULL が現れますが、これもやはり「不明」とも「適用不能」とも異なるタイプの NULL です。

　もっと酷いのが、サブクエリの戻り値としての NULL です。クエリは、条件に該当するレコードが存在しなかった場合、空集合を返すことになっています。その原則は、サブクエリの場合も変わりません。クエリはどんな場合でも、一応集合を返さなければならないからです（閉包性の原則）。ところが、SQL は空集合を表すための記号を持っていないため、これを NULL で代用しているのです。･･････ NULL は値ではありませんし、ましてや集合でもありません。どうも NULL は、SQL において厄介な問題をまとめて放り込むブラックホールのような扱いを受けているようです。

　星新一の短編に、そんな穴の話がありましたね。どんなゴミを捨てても決して一杯にならない不思議な穴。みんな調子に乗って核廃棄物や粗大ゴミを次々投げ捨てていたら、ある日、空から･･････（「おーい、でてこい」）。

　最後に、極めつけの小話を紹介しましょう。デイトの友人でもある IT コンサルタントのフェビアン・パスカルが自分のサイトで紹介している話ですが、かつて SQL:1999 の策定委員会で検討されていた NULL に関する草案の中には、ユーザ定義 NULL というアイデアが含まれていた、というのです^[1]。プロシージャで使うユーザ定義例外の NULL 版のようなものでしょうか。ユーザが自由に NULL の意味を決めて分類できる機能のようです。

　「おや、なかなかいいじゃないの、それ。プログラミングの自由度が広がりそうで」

　そう思います？でもね、話はまだ半分なんです。凄いのは、その NULL の分類が128パターンまで可能とされていた、ということ。ほう、128、それは豪気な……

　ひゃくにじゅうはち！？

　そう、128種類。ということはです、もしこの128種類を全部使ってデータベースを設計したとしたら、通常の真と偽の二つの値を含めて、130値論理が必要になったということです。さっきの真理値の数と複雑さの度合いを示した表を見返してください。130値論理において定義可能な2項の論理演算の種類は……

130^130²

ほとんど想像力の限界に挑戦する SF の世界です。パスカルのサイトでは「このアイデアを実装しようというベンダーは存在せず、結局は立ち消えになった模様」と投げやりなことが書かれてますが、これ見たら誰だってヤケクソな気分になります。この話を聞いた後だと、コッドの4値論理が可愛く見えてくるから不思議です。

　「分からない」ということについて、私たちは、ほとんど何も分かっていないのだな、ということを痛感させられる小話ではあります。え？怪談の間違いじゃないかって？まあ確かに背筋の寒くなる話ではありますけどね……。

注
[1] F.Pascal, "ON 128 TYPES OF NULL?"