割と熱しやすく冷めやすいのだけど、まだ冷めない*1。
以前の記事で分かりにくかった所を補足して、あと、関手的データモデルの心理的効果(?)とかについて書きます。
「関手的データモデルをどう説明するか？ 考えてます」において：
NULLがどうだの、第N正規形がどうたら、みたいな話も割とドーデモイイことになります（問題が相対化されてしまいます）。実際、スピヴァックは正規化についてはほとんど無関心なようです。
追記した注釈のほうには次のように書きました。
スピヴァックが興味を持ってないから無意味なのか？ と言うと、そんなことはなくて、我々にとっては、正規形／正規化を関手的データモデルのなかで再現することは重要で有意義なことだと思います。
NULLや正規形はドーデモイイのか重要なのか、いったいドッチやねん!? と突っ込まれそう。
関係データモデルにおける金科玉条みないな話が、相対化されてしまうのは事実です。理論的には、「Aという定式化があり、Bという定式化もある。AとBの相互関係はコレコレ」というドライでクールな記述があるだけ。良し悪しの価値判断は、現実世界との適合性の議論に追い出されてしまいます。ところが、現実は多様なので「世の中イロイロ」に落ち着くことになるでしょう。
ドライでクールな記述は、宗教論争や感情論をカームダウンさせる効果があるでしょう。（ドライでクールな記述を受け入れられないから感情的になる、ってことかも知れないが。）NULLや正規形も相対化されて、理論的な比較が可能となり、「世の中イロイロ」ってことになるので、熱心に議論すべき話題とは思えなくなるのです。とはいえ、「ドーデモイイ」は言い過ぎ、語弊がありましたけど。
もうひとつの観点としては、スピヴァックのような先頭を走る研究者が、確立された既存の概念・手法に興味を持つか？ ってこと。新しい道具を手に入れたら新しい結果を出したいわけで、既に知られていることを言い換える作業にモチベーションが湧くとは思えません。しかし、僕のように後追いで学習する者には、「言い換える作業」も重要なトレーニングになるでしょう。
デイヴィッド・スピヴァックは、たぶん温厚なおにいさんなのでしょうね。他のデータモデルやデータベース製品を批判するようなことは言いません*2。それでも次のようなことは書いています。
The theory of relations (150 years old) is not adequate to mathematically describe modern DBMS.
150年前に生まれた関係の理論は、現代のDBMSを数学的に記述するには不十分だ。
関係論理／関係代数はさすがに古すぎて、実情に合わなくなっている、と。経年劣化で、もはや新しい結果を生み出す活力を失っているのでしょう。
僕自身は、関係の理論をロクに知らないし、したがって信奉者でもあり得ません。しかしそれでも、なんとはなしに関係の理論の枠組みを想定しているところがありました。それが自由な発想を抑制していた、思考の限界を勝手に設けていたように思います。
例えば、ジョインの話。MongoDBはジョインをサポートしてません。そりゃそうだろう、と。RDBじゃないのだから出来なくて当然、みたいな。僕はそんな感想を漠然と抱いていました。でも、ほんとに出来ないの？ 原理的に出来ないの？ それとも、実装やパフォーマンス上の都合？
圏的定式化では、ジョインはファイバー積（pullback図式）に過ぎません。MongoDBにおけるような入れ子のデータを蓄えた集合（MongoDBではコレクションと呼ぶ）に対して、ファイバー積は作れるのか？ データの実現を集合圏で行うなら、出来るに決まってますよね。出来るんですよ。
ただし、RDBに比べると、ジョインの結果を表現する方法に工夫が必要です。その工夫が恣意的なようにも思えます。しかし、これは恣意的でいいのです。圏論の教えるところでは、ファイバー積は一意に決まるわけじゃないです。up-to-isoで決まるものです。つまり、ジョインの結果＝ファイバー積の表現はたくさんあって、それらが同型なら特に問題はないのです。
実装の観点からは、up-to-isoを扱うのが鬱陶しいのは確かです。なので、「入れ子のデータだろうが何だろうがジョインはできる、だが面倒くさい」という事情なのでした。「なんだ、それだけか」という結論ではありますが、いったんはファイバー積という形で抽象化しないと、関係モデル以外のデータモデルにおける「ジョイン」の解釈さえできません。問題を述べることさえ出来なかったわけです。
コリャつまんない実例ですが、僕にとっては、特定のデータモデルや手法に捕らわれない“自由な感じ”を得た心理的な効果は大きいですね。
