Web Analytics Made Easy - StatCounter

工業大学生ももやまのうさぎ塾

うさぎでもわかるをモットーに大学レベルの数学・情報科目をわかりやすく解説! 数式が読み込まれない場合は1回再読み込みしてみてください。

【基本情報対策】うさぎでもわかるデータベース 第01羽 関係データベース(主キーと外部キーの違い)

こんにちは、ももやまです。

最近忙しすぎて全然ブログを書くことに集中できていませんでしたが、久しぶりに更新をしていきたいと思います。 

今回から数回に分けてデータベースについて説明していきます。

初回となる今回は、データベースの中で一番出てくる関係データベースについて、用語などを確認しながら見ていきましょう。

1.関係データベース (リレーショナルデータベース)

(1) 関係データベースとは

関係データベースでは、データをExcelのような2次元の表として管理します。リレーショナルデータベースと呼ぶ人もいます。

 

下のような2次元の表として管理するので、我々人間にとって非常に確認をしやすいといえます。

f:id:momoyama1192:20200903194702g:plain

データベース単元では、基本的に関係データベースの操作方法、管理方法についてお勉強していきます。

 

 

 

(2) 用語紹介

ここからは、関係データベースでよく出てくる単語について確認をしていきましょう。

(a) 行と列

データベースの世界では、

  • 行のことをレコード、タプル
    (それぞれのデータを特定するのが行)
  • 列のことを項目、フィールド、属性
    (それぞれの項目を特定するのが列)
  • 表のことをテーブル

と呼ぶこともあります。

f:id:momoyama1192:20200903194707g:plain

(3) 関係データベースとスキーマ

データベースに格納されているデータの種類を表したものをスキーマといいます。

 

関係データベースの場合、2次元の表の「テーブル名と項目」を格納したものがスキーマ*1となります。

f:id:momoyama1192:20200904083855g:plain

なお、データベースの試験の場合、データベース内に格納されているデータは関係スキーマの形で表されることが多いです。さらに、

表名 ( 項目名1, 項目名2, 項目名3, … )

と省略した形で書かれることが基本です。

 

例えば、上の学生一覧だと、関係スキーマの省略形は、

学生一覧 (学生番号, 氏名, 部活)

となります。

2.主キー

(1) 主キーとは

この列を見れば、必ず各データを特定することができる!という列のことを主キーと呼びます。

言われてもわかりにくいと思うので、先ほどの表で確認しましょう。

f:id:momoyama1192:20200903194711g:plain

この表には、学生番号、氏名、部活の3つの項目があります。

 

学生番号は、必ず各個人で異なりますよね*2。そのため、学生番号は主キーです。

別に氏名でも各個人特定できるじゃん。と思った方もいると思います。しかし、運悪く同姓同名の人が入ってしまうことが考えられるので、各データを特定することはできません*3

 

主キーとなる項目は、学生番号、受験番号、社員番号などの個人を特定する番号番号(ID)がほとんどです。

(2) 主キーに選ばれる項目の条件

主キーは、各個人を1つに特定できるような項目でなければなりません。

そのために、以下の2つの条件が課されます。

  • データが一意であること(重複するデータがないこと)
    → 同じデータが2つ以上あるとデータを1つに特定できません
  • NULLではないこと(値が設定されていないデータがないこと)
    → データが空だと、当然特定をすることができません。例えば、答案用紙に受験番号を忘れると、だれの答案用紙かわかりませんよね。

(3) 主キーの組み合わせ・複合キー

1つの項目だけではデータを特定できないけど、2つ以上の項目を組みあわせれば1つに特定できる場合があります。

このように、複数の項目を組みあわせて主キーとしたもの複合キーと呼びます。

 

例えば学校の組ごとに出席番号が振られているとします。

 

f:id:momoyama1192:20200903194715g:plain

このとき、出席番号だけを主キーにしてしまうと、どの組(or 学年)かわかりません。

 

しかし、学年、組、番号の3つがすべて異なればほかの人と重複することはありませんね。

そのため、「学年、組、番号」の3つの項目を組みあわせて主キーとして組み合わせれば各個人を特定できる複合キーとなりますね。

(4) 主キーになるかも・候補キー

主キーとなりうる項目、つまりデータを1つに特定できる項目のことを候補キーと呼びます。

データを特定できる項目(候補キー)が2つ以上ある場合、特定できる列の中から1つを選び、主キーとします。

 

例えば、下の表のように学生番号と(試験のとき用に使った)受験番号が両方入っているとしましょう。

f:id:momoyama1192:20200903194719g:plain

学生番号は、学校の中で個人(それぞれの行)を識別するための番号なので、当然各個人を識別することができるデータだといえます。

今回は学生番号を主キーとしたいと思います。

 

同じく、受験番号も受験する人の中で個人を識別するための番号なので、各個人を識別できます。

 

そのため、候補キーは学生番号、受験番号の2つとなりますね。

(すでに特定に使っている主キーも候補キーに入るので注意)

 

なお、候補キーの中で、主キーとして使っていないキーのことを代替キーと呼びます。

 

 

主キーで覚えるべき用語

主キー:各データを1通りに特定することができる項目(列)

複合キー:複数の項目を主キーとすることで各データを1通りに特定することができる項目

候補キー:主キーとなりうる候補となる項目

 

主キーとなる項目にかけられる制約

  • データが一意であること(重複するデータがないこと)
  • データが空ではないこと

 

3.外部キー

(1) 外部キーとは

関係データベースでは、複数の表同士を対応付ける場面が出てきます。その際、どのデータを使って表を対応づけるかを決める必要があります。

 

例えば、下の2つの表があるとします。

f:id:momoyama1192:20200903194723g:plain

 下のように学生一覧にある部活IDから、部活一覧にあるIDを対応付けることで、各個人の部活を特定することができますね。

f:id:momoyama1192:20200903194727g:plain

このように、ほかの表の主キーを参照することで、表と表を対応付ける項目(列)のことを外部キーと呼びます。

(2) 外部キーに選ばれる項目の条件

外部キーは、ほかの表へ参照するために必要なため、外部キーとなる項目は、参照先の項目の列内に存在する値しか設定できないという制限があります。

この制限のことを参照制約と呼びます。

(3) 最初から表をくっつけたらいいのでは?

わざわざ表を分けて外部キーまで設定しなくても、最初から下のように表をくっつけたらいいじゃんと思った人もいると思います。

f:id:momoyama1192:20200903194702g:plain

しかし、このように表をくっつけて管理してしまうと、1つ問題が発生してしまいます。

 

こちらが分けた後の表なのですが、分ける前の表には「サッカー部」や「帰宅部」の存在がありませんよね。

f:id:momoyama1192:20200903194723g:plainこのように、表をくっつけて管理してしまうと、だれも所属していない部*4の存在が消えてしまうという問題があります

また、「かるた部」が「競技かるた部」のように名前を変えた場合、部活一覧表と分けて管理していた場合は、部活一覧の部分を1か所変えるだけで済みます。しかし、くっつけて管理していた場合は「かるた部」に所属する人の部活全員をいちいち「競技かるた部」に変えなければならず、結構しんどいです。

 

そのため、データベースではデータに矛盾が生じたり、管理をなるべく楽にするために適切に表を分けることで最適化をします。

この表を分ける操作のことを正規化と呼びます。正規化は、データベースの試験で頻出する項目なのでまた分けて紹介したいと思います。

 

 

外部キーで覚えるべき用語

外部キー:各データを1通りに特定することができる項目(列)

 

外部キーとなる項目にかけられる制約

  • 参照先の項目の列内に存在する値以外は登録できない(参照制約)

 

4.インデックス

(1) インデックスとは

データベースには、大量のデータが記録されています。そんな大量のデータを、やみくもに上から下へ順番にデータを検索する(線形探索を行う)と非常に時間がかかってしまいます。

 

そこで、データがどこにあるのかを表す目次をつけてあげます。この目次のことをインデックスと呼びます。

インデックスをつけることで、探したいデータがデータベース中のどこにあるのかをすぐ見つけることができるので、検索効率、速度のアップを行うことができます。

 

(2) インデックスがあまり有効ではない例

ただし、インデックスを用意するだけで必ず速度が上がるとは限りません。

 

データベースの中身を追加、削除を行うと当然場所が変わるので、目次の内容も書き換えないといけません。

そのため、頻繁に書き換わるデータに対しては、書き換えるたびに目次も書き換える必要が出てくるため、効率、速度がかえって落ちてしまいます

 

インデックスが有効な例は、以下の2つを満たすときが条件です。

  • データベース内にあるデータが大量にあるとき
  • データベース内のデータの追加、削除があまり起こらない場合

 

5.練習問題

では、3問ほど練習していきましょう。

練習1

関係データベースの主キーの性質として適切なものはどれか。

[基本情報技術者平成21年秋期 午前問32]

ア:主キーとした列に対して検索条件を指定しなければ、行の検索はできない。
イ:数値型の列を主キーに指定すると、その列は算術演算の対象としては使えない。
ウ:一つの表の中に、主キーの値が同じ行が複数存在することはない。
エ:複数の列からなる主キーを構成することはできない。

練習2

関係データベースの主キー制約の条件として、キー値が重複していないことの他に、主キーを構成する列に必要な条件はどれか。

[基本情報技術者平成25年秋期 午前問30]


ア:キー値が空でないこと
イ:構成する列が一つであること
ウ:表の先頭に定義されている列であること
エ:別の表の候補キーとキー値が一致していること

 

練習3

関係データベースにおいて、外部キ一定義を行う目的として、適切なものはどれか。

[基本情報技術者平成23年特別 午前問34]

ア:関係する相互のテーブルにおいて、レコード間の参照一貫性が維持される制約をもたせる。

イ:関係する相互のテーブルの格納場所を近くに配置することによって、検索、更新を高速に行う。

ウ:障害によって破壊されたレコードを、テーブル間の相互の関係から可能な限り復旧させる。
エ:レコードの削除、追加の繰返しによる、レコード格納エリアの虫食い状態を防止する。

 

6.練習問題の答え

解答1

解答:ウ

ア:主キーとした列に対して検索条件を指定しなければ、行の検索はできない。
→ そんなことはありません。

イ:数値型の列を主キーに指定すると、その列は算術演算の対象としては使えない。
→ 主キーだろうが演算の対象として使えます。

ウ:一つの表の中に、主キーの値が同じ行が複数存在することはない。
→ 正解。

エ:複数の列からなる主キーを構成することはできない。
→ できる。複合キーのこと。

解答2

解答:ア

主キーになるための2つの条件を必ず覚えておきましょう。

  • キー値が重複していないこと
  • キー値が空でないこと

解答3

解答:ア

外部キーは、参照一貫性を保つために参照先の項目の列内に存在する値しか登録できないようにするのでしたね。

よって答えはア。

 

7.さいごに

今回は関係データベースの基本用語(主キー、外部キー、候補キーなど)について説明していきました。

次回は、関係データベース内で使われる演算について確認していきましょう。

*1:関係データベースのスキーマのことを関係スキーマと呼ぶ人もいます。

*2:同じ番号になる人がいないように振られてます

*3:部活で各データを特定するのは絶対無理です。それぞれの部活に入っている人は1人とは限らないからです。というか、それぞれの部活に1人しか入れなかったら野球部とかどうするんですか。

*4:現実的にはあまりありませんが、新しくできた部活だと誰もいないということはあるかもしれません。