9-1.MySQLマスター①データベース設計と正規化
9章きたーーーー(｡>ω<)ﾉ
まだ半分いってないけど…毎日なんとか続いてリスと戦ってます。
前勉強してた時よりも、楽しんでやってる感があって、毎日リスをやることが習慣化してきてる。
といっても、明日は更新できないのだが。
そして、まだ半分だし、うろ覚えな部分が多いし、この記事を読んで初心者の人がわかるのか？というとダメな部分がほとんどだと思うから、調子に乗らないようにします。すみません。
さて、8章ではデータベースをSQLで操作するための基礎を勉強しました。
テーブルを作ったり、消したり、入れたり、変えたり、、、。
9章では、データベースを高速化し効率化するための設計方法を勉強します。
【目次】
1. データベースの設計
1-1.データベースの設計
1-2.主キー：リレーショナルデータベース
2. 正規化
2-1. 正規化
2-2. 第1正規形
2-3. 第2正規形
2-4. 第3正規形
1. データベースの設計
1-1.データベースの設計
1-2.主キー：リレーショナルデータベース
2. 正規化
2-1. 正規化
2-2. 第1正規形
2-3. 第2正規形
2-4. 第3正規形
1-1. データベースの設計
データベースは作成の前に、設計が命！らしい。
設計がずさんだと、データベースに戻ってテーブルの分割や結合、列の移動などの変更を行う必要があります。
データベースに、何が必要なのか？ユーザーが要求しそうなクエリは何だろうね？というのをぐじゃぐじゃと書き留めておくことが大事です。
◎例：オンライン書店の問い合わせの場合
・データベースにはどれだけの数の著書や本、顧客が登録されているのか？
・この本は誰が書いたものか？
・この著者の（複数の）著作は何か？
・最も高い本はどれか？
・最もよく売れている本はどれか？
・今年販売されなくなった本はどれか？
・この顧客が買った（複数の）本はどれか？
・その（複数の）本といっしょに購入されたのはどの本か？
などなど
ここからテーブルを作るとなった場合、
ある事柄に関し、多くの検索を実行する予定のあるときには、その事柄に専用のテーブルを持たせるとよいです。
また事柄同士の関係性が緩いときには、別々のテーブルに入れるのがベストです。
上記の例の場合、3つのテーブルが必要なことが推測できます。
①authors
各著者に関するさまざまな情報をその著者に関係づけて表示する
②books
同じ本でも出版社が違うものや、同じタイトルで中身がまったく別のものもあるので、本と著者のテーブルは別にする
③customers
顧客データは専用テーブルを入れる（顧客はどの著者のどの本でも自由に購入できるので）
1-2.主キー：リレーショナルデータベース
リレーショナルデータベースを利用すると、著者と本、顧客の情報を1ヵ所で定義することができます。
誰がその本を書いて、だれがその本を買ったのかという著者と本、顧客の関係性を3つのテーブルをリンクさせることで保持ができます。
その際は、「AUTO_INCREMENT」の機能を使います。
以下の例は、
idという名前の新しい列をオートインクリメント属性でclassicsテーブルに追加しています。
ALTER TABLE classics ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT KEY;
各々説明すると
・INT UNISIGNED
列が40億を超えるレコードが保持できる大きな整数をとれるようにします
・NOT NULL
すべての列が確実に値をもつようにします
・AUTO_INCREMNT
MySQLはすべての列のこの行について、必ず一意の値を設定するようになります
2-1.正規化
データをテーブルに分け、主キーを作成する過程を正規化といい、情報の各部分がデータベース内に確実に1度だけ現れるようにすることを目的とします。
データが重複すると、データベースが必要以上に大きくなり、アクセスに余計な時間がかかってしまいます。また、データを更新するとき重複したデータの1つの行しか処理しなかったという事態が起こり得るので、それによりデータに矛盾が発生し、エラーの原因になってしまいます。
最適なデータベース作成のための正規化について1から3まであるらしいので、みていきます。（さくっと）
2-2.第1正規形
第1正規形は、複数の列（水平方向の）にわたるデータの重複を処理します。
第1正規形の要求を満たすには、次の3つの要件をクリアする必要があります。
①同種のデータを含む繰り返しがないこと
②すべての列は単一の値を含むこと
③各行を一意に認識する主キーがあること
2-3.第2正規形
第2正規形は、複数の行（垂直方向の）にわたるデータの重複を処理します。
第2正規形を実現するには、テーブルの第1正規形の処理が終わっている必要があります。
第2正規形はその後、データが複数の箇所で繰り返されている列を特定し、それを専用のテーブルに移すことで実現できます。
2-4.第3正規形
データベースをさらに厳格にしたい場合、第3正規形がでてきます。
主キーに直接依存せず、テーブル内の別の値に依存するデータも、その依存性に応じてテーブルに移すことが求められます。
第3正規形による正規化をやるのか？という判断は、以下2つを検討したうえで決めたほうがいいよーとのことです。
①そのテーブルには新しい多くの列を追加する可能性があるのか？
②そのテーブルのフィールドは今後、ある時点で全体的に更新する必要があるのか？
い、いじょーーーー
リスにのってる表を見ながらだと、正規化ってすげーかしこい頭いい秀才すげーってなるけど、それをうまく書けない。。。
とりあえず、先に進みます。
