それでは早速データモデルの読み方を説明しましょう。いくつかの準備が必要です。

まず、あるテーマに関するデータがいくつかの表の中に収まっていると考えてください。データモデルは、どのような表があり、その表の中にどのような列があるか、その列はどういう性質を持っているか、表と表はどのような関係にあるかを記述しています。前回、「目指すもの」たとえば特定の図書に関するひと固まりのデータを「タプル」と呼びましたが、タプルが表の行になります。「目指すもの」の数が増えれば、表の中に行が追加されて、縦方向に長くなっていきます。列には「○列目」という呼び方ではなく、それぞれに名前（たとえば図書に関して言えば「表題」や「発行年月日」）がついています。

【図書】

目指すデータを表現するためにどのような表を組み合わせるとうまくいくのかは、データモデルを作る人が考えることで、これが上手か下手かで大きな違いがでてきますが、これが正しく作られていると仮定して、先に進みましょう。

簡単に「表」と言いましたが、Excel のような表とは３つの点で違っています。１つめの相違点は、行の順番には意味がないということ。表の７行目と８行目の間にしかじかの行を挿入する、等という表現はここで考えている表の場合は意味を持ちません。

Excel のような表との相違点の２つ目は、各列のとりうる値があらかじめ定まっていること。これは文字列か数値か、というような「ざっくりした」決め方の場合もありますし、曜日のように７種類のうちのどれか、と「かっちりと」決まっている場合もあります。とりうる値の集合をその列の「ドメイン」と呼んでいます。（かっちりと決まっているものを狭義の「ドメイン」、ざっくりと決まっているものを「データ型」と使い分けることもありますがここでは両方を「ドメイン」と呼びます。）その列のドメインが何かはデータディクショナリの中に書いてあります。

相違点の３つ目は、表に同じ行が２つ存在することはないこと。つまり、「何行目」と言う指定には意味がありませんが、各列の値をドメインに従って指定すれば、その行を特定することができるということです。（指定する値によってはその行がない、と言うこともあり得ますが、あるとすればただ一つに定まります。）

全ての列の値を指定すれば対応する行を（あるとすれば）特定することができますが、たいていの場合全ての列の値を指定するまでもなく、一部の列の値を指定するだけで行を特定することができます。行を特定するために必要かつ十分な列の組み合わせを「主キー」と呼びます。表には必ず主キーがあります。それぞれの表の主キーが何かは、データモデルの構成要素であるER図というダイアグラムの中に書いてあります。

次にあるのは前回お見せしたER図のサンプルですが、【図書】【著者】【著作】という四角形で表現されているものがそれぞれ表になります。四角形の中が横線で仕切られていて、線の上に書かれているのが主キーの列を表す名前（例えば【図書】表の《表題》）、下に書かれているのが主キー以外の列の名前（例えば【図書】表の《NDCコード》《発行年月日》）です。この連載の中の約束なのですが、表の名前は【　】、列の名前は《　》、表の中に入る値は "　" で囲んで表記します。

図１　前回に使ったER図のサンプル

ユーザーの立場からは少し離れることになりますが、主キーというものの性格を理解していただくために説明すると、このモデルでは【図書】の各行は《表題》という主キーで特定される、ということになっていますが、例えば"論理学の哲学"という《表題》の【図書】は、"ヒラリー・パットナム"も"ウィラード・v・クワイン"も書いているので、この図書館が両方の【図書】を蔵書として持っている場合、このモデルでは都合が悪いことになります。"論理学の哲学" というように《表題》を指定しただけではどちらのことを言っているのかわからないからです。

【図書】

こういう場合は《発行年月日》を主キーに昇格させて次のようにすれば、大丈夫です。“1975/12/15”発行の“論理学の哲学”といえば、どの行を指しているのか特定できるからです。（たまたま《発行年月日》も同じ“論理学の哲学”があったらどうするか、これはデータモデルを作る人の工夫に任せましょう。）

図２　改良版（暫定）

【図書】の主キーが変更されたことに関連して、【著作】の主キーが変更になっていますが、この意味は次回説明します。《著者名》を【図書】に加えれば、これでも区別がつくようになるではないか、という考え方もあると思います。実は《著者名》を【図書】の中に入れてしまうことは、設計のルール（正規型のルール）に違反するので、ユーザーの立場からすると便利でもそういう設計にはできない（するべきではない）のです。どの列が主キーになっているかはデータモデルを作る人がきちんと決めてくれている、という前提で先に進みます。

「表」「行」「列」などと呼んでいますが、上でみたようにExcel で使っている言葉とは違う性質をもっているので、きちんと特別な名前がついています。表と呼んでいたものは「リレーション」「エンティティ」「テーブル」、列のことは「属性」「カラム」、行のことは「タプル」「レコード」などと呼ばれています。言い方が複数あるのは論理的な構造を明らかにする段階と、計算機への実装を前提にした段階で、違った言葉で呼んだ方が便利なことがあるためです。専門家はきちんと使い分けていることが多いのですが、この議論を始めると「入門」の域を越えると思いますので、この連載では今後も「表」「列」「行」という名前を使います。
さて、表の名前を【N】この表の主キーをが《P》《Q》それ以外の列を《X》《Y》としましょう。《P》《Q》《X》《Y》にそれぞれ"p" "q" "x" "y"という値が入っている行があったとします。このことは

【N】

ということを表しています。

例えば【図書】という表に主キー《表題》《発行年月日》、その他の列として《NDCコード》があって、次のようにデータが入っていた場合（わかりやすいように、主キーの列を左に寄せて表示しています）、

【図書】

となります。

表の意味がわかったところで、次回はいよいよデータモデルが何をあらわしているかを考えましょう。図２のようなER図と、次のようなデータディクショナリからなるデータモデルを考えます。（データディクショナリにどのような項目が記録されているべきかという問題には、まだ誰もが合意できる標準的な答えはできていないように思います。ただしドメインに関する情報は最低限含まれているので、サンプルとして見てください。）

このようなデータモデルで、【図書】表の定義は次のように読むことができます。

このようにデータモデルを読み下して、もし間違っている日本語になっていたら、データモデルを作った人と読む人の間で、表や列の名前の定義について行き違いがある可能性が高いので、よく確認して先に進んだ方がよいでしょう。

ご意見募集

ここまでの内容で質問やコメントがある方は、 編集部までお問い合わせお問い合わせ下さい。
「入門」なのであまり高度な質問にはお答えできませんが、みなさまの役に立ちそうな内容については、この連載の中でとりあげたいと思います。