「ITって、何？」 インターチェンジ（１／２）　『データをデザインする方法』

＜＜　デザインの図と見方　＞＞
（今回はインターミッションです。データ・モデリングに興味のない方はとばしても結構です）

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

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

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

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

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

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

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

「そうお？」

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

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

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

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

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

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

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

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

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

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

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

「うん。」

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

「あ、そうね。」

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

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

　＋－－－－－－－－＋
　｜　　商品マスタ　｜
　＋－－－－－－－－＋
　｜　商品名　　　　｜
　｜●JANコード 　　｜
　｜　単価　　　　　｜
　｜　仕入先名　　　｜
　｜　仕入先電話番号｜
　＋－－－－－－－－＋

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

　＋－－－－－－－－＋　　　　　　　＋－－－－－－－－＋
　｜　　商品マスタ　｜　　　　　　　｜　仕入先マスタ　｜
　＋－－－－－－－－＋　　　　　　　＋－－－－－－－－＋
　｜　商品名　　　　｜　　　　＋ー＞｜●仕入先コード　 ｜
　｜●JANコード 　　｜　　　　｜　　｜　仕入先名　　　｜
　｜　単価　　　　　｜　　　　｜　　｜　仕入先電話番号｜
　｜　仕入先コード　｜＜＜ーー＋　　＋－－－－－－－－＋
　＋－－－－－－－－＋

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

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

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

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

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

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

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

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

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

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

（つづく）