--デザインの図と見方-- (2002/4/14 発信)

 食後のコーヒーに手をのばしながら、彼女はいった。

「ふう、やっと人心地ついたわ。・・さっきはなんだか専門用語の羅列でおどか
され続けたみたい。でもねえ、もしもデータベースの文法ってのが、あなたのい
うように四角四面で単純なものなら、誰でも簡単にデータの世界への翻訳ができ
てしまうんじゃない?」

--まあ、簡単かどうかはともかく、ある程度の翻訳はできるだろうね。少なく
とも、ちょっと慣れれば翻訳の結果を理解することはできると思う。建物のフロ
アプランをみて理解できるようにね。

「でも、フロアプランと違って、ここには創意工夫の入る余地はあまりないんじ
ゃない? ふつうの言語の翻訳の世界だったら上手へたがあるけれど、このデー
タベースの翻訳の方は単純だもの。」

--おいおい、冗談はやめてくれ、このデータ・モデリングの世界だって上手へ
たはものすごくあるよ。いや、ふつうの翻訳以上に、人による差は大きいと思う。

「あら、どうして? 現実の世界にある事物の『属性』と『関係』を、単にそれ
ぞれ、えーと、マスタ・テーブルだっけ? それのフィールドと、参照の関係に
置きかえるだけでしょ? すっごく機械的で、主観的な判断とか曖昧さとかが入
り込むすきまはなさそうに思えるけれどな。」

--馬鹿いわんでくれ。そんなに機械的であってたまるか。

「そうお?」

--そうさ。事物とその属性って簡単に言ってくれるけれど、データの対象とな
る事実の捉え方はそんなに自明じゃない。

「そうかしら。客観的事実は事実だと思うけれど? ITは事実に関する道具だ、
ってあなたさっき宣言したばかりじゃない。」

--客観的事実は一つしかないかもしれないけれど、その記述のしかたは多様だ
よ。

「なんだか哲学の講義みたいね。」

--だって認識論だもん。ITってじつは西洋哲学の子供なんだ。非嫡子かもし
れないけどさ、実用の道具だからね。

「あらまあ高尚だこと。でもそれじゃ説明になっていないわよ」

--たとえば、新聞記事の事を考えてごらん。あるいは歴史の教科書でもいいか
な。客観的事実ってのは限りなく多様な説明が可能なものだ。
 たとえばどこかに事件があったとする。公害にまつわる経済事件にしようか。
記者が問題をおこした会社に直行する。現場で色々な事を取材する。舞台となっ
た会社はどういう会社か。本社の所在地からはじめて、社長の名前、年商、従業
員の数、業種、おもな商品・・その会社に関連する事がらは際限なくある。
 でも、そのすべてを記事に書きはしない。記者はその中から、事件の記述に必
要と思われる事を、自分で判断してえらぶわけだ。経済紙の記者なら、その事件
が業界に与える影響を考えて、市場のシェアだとか株価を中心に書くだろう。で
も、市民運動に近い立場の雑誌記者なら、その会社が消費社や地域に対してとっ
てきた態度や、政治とのつながりに注目するかもしれない。でき上がる記事は、
同じ事件を対象にしてもまったく違う。客観的事実は一つしかないとしても、さ。

「人はそれを報道の偏向とよぶんじゃないの?」

--そうだろうか? だとしたら、偏向のない報道なんてありえないんじゃない
かとぼくは思う。記事のスペースは有限なのに、事物が持つ属性はのほうは限り
なく沢山ある。その属性の取捨選択や焦点のあて方は、記述の目的や関心のあり
方に応じて違っても当然だろう。
 話がへんな方向に行っちゃったけれど、データベースを設計するときにも、ど
の属性を選んでどれを捨てるか、事物の捨象のしかたは人によって個性が出る。
かなりスキルの差が出るところだ。翻訳と同様、うまいへたがあるのさ。

「その、うまい下手って、どういうところにあらわれるの?」

--下手だとね、データに無理や無駄が多くなって、使いにくくなる。たとえば
ね、さっきのコンビニのデータの例でいけば、商品マスタの中に仕入先の電話番
号が入っていたろ、最初?

「うん。」

--あのままだとね、もし、ある仕入先が引っ越して電話番号が変わったとき、
その仕入先から買っているすべての商品のレコードについて、データを直さなく
ちゃならなくなる。商品が100個あったら、100ヶ所の修正だ。間違える可
能性がすごく高い。しかし、もし仕入先のマスタが独立していたら、直すところ
はたった一ヶ所で無駄がない。

「あ、そうね。」

--これはほんの一例。ソフトの良し悪しの半分以上は、データベースの設計の
良し悪しで決まるんだ。へんてこなデータ構造になっていたら、ちょうど建物の
土台の形がゆがんでいるのと同じで、その上にすなおで頑丈なビルを建てること
なんてできやしない。
 たぶん、普通の人は、ソフトを評価するときには画面やプリントアウトの見た
目で使いやすさをはかるだろう。それはそれで間違いじゃないけれど、一面でし
かない。建物を、外観だけで判断するようなものだ。
 ぼくらプロのIT屋は、むしろデータベースの構造を見る。ちょうど建築士が
設計図から構造を判断するようにね。
 
「さっきの、四角い表をみるわけ?」

--いや、あれは具体的なデータの入っている表だよね。そうじゃなくて、デー
タの入れ物、器としてのデザインを見るんだ。・・ちょっとその紙を貸して。あ
あ、サンキュ。図を書いて説明しよう。
 たとえばね、さっきの例で言えば、最初のデザインは、こうだ:
(注:以下の図は等幅のフォントでご覧ください)

 +——————+
 |  商品マスタ  |
 +——————+
 | 商品名     |
 |●JANコード    |
 | 単価      |
 | 仕入先名    |
 | 仕入先電話番号 |
 +——————+

 これに対して、2番目の、仕入先マスタを独立させたデザインは、
 

 +——————+       +——————+
 |  商品マスタ  |       | 仕入先マスタ  |
 +——————+       +——————+
 | 商品名     |    +—> |●仕入先コード  |
 |●JANコード    |    |   | 仕入先名    |
 | 単価      |    |   | 仕入先電話番号 |
 | 仕入先コード  | <<—–+   +——————+
 +——————+

 という風に表現できる。
 
「・・何、これ?」

--エンティティとリレーション(関係)を表現した図で、頭文字をとって「E
-R図」と呼ばれてる。それぞれのエンティティとその属性をまとめて四角で囲
ってある。●のついているのはキーとなる属性だ。矢印は参照関係を示している。

「矢印が<<—>ってなっていて右左の形が違うのはなぜ?」

--これは、仕入先コードという属性が商品マスタと仕入先マスタの間で多対一
の関係になっていることを示している。まあ、このE-R図の書き方はいろいろ
流儀があるんだけれど、これはその簡単なサンプルだ。

「さっきみたいに口で説明されるよりは、この方がたしかに分かりやすいけれど
・・あなたのITの話って、ちっともプログラムのことが出てこないのね。」

--プログラムは裏方でね。いわば、データが主ならプログラムは従なんだ。デ
ータ構造が決まればプログラムは自ずと決まる。建物のレイアウトが決まれば空
調のダクトやエレベーターの通し方が自ずと決まるようにね。それに、プログラ
ムは計算機のハードが進歩すればどんどん変わるけれど、データは生き残る。デ
ータの方がソフトよりもずっと寿命が長いんだ。

「こんな図だったら、私でもかけそうな気がするけどな。」

--そうかい? それじゃ、試しに書いてみる? 例は何にしようか。

「住所録なんてどうかしら。」

--住所録。いいね。じゃ試しにやってみよう。

(c) 2002, Tomoichi Sato
              (この話の登場人物はすべて架空のものです)