テーブル定義とER図の関係（変換方法）

　以前、業務をまとめたシートについて書き、また、入出力についてまとめたシートについても書いたので、今日は、その入出力のまとめから、ER図へ落とす落とし方。

　といいますか、一般的なテーブル定義、もしくはテーブルのスキーマからER図への落とし方。
　もしくは、その逆で、ER図からテーブルの落とし方

について書きます。

---

■そもそも、ER図とは、何で、何が分かれば描けるか？

　ER図とは、エンティティと、リレーション（関係）を描いた図です。
　って、文字どおりですね（＾＾；）

　こんな風な図になります。
ERD（entity-relationship diagram）
http://www.atmarkit.co.jp/aig/04biz/erd.html

なお、IDEF1Xの形式で書くと、他に、キー（主キー、外部キー）と、項目が必要です。T字型ERでも、項目まであれば、確かかけたはず。

　ってことは、つまり、テーブル定義に、
・エンティティ名
・関係
・１対多とか（カーディナリティー）
・項目名
・主キー、外部キー
が書いてあれば、情報的には足りているということになります。

---

■ER図からRDBに落とすときの問題点：多対多

　しかし、エンティティが多対多のとき問題があります。
　っていうか、そのまえに、１対１、１対多のときは、
　これらのときは、１のほうが、主キー、多のほうが外部キーになることで、あらわせます（というか、あらわしています）。

　でも、多対多は、RDBでは、表現できません
　（うーんと、無理すればできるんだけど、そういうことをしない）。
　そこで、ふつう、AテーブルとBテーブルが多対多のとき、AテーブルのどのレコードとBテーブルのどのレコードが対応しているかを表したテーブル、AB対応テーブルを作ります。

　このテーブルは、本来、実体のないものです（テクニック上、関係を表すものとして出てきたものだから）。しかし、ER図に描かないと、ER図からテーブルを作ろうとしている人は、困ってしまうので、こういうものも（対応テーブルも）ER図に書くこととします（実際書いてますけどね）。

　なお、テーブル定義は、１対多の関係になっているものとします。
　（正規化していれば、第一正規形のところで、こうなっていると思います）

---

■テーブル一覧から、ER図をつくる

では、まず、世間一般にあるテーブル一覧（かつ、今回の「入出力についてまとめたシート」）から、ER図を作る方法について。

＜＜方法＞＞

（１）テーブル名をエンティティとします。
　　　エンティティの四角形をかいて、そこに、テーブル名を入れてください。

（２）FKキー（外部キー）があったら、
　　　　その外部キーを主キーとしているテーブルとは関係がありますから、
　　　関係を結びましょう（関係の図を書きましょう）。

（３）１対多とかの（カーディナリティー）は主キーを持っているほうが１です。
　　　FKキーのほうは、０、１、多は分かりません。
　　　例：受注と受注明細、
　　　　　　　受注のほうに受注番号（主キー）があり、
　　　　　　　受注明細のほうに、受注番号（FK）と、受注明細番号（主キー）
　　　　　があるはずです。

　　　　　このとき、受注番号があるので、関係があります。
　　　　　受注番号が主キーなので１、受注明細は、０，１、多は？
　　　　　　　　（多分、”多”だけど）
　　　　　なお、受注明細の場合、
　　　　　　　　受注番号と、受注明細番号で主キーとしている場合
　　　　　もあると思いますが、このときも、受注番号はFKとなります。
　　（って、テーブル一覧には、表が悪くて書いてないかも知れないが、
　　　理論的には、そうだ）

（４）T字型ER,IDEF1Xで、項目名と、主キー、外部キーが必要な場合は、
　　　テーブル定義をみて、書いてください。

（５）配置は、適当に入るように書いてください。

　ってことで、テーブル定義でかけないのは、カーディナリティーと、関係の内容になります。

　コレに関しては、FKの項目の備考に、コメントとして書くようにします。
　そうすれば。。

（６）関係を、FKキーの備考をみて、書いてください。

（７）（３）の１対多、FKキーのほうは、FKキーの備考をみて、書いてください。

　これで、OK。

---

■テーブル一覧からテーブルを作る

　これは、できますよね。できなかったら、そのテーブル一覧に問題があります。

　RDBのテーブルを作成するにはCREATE TABLEすれば、いいことになります。

　CREATE TABLEで必要な内容は、

　　テーブル名、各項目名、型と大きさ、主キー、NULLを許さないかなどです。

　で、これは、テーブル一覧に書いてあるはずです。
　そこに書いてあることをCREATE TABLEの文法にそって、書いてください。

---

■ER図からテーブル作成
　ということは、ER図からテーブル一覧に落とせれば、
　あとは、上記のようにOKなわけです。

ところが、

●ER図の情報は、
　エンティティ、関係、１対多、項目名、主キー、外部キー

●テーブル一覧は、
　テーブル名、各項目名、型と大きさ、主キー、NULLを許さないかなどです。

ER図の情報に、型と大きさがないので、作成できないんです。実は。

したがって、データ定義などで、項目名から、型と大きさが分からない限り、作成できません。
逆に、コレが分かれば、テーブル一覧を（頭の中でもいいから）作って、CREATE TABLEで作成できます。

---

■ということで

　初めの目標、「入出力についてまとめたシート」は、例が画面用だったのではっきり書いてませんでしたが、テーブル用は、
　　主キー、外部キー、NULL禁止？が書いてあって、
　　外部キーのコメントのところには、
　　　　主キーになっているテーブルとの関係と、
　　　　それが複数あるかどうか（１対多か１対１か１対０か）
が書いてあるものとして、

　それを、上記の方法でやって、ER図がかける。。めでたしめでたし。。
　とします。

---

　次回のこのシリーズは、他の図を取り上げます
　

富士通が一般公開しているシステム開発方法論の、開発する手順をまとめてみたけど。。

　富士通は、開発体系ＳＤＡＳのうち、Ｊ２ＥＥベースでのシステム開発体系ＣｏｍｐｏｎｅｎｔＡＡを、
標準化規約1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
というところに公開しているというのは、以前かきました。

　そして、その公開している資料をもとに、

富士通が一般公開しているシステム開発で作成するドキュメント
http://blog.goo.ne.jp/xmldtp/e/3c0b16f086142f88c3201714b566abce

で、そのComponentAAで作成するドキュメントについて、まとめました。

　今回は、その公開されている開発標準の資料から、要求仕様から、詳細設計までの工程を（表題だけ）抜き出して、まとめて見ました。
（なお、抜き出し元は、ComponentAA開発標準 ドキュメント標準編1.0a版のPDF版、18および19ページの図です）

こんなかんじです。

---

■開発手順　

SA(要求仕様）段階
	(1) 業務要件定義
	(2) 業務機能分析、データ分析
	(3) 分析検証
	(4) 用語・データタイプ・コードの定義

UI(外部設計）段階
	(1) ユースケースの整理、統合
	(2) ユースケース機能概要および画面設計
	(3) 帳票設計
	(4) 外部システムインタフェース設計
	(5) テーブル・ファイル設計
	(6) 業務ロジック設計
	(7) 機能とデータの整合性検証
	(8) 説明資料作成

SS（構造設計)部分
	(1) CBMの概要設計
	(2) ユースケースの構成分割
	(3) C/S間インタフェース洗出し
	(4) CBSMsg設計
	(5) 画面アプリの構成設計
	(6) バッチの構成設計
	(7) 中間ファイル設計

PS(詳細設計）部分
	(1) CBSのロジック定義
	(2) 画面アプリのロジック定義
	(3) バッチのロジック定義

---

なお、これは、業務アプリ設計のみです。
このほかに共通部分等の設計方法があります（上記資料、２０ページ）
うーんと、表題だけ書いたら、説明が短すぎて、よくわかんなくなっちゃったね（＾＾；）
あと。。。仕様変更のときは、どーなるんだろうね（＾＾；）

PLCに反対してるって言うことが、アマチュア無線家の存在価値の１つだと思うけど？

やー、コメントはずしたんで、なんでもかけますね（＾＾）
コメントいれてたら、炎上しそうな話をひとつ。

ここのスラッシュドットニュース
経済学者 vs. アマ無線
http://slashdot.jp/askslashdot/06/12/20/2331202.shtml
によると（以下斜体は上記ニュースより引用）、

上武大学大学院客員教授の池田信夫氏が「アマチュア無線って必要なのか」というタイトルで書いたブログ記事が、もっか250以上(削除した上での数字)のコメントをつけられて「炎上」中らしい。氏のブログではPLCを擁護する一方で日本アマチュア無線連盟(JARL)を政治圧力団体と位置付け、アマチュア無線は今やユーザも少なく、インターネットの登場で不要になったのだから、1.2GHzバンドを開放しろと主張している。


そうな。。
ちなみに、その池田信夫氏のブログは、以下のURL
「アマチュア無線って必要なのか」
http://blog.goo.ne.jp/ikedanobuo/e/a3648c5745986bf6b6dd835dd635f5f6

---

　うん？？

　そもそも、PLCに反対しているっていうことが、アマチュア無線家が存在している１つの理由として、挙げていいのでは？

つまり、PLCの問題は、短波帯全体の問題だけど、短波を使っているのは

・ラジオ日経をラジオで聞いている、株好きのおじいちゃん、おばあちゃん
・外国から来た人で、自国の海外放送、あるいは自国語のラジオジャパンを聞く外国人
・船舶放送
・CB無線やってる人
・HF帯やってる、アマチュア無線家
・あと、あんまりないと思うけど、緊急放送
・ひょっとすると、外務省や通信社！？

などなど。。。

　で、PLCの雑音を軽減する措置というのは、結局、変調方式の問題とかにまで
入り込むと思う（たしか、なんかの変調方式をしているので、雑音が軽減された
と思う。自信ない。。なんだったっけかなあ。。？？）。

　で、メーカーが安全といっていても、その結果が、本当に安全なものかどうかを
判断するには、

　　その変調だと、この周波数域も影響あるはずでえ。。
　　だからあ。。。

　とか、そーいう、かなりディープな技術的な話題に入るはず。

　そーすると、それを分かる人は。。。
　株好きのおじいちゃんでは（＾＾；）
　外国人の人は、そもそも、日本語が（＾＾；）
　緊急放送・・・をする人っていわれても、緊急にならないとわからないしなあ。。
　CBやってる人は、わかんないと思うよ。あれ、勉強しなくてもOKだから（＾＾）

　ということで、船舶無線なんかの人と、アマチュア無線家。
　船舶無線とかやってる人たちは、自分たちのお仕事があって忙しい。

　なので、アマチュア無線家しか、いまのところ、PLC団体に反対する人たちがいない。

　もし、PLCに「技術的に」反対する人たちが居なかったら、本当は、短波帯に迷惑をかけてるのかもしれないのに、それを平気で使われてしまう。そういう意味で、反対する人たちと、賛成派で、裁判の上で、公正に戦う必要がある。
　PLC陣営が、本当に迷惑かけてないと思うなら、裁判で技術的に争えばいいだけのことだし。。

（念のために言っておくけど、国が認めたら、なんでも大丈夫っていうことは、ありえないよ。
　もしそうなら、薬害エイズ問題とか、起こらないはずだ）

　ってことで、PLC陣営が、短波帯に本当に迷惑をかけないかどうかを、チェックする人たちとして、今、アマチュア無線の人たちが必要って言うことは確かだ。
　その上で、言いか悪いかを判断するのは、法治国家である以上、裁判官になるけど。

　もしこれが、PLCにとって、アマチュア無線家が邪魔だから、お前ら要らないというのなら、日本が核兵器持つのに邪魔だから、反対論者は要らないっていうのと、同じ論理だと思う。。。

。。。とか、書くとコメントがくるんだよねー「わけわかんねー」って（＾＾）
よかった、コメントはずしておいて（＾＾；）