関係データベースについて（ＩＴパスポート）

ＩＴパスポートの勉強をしているのですが、その中で関係データベースについて参考書やネットで検索をしてもまったく理解ができません。
下記の２点の問題についてですが、回答の解説を読んでも理解が全くできず、なぜこの答えが正しいのかがわかりません。
できるかぎり詳しく解説をして頂ければと存じます。

(1)
問）関係データベースにおいて主キーを指定する目的はどれか？

答）主キーに指定した属性（列）で、レコード（行）を一意に識別できるようにする


(2)
問）関係データベースを利用する際に、データの正規化を行う目的として、適切なものはどれか？

答）データが重複したり、データの更新の際に矛盾が生じたりしないようにする。

No.3 回答者： mitoneko 回答日時： 2014/06/21 22:52

　この解答が正しいことだけを説明するなら、たいしたことでは無いのですが・・・

　まぁ、先にやっておきましょうか。

　（１）主キーの存在理由。
　関係データベース（普通は、リレーショナルデータベースとカタカナで書かれることが多いですね。）は、数学の集合論をベースにした理論体系です。
　まず、集合には、行の順序はありません。これを理解しておいてください。
　社員の住所を記載した従業員表を作るとしましょう。このとき、Ａさんのデータが欲しい時に、どうやって、Ａさんを指定するかというのが問題です。（Ａさんの住所を調べたい時にも必要ですし、Ａさんが引っ越したから住所を変更するという時にも必要ですね。Ａさんが退職した時にも、まずＡさんのデータを指定する必要があります。ありとあらゆる操作の基本操作です。）
　従来のファイル形式のデータや表計算ソフトですと、１番目のデータとか５番目のデータとかいう表現が出来ますが、関係データベースでは、この表現は不可です。先に書いたように順序が無いからです。
　では、Ａさんの名前で行を指定しましょうか？もし、同姓同名の人がいたらどうしますか？（あり得ない話ではありません。というか、比較的良くある話です。）
　普通は、社員番号を一人に一つづつ割り振り、社員番号で行を指定します。これなら、絶対に重複することはありません。（というか、重複しないように割り振るという方が正しいですね。）この社員番号が主キーになります。
　これは、この従業員表を使う全ての手続きにおいて、必ず社員番号が指定されていることを表します。平たい言い方をすれば、会社に出す申請書類や報告書類には必ず社員番号が書いてあるということです。
　ちなみに、もし、他に社員を完全に一意に決められる属性があるなら、別に社員番号をわざわざ作る必要はありません。例えば、この国では、法律で、「同じ日に産まれた人は絶対に違う名前で無ければならない」と決められていたします。そうすれば、社員番号は実は不要です。主キーは、（名前・生年月日）の組で表すことが出来ます。
　これが主キーの存在意義であり、主キーの定義の一部です。

　（２）正規化の意義
　引き続き、従業員データベースを例に。従業員には、所属課があります。当然、課には、課長がいます。課長も従業員ですから、住所も電話番号もあります。
　これを１行に全部登録することは可能です。
　従業員番号・名前・住所・電話番号・課名・課長社員番号・課長名・課長住所・課長電話番号
　という表を作ったとしましょう。
　課長の住所は、この表にいったい何回現れるでしょうか？まず、課長の自分のレコードに一回。課員全員の課長住所として、課員の数だけ。おんなじデータを何回も何回も登録するのは、ディスクスペースの無駄だと思いませんか？これが、データの重複です。
　この表には、まだ問題があります。これは、人事異動の季節に顕在化します。課長さんがめでたく栄転され、新しい課長さんが着任されました。さぁ、問題です。この表の何行を直す必要があるでしょうか？はい。課員全員の課長の属性全部と、元課長自身の所属に、新任の課長自身のレコードをちゃんと直す必要があります。一つでもやり忘れたら、元課長さんは、元部下を道連れに転任したことになってしまいます。
　このようなことが起こらないように、表の形を、決まった形で変形していくのが、正規化というプロセスです。

　さて、答えの解説は、終わり。
　なんですが・・・実は、これ、データベース理論の本なら、第一章の中に書いてある内容です。つまり、スタート地点なんです。
　この段階で既に引っかかっていると言うことは、データベースの学習を何もしていないと想定できます。
　できれば、データベースの理論書を探して（どんな物でもかまいません。ＭｙＳＱＬやＳＱＬＳｅｒｖｅｒやその他、特定のデータベースの入門書でもかまいません。）一冊読みこんでおくと良いでしょう。
　残念なことに、データベースの理論は、ｗｅｂの断片的な情報だけでは理解することが、わりと難しい分野です。基礎から順番に理解していく必要があるからです。

この回答へのお礼

ご回答を頂きありがとうございます。
参考にさせて頂きます。

お礼日時：2014/07/20 09:59

No.2 回答者： ngwave 回答日時： 2014/06/21 22:21

(1)

例えば名簿に鈴木一郎という人の「名前」「住所」「生年月日」が入っているとする。
「名前」を主キーにしたら同姓同名の人がいると、破たんするでしょう。
なので、
「名前」＋「住所」で主キーにしたり、
会員番号のようなものを作って主キーにしたりして、レコードを一意に識別（特定可能）にするのが主キーの役割です。

ID01,鈴木一郎,東京都千代田区,1979-01-01
ID02,佐藤学,兵庫県神戸市北区,1985-01-01
ID03,鈴木一郎,大阪府大阪市中央区,1968-01-01



(2)
さっきの人達と、その兄弟をデータにする場合、
ID01,鈴木一郎さんは、姉が３人
ID02,佐藤学さんは兄と妹
ID03,鈴木一郎さんは一人っ子
とすると、

横につなげると、わけわかんない
ID01,鈴木一郎,東京都千代田区,1979-01-01,姉,長女,鈴木泪,姉,次女,鈴木瞳,姉,三女,鈴木愛
ID02,佐藤学,兵庫県神戸市北区,1985-01-01,兄,長男,佐藤太郎,妹,長女,佐藤花子
ID03,鈴木一郎,大阪府大阪市中央区,1968-01-01

そのまま分割すると、前半部分が重複して（ダブって）しまう
ID01,鈴木一郎,東京都千代田区,1979-01-01,姉,長女,鈴木泪
ID01,鈴木一郎,東京都千代田区,1979-01-01,姉,次女,鈴木瞳
ID01,鈴木一郎,東京都千代田区,1979-01-01,姉,三女,鈴木愛
ID02,佐藤学,兵庫県神戸市北区,1985-01-01,兄,長男,佐藤太郎
ID02,佐藤学,兵庫県神戸市北区,1985-01-01,妹,長女,佐藤花子
ID03,鈴木一郎,大阪府大阪市中央区,1968-01-01

この状態で、ID01,鈴木一郎が婿養子になって苗字が変わり、渡辺一郎になったら、ダブってるところを意識して全部変えないといけない。
うっかりすると、１つ変更し忘れると、データが矛盾する。
ID01,渡辺一郎,東京都千代田区,1979-01-01,姉,長女,鈴木泪
ID01,渡辺一郎,東京都千代田区,1979-01-01,姉,次女,鈴木瞳
ID01,鈴木一郎,東京都千代田区,1979-01-01,姉,三女,鈴木愛

正規化して、分割し、主キーで関係付ける事で、重複も矛盾もなくなる。
テーブル１（自分データ）
ID01,鈴木一郎,東京都千代田区,1979-01-01
ID02,佐藤学,兵庫県神戸市北区,1985-01-01
ID03,鈴木一郎,大阪府大阪市中央区,1968-01-01

テーブル２（兄弟データ）
ID01,01,姉,長女,鈴木泪
ID01,02,姉,次女,鈴木瞳
ID01,03,姉,三女,鈴木愛
ID02,01,兄,長男,佐藤太郎
ID02,02,妹,長女,佐藤花子

この回答へのお礼

ご回答を頂きありがとうございます。
参考にさせて頂きます。

お礼日時：2014/07/20 10:00

No.1 回答者： lv4u 回答日時： 2014/06/21 22:08

>>できるかぎり詳しく解説をして頂ければと存じます。

参考書やネットで検索された記事を読まれて、まったく理解ができないのですね？
一般的に、書籍は、ていねいな解説文や図版がついています。ここでそれ以上の詳しい説明なんてできないでしょう。

たぶん、足し算・引き算しか判らない小学生が「微分・積分がわかりません。できるかぎり詳しく解説をしていただければと存じます」とお願いしている状況でしょう。
まずは、関係データベース以前の勉強をしっかり行ってください。

この回答へのお礼

ご回答を頂きありがとうございます。
参考にさせて頂きます。

お礼日時：2014/07/20 10:00