第１０回　データの世界に文法ってあるの？

－－データの辞書と文法の話－－　(2002/4/06 発信)

－－文法、っていい方が適当かどうかわからないけれど、たとえるならば単語・文・文章にあたるものはそれぞれあるね。文章はどうやってできていて、単語というのが何で、単語をどう並べれば文章になるかの原理がある。

「それがパスカルとかなんとかのコンピュータ言語なのね」

－－あ、それは違う。ぼくがここでいっているのはあくまでもデータの構成原理の話。ぼくはここではパスカルだのコボルだのといったコンピュータ言語の話は一切するつもりはない。PascalもCOBOLももう時代遅れだけれどね、まあそれはさておき。

「え、どうしてなの？　それって違うものなの？」

－－まったく別です。コンピュータ言語というのはね、プログラマという職種の人が、計算機で行う処理の細かな手順を書き留めるためのメモみたいなものだ。つまりプロセス、過程に関する記述。それは機械ならびにプログラマが解釈できればいいもので、普通の人が理解する必要はない。

　これからぼくが説明するのは、データの構造の話で、つまりデータというブロックをつみ上げてデータベースという建物を作るときの考え方だ。どうやってフロアプランやレイアウトを作るか。これは、すくなくとも、その建物を利用する人にはみな関係がある。フロアプランがわからなければ行きたい場所にたどり着けずに迷ってしまうから。

　プログラム言語なんてものは、いってみればエレベーターの制御方法や、空調ダクトをどう通すか、みたいなものだ。これは一般人には関係がない。

「じゃあその、フロアプランの規則を説明して」

－－建物がふつう四角い部屋が集まってできているように、データベースというものも普通は四角い表からなりたっている。

「四角い表、って？」

－－普通にどこにでも見かけるような表さ。たとえば、こんな風な：

商品名　　　　　JANコード　　　単価　　仕入先名　　　　仕入先電話番号

———————————————————————

チョコレート　　4912345670001　192 　　昭和食品（株）　03-3456-1234

キャラメル　　　4906543218046 75 　　（株）三田製菓　03-7654-9000

メロンパン　　　4900223360097 120 　　昭和食品（株）　03-3456-1234

・・・　　　　　・・・　　　　・・　　　・・・　　　　　・・・

　この表はすなわち、さっき説明した事物の世界における、コンビニの「商品」というエンティティに対応している。

「四角はわかったから、運転中にハンドルから両手を放すのはやめて！　それに、いまどきコンビニにキャラメルなんて売ってないわよ。それにメロンパンですって、ふふふ。あなたの頭の中って小学校時代の駄菓子屋から進歩していないんじゃないの。」

－－いいじゃないか、そんなこと！　・・とにかくね。これは商品という事物一つ一つについて、その属性が並んでいるという形式になっている。横に続くそれぞれの行が個々の事物で、縦に並ぶ項目が属性に対応する。

「それがExcelみたいな表計算なのね。」

－－いや、あのね。ここでは当分の間、表計算ソフトのことは忘れてほしい。表計算ソフトというのは表みたいな「見え方」をつくったり計算したりするソフトで、ぼくがここで語っているのは四角い表という論理的な「構造」なんだ。

「なんだかよくわかんない。」

－－混乱しやすいことはみとめる。でも、ここではソフトとかプログラムの話をしているんじゃなくて、その底に横たわっているデータの構造とか「文法」とかの話をしているんだろ？　どうかしばらくの間、表計算ソフトのことは忘れてほしい。

「わかったわ、まだわかんないけど。それでその、属性だっけ、それがどうなったの？」

－－データの四角い表の横１行が、事物の世界では個別のモノに対応する。これをね、データの世界では『レコード』と呼ぶ。さっきまでは、データ１件、とか言わざるをえなかったけれども、これからは１レコード、と呼ぶことにする。それから、事物の世界で属性と呼ばれている、表の縦の列は、データの世界では『フィールド』と呼ぶ。

「Field？　なんで急にそんなところに“平原”が出てくるの？」

－－このフィールドって用語は、はるか昔に、パンチカードでデータを集計していた時代からのなごりでね。カードの１０桁目から２０桁目まで、みたいな区画を意味していた。今ではフィールドやレコードよりも、もっとモダンな用語があるんだけれど、こういう慣習は根強いので、まだぼく自身ももっぱらこう呼んでいる。

「あなただって駄菓子屋時代から進んでいないもの。でもこれ、本当に文法の話？」

－－このレコードが、言葉でいえばセンテンスにあたる。レコードの中の各フィールドの値が、単語に相当する。この単語というのは、前に説明したとおり、定型化されていなければならない。

「定型データの究極の最小単位は選択肢だ、っていってた、あれ？」

－－ご名答。ある定められたメニューがあって、その中から特定の選択肢を一つ選ぶ。数値というのも、前に説明したように選択肢の一種だ。そして、どのフィールドにはどの選択肢が許されているか、メニューを定義しているものが、いわば「辞書」にあたる。

「ふーん。でも、ちょっと待って。あなたがさっきあげた表の例でいくと、値段は数字かもしれないけれど、あとは選択肢でもなんでもないわ。たとえば電話番号。」

－－いい質問だ。電話番号の各桁は、０から９までの数字とハイフンの中から選ばれる。そしてその組みあわせは、一定の条件を満たしている必要がある。全部で１２桁以内、ハイフンは必ず２個、そして最後は必ず４桁の数字が続いている事、など。あるメニューからの選択肢という形をとれないようなものは、「単語」として許される範囲の規則を明確に決めなければならない。これも一種の文法さ。

「もしも規則に反するような単語がデータの中にあったらどうなるの？」

－－データの処理をするプログラムが正常に動かなくなってしまう。たとえばさ、電話番号のデータをつかって、電話を自動的にかけるようなプログラムを組んでいたとしよう。もし数字とハイフン以外の文字が混ざっていたら、電話をかけるモデムという装置が誤動作してしまうだろ。だからふつうは、そういう文法に反するようなデータをユーザが入力しようとしたら、そこで警告のメッセージを出して受け付けない、という風にしておく。

「ふうん。でも、じゃあ商品名の方はどんなルールがあるの？」

－－そう、こういう名前に類するフィールドは、一番規則がゆるやかだ。ここでは、名前に許される文字の種類、たとえばカナだけなのか、漢字も許されるかなどを決め、それから、字数の最大限を決める。２０文字以内、とかね。

「ふーん。でも、最大何文字とかって決めきれないような場合はどうするの？」

－－その場合はたとえば、『終わりの印』を決めておく。何文字でも好きなだけ続けていいけれども、文字列のおしまいである事が分かるような特殊な記号をおいて、それで締めくくる。

「よく外国の雑誌で一つの記事のおしまいを示すためにページの隅にロゴみたいなマークを打っているけれど、あれみたいなものかしら。」

－－かもね。ただし、あれは文章の終わりで単語のおしまいじゃないけれど。

　さて、こうして定型化された単語・すなわちフィールドの値がならんで、一つのセンテンス・つまりレコードを作る。もちろんレコードの中でどのフィールドがどの順番で並ぶのかに関しても、きちんとした規則が必要になる。

　同じ規則で作られた対等なレコードが並んでいる表を、テーブルとよぶ。

「それがさっきの四角い表なの？」

－－そうだ。

「それがさっきの、えーと何だっけ、エンティティに対応するって訳？」

－－そうです。

「つまりそれが翻訳なのね」

－－事物の世界から、データの世界への翻訳です。あるエンティティについて、キーとなる属性と、その他の属性を並べたテーブルは、その事物の『マスタ』とよばれる。たとえばさっきみたいな表は、コンビニで売る商品のマスタ・データなので、「商品マスタ」という風に呼んだりする。

　マスタは一種の辞書だと思えばいい。辞書と同じで、最初に見出し語があり（これがキー）、それに続いて説明の記述（属性）が並んでいる。マスタを引けば、そのエンティティに関するデータを得ることができる。

「こうしてＩＴ屋さんの単純な世界観が、コンピュータの中のデータの構造に翻訳されたというわけね。なんて平板で単純なのかしら。・・そうだ、『関係』の方ははどうなったの？」

－－それはこれから説明する。関係というのはね、あるフィールドの値が選択肢で規定されるときに、それを別のマスタ・テーブルへの参照として表現する事だ。

「え？　もう一度いって。」

－－あのね。さっきの表でいくと、商品の仕入先の名前と電話番号というフィールドがあっただろ？　でもね、これはよく考えてみると、これは商品の属性ではなく、取引先の属性だ。

「たしかにそうね」

－－だから、本当はこんなフィールドを商品マスタの中に抱えているのは論理的におかしい、ってことになる。商品の属性は、どこの会社から仕入れるかということだけに留めるべきだ。そして、仕入先の属性データは、「仕入先」というエンティティのために別のマスタを用意して、そこに格納すべきだろう。たとえば、こんな：

仕入先コード　仕入先名　　　　仕入先電話番号

——————————————–

1001 　昭和食品（株）　03-3456-1234

1002 　（株）三田製菓　03-7654-9000

・・・　　　　・・・　　　　　・・・

　このテーブルにもキー属性が必要だから、「仕入先コード」という背番号をつくることにした。これは各社に対してそれぞれ一つの番号を振りあてている。

「それで商品のマスタの方はどうするの？」

－－商品マスタには、「仕入先名称」や「電話番号」のかわりに、単に「仕入先コード」のみを記録する事にする。つまり、こんな風に：

商品名　　　　　JANコード　　　単価　　仕入先コード

—————————————————

チョコレート　　4912345670001　192 　　1001

キャラメル　　　4906543218046 75 　　1002

メロンパン　　　4900223360097 120 　　1001

・・・　　　　　・・・　　　　・・　　 ・・

　これをみるとわかるとおり、『商品マスタ』と『仕入先マスタ』の二つのエンティティをあらわすテーブルが、「仕入先コード」という共通のフィールドをキーにして“関係づけられて”いる。

　別の言い方をすると、『仕入先マスタ』というテーブルは一種のメニューとして定義されていて、商品の仕入先は、その『仕入先マスタ』からの選択肢になっている。複数の商品が同じ仕入先コードを持つことができるから、ここには多対一の関係が成立していることになる。これが、データベースにおける関係の表現なのさ。

　

「うーん・・なんだか複雑ね。わかったようなわからないような・・」

－－そりゃね、本当だったら何週間もかけて講義するようなデータベースのスキーマの話を３分で話しているんだから、分かりにくいかもしれない。そこはかんべんしてもらわないと。

　とにかく、このようにして、複数のテーブルが関係をもって組あわさって作るものが『データベース』なのです。ちょうど、部屋と部屋が廊下やドアでつながり組合わさって建物ができるように、ね。

「センテンス同士が接続詞でつながりあって文章ができるようなものかしら。」

－－そうともいえるかな。とにかく、ここでちょっとまとめておこう。

　データの最小単位とは、有限の選択肢の中から一つを選んだものを指す。これは（選択肢のメニューさえ決めれば）数字で表現できる。選択肢で定義できないようなものは、それが満たすべき規則を決める。これがフィールドで、いわば単語にあたる。

　レコードとは、フィールドが決められた順序で決められた数だけ並んだものをさす。データの並び方を決める約束事をデータの文法と呼ぶ。

　対等なレコードが複数並んだものを、テーブルという。レコードを識別するためのフィールドを、キーと呼ぶ。キーの値はそれぞれのレコードごとに必ず異なっていなければいけない。

　エンティティとその属性を表現するようなテーブルのことをマスタと呼んだりする。マスタは、選択肢のメニューをあらわす辞書としても機能する。

　あるテーブルが、別のテーブルのキーとなるフィールドを共有することによって、テーブル間の関係が生じる。

　データベースとは、複数のテーブルが関係を持って成立するものをいう。

「ふう。これがデータの世界の文法規則の全貌というわけね？」

－－そのごく概略のありさまです。まあ、細かな点をいろいろはしょっているから厳密には不正確なところもあるけど、理解してもらう助けにはなるだろう。見慣れない用語も多くて申し訳ない。消化不良になりそうかな？

「・・そうね、飲み込むには時間がかかるかも。

　消化といえば、それにしても、なんだかお腹がすいてこない？」

－－そうだな、ぼくもずっとしゃべりどおしで、のどがカラカラだ。もうそろそろインターチェンジだから、パーキングエリアのレストランでも探そうか。ちょっと休憩して何か飲みたいな。

「賛成。わたしも、お腹がぺこぺこよ。」

(c) 2002, Tomoichi Sato

　　　　　　　　　　　　　 （この話の登場人物はすべて架空のものです）