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