ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

ER図からテーブル生成SQL,データアクセスクラス自動生成の可能性

2009-08-11 17:36:01 | Weblog

 昨日、クラス図から、Javaのプログラム自動生成について書いた
 そして、今日、ER図について書いたので、
 今回は、ER図からの自動生成、具体的には、テーブル生成SQL,データアクセスクラス自動生成の可能性について書いてみる。




■ER図→テーブル生成SQL

具体的には、ER図のエンティティから、SQLのCreate Table文を作成することになる。
この場合、エンティティの属性が、SQLのテーブルの各項目っていうことになる。
しかし、Create Table文を発行するためには、属性の
   属性名はわかるのですが
   属性のタイプ(型、intなど)
がわからないといけません。このうち、属性のタイプはわかりません。
また、NOT NULL属性はわかりません。
主キーについては、PKとかかれるのでわかります。
参照制約に関しては、FK(外部キー)はわかるのですが、これを全部制約にして、よいかどうか。。。
  ただ、参照制約は書かなくても、テーブルは作れます。

ということで、テーブル生成をするためには、

・属性のタイプとNOT NULL制約

をER図のほかに情報として、属性に持たないといけません。

これをもてば、以下のような形で作成できます。
(ER図がRDBに、前に書いたように入っているとします)

1.エンティティテーブルのすべてのテーブルについて、以下の処理を行う
 1-1.Create Table エンティティ名 ( 出力
 1-2.属性テーブル中、対象のエンティティIDを持つものを抽出し、全レコードに以下の処理を行う
   1-2-1.属性名 型 (NOTNULL制約あるとき NOT NULL),
        →型とNOTNULL制約はER図拡張
 1-3.1-2のレコード中、項目種別がPKのものを抽出し(複数ある場合もある)、
   1-3-1.PRIMARY KEY (を出力
   1-3-2.抽出した項目名を全部列挙
   1-3-3.) USING BTREE,とかかく

(今回参照制約は省略)

 1-4.)のあと、必要なことを書く(ENGINE=InnoDB DEFAULT CHARSET=utf8;とか)





■ER図→データアクセスクラス

 2通りある。拡張する場合としない場合。

 拡張しない場合も、する場合もどちらも、クラスはエンティティになる。
 しかしこのとき、

   拡張しないほうは、属性の型を持ってないので、
     クラスのフィールドにsetter,getterを持たない。

   拡張したほうは、属性をフィールドでかけて
     private 型 属性名;
     public get属性名1文字目大文字(型 属性名)
     のようなかんじで、getter,setterがかける
    →つまり、Beanになる。

 どちらも、メソッドとしては、検索メソッド、編集メソッドを持つ。
 もっと細かく、Create,Update,Select(Read),Deleteを作ってもいいけど、
 (検索と編集は返り値が違うので分けないといけない)どちらにしても、

   拡張しないほうは、引数にハッシュマップ等を使って、検索条件を設定するか
     SQLをそのまま受け取り
     結果を、検索の場合、ハッシュマップの配列にいれる。

   拡張したほうは、引数にハッシュマップ等を使って、検索条件を設定するか
     SQLをそのまま受け取り
     検索結果を、Beanの配列などにセットできる(ハッシュマップでもOKだけど)


 どちらにしても、エンティティテーブル、属性テーブルからある程度作成可能




てなことで、ER図は自動生成に使うには、型とNOTNULLとかを入力してもらったほうがいい。
そうすると、テーブルや入出力プログラムを自動生成できる。

なお、文中に、「クラスはエンティティになる」と簡単に言い切っちゃったけど、
このクラスとエンティティの話は、またこんど


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

パソコンを、夜充電しておいて、昼間コンセントを抜いて使うと、夜間料金で運用してることになり

2009-08-11 16:38:45 | Weblog

電気代が安くなる?

ひょっとして・・・??

もしそうなら、なんか、そんな制御するコンセント(夜間電力時間になるとスイッチON,昼の料金になったとき、スイッチOFF)なんていう、エコスイッチが出てきたりして(いや、エコではないか・・・電気代は安くなるけど・・)

ここ(8月10日分)読んでて思った

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

UML等各種ダイアグラムのエラーチェック体系化(その17:ER図をRDBに)

2009-08-11 02:44:21 | Weblog

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

 現在「いろんなダイアグラムをRDBにいれよう!」化計画、
 をやっていて、実際、いろんなダイアグラムをRDBに入れる方法を書いています。

 今回はER図です。

 なお、ここで書いたとおり、RDBへの入れ方など、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm





■ER図

実は、ER図の書き方は、いろいろあります。
Wikipediaみたいな書き方も、たしかにあります。
(むかしは、この形式で良く書きました)

最近は、ここの「まる3」みたいな書き方が多いかな。

ただ、ER図の書き方の標準ってのはあって、IDEF1Xが、それにあたるんですけど・・・
ちなみに、EAにおいては、図を明示していません

ま、最小公倍数的に、共通部分を集約すると、MAXこんなかんじ?

エンティティ
(エンティティ名、属性(プロパティ)、キー種別(主キー、外部キー、キーではない))

リレーション
(元エンティティ、先エンティティ、リレーション内容、元カーディナリティ、先カーディナリティ、リレーション種別)

*リレーション種別 JUDEのER図のばあい非依存関係と依存関係を描き分けられるようだし、(ってか、IDEF1Xだと、書き分けられると書くべきか)なので、依存、非依存などを分けるため、リレーション種別をいれています。




■RDBに入れる

まず、ノードとアーク(リレーション)にわけます。
ノード:エンティティ
アーク:リレーション

 になります。Wikipediaみたいな、関連をひし形で書くと、あたかも、ノードのように見えるかもしれませんが、ノードの定義である、独立で存在することができないうえ、アークの定義、2つのノード(エンティティ)を結ぶには、ぴったしなので、リレーションは、アークです。
 同様の理由で、属性も、丸っこく書くと、ノードのように見えますが、これも、ひとつのノード(エンティティ)に結びついているものなので、属性です。

 ただし、属性(プロパティ)は、1つのエンティティに複数あるので、別テーブルとなります。したがって、テーブル的には、

エンティティテーブル
属性テーブル
リレーションテーブル

となり、それぞれのテーブル項目は、こんなかんじです。

●エンティティテーブル
(エンティティID,エンティティ名)

●属性テーブル
(エンティティID,属性ID,属性(プロパティ)名、キー種別(PK,FK,その他)

●リレーションテーブル
(リレーションID,元エンティティID、先エンティティID、リレーション内容、元カーディナリティ、先カーディナリティ、リレーション種別)

*カーディナリティは、クラス図の時と同じ。




 これと、クラス図、よく似ているというか、クラス図の一部がER図のように見えますが、その関係については、また今度

 で、今回はここまで。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする