T字形ER手法でnullを認めない理由(2)
ここでは３値論理のアウトラインを書いて、前回の課題のうち「maybe, unknown, undefined とはどういう意味の値か」だけ解決する。
３値論理
SQLでは、nullは３値論理で扱われる。３値の真理値表は以下の通り。
NOT
not true false null null false true
AND
true null false true true null false null null null false false false false false
OR
true null false true true true true null true null null false true null false
nullがらみの論理演算結果、例えば
- nullの否定はnull.
- true AND null は null.
- true OR null はtrue.
などは「直感的ではない」とか言われることがあるみたいだが、そんなことはない。
nullとは「trueかもしれないし、falseかもしれない」という意味と考えれば直感的に理解できる。
「データベース設計論」にある "maybe" は、この「trueかもしれないし、falseかもしれない」という意味。
maybeの何がいけないのかというと、
- プログラマがうっかり２値のつもりで書いたコードがバグになる
- プログラマが期待する null の意味には「値がわからない」「値がありえない」の２つがあるが、３値論理が表現しているのは「値がわからない」の方だけ
という２つの問題があるから。
１.は、テーブル定義には not null を付けなさい、という話でよく言われること。
例えば３値論理の世界では排中律が使えない。詳細は次回。
２．について。
わざとらしい例だが、社員マスタ上に所属部門コードがあるとする*1。
社員マスタ（Ｒ）＝｛ 社員コード, 社員名, 所属部門コード, ... ｝
このテーブルに、社長と、配属未定の新入社員のレコードを収容するとすれば、両方とも所属部門コードはnullになる。
が、新入社員の所属部門のnullは「未定」という意味なのに対して、社長の所属部門のnullは「ありえない」という意味。つまり、同じ null でも意味が違う。
このデータベースに対して、新人の配属先を考えるために配属未定の社員一覧を問い合わせたら、社長もリストアップされてしまうが、これはクエリの発行者が期待していることではない。そこで「未定」と「ありえない」を区別してアクセスできるようにしようという発想が出てくる。
前掲書P-80にある unknown・undefinedというのは、上記の２つのnullの意味に対応している。
- 新入社員の所属部門 ... unknown
- 社長の所属部門 ... undefined
