UML等各種ダイアグラムのエラーチェック体系化（その１１：ダイアグラムをグラフ理論化－２）

　前回までの話、いろんなダイアグラムをＲＤＢにいれよう！化計画、

　今、ダイアグラムの構成要素を、ノード、リレーション（エッジ）、属性、属性値に分けようとしています。

　そして、前回、
　　その構成要素単独で意味をなすもの
　をノードとしました。

　今回は、その反対、つまり
　　その構成要素単独で意味をなさないもの
　について考えます。

---

■その構成要素単独で意味をなさないもの

　これはつまり、ある構成要素と他の構成要素を結びつけたり、
　ある構成要素の説明になっているようなものがあります。

　今回は特に、「ある構成要素と他の構成要素を結びつけ」る物について考えます。
　言い換えれば、これは、２つ（以上）の構成要素を結びつけるものです。

　これを、ここでは、リレーションと呼びます。グラフ理論のエッジです。

　これの例としては、
　・ＥＲ図のリレーション
　・ＤＦＤのデータフロー
　・流れ図などで書く→線
　・音符の連符のところについている、音符間の線（って、なんていうんだろう　＾＾；）

---

■みえないけど、ひかれているリレーション

　なお、前ノードの上に、ノードが載っていることもあると書きましたが、その場合、
２つのノード間に関係があって結びついていれば、リレーションがあるとみなします。
　つまり、線が引かれているとみなします。

　前回、落書きした場合について書きました。その際、たまたま上に書かれていても
落書きは、ドキュメントと内容が関係なければ、上にあっても関係ないと書いた理由は、
このように、ドキュメントと落書きが関係なければ、リレーションがないからです。
（関係があれば、みえないリレーションがあると考えます）

　また、ある構成要素について、詳しく書かれている場合や、続きが書かれている場合も、
　見えないけど、リレーションがひかれていると考えます。
　ＤＦＤなどで、あるプロセスを別のＤＦＤとして書く場合です。
　また、絵と、絵の上にある１ピクセルも、リレーションで結びついていると考えます。

---

　次回は、「その構成要素単独で意味をなさないもの」で、１つの構成要素に結びついている「属性」についてです。

データアクセスと処理との間の中間層のインターフェースは、ハッシュマップとその配列に集約する

　この前書いた、ＲＤＢとかに直接アクセスしないで、デバイスを意識しないデータアクセス層を作る話だけど、こうすると、

ひとつのメリットとしては、
　　・ＫＶＳとか、どこに分散されてるかとか、ファイルかとか意識しないでアクセスできる
　　　　→みんながアクセス法をしらなくてもいい

そのほかにも
　　・もし、ＤＢ上で変更が起こったとき、入出力が集約しているので、対応しやすい
　　　　→場合によっては、変更をこの層で吸収できる。

なんていうメリットがある。

さらに、
　　・すべてのデータを同じように表現できる

ということがある。このメリットはさておき、まず、デバイスにかかわらず、
どう表現すると、データを同じように表現できるのかについて、述べてみたいと思います。

---

■データは、ハッシュマップ（連想配列）とその配列で表現できる。

　たとえば、ＲＤＢのデータは、１レコードを１ハッシュマップとし
　（項目がキー、値がvalueになる）、それの配列で、テーブル、ビュー、検索結果が表現できます。

　ＫＶＳは、まさにハッシュマップ

　プロパティファイルはハッシュマップ

　ＣＳＶの場合は、１レコード１ハッシュマップにして、
　キーに項目番号１、２、３・・・値に、その項目のセルの値をセット

　ＸＭＬはいやらしい形なのですが、

　１ノード１ハッシュマップ。
　そのときのパラメータをキー、値にセット
　テキスト部分はキーを#text#1のような形で
　　（テキストが、２つの部分に分かれてれば#text#2,３つなら＃３・・・）
　子ノードは、キーに子ノード名#1(同名の２番目のノード#2・・・）
　　　　　　　値に子ノードのハッシュマップ

　という形でいれられないこともないです。

　こんなかんじで、大体のデータは、ハッシュマップ（連想配列）とその配列で表現できます。

---

さらにまとめると、ハッシュマップだけで表現されているものも、要素１個の
ハッシュマップの配列にできるので、これだけで表現できるともいえます。

で、こうやって、ハッシュマップの配列にすると、何が楽しいのかについては、
今度書きます。