このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

絵で分かる! 主キー/外部キーのアホらしさ

昨日と同じ話題を繰り返します。しかし今日は、誰にでもわかるように絵解きで説明します。

デイヴィッド・スピヴァックデータベース理論の特徴を僕は「驚嘆すべき単純さだ」と言っていますが、圏論を使っているというだけの理由で、「関係データモデルのほうが分かりやすいんじゃないの?」と思っている人はいるでしょう。いいえっ、関係データモデルは複雑で難解です。いったんスピヴァック理論に慣れてしまえば、関係データモデルが無駄に晦渋だったことが分かるでしょう。この記事は、その無駄な晦渋さ=アホらしさを
絵を使って解き明かします。

若干あおり気味の口調なので、より理論的な背景は昨日の記事で確認してください。

内容

  1. 例題:勤務先の電話番号を知る
  2. スピヴァックのモデルでは
  3. 関係データモデルではどうなる
  4. 主キー/外部キーはハードウェアのメモリ番地のようなもの
  5. デイヴィッド・スピヴァックのこと

例題:勤務先の電話番号を知る

ある会社が3つの営業所、例えば東京、千葉、大阪の営業所を持っているとします。この会社に100人の従業員がいるとしましょう。どの従業員も、東京、千葉、大阪のいずれかの営業所に勤務しています。どの営業所にも当然に電話があります。営業所ごとの代表番号はただ1つに決まっています。

従業員情報をレコードとするデータベーステーブルと、営業所情報をレコードとするデータベーステーブルがあるとします。このデータベースを使って、とある従業員の勤務先電話番号を調べることを考えましょう。

スピヴァックのモデルでは

スピヴァックのデータモデルは、集合と写像しか使いません*1

従業員テーブルは100個の要素を持つ集合です。営業所テーブルは3個の要素を持つ集合です。各従業員には勤務先営業所が決まっているので、「従業員 → 営業所」という写像が存在します。同様に、各営業所には(代表)電話番号が決まっているので、「営業所 → 電話番号」という写像があります。この状況を絵に描くと次のようになります*2

このなかに登場する2つの写像を結合(合成、composition)すると「従業員の勤務先電話番号」が得られます。結合により得られた写像を破線矢印で描くと次の絵になります。

なにか難しいことがありますか? なにか不思議なことがありますか?

これがスピヴァック流の情報モデリングの基本です。

関係データモデルではどうなる

関係データモデルでは主キーを要求するので従業員番号を付けることにします。これは、「従業員 → 番号(整数値)」という写像になります。営業所にも適当なコードを振ります。「営業所 → コード(何らかの記号文字列)」という写像ですね。従業員の勤務先は、営業所コードという代理を使って示されます。この状況を絵に描くと次のようです。

「従業員の勤務先電話番号」を得るには、準備としてまず、「従業員の勤務先コード=営業所のコード」という等値条件によりテーブルのジョインを作ります。ジョインというは、集合の直積(ペアの全体)を作ってから条件で絞り込んで部分集合を取ることです。次の絵のようになります。「×」は集合の直積を表す記号です。

「成分射影」という言葉が出てきますが、これは (従業員レコード, 営業所レコード) というペアから、その第一成分である従業員レコードと、第ニ成分である営業所レコードを取り出す写像のことです。

この準備をしただけでは、まだ「従業員 → 勤務先営業所」という写像が構成できていません。従業員の代理である番号をキーとして、ジョインにより作ったテーブルをルックアップ(探索)する必要があります。ルックアップにより見つかったジョインテーブル内のレコードから、その営業所成分を取り出すことにより、「従業員 → 勤務先営業所」という対応が得られます。一般的には、この対応は 1:n となります(なので、変わった形の矢印で描いています)。

上の絵の変わった形の破線矢印が「従業員 → 勤務先営業所」ですが、勤務先も(代表)電話番号も一意的であることから、この対応は写像となります。途中の仕掛けは省略すると、次の絵となります。

ここまで来てやっと、スピヴァック・モデルの最初の状態を実現できます。ナニヤラカニヤラ・ゴニョゴニョして組み立てた「従業員 → 勤務先営業所」に、「営業所 → 電話番号」を結合するステップはスピヴァック・モデルと同じです。

主キー/外部キーはハードウェアのメモリ番地のようなもの

同じことをするのに、なんで関係データモデルでは、もって回ったシチメンドクサイことをしなくてはならないのでしょう? それは、実行の仕掛け・手段が露骨に見えているからです。ゴタゴタした準備の部分を見ないで最後のステップだけなら、スピヴァック流モデルも関係データモデルも変わりがありません。

「主キー/外部キーというのは、ハードウェアのメモリ番地のようなものじゃないか」と僕は思うのですよ。データブロックであれ機械語手続きであれ、メモリのどこかに配置され、その先頭番地で識別されます。コンピュータはメモリ番地なしではまったく動作しません。その意味では極めて重要な概念です。また、かつては生のメモリ番地を人間が意識したり手で書いたりという時代もありました。

現在でも、「プログラミングするなら、メモリ番地の知識もあったほうがいい」というのはまんざら嘘ではありません。ですが、多くのケースではメモリ番地なんてドーデモイイわけで、「生のメモリ番地を人間が意識したり手で書いたり」なんてジジイのノスタルジアに過ぎません。余程低水準のバイナリハックでもない限りそのテの知識は不要です。もし「生のメモリ番地」を手で制御することに拘っていたら高級言語の恩恵をすべて拒絶・放棄することになります。

関係データモデルは、その誕生の時期には抽象度が高いものだったのでしょうが、現時点から見れば、(比喩的に言って)メモリ番地/レジスタ/スタックなどが生で露出しているアセンブラみたいなものです。その証左は、たかが写像の合成をするのに、ジョインやルックアップという裏方のウザい仕掛けが見えてしまうことです。

デイヴィッド・スピヴァックのこと

「関係データモデルは、なんとか理論に基づき、数学的に厳密でナンチャラかんちゃら」という能書きはよく目にします。口承文芸の冒頭フレーズのようなものです。それって、ほんとですか? ほんとに数学的に厳密ですか?

主キー/外部キーとは、仕掛けが露出しているだけだ、とは今述べました。ナントカ正規形ってチャント定義されていますか? そもそも、なんで正規化するんですか? もっとスッキリした定式化があるんじゃないですか? と、こんな素朴な疑問(あるいは不満)は、関係データベースがあまりにも成功し普及した現状では口に出しにくい雰囲気さえあります。

デイヴィッド・スピヴァックの理論を少しかじってみると、例の口承文芸フレーズは眉唾だと気づきます。データベース理論は経年劣化でボロボロです。スピヴァックは既存の理論や仕様を批判するようなことはほとんど口にしません(ちょっと歯痒いくらいに)。彼は「××はダメだ。だから、僕は○○を考えた」とはアピールせず「僕は○○を考えました」と言うだけです。そして黙々と、データベース理論をシンプルでモダンなものに書き換えています。だから陰ながら応援せずにはいられないのです -- デイヴィッド君がんばれ。

*1:正確に言えば、ある圏Cを設定して、その圏の対象と射です。圏Cを取り替えたり、複数の圏C1, ..., Cnを同時に考えたりもできます。

*2:この絵の描き方は、スピヴァックのologを参考にしています。ologでは、ノードを四角い箱で描きますけどね。