前回までのあらすじ

パート１はこちら
パート３はこちら

kintoneで簡単にExcelからアプリを作れてしまう僕たち。
だけど、現実の世界で利用するにはまだまだ機能が足りないのだった。
いったん現実の世界から離れて、情報として取り扱う対象を
俯瞰してみてみよう。

ということでした。

用語の説明

ここから長々と説明が続きますので、結論だけが知りたい方は
「用語の説明」を飛ばしてもらって構いません。結論としては図を1枚描くだけですので。

では、はじめましょう！

要素と集合

たとえば、この世に存在する「すべての車」を考えてみましょう。
この「すべての車」を指し示したいとき、１つ１つの車を要素と言い、すべての車の集まりを集合と呼びます。

一意とキー

集合の中から要素をたった一つ指定したい。この「たった一つ」を一意と呼びます。では要素をいつも取り扱っているデータだとしましょう。データのうち、そのデータを指し示すのに用いられる属性（項目）をキーと呼びます。

主キーとはその属性値が決まれば、データ要素を一意に指定できる属性を指します。例えば、すべての車から「生産番号」を指定したら車を１つ、いつでも同じものを取り出せるとき、「生産番号は車の主キー」です。

複合主キーとは主キーが複数の属性にまたがっている状態を示す言葉です。例えば車についている各シートが「1,2,3,4…」とシート番号が付いているとき、この世界・・・つまりすべての車のすべてのシートの集合から、一意にシートを取り出すには、「生産番号」と「シート番号」があればよいでしょう。
このとき、すべての車のすべてのシートの集合の主キーは「生産番号、シート番号」で、これは複数の属性なので、複合主キーの状態です。

ナチュラルキーとサロゲートキーについて。

サロゲートキーとは”代理キー”とも言います。先述の車とシートの例では、シートを一意に指し示すために「生産番号」と「シート番号」が必要でしたが、主キーが複数あると、システム上重複チェックがめんどくさくなったりなど、不都合が発生します。
なので、代わりに連番などを振って、取り扱いやすさを担保する場合があります。このようにシステム用の都合から「人工的に作られるキー」をサロゲートキーと呼びます。ナチュラルキーとはサロゲートキーの逆で、もともとデータとして持っている主キーを指して呼びます。

例えばkintoneで法人マスタアプリを作ったとしたら、サロゲートキーは「レコード番号」で、ナチュラルキーは「法人番号」となるでしょうね！

クラス、汎化、継承

すべての車を考えたとき、その中にはタクシーもあるし、クレーン車もあると思います。ある視点で集合を分類したとき、それぞれの”分類”をクラスと呼びます(class / classify)。

「タクシー」と「クレーン車」は全く別の分類ですが、「車」という意味では同じですよね。

「タクシーとクレーン車はちがうけど、車という意味では同じだよなぁ」と考えるとき、われわれは「タクシーとクレーン車から汎化して車として」扱っています。逆は特化です。

では車って何でしょうか？　「車輪がついていて、物を運べるもの」って感じですよね。だから「自転車」も車のような気がしますね。なので、「車」の属性を継承して「自転車」という別のクラス（つまり分類）を作ってしまいましょう。
「自転車」には「車」から引き継いだ【速度】とか【車輪】といった属性をもちつつ、【サドル】のような特徴的な属性を備えています。

依存

引き続き車で考えてみましょう。車がこの世に存在するとき、必須条件になるものは何でしょうか？　例えば、製造元は必要そうですよね。つまり、「車という要素は製造元に依存している」と言います。

データとしてみてみましょう。「車」というデータがある場合、そのデータがあれば必ず「会社」というデータの集合から製造会社になる要素が決まっています。

ふう、長かったですね。データの分析に必要な概念の説明は以上です。

データを分析しよう

では、単価表をじっと眺めてみます。

むーん。どうやって生成されたデータでしょう？

まず仕入先。仕入先は自由入力でしょうか？　
いや違いますね。
この世に存在する会社の集合があって、その中から選択されたのではないでしょうか？

また商品名。商品名もここで生成されたわけはないのでは？　仕入先企業がの集合や、自社が取り扱っている商品（材料）の集合があって、その中から選択されたのではないですか？

つまり、このデータは「仕入先」と「商品」という情報に依存している（逆に言うと、仕入先と商品がなければデータが作成できない）のです。

「仕入先」についても考えてみましょう。

仕入先とは「顧客企業が取引がある企業のうち、仕入を行っている企業」でしょう。つまり仕入先のさらに先には「取引先」という大きな集合があるでしょう。

つまり取引先という汎化されたクラスがあって、それを仕入先が継承しているはずです。

仕入先とは取引先ではあるが、取引先は仕入先ではない。

こんな集合になるはずです。

さらに！　もしかしたら商品についても、単価管理対象とそうでないものがあるかもしれません。・・・と突き詰めていくと結構な構造図が作成できてきます。

まあ、ここでは取り扱い可能な全商品まで扱うようになるかどうかは未知数です。ここでやめておきましょうか。

さあ、データの塊、つまり集合について推論してきました。
１）仕入先
２）取引先（仕入先のより大きなクラスとして）
３）商品
４）単価表

取引先について、取引先を一意に指し示すキーがExcelにはないですね。
では設けましょう。「取引先コード」です。同じように商品も設けましょう。「商品コード」です。

取引先のうち、仕入先であることを示す属性がないですね。では設けましょう。「区分」という名前とします。この区分が"仕入先"という値をとるとき、その取引先は仕入先です。とらないとき、仕入先じゃないです。

さて、やっと単価表について考えてみましょう。
商品と仕入先だけでデータが作成されるでしょうか？

いいえ。たしか、年度と月も、データの生成にかかわっていたはずです。

なので、年度と月も一意に決定する項目です。

さあ、単価表を生成するために必要な条件がやっとそろいました。
・取引先コード（仕入先を示すキーとして）
・商品コード（商品を示すキーとして）
・年度
・月
が決まったとき、データが初めて一意に決定され、単価が数値の自由入力で決まりますね？

つまりこのレコードの自然キー（NaturalKey）は「取引先コード」「商品コード」「年度」「月」となります。

さて、ここからは各集合の関係を見ていきましょう。

仕入先は取引先を継承している。
単価表は仕入先に依存している。取引先には依存しない（仕入先じゃない会社とも取引している）
単価表は商品に依存している。

データ概念図に必要な条件

出来上がった概念図に必要な条件は下記となります。

１）システムで取り扱うデータが漏れなく、重複なく記載されていること。
２）各データの集合について、主キーが示されていること。
３）データが表現する範囲（スコープ）に対して、大きすぎないこと。
４）サロゲートキーが主キーになっていないこと。

まとめ

長かった・・・。図も完成して、パート２は終わりです。

実際技術者がExcel表を眺めたときには最初から図が頭に浮かんでいます。
だから図を描かないと作れないということはないんです。
ただ、描く練習はしたほうがいい！

さて次回は、実際にこの図をkintoneでどう表現するか、をやってみます。
プラグインも登場するよ！　座学は終わりだ！

お楽しみに。

この記事は以上です。お読みいただきありがとうございました。

補足

書いてみて思ったんですが、集合の話と関係モデルの話が交錯して分かりにくいところがありますね。うーん。表現って難しいです。できるだけわかりやすく書いたつもりなのですが、改善点があれば教えてほしいです。