画面項目からDBのテーブル設計をする方法 フロントからサーバーサイドへの移行法

　フロントのほうの設計方法は、ギャレットの「ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザイン」で、「戦略、要件、構造、骨格、表層」っていう５つの段階で考えればよい手順が示されている。

で、これを、サーバーサイドのDBに持ってくる方法に関しては、DBはDBで、設計方法はあるけど（正規化理論）、それをどう使うのか、書いていない。

ざっくり書いておく

---

■フロントの画面項目から、テーブルを出す方法

１．各画面の入力項目、出力項目を出していく

　　ワークショップ風にやるなら、入力項目１項目１付箋紙をつかうといい。
　　例：ログイン画面で、「ログイン名」で１枚の付箋紙、「パスワード」でもう一枚の付箋紙の感じ

２．その項目を、グループごとにまとめる。
　　（２－１）項目を●●のXXという形でわざと表現する
　　　→ログイン名＝ユーザーのログイン名、パスワード＝ユーザーのパスワード
　　　　受注日＝受注した日

　　（２－２）そしたら、●●がグループ、上記の例だと、ユーザーや受注でグループを作る
　　　　DBに保存しないもの：操作（～ボタン、並び替え順など）は、ひとまとめのグループに

　　（２－３）グループに表題をつける
　　　　付箋紙にグループ名を書く場合、色を変えたほうがいい


３．グループの表題１レコードに対して、各項目は１個かどうか確認する
　　１個で無かったら、（たとえ１項目でも）別グループにする
　　　→すでに出来ているグループに所属するのでなければ・・

　　ユーザー１人に対し、ログイン名は１つであれば、ログイン名はユーザーグループ
　　ログイン日は、複数考えられるので、別グループに分ける

　　→この操作が終わると、第一正規形が完成する

４．各グループごとの関係をいれる
　　グループA,Bとあったとき、A１件に対して、Bが何件もあったら１対多
　　逆は多対１、両方有り得たら多対多。これをいれる

５．IDをつける
　　各グループで、グループ名＋IDのIDをつける
　　　→１件に１つのもので、IDになりえるものがあったら、わざわざIDを
　　　　ふらなくてもよい。
　　　　　例：ユーザーテーブルのログイン名
　　　　　　（振っても良い：その場合IDはユーザーIDとなる）

６．外部キーを入れる
　　４の操作で、１対多の場合、多のグループに１のグループのIDを追加する

７．各グループをみて、
　　この項目がきたときは、この項目がからなずきている！というのが無いかさがす
　　例：都道府県と地域（関東、関西など）
　　　　→ユーザーからみると、どちらも１対１だが・・
　　もしくは、ロジック的にこの項目のこの値が決まると、他の項目の値が
　　推測できるものを探す。
　　　それは、別グループにわけ、IDを振って、IDだけを、もとのグループに入れる

　　→この操作が終わると、第三正規形が完成する

８．ER図にまとめる
　　　　エンティティ＝グループ（エンティティ名＝グループ名）
　　　　アトリビュート＝項目（付箋紙１枚１枚）
　　　　関係：４でつけた
　　→ER図に書ける

　　なお、テーブルをつくるときは
　　　　エンティティ＝テーブル（エンティティ名＝テーブル名）
　　　　アトリビュート（属性）＝テーブルのカラム（各項目）
　　　　関係：６で外部キーをつけた
　　　　主キー：５で割り振った
　　となる。

９．シナリオに沿って動かしたとき、テーブルのデータが生成、参照、変更、削除
　　されるか、矛盾ないか確認

---

ここでは第二正規形の議論は起こらない（複合キーがないので）
その理由は別のときに・・・

佐野氏デザインの五輪エンブレム使用中止へ

だって。


佐野氏デザインの五輪エンブレム使用中止へ　組織委が方針固める
http://headlines.yahoo.co.jp/hl?a=20150901-00000095-spnannex-spo