－－デザインの図と見方－－ (2002/4/14 発信)
食後のコーヒーに手をのばしながら、彼女はいった。
「ふう、やっと人心地ついたわ。・・さっきはなんだか専門用語の羅列でおどか
され続けたみたい。でもねえ、もしもデータベースの文法ってのが、あなたのい
うように四角四面で単純なものなら、誰でも簡単にデータの世界への翻訳ができ
てしまうんじゃない？」
－－まあ、簡単かどうかはともかく、ある程度の翻訳はできるだろうね。少なく
とも、ちょっと慣れれば翻訳の結果を理解することはできると思う。建物のフロ
アプランをみて理解できるようにね。
「でも、フロアプランと違って、ここには創意工夫の入る余地はあまりないんじ
ゃない？ ふつうの言語の翻訳の世界だったら上手へたがあるけれど、このデー
タベースの翻訳の方は単純だもの。」
－－おいおい、冗談はやめてくれ、このデータ・モデリングの世界だって上手へ
たはものすごくあるよ。いや、ふつうの翻訳以上に、人による差は大きいと思う。
「あら、どうして？ 現実の世界にある事物の『属性』と『関係』を、単にそれ
ぞれ、えーと、マスタ・テーブルだっけ？ それのフィールドと、参照の関係に
置きかえるだけでしょ？ すっごく機械的で、主観的な判断とか曖昧さとかが入
り込むすきまはなさそうに思えるけれどな。」
－－馬鹿いわんでくれ。そんなに機械的であってたまるか。
「そうお？」
－－そうさ。事物とその属性って簡単に言ってくれるけれど、データの対象とな
る事実の捉え方はそんなに自明じゃない。
「そうかしら。客観的事実は事実だと思うけれど？ ＩＴは事実に関する道具だ、
ってあなたさっき宣言したばかりじゃない。」
－－客観的事実は一つしかないかもしれないけれど、その記述のしかたは多様だ
よ。
「なんだか哲学の講義みたいね。」
－－だって認識論だもん。ＩＴってじつは西洋哲学の子供なんだ。非嫡子かもし
れないけどさ、実用の道具だからね。
「あらまあ高尚だこと。でもそれじゃ説明になっていないわよ」
－－たとえば、新聞記事の事を考えてごらん。あるいは歴史の教科書でもいいか
な。客観的事実ってのは限りなく多様な説明が可能なものだ。
たとえばどこかに事件があったとする。公害にまつわる経済事件にしようか。
記者が問題をおこした会社に直行する。現場で色々な事を取材する。舞台となっ
た会社はどういう会社か。本社の所在地からはじめて、社長の名前、年商、従業
員の数、業種、おもな商品・・その会社に関連する事がらは際限なくある。
でも、そのすべてを記事に書きはしない。記者はその中から、事件の記述に必
要と思われる事を、自分で判断してえらぶわけだ。経済紙の記者なら、その事件
が業界に与える影響を考えて、市場のシェアだとか株価を中心に書くだろう。で
も、市民運動に近い立場の雑誌記者なら、その会社が消費社や地域に対してとっ
てきた態度や、政治とのつながりに注目するかもしれない。でき上がる記事は、
同じ事件を対象にしてもまったく違う。客観的事実は一つしかないとしても、さ。
「人はそれを報道の偏向とよぶんじゃないの？」
－－そうだろうか？ だとしたら、偏向のない報道なんてありえないんじゃない
かとぼくは思う。記事のスペースは有限なのに、事物が持つ属性はのほうは限り
なく沢山ある。その属性の取捨選択や焦点のあて方は、記述の目的や関心のあり
方に応じて違っても当然だろう。
話がへんな方向に行っちゃったけれど、データベースを設計するときにも、ど
の属性を選んでどれを捨てるか、事物の捨象のしかたは人によって個性が出る。
かなりスキルの差が出るところだ。翻訳と同様、うまいへたがあるのさ。
「その、うまい下手って、どういうところにあらわれるの？」
－－下手だとね、データに無理や無駄が多くなって、使いにくくなる。たとえば
ね、さっきのコンビニのデータの例でいけば、商品マスタの中に仕入先の電話番
号が入っていたろ、最初？
「うん。」
－－あのままだとね、もし、ある仕入先が引っ越して電話番号が変わったとき、
その仕入先から買っているすべての商品のレコードについて、データを直さなく
ちゃならなくなる。商品が１００個あったら、１００ヶ所の修正だ。間違える可
能性がすごく高い。しかし、もし仕入先のマスタが独立していたら、直すところ
はたった一ヶ所で無駄がない。
「あ、そうね。」
－－これはほんの一例。ソフトの良し悪しの半分以上は、データベースの設計の
良し悪しで決まるんだ。へんてこなデータ構造になっていたら、ちょうど建物の
土台の形がゆがんでいるのと同じで、その上にすなおで頑丈なビルを建てること
なんてできやしない。
たぶん、普通の人は、ソフトを評価するときには画面やプリントアウトの見た
目で使いやすさをはかるだろう。それはそれで間違いじゃないけれど、一面でし
かない。建物を、外観だけで判断するようなものだ。
ぼくらプロのＩＴ屋は、むしろデータベースの構造を見る。ちょうど建築士が
設計図から構造を判断するようにね。
「さっきの、四角い表をみるわけ？」
－－いや、あれは具体的なデータの入っている表だよね。そうじゃなくて、デー
タの入れ物、器としてのデザインを見るんだ。・・ちょっとその紙を貸して。あ
あ、サンキュ。図を書いて説明しよう。
たとえばね、さっきの例で言えば、最初のデザインは、こうだ：
（注：以下の図は等幅のフォントでご覧ください）
+——————+
| 商品マスタ |
+——————+
| 商品名 |
|●JANコード |
| 単価 |
| 仕入先名 |
| 仕入先電話番号 |
+——————+
これに対して、２番目の、仕入先マスタを独立させたデザインは、
+——————+ +——————+
| 商品マスタ | | 仕入先マスタ |
+——————+ +——————+
| 商品名 | +—> |●仕入先コード |
|●JANコード | | | 仕入先名 |
| 単価 | | | 仕入先電話番号 |
| 仕入先コード | <<—–+ +——————+
+——————+
という風に表現できる。
「・・何、これ？」
－－エンティティとリレーション（関係）を表現した図で、頭文字をとって「Ｅ
－Ｒ図」と呼ばれてる。それぞれのエンティティとその属性をまとめて四角で囲
ってある。●のついているのはキーとなる属性だ。矢印は参照関係を示している。
「矢印が<<—>ってなっていて右左の形が違うのはなぜ？」
－－これは、仕入先コードという属性が商品マスタと仕入先マスタの間で多対一
の関係になっていることを示している。まあ、このＥ－Ｒ図の書き方はいろいろ
流儀があるんだけれど、これはその簡単なサンプルだ。
「さっきみたいに口で説明されるよりは、この方がたしかに分かりやすいけれど
・・あなたのＩＴの話って、ちっともプログラムのことが出てこないのね。」
－－プログラムは裏方でね。いわば、データが主ならプログラムは従なんだ。デ
ータ構造が決まればプログラムは自ずと決まる。建物のレイアウトが決まれば空
調のダクトやエレベーターの通し方が自ずと決まるようにね。それに、プログラ
ムは計算機のハードが進歩すればどんどん変わるけれど、データは生き残る。デ
ータの方がソフトよりもずっと寿命が長いんだ。
「こんな図だったら、私でもかけそうな気がするけどな。」
－－そうかい？ それじゃ、試しに書いてみる？ 例は何にしようか。
「住所録なんてどうかしら。」
－－住所録。いいね。じゃ試しにやってみよう。
(c) 2002, Tomoichi Sato
（この話の登場人物はすべて架空のものです）
