3.リレーショナルデータベース

テーブル

データベースのデータは「テーブル」という入れ物に入っていますｗ
テーブルは表みたいなものですｗ

Amazonのようなショッピングサイトであれば、以下のように顧客の情報は顧客テーブルにデータを入れ、商品の情報は商品テーブルに入れ、顧客が注文した商品の情報は注文テーブルにデータを入れますｗ

顧客テーブル

ユーザID	名前	住所
tarou	太郎	東京都１丁目
zirou	次郎	北海道２丁目
hanako	花子	福岡県３丁目

商品テーブル

商品番号	商品名	価格
0001	薬草	10円
0002	聖水	30円
0003	銅の剣	100円

注文テーブル

注文番号	ユーザID	商品番号
1	tarou	0001
2	tarou	0003
3	hanako	0002
4	zirou	0001

上記を見ると分かりますが、ユーザIDや商品番号でテーブル間が関連を持っていますｗこの関係をリレーションシップと呼びますｗ
図にすると、以下のような感じですｗこういう実態(データ:Entity)と関連(Relationship)の図をER図(EntityRelation図)と呼びますｗ

主キー(PrimaryKey)

テーブルの中でデータを一意に特定できる列を主キーと呼びますｗ
顧客テーブルであれば、ユーザIDですｗ
商品テーブルであれば、商品番号ですｗ
例えば、とある顧客のユーザIDが「tarou」と分かれば、その顧客の氏名も住所も分かりますｗ

外部キー

主キーではないが、外部のテーブルと関連を持つキーとなる列を外部キーと呼びますｗ
注文テーブルでのユーザIDと商品番号が外部キーとなりますｗ

正規化

上記の３つのテーブルは実はわざわざ３に分けなくても、実は１つのテーブルで実現可能であることはお気づきでしょうか？

注文顧客テーブル

注文者名	注文者住所	注文商品名	価格
太郎	東京都１丁目	薬草	10円
太郎	東京都１丁目	銅の剣	100円
花子	福岡県３丁目	聖水	30円
次郎	北海道２丁目	薬草	10円

上のようなテーブルを一つ作れば、表現できますｗ
しかし、このようなテーブルだと、顧客の住所が変更になった場合、２箇所を書き換えなければなりませんｗ
同じデータを二重も持つので、データ量も増えますｗ
また、顧客情報を別のテーブルでも使用している可能性もありますｗ

このような理由から１つに出来るテーブルでもシステムの都合の良い形にテーブルを分割していきますｗ
分割しておけば、データの更新は一箇所で良く、データを読むときだけ、注文顧客テーブルの形にして取得しますｗ
どこまで分割するかはシステムの挙動に応じて、考える必要がありますｗ
ですので、画面設計や機能設計など、システムの動きを考えるレベルの設計と同時にテーブルを設計していきますｗ