インターチェンジ(1/2) 『データをデザインする方法』

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

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


「ふう、やっと人心地ついたわ。・・さっきはなんだか専門用語の羅列でおどか

され続けたみたい。でもねえ、もしもデータベースの文法ってのが、あなたのい

うように四角四面で単純なものなら、誰でも簡単にデータの世界への翻訳ができ

てしまうんじゃない?」


--まあ、簡単かどうかはともかく、ある程度の翻訳はできるだろうね。少なく

とも、ちょっと慣れれば翻訳の結果を理解することはできると思う。建物のフロ

アプランをみて理解できるようにね。


「でも、フロアプランと違って、ここには創意工夫の入る余地はあまりないんじ

ゃない? ふつうの言語の翻訳の世界だったら上手へたがあるけれど、このデー

タベースの翻訳の方は単純だもの。」


--おいおい、冗談はやめてくれ、このデータ・モデリングの世界だって上手へ

たはものすごくあるよ。いや、ふつうの翻訳以上に、人による差は大きいと思う。


「あら、どうして? 現実の世界にある事物の『属性』と『関係』を、単にそれ

ぞれ、えーと、マスタ・テーブルだっけ? それのフィールドと、参照の関係に

置きかえるだけでしょ? すっごく機械的で、主観的な判断とか曖昧さとかが入

り込むすきまはなさそうに思えるけれどな。」


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


「そうお?」


--そうさ。事物とその属性って簡単に言ってくれるけれど、データの対象とな

る事実の捉え方はそんなに自明じゃない。


「そうかしら。客観的事実は事実だと思うけれど? ITは事実に関する道具だ、

ってあなたさっき宣言したばかりじゃない。」


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

よ。


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


--だって認識論だもん。ITってじつは西洋哲学の子供なんだ。非嫡子かもし

れないけどさ、実用の道具だからね。


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


--たとえば、新聞記事の事を考えてごらん。あるいは歴史の教科書でもいいか

な。客観的事実ってのは限りなく多様な説明が可能なものだ。

 たとえばどこかに事件があったとする。公害にまつわる経済事件にしようか。

記者が問題をおこした会社に直行する。現場で色々な事を取材する。舞台となっ

た会社はどういう会社か。本社の所在地からはじめて、社長の名前、年商、従業

員の数、業種、おもな商品・・その会社に関連する事がらは際限なくある。

 でも、そのすべてを記事に書きはしない。記者はその中から、事件の記述に必

要と思われる事を、自分で判断してえらぶわけだ。経済紙の記者なら、その事件

が業界に与える影響を考えて、市場のシェアだとか株価を中心に書くだろう。で

も、市民運動に近い立場の雑誌記者なら、その会社が消費社や地域に対してとっ

てきた態度や、政治とのつながりに注目するかもしれない。でき上がる記事は、

同じ事件を対象にしてもまったく違う。客観的事実は一つしかないとしても、さ。


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


--そうだろうか? だとしたら、偏向のない報道なんてありえないんじゃない

かとぼくは思う。記事のスペースは有限なのに、事物が持つ属性はのほうは限り

なく沢山ある。その属性の取捨選択や焦点のあて方は、記述の目的や関心のあり

方に応じて違っても当然だろう。

 話がへんな方向に行っちゃったけれど、データベースを設計するときにも、ど

の属性を選んでどれを捨てるか、事物の捨象のしかたは人によって個性が出る。

かなりスキルの差が出るところだ。翻訳と同様、うまいへたがあるのさ。


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


--下手だとね、データに無理や無駄が多くなって、使いにくくなる。たとえば

ね、さっきのコンビニのデータの例でいけば、商品マスタの中に仕入先の電話番

号が入っていたろ、最初?


「うん。」


--あのままだとね、もし、ある仕入先が引っ越して電話番号が変わったとき、

その仕入先から買っているすべての商品のレコードについて、データを直さなく

ちゃならなくなる。商品が100個あったら、100ヶ所の修正だ。間違える可

能性がすごく高い。しかし、もし仕入先のマスタが独立していたら、直すところ

はたった一ヶ所で無駄がない。


「あ、そうね。」


--これはほんの一例。ソフトの良し悪しの半分以上は、データベースの設計の

良し悪しで決まるんだ。へんてこなデータ構造になっていたら、ちょうど建物の

土台の形がゆがんでいるのと同じで、その上にすなおで頑丈なビルを建てること

なんてできやしない。

 たぶん、普通の人は、ソフトを評価するときには画面やプリントアウトの見た

目で使いやすさをはかるだろう。それはそれで間違いじゃないけれど、一面でし

かない。建物を、外観だけで判断するようなものだ。

 ぼくらプロのIT屋は、むしろデータベースの構造を見る。ちょうど建築士が

設計図から構造を判断するようにね。

 

「さっきの、四角い表をみるわけ?」


--いや、あれは具体的なデータの入っている表だよね。そうじゃなくて、デー

タの入れ物、器としてのデザインを見るんだ。・・ちょっとその紙を貸して。あ

あ、サンキュ。図を書いて説明しよう。

 たとえばね、さっきの例で言えば、最初のデザインは、こうだ:

(注:以下の図は等幅のフォントでご覧ください)


 +——————+

 |  商品マスタ  |

 +——————+

 | 商品名     |

 |●JANコード    |

 | 単価      |

 | 仕入先名    |

 | 仕入先電話番号 |

 +——————+


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

 


 +——————+       +——————+

 |  商品マスタ  |       | 仕入先マスタ  |

 +——————+       +——————+

 | 商品名     |    +—> |●仕入先コード  |

 |●JANコード    |    |   | 仕入先名    |

 | 単価      |    |   | 仕入先電話番号 |

 | 仕入先コード  | <<—–+   +——————+

 +——————+


 という風に表現できる。

 

「・・何、これ?」


--エンティティとリレーション(関係)を表現した図で、頭文字をとって「E

-R図」と呼ばれてる。それぞれのエンティティとその属性をまとめて四角で囲

ってある。●のついているのはキーとなる属性だ。矢印は参照関係を示している。


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


--これは、仕入先コードという属性が商品マスタと仕入先マスタの間で多対一

の関係になっていることを示している。まあ、このE-R図の書き方はいろいろ

流儀があるんだけれど、これはその簡単なサンプルだ。


「さっきみたいに口で説明されるよりは、この方がたしかに分かりやすいけれど

・・あなたのITの話って、ちっともプログラムのことが出てこないのね。」


--プログラムは裏方でね。いわば、データが主ならプログラムは従なんだ。デ

ータ構造が決まればプログラムは自ずと決まる。建物のレイアウトが決まれば空

調のダクトやエレベーターの通し方が自ずと決まるようにね。それに、プログラ

ムは計算機のハードが進歩すればどんどん変わるけれど、データは生き残る。デ

ータの方がソフトよりもずっと寿命が長いんだ。


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


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


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


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



(c) 2002, Tomoichi Sato

              (この話の登場人物はすべて架空のものです)

Follow me!