contents menu
since 2006.04.01管理人 : Ryo
mail : infinity_above_zero@yahoo.co.jp
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
基本情報技術者試験でも必ずのように出題される、OSI基本参照モデル。
「アプセトネデブ」という順番だけ覚えていても、
問題が解けるとは限りません。
どの層がどんな役割なのか、ごちゃごちゃになってしまう事もよくあります。
前回の関数従属性と正規化 (3)で、
あえて正規化を完成させないことがよくある、とお話ししました。
どういうことか、第3正規形を見ながら考えてみます。
関数従属性と正規化 (2)で、
ようやく第2正規形が完成しました。
db_format2.html
ただし、レシート表をよく見てください。
店舗の情報(店舗名、店舗住所、店舗電話番号)が完全に重複していますね。
各レシートでは、「どこの店で買ったか」の情報さえ残っていればいいので、
レシート表には店舗名だけを残し、新たに「店舗表」を分離させましょう。
そして、今回のレシートではレジ担当者は別の人な訳ですが、
同じ従業員が違う客相手に何度もレジを打っているはずなので、
レシートをもっと集めれば担当者情報(担当者No.、担当者名)の重複も出てくるはず。
各レジ担当者には「担当者No.」という番号が振られているので、
同じように「担当者表」を分離させます。
ここまでの作業で、このような5つの表が出来上がります。
db_format3minus.html
これで第3正規形の完成……ではありません。
データベースの勉強で、正規化の付近でつまづく人も多いと思います。
「これが決まれば、そっちが決まる」というような、数学的考え方も必要ならば、
プログラムの処理効率なども考えなきゃならない。
でも実際のところ、 そんな難しいこと考える必要ないです。
例えば、とあるドラッグストアのレシートをデータベース化したいと思います。
続きを読む次のような2つの表があったとします。
| 学籍番号 | 氏名 |
|---|---|
| 001 | 大川大輔 |
| 002 | 田中麻衣 |
| 003 | 柳原智也 |
| 学籍番号 | 部活 |
|---|---|
| 001 | 野球部 |
| 001 | 陸上部 |
| 002 | 美術部 |
| 003 | 陸上部 |
| 003 | 美術部 |
この2つの表のうち、共通している「学籍番号」を合わせて表を繋げる、それが「表結合」です。
上の例だと、こうなります。
| 学籍番号 | 氏名 | 部活 |
|---|---|---|
| 001 | 大川大輔 | 野球部 |
| 001 | 大川大輔 | 陸上部 |
| 002 | 田中麻衣 | 美術部 |
| 003 | 柳原智也 | 陸上部 |
| 003 | 柳原智也 | 美術部 |
まさに「各部ごとの部員一覧」ですね。
この表を見ると、大川大輔くんは野球部と陸上部に、
田中麻衣さんは美術部に、
柳原智也くんは陸上部と美術部に所属している事がわかります。
1つ目の表を「学生名簿」、2つ目の表を「部活所属表」とします。
この表結合を、SQL文では
SELECT * FROM 学生名簿, 部活所属表
WHERE 学生名簿.学籍番号 = 部活所属表.学籍番号
または
SELECT * FROM 学生名簿 INNER JOIN 部活所属表
ON 学生名簿.学籍番号 = 部活所属表.学籍番号
と書きます。