暗黙のうちに持っているメンタルモデルを意識すること
こんにちは。ドキュメント・コンサルタントの開米瑞浩です。
前回、「この内容は、ベン図を使って説明するのには向かないテーマ」であると書きました。
それがなぜなのかについて今回書きます。(まあ、マニアックな話なのであんまり受けないでしょうけど・・・(^_^;;;;)
ということで本題です。
まず、ベン図というのは集合論でよく使われるこういう図ですね。
外側の四角い枠いっぱいが「全集合」という集合のすべての要素を表し、その中に部分集合がいくつかあります。上図でいえば「自動車」全体の中に「ガソリン(で動く車)」「電気(で動く車)」という部分集合があり、軽油やガスで動く車は「その他」に入っています。
そして部分集合「ガソリン」と「電気」の積(共通部分)にあたるのが両方を使う「ハイブリッド」車というわけです。G1,G2やH1,E1 などの記号は集合に含まれる個別の要素(カローラとかプリウスとかスカイラインとかの個別車種)だと思ってください。
数学の集合論は極めて抽象的な概念ですから、集合に含まれる要素については何の仮定もおかずに考えることができますが、学習者がこの種の概念を理解しようとするときは、何らかの現実世界の例を使って感覚的に把握しようとするものです。
たとえば上図のように「自動車全体の中にはガソリン駆動のものと、電気で動くものと、それ以外があるよね・・・」といった例があると理解しやすくなるので、そうした例で教える場合が多いんですね。
こうした現実世界の例をイメージするとき、そこで使われる集合というのはたいてい「内包的に定義できるもの」が多くなります。
内包的というのは集合を記述する方法のうちのひとつで、簡単にいうと「鳥類とは、空を飛ぶ脊椎動物である」というように共通する性質を語る方法を内包的定義、「鳥類とは、ニワトリ、ツバメ、スズメ、ヒヨドリ・・・・である」と個別要素を列挙する方法を外延的定義と言います。(飛べない鳥もいますが例外として目をつぶってクダサイw)
集合を外延的に定義すると、まったく性質の違うものでも記述できます。たとえば「A集合の要素はイカ、ツバメ、コーヒー、東京タワー」なんてわけのわからないものも記述できますね。
しかし、内包的定義だと「共通する性質」によって定義するので、そういうことはできません。図1でも「自動車」という全集合にはある共通する性質が存在するわけです。
その結果何が起きるかというと、実は内包的方法によって定義された集合というのはたいていの場合、1つの表として表すことができます。
つまりこんなイメージです。
G1、G2・・・という個別の車種がそれぞれ「ガソリン駆動するか否か」「電気駆動するか否か」という属性を持っていて、その属性値の組み合わせで部分集合が決まる。で、その他も含めた全集合は表全体となる。
と、こんなイメージになるわけです。
そうすると、ベン図が表す範囲をこの表の上にプロットしてやると
と、こんな風になりますね。ベン図という表記法自体は高度に抽象的なものですから、「1つの表のイメージ」にしか使えないわけではありませんが、学習するときに無意識のうちにメンタルモデルとしてこんなイメージを持ってしまうことが多いのです。
一方、RDBで2つのテーブルをOUTER JOINして結果を得よう、という場合のイメージは実はこうなりません。
JOINという操作はそもそもほとんどの場合、「内包的定義の異なる2つの表」の間で行われるので、こんなイメージなんですね。
自動車の例で言えば、車種だけを記述するAテーブルと、駆動方式を記述するBテーブルが分離されていてIDでマッチング可能になっている。
そこで、JOINによってマッチングを行い、OUTERの指定によってマッチングしなかった部分を残すのがOUTER JOIN 操作なわけです。
図5:LEFT OUTER JOIN 操作
既に書いたように、「ベン図」表現は「共通する内包的定義を持つ全集合の中の部分集合の操作」として、つまり「1つの表の中の操作」として理解されることが多いのに対して、テーブル A とBではそもそも内包的定義が違う複数の表なので、JOINのINNER、OUTER概念を説明するためにベン図を使うと、暗黙のうちに持っているメンタルモデルと食い違い、理解に混乱を来す可能性が高いです。
難解な概念を説明するときは、こうした、人が暗黙のうちに持っているメンタルモデルを意識して、混乱が起きないように配慮する必要があります。特に、熟練者と初心者では持っているメンタルモデルが違う場合があるため、一筋縄ではいきません。