今日は一日中データベースのテーブルの設計をしてました。
（裏でVistaインストールしていたことは内緒です）
そんな訳で、今日のネタは
初心者向け
のテーブルの設計についてです。
早速ですが、テーブルの設計をする場合の注意点は次の通りです。（他にもあるかもしれませんｗ）
・必要情報を明確にする。
・正規化を行う。
・インデックスを付ける。
・最も適している型を選択する。
そう言われても何のこっちゃわからないと思う（初心者ですからね）ので、とりあえず図書館の本の貸し出し管理を行うシステムのデータベースを設計する場合を考えてみます。
(1) どんな情報が必要なのかを明確にする。
本の貸し出し管理ですから、必要であろう情報は「誰にいつ何を貸し出したのか？」ということです。
そして「それがいつ帰ってきたのか？」も知りたいですよね。
これを、ノートに手書きして管理した場合、次のような表を用意すると思います。
| 連番 |
貸出日 |
利用者番号 |
利用者氏名 |
書籍番号 |
書籍名 |
返却日 |
| 1 |
|
|
|
|
|
|
| 2 |
|
|
|
|
|
|
| 3 |
|
|
|
|
|
|
| 4 |
|
|
|
|
|
|
| 5 |
|
|
|
|
|
|
| 6 |
|
|
|
|
|
|
で、上から順に記入していく訳です。
利用者番号は、同姓同名の人がいた時、どちらの人なのかをきちんと分けるためのものです。
他人の名前を語って本を借りたまま返さない人がいたら困るので、利用者カードを提示してもらうようにします。
書籍番号は、同じ本が複数ある場合を想定して、１冊ごとに異なる番号が振られているという前提です。
これを単純にテーブルに置きかえると次のようになります。
貸出履歴テーブル
・連番
・貸出日
・利用者番号
・利用者氏名
・書籍番号
・書籍名
・返却日
(2) 正規化を行う。
さて、この表を運用した場合、あなたが面倒だと思うことは何でしょうか？
恐らく人気のある本や、よく利用する人の名前を何度も書くことだと思います。
つまり、この表をテーブルとして定義した場合、利用者氏名・書籍名が繰り返し登場するごとに無駄なデータを溜め込むことになってしまいます。
これでは、効率の良い処理は望めません。
そこで、次のように３つの表に分けることにします。
利用者名簿テーブル
・利用者番号
・利用者氏名
書籍名簿テーブル
・書籍番号
・書籍名
貸出履歴テーブル
・連番
・貸出日
・利用者番号
・書籍番号
・返却日
これなら、同じ本が100人の人に貸出されても、書籍名が記録されているのは、書籍名簿テーブルの１ヶ所だけです。
テーブルの数は増えてしまいますが、何度も貸出される本、よく利用する人の名前を毎回記録する必要が無い分だけ、データの総量は減ることになります。
(3) インデックスを付ける。
辞書で何かを調べる際、、一般的には索引から目的の語句を探し、そのページを開きます。
つまり、インデックスを付けるというのは、どの項目の索引を作るのかと言う意味です。
先ほどのテーブルにインデックスを付けてみます。
利用者名簿テーブル
・利用者番号(キー)
・利用者氏名
書籍名簿テーブル
・書籍番号(キー)
・書籍名
貸出履歴テーブル
・連番（キー）
・貸出日
・利用者番号（インデックス）
・書籍番号（インデックス）
・返却日
(4) 最も適している型を選択する。
これらはセットで考えます。
データアクセスや管理の効率を上げるためには、適度な型を付加すれば良いのです。
これらの型は、SQL Server や Oracle など様々な DBMS ごとに微妙に異なっているので、ここでは詳細には触れません。
数字で表現できるなら、数値で表現するようにして、文字列系の型は使わないようにします。
例えば、利用者番号が全て数字で表されているなら、数値系の型を使います。
また、数値系の型も、格納できる値の範囲があり、文字列系の型なら、桁数（最大桁数）を設定する場合が多いのですが、ここでも必要以上に大きく取らないようにします。
例えば、書籍名を文字列系の型にした時「何桁分を確保するのか？」を考えると、つい「長いタイトルの本でも入力できるように多めにしておこう」と思ってしまいがちです。
しかし、必要以上に大きく桁数を設定してはいけません。
以上です。
データベースの設計は、まだ終わってないので、明日も同じようなネタになるかも・・・