ER図とクラス図、テーブルの関係

　RFPからプログラミングまで、シームレスに開発する方法というのを、書いていて、現在以下の図

の①、②、④、⑤は書いたので、今日は、③のER図とクラス（クラス図）と、テーブルの関係。

---

■ER図で描かれていること

　ER図で書かれているのは
　　・エンティティ
　　・アトリビュート
　　・リレーション
　なんだけど、この作り方を復習しておく

ドメインをきめて、データ構造と機能概要を割り出す方法を考えるで書いたとおり、成果物から、それを作成するのに必要な入力というのを考える。
　そうすると、成果物(画面とか帳票とか）と入力（画面が多いのかしら)する「モノ」っていうのが考えられる

　受注画面とか、売上トップ１０帳票とか・・・

　これらは、モノなんだから、オブジェクトと考えられる。記載されている（可変）項目がプロパティとなる。

　さてさて、これらの項目のうち、コンピューターに保存しておかないといけないものがある。
　受注した商品とか、受注先とか・・・
　電気が切れたらさようなら・・・では困る。
　そこで、ファイルかDBに入れるんだけど、共通で利用するものは、DBに入れる。

　現在、データベースの主流は、RDBで、これは、単純なテーブル構造（項目の並びをテーブルとする構造）であって、階層構造にはなっていない。ところが、上記オブジェクト（受注画面）とかは、受注１つに対して受注品目が２個も３個も・・・という階層構造になっている。

　こまった・・・

　ということで、この階層構造を単純なRDBのテーブル構造に直す手順が正規化である。

　この複雑（階層構造を含む）なオブジェクトってか、データ（＝受注画面とか、売上トップ１０とか）を、

１．繰り返し部分っていうのは、その繰り返し部分だけで１つのデータ構造を持っているわけだから、
　　繰り返し部分をなくしましょう＝第一正規形

２．で１つのレコードになったら、保存するためには管理する必要があるので、ID（＝主キー）をふります。
　　主キーは、複数項目の組み合わせでもOKなんだけど、
　　複数項目の場合、一部の項目が決まると、他の項目の値が決まってしまう
　　＝他のデータ構造を含んでしまってる
　　　　→場合は分離しましょう＝第二正規形

３．主キー以外でも、一部の項目が決まると、他の項目の値が決まってしまう
　　　＝他のデータ構造を含んでしまってる
　　　　　→場合は分離しましょう＝第三正規形

　という行為を行って、単純なデータ構造にする。

　そして、このとき、分離していった一つ一つのデータのまとまりがエンティティであり、
　そこの項目がエンティティのアトリビュートとなる。
　この場合、エンティティをテーブルとして、差し支えない。

　ER図のエンティティとアトリビュートは、このようにできる。

　一方のリレーションは、データを分離していくときに、分離先に分離もとのID(主キー）を入れて渡す。

　このデータ分離元－分離先の線がリレーションで、
　・分離元（主キー）側が１
　　　（主キーが同じなのは、１レコードしかないでしょ、
　　　　もし２レコード以上、同じ値の主キーがあったら、
　　　　それはおかしい・・ってか、主キーじゃない）
　・分離先がNで、外部キーとなる

　リレーションには、どんなリレーションかって言うのを書くことになってるんだけど、それはいいかな・・・と（＾＾；）なくても開発上、こまらない。

---

■エンティティとクラス、ER図とクラス図

　エンティティは、上記操作によって作ると、ID(主キー）が振られることになる。
　つまり、このエンティティのインスタンスであるレコードは、一意に識別できて、管理できることになる
　これって、オブジェクトってことになる。オブジェクトは、何によってインスタンス化されたかというと、
　クラス。

　なので、こんな関係になる

 エンティティ⇒テーブル　　　　　　クラス
　　　　　　　↓　　　　　　　　　　↓
　　　　　　レコード　　　　＝　　オブジェクト

ってことで、エンティティは、クラスとなりえる
（もちろん他にも、クラスになるものもある）

具体的には、ER図からクラスを以下のように作成する

・ER図のエンティティ名＝クラス名
・ER図のプロパティ　　＝クラスのプロパティ
　　　　　　　　　　　＝プロパティを元にSetter,Getter

こうすると、値のBeanクラスができる。
（Hibernateのマッピングクラス。プロジェクトによっては、これをバリューオブジェクトと呼ぶ）

ということで、ER図から、クラスができるのだから、
ここからクラス図が、かけないこともない。

ただ、クラスに書く場合、プロパティの型を決めないといけない。
DB定義書なら、型が書いてあるけど、ER図の場合は、プロパティ名から判断
（なんとか数＝intみたいな）するしかない。

---

■ER図／クラス(図）からテーブル

　クラスで型を決めたら、テーブル作成のSQL（CREATE TABLE)も作成できる。

　ER図に主キーはあり、型もクラスのとき決めた。
　ただ、何桁分取るかということは、DB定義書からでないと、本来わからない。

　ここを、テキトーに取るんなら、作成できる。

　逆に言うと、実はDB定義書最強で、DB定義書からER図、マッピングクラス、CREATE文すべて作れる。

---

■・・・しかし、本当にクラス図？

　ここで、　
「これらは、モノなんだから、オブジェクトと考えられる。記載されている（可変）項目がプロパティとなる。」
と書いた。オブジェクトはインスタンスなので、これを生成したクラスというのも、考えられるってことだ。

つまり、

・受注画面なら、
　　　受注画面入出力項目を集め、それのセッターゲッターを書いたクラス

　＝StrutsにおけるActionFormだ。まさに、クラス。

・売上トップ１０帳票なら
　　　出力内容項目

　＝これは、Cocoonなど帳票出力のソフトを使う場合、XMLで表現される。
　　XMLで表現できる場合、マーシャリング、アンマーシャリング（って今、言わないの？O/Xマッピング？）
　　を使えば、オブジェクトになることからわかるように、

　　この項目もクラス化できる（出力項目をアトリビュートにし、セッター、ゲッターをつける）

ってことは、入出力メディアは、データのクラス化ができる。
これを、クラス図に描くことは可能だが・・・

帳票１つをクラス図にすると、ものすごく大きなクラス図になり、
それらを、帳票分、さらに、画面分、データベース分・・・

などと作っていくと、それだけで、莫大なクラス図になる。。。。

・・・意味あんのか？これらは、自動生成できるわけよ、上記のように・・・

なので、ここの部分のクラス図は描かないことが多いと思うけど、書こうと思えばかける。