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

＜＜実習：住所録データベースを考える＞＞


－－さて、住所録の目的は何だろう？

「目的？　住所録に目的なんて無いわ。」

－－そんなことないだろう。いろいろな目的に使うはずだ。電話をかけたり、手紙を書いたり、冠婚葬祭のお知らせとか、年賀状・・

「じゃあ、電話帳と、年賀状の宛名印刷を主な目的とした住所録。」

－－ＯＫ。じゃ、まず、必要なエンティティと属性を洗いだそう。

「なんか大げさねえ。要するに、人がいて、その人の名前と住所と電話番号があればいいんでしょ？」

－－電話番号って、自宅の？　それとも勤務先の？

「それは両方あった方がいいわ。・・っていうことは、こうなるのね。」

　＋－－－－－－－－＋
　｜　住所録　　　　｜
　＋－－－－－－－－＋
　｜名前　　　　　　｜
　｜住所　　　　　　｜
　｜自宅電話番号　　｜
　｜勤務先電話番号　｜
　＋－－－－－－－－＋

－－キー属性は何？　この表の中で、辞書における「見出し語」に相当する属性はどれだい。

「何って、名前に決まっているじゃない！」

－－同姓同名があったら？　同じものが二つ以上あると、キー属性には使えないよ。

「私の知り合いには今のところいないわ。」

－－もし出てきたらどうする？　でてこないという保証はないね。

「やな人ねえ。じゃ、電話番号にしたらどうかしら、自宅の。これを見出しにするの。これだったら各人で必ず異なるはずだわ。」

－－ふうん。でも、夫婦の二人とも知り合いの時はどうするの？　自宅の電話番号は同じだから、二人のレコードが同じキーの値になるよ。」

「意地悪！　じゃ、どうしろっていうの？」

－－キーの値が夫婦同士で重ならないように、個人個人に整理番号をつけてキーにするしかないね。

「いやよ、そんなの。まるで背番号じゃない！　私は国民総背番号制に反対なのに、何で自分の住所録のためにつけなきゃならないの。」

－－ＯＫ、じゃ、この問題は後回しにしよう。ところで、仕事の上だけのつきあいの人で、会社に年賀状を出さなきゃならない人はいないかい？

「いるわよ。そしたら、住所のところに会社の住所を入れればいいじゃない。」

－－自宅と勤務先と両方知っている人はどうする。そういう人もいるじゃないか。

「・・そうねえ。そうしたら、住所を二つ持ったらどうかしら、自宅と勤務先の。」

－－なるほど。その場合はさあ、年賀状を印刷するプログラムはどちらの住所を印刷したらいいか迷っちゃうぜ。

「じゃあ、どうするの？」

－－自宅住所と勤務先住所の二つのフィールドの中で、どちらを年賀状の宛先に使うかを判断するためのフィールドを別に持つといい。こういう、YesかNoかの判断をするためのスイッチみたいなフィールドをフラッグと呼ぶことがある。手旗信号の旗だ。

「わかった。そしたら、結論は、こうね。」

　＋－－－－－－－－＋
　｜　　住所録　　　｜
　＋－－－－－－－－＋
　｜●整理番号　　　｜
　｜　名前　　　　　｜
　｜　自宅住所　　　｜
　｜　自宅電話番号　｜
　｜　勤務先住所　　｜
　｜　勤務先電話番号｜
　｜　宛先フラッグ　｜
　＋－－－－－－－－＋

－－そうだね。これで一応、電話帳兼住所録になる。

「でも、この整理番号制って、どうしてもやだな・・。それに、ちょっと待ってよ。これじゃ、知り合いの夫婦のところに出す年賀状は、二人別々になっちゃうわ。」

－－たしかにそうだな。

「うーん・・あ、わかった！　そのときは、夫婦二人の名前を、『名前』のところに入れればいいのよ。データを夫婦単位にするの。それに、そうすれば自宅電話番号をキーにできるから、へんてこな整理番号なんていらなくなるわ。」

－－なるほど。でも、夫婦では勤務先の住所や電話番号は違うよ。

「だったら、夫婦それぞれの勤務先についてのフィールドを持てばいいのよ。これで完成。どうお、先生？」

　＋－－－－－－－－－－＋
　｜　　　　住所録　　　｜
　＋－－－－－－－－－－＋
　｜　名前　　　　　　　｜（夫婦の場合は両方の名前を入れる）
　｜　自宅住所　　　　　｜
　｜●自宅電話番号　　　｜
　｜　夫の勤務先住所　　｜
　｜　夫の勤務先電話番号｜
　｜　妻の勤務先住所　　｜
　｜　夫の勤務先電話番号｜
　｜　宛先フラッグ　　　｜
　＋－－－－－－－－－－＋

－－なるほど。なかなか良くできているね。夫婦二人を単位として、１レコードに押し込めるというのがアイデアだな。ぼくも思いつかなかったよ。

「でしょ？　でも、・・ってことは、あなたの考えてる正解とは違うわけ？」

－－ぼくは実はもう自分用のデータベースを作ってあるんだ。それは、こうしている：

　＋－－－－－－－－－＋　　　　　　　＋－－－－－－－－＋
　｜　　個人住所録　　｜　　　　　　　｜　勤務先住所録　｜
　＋－－－－－－－－－＋　　　　　　　＋－－－－－－－－＋
　｜●整理番号　　　　｜　　　＋－－> ｜●勤務先コード　｜
　｜　名前　　　　　　｜　　　｜　　　｜　勤務先会社名　｜
　｜　配偶者氏名　　　｜　　　｜　　　｜　勤務先事業所名｜
　｜　自宅住所　　　　｜　　　｜　　　｜　勤務先住所　　｜
　｜　自宅電話番号　　｜　　　｜　　　｜　代表番号　　　｜
　｜　勤務先コード　　｜<<－－＋ 　　＋－－－－－－－－＋
　｜　勤務先部署・肩書｜
　｜　勤務先電話番号　｜
　｜　宛先フラッグ　　｜
　＋－－－－－－－－－＋

「何、これ。わたしのと全然ちがうじゃない。」

－－そう。どうしてこうなっているかというと、まず、ぼくの場合は会社単位のつきあいの人が圧倒的に多い。それと、この業界は転職や会社の引越、それも事業部単位での引越が多い。勤務先の住所を個人のレコードに書き込んでしまうと、大勢のレコードを直さなくてはならなくなる。だから勤務先のエンティティを独立させたんだ。

「これが正解なの？」

－－いや、君のは君ので正しい。こういう問題は正解は一つだけではないんだ。さっき、事実認識は人によって違うと言っただろ。
　ぼくのつきあいの範囲と君のつきあいの範囲は違う。君は翻訳業で個人事業者が中心だから、夫婦単位の知り合いが多い。ぼくは会社員で変転の多いＩＴ業界が中心だ。だから住所録データベースのデザインが違うのは当然さ。ぼくのデザインを君に押しつければ窮屈になり、逆をやればぼくが面倒になる。事物のデータへの翻訳のしかたは一通りとは限らなくて、データの性質と目的をよく考えながらデザインしなければいけないんだ。それにはけっこうスキルがいることはわかってくれたかい？

「ふーん。でも、こんな、フィールドだとかエンティティだとかって、普通の人は覚える必要あるのかしら？」

－－まあ用語は忘れてもいいよ。でも基本的な概念は知っておいても損しない。パソコンの構造やプログラミング言語について勉強するよりも、ＩＴを理解するにはずっと有益だ。

「でもね。住所録なんかはいいでしょうけれど、こんなぎちぎちで窮屈な形式にしばられないで、もっと自由に情報をデータにする方法はないものかしら。」

－－“自由”の意味にもよると思うけれど、あるといえばあるよ。それはインターネットの世界でホームページを作るHTMLというやつさ。ホームページも一種のデータベースだけれど、これはかなりフレキシブルな構造を作ることができる。だから情報を表現するのに向いているんだ。

「インターネット！　そうよね。やっと話がＩＴっぽくなってきたじゃない。データについての石頭な講義はもうおしまいにして、もっと情報よりの話が聞きたいわ。」

－－やれやれ、わかったよ。それじゃお腹もくちたことだし、車に戻ろう。別の高速に乗り換えることでもあるし、話も少し情報産業の方向に切り替えようか。