ER図頭痛い。
ま～、最初からサクサクこなせるもんでもないわな。元気出していってみよう～。
2、論理：
論理設計では、抽出できたエンティティ同士を関連づける（リレーションシップ）のがキモのようです。
第2回 30分間データモデリング ～ER図を描こう！～＞■リレーションシップを設定しようを読むと以下のように書かれとります。
リレーションシップを設定するためには、各エンティティに「主キー」を設定する必要がある。
「主キー」実は「その(75) sqlite3でお勉強」を書く過程で学習したんだけど、あの時のテーブルには必要なかったんでブログ自体には書いてない。ただし結構重要な属性（プライマリキーとも言うらしい）。
テーブルの中の特定のレコード（1行）を特定できる値です。
この花は？で言えば提案エンティティは名前候補とコメントという属性を持っているけど、いろいろな提案がなされると、中には名前候補、コメント、両方一緒という提案インスタンスが出てくる。
下線部が一致しちゃって名前候補、コメントどっち使っても、1番目の行か3番目の行か特定できない。
この場合にちゃんと提案インスタンスBだけを指定するためには主キーが必要になるわけですわ。
ということで各エンティティに主キーを設定。
次に出てくるのが
依存型エンティティの場合、子エンティティの主キーに親エンティティの主キーを含める。
ふむふむ、依存型エンティティとは、親のエンティティの存在無しには存続できないエンティティを指すのね。
この花は？の場合、提案は投稿に、投票は提案に依存するので各親エンティティの主キーを設定ですな。花の写真は投稿に依存させない予定なので設定しない。
でそれぞれの関連（リレーションシップ）を設定すると、投稿インスタンスは複数の提案インスタンスと関連し、提案インスタンスは複数の投票インスタンスと関連を持つので
といったものになる。この関連を表してる線はIE記述とかいうらしい。他にもIDEF1Xとかいろいろあるみたい。詳しくは上のサイトを読みましょう。
この程度なら楽勝なんですが、もうちょっと入り組んでくると関連づけも大変。
整理の過程で利用されるのが「正規化」という手法で、1～3段階の正規形、ボイスコッド正規形、4、5段階の正規形への正規化というものが利用されるみたいです。
ただし、今回のこの花は？レベルじゃ、ボイスコッドや4、5は発生しないみたいですな。
とりあえず、1～3の正規形への推移を勉強の意味であらためて書いてみると
まず、正規化されていない一覧表を用意。
ここから、繰り返し（例えば投稿ID=1は3行繰り返されているし、提案ID=1も2行繰り返されている）を別の表にすることで第１正規形（first normal form:1NF）を作成。
ここから部分従属性（写真IDがあればURLは導きだせる）を取りはぶき第２正規形（2NF）作成。
ここから推移関数従属性（支持率は投票インスタンスを数える事で計算できる）を取りはぶき、第３正規形（3NF）完成
で、これを元にER図のエンティティやリレーションを導きだす。らしい。実際はこの正規化作業とER図をいったりきたりしながら最適な構成を考えるってとこなのかな～。
ま～、とりあえず、ここらで実際に作ってみましょう。
ボイスコッドNFや4NF、5NF、データベースエンジニアへの道（4）～（6）は各自自習ということで、ひとつ。もしかしたらこの花は？のリリース版作る時に取り上げる事になるのか？謎。
次回、MySQLでのテーブル作成と取り出し、アーンド、Webページ上でのデザイン！
ま～、最初からサクサクこなせるもんでもないわな。元気出していってみよう～。
2、論理：
論理設計では、抽出できたエンティティ同士を関連づける（リレーションシップ）のがキモのようです。
第2回 30分間データモデリング ～ER図を描こう！～＞■リレーションシップを設定しようを読むと以下のように書かれとります。
リレーションシップを設定するためには、各エンティティに「主キー」を設定する必要がある。
「主キー」実は「その(75) sqlite3でお勉強」を書く過程で学習したんだけど、あの時のテーブルには必要なかったんでブログ自体には書いてない。ただし結構重要な属性（プライマリキーとも言うらしい）。
テーブルの中の特定のレコード（1行）を特定できる値です。
この花は？で言えば提案エンティティは名前候補とコメントという属性を持っているけど、いろいろな提案がなされると、中には名前候補、コメント、両方一緒という提案インスタンスが出てくる。
| 名前候補 | コメント |
|---|---|
| 蓮 | だと思います。 |
| チューリップ | でしょうか？ |
| 蓮 | だと思います。 |
下線部が一致しちゃって名前候補、コメントどっち使っても、1番目の行か3番目の行か特定できない。
この場合にちゃんと提案インスタンスBだけを指定するためには主キーが必要になるわけですわ。
| 主キー | 名前候補 | コメント |
|---|---|---|
| 1 | 蓮 | だと思います。 |
| 2 | チューリップ | でしょうか？ |
| 3 | 蓮 | だと思います。 |
ということで各エンティティに主キーを設定。
次に出てくるのが
依存型エンティティの場合、子エンティティの主キーに親エンティティの主キーを含める。
ふむふむ、依存型エンティティとは、親のエンティティの存在無しには存続できないエンティティを指すのね。
この花は？の場合、提案は投稿に、投票は提案に依存するので各親エンティティの主キーを設定ですな。花の写真は投稿に依存させない予定なので設定しない。
でそれぞれの関連（リレーションシップ）を設定すると、投稿インスタンスは複数の提案インスタンスと関連し、提案インスタンスは複数の投票インスタンスと関連を持つので
といったものになる。この関連を表してる線はIE記述とかいうらしい。他にもIDEF1Xとかいろいろあるみたい。詳しくは上のサイトを読みましょう。
この程度なら楽勝なんですが、もうちょっと入り組んでくると関連づけも大変。
整理の過程で利用されるのが「正規化」という手法で、1～3段階の正規形、ボイスコッド正規形、4、5段階の正規形への正規化というものが利用されるみたいです。
ただし、今回のこの花は？レベルじゃ、ボイスコッドや4、5は発生しないみたいですな。
| 前回のようにいきなりエンティティを分別する手法以外に、こういった全項目での表を用意して正規化によってエンティティを分別する手法もあるってことなのかな～。う～ん、謎ですわ。 |
とりあえず、1～3の正規形への推移を勉強の意味であらためて書いてみると
まず、正規化されていない一覧表を用意。
| この表自体をどうやって考えだすんだよって話になりそうだけど、特にこれといった方法は見つからなかった。私は頭の中で投稿、提案、投票がおこなわれて表が組み上がっていく状態をシミュレーションして考えました。 |
ここから、繰り返し（例えば投稿ID=1は3行繰り返されているし、提案ID=1も2行繰り返されている）を別の表にすることで第１正規形（first normal form:1NF）を作成。
| これ、奥村教授の第1正規化の説明と微妙に違うけど、どっちなんだろうね～。 |
ここから部分従属性（写真IDがあればURLは導きだせる）を取りはぶき第２正規形（2NF）作成。
ここから推移関数従属性（支持率は投票インスタンスを数える事で計算できる）を取りはぶき、第３正規形（3NF）完成
で、これを元にER図のエンティティやリレーションを導きだす。らしい。実際はこの正規化作業とER図をいったりきたりしながら最適な構成を考えるってとこなのかな～。
ま～、とりあえず、ここらで実際に作ってみましょう。
ボイスコッドNFや4NF、5NF、データベースエンジニアへの道（4）～（6）は各自自習ということで、ひとつ。もしかしたらこの花は？のリリース版作る時に取り上げる事になるのか？謎。
次回、MySQLでのテーブル作成と取り出し、アーンド、Webページ上でのデザイン！
| 追記： ER図作図ツール調べてみました。 有料 VISIO Windows用っていうかマイクロソフト製品。プロフェッショナル版のみにER図作図機能があるみたい。SQL出力、データベースのテーブル情報からER図を起こしてくれるDBリバースもあるような。 OmniGraffle Mac用で、使ってるんですがOmniGraffleバージョン4愛用してるんですけど、こいつのER作図機能はそれほどって感じ。バージョン5のプロ版はVISIOのファイルを読めるとか書いてるな... JUDE/Professional Javaなんでプラトフォーム非依存。こいつのフリー版JUDE/Communityも愛用してるけど、ER作図機能はProfessional版でないと使えないみたい。DBリバース、SQL出力もできるみたい。 フリー DBDesigner 4 MySQLとの親和性も高いらしい。 ただしWin用とLinux用だけみたい。Linux用はX WindowいれればOS Xでも動くとは思うけど... |