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

　ひさびさに、シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、そのため、ダイアグラムの構成要素を、ノード、リレーション（エッジ）、属性、属性値に分けようとしています。

　前々回、構成要素単独で意味をなすもの：ノードをやり
　前回、　構成要素単独で意味をなさないもの
　　　　　　　２つ以上のものと結びつく：リレーション（エッジ）

　今回は、１つのものと結びつく：属性について行います。

　なお、今までの話は、ここにまとめてあります。

---

■ノードにむすびつくもの－属性値

　あるノードの説明になっているものが、属性値です。
　ノードの説明は、引き出し線が引っ張ってあって、そこに書いてあることもあるけど、
　たいてい（ノードの上にノードに書くと、結びつきがあったように）
　ノードの上とか横に説明を書いて、それが属性値になる場合が多いです。

　ノードの名前とか。。。

　この場合、ノードの説明は、文字で書かれているものだけでなくって、
　ノードの形で、種類が示してあるもの（たとえば、業務流れ図で、帳票の形とか、
　楽譜で、四分休符とか、八分音符の形とか）も属性値になるし、
　位置座標なども、属性値になります

---

■リレーションにも属性値がある
　そして、リレーションにも属性値があります。
　線の上に書いたりしますよね。

　ＤＦＤでデータフローのところに、データを書いたり
　流れ図の分岐で、何の場合というので、書いたりとか。。。

　ああいうのが、属性値になります。
　リレーションの場合、位置座標は関係ないようなケースでは、
　属性値がないこともあります（線で結ばれているだけなど）

---

■属性値と属性

　属性値は、なんらかの意味、意義を持っています。
　もってないで、書いてあったら落書き、いたずら書きです。
　なにか、意味合いがあるわけです。

　たとえば、帳票のマークのところに、「受注票」と書いてあったら、それは
帳票名という意味です。

　このように、属性値に対する、なんらかの意味、意義を「属性」とします。

　なお、属性は１つなのに、属性値がたくさんということもあります。

　ＥＲ図に、項目名を書く場合、項目名（ＩＤ，氏名、住所・・・）はいろんなものがあります。
　項目名という属性１つに対して、値いっぱいなわけです。

---

ということで、ひととおり「ダイアグラムの構成要素」を説明しました。
次回は、ここまでのまとめです。

きのうのＰ≠ＮＰ問題の話

で、きのうのＰ≠ＮＰ問題の話。大勘違いしてるかもしれないけど。。。（してたら、ごめん）
結局Ｐ，ＮＰって、ある事象（項や要素、桁もあるけど）と次の事象が、
　　　　　　　１つに決まる場合が、Ｐ
　　　　　　　複数ありえる場合が、ＮＰ
ということ＊は、その前とか、もっと前とかについては、考えてない？？

循環するっていうのは、前の事象と次の事象は無関係のように思えているけど、ある程度はなれたところの事象と比べると、関係がある（独立ではない）というもの。

＊＝循環しないとは言ってない・・・もし、なんらかの関連性があると、解ける可能性がある？？

ところで＊って、マルコフ連鎖？