今回は、SQLの中編ということで、

• データベースの作成、削除
• 表の定義, 構造変更, 削除
• データの挿入, 削除
• データベースの権限

の4つについて説明します。

１．データベースの作成・削除

特に意識して覚える必要はなし。

(1) データベースの作成

create database 作成するデータベース名

(2) データベースの削除

drop database 削除するデータベース名

create が作成、drop が削除というのは頭に入れておきましょう。

本番、SQLの構文をど忘れしたときでも選択肢を絞ることができます。

２．表の定義, 構造変更, 削除

(1) 表の定義

定義に関する問題はたまに見かけるので、どんなふうに書くのかをさらっと確認しておきましょう。

基本構文

create table 表名 (
列名1  データ型  [列名1の列制約]
列名2  データ型  [列名2の列制約]
列名3  データ型  [列名3の列制約]
　︙
[表制約]
)

それぞれの列の列制約、および表制約が必要ない場合は省略できます。また、2つ以上の制約を入れることもできます。

データ型、[列制約]、[表制約] に具体的に何が入れられるかは下で説明しています。

データ型

char と varchar の違いに気をつけましょう。

例えば、char(5) であれば必ず「5文字」の文字列が格納される必要があります。一方 varchar(5) であれば「5文字以下」の文字列を格納することができます（5文字でなくてもOK）。

列制約

[※注意]

• primary keyを使って主キー制約を行うと、unique制約とnot null 制約も自動的に加わる*1
• 参照先は references 表名(列名) で指定した表、列となる

表制約

表制約では (列名1, 列名2,…) と指定した列名に対して、一括で制約を加えることができます。

[※注意]

• foreign key(列名1, 列名2) の部分で外部キーを設定し、references 以降で参照先を決定する
• check(条件) では、表全体に対して条件を満たすもののみを登録できるようにする

具体例

具体的に表の定義例を見てみましょう。

表：メニュー

以下の条件を満たすように、表「メニュー」を定義してみましょう。

• 必要な列は番号、メニュー、値段の3つ
• 番号は4文字の文字列型、メニューは10文字以内型、値段は0円以上の整数型
• 列「番号」に主キー制約を書ける

実際に書いて見ると、以下のようになります。皆さんも同じになりましたか？

create table メニュー (
番号  char(4), primary key,
名前  varchar(10),
値段  int,
check(値段 >= 0)
)

(2) 表の変更

表の変更 alter は、過去に1～2回ほど基本情報の午後問題で出題されたことがあります。（例えば平成22年度秋期）

列の追加

列の追加と削除は念の為に覚えておくと安心。

alter table 表名 add 列名 データ型

列名　　：追加する列の名前
データ型：追加する列のデータ型

列の削除

alter table 表名 drop 列名

列名　　：削除する列の名前

表名の変更

出ないから覚えなくてOK

alter table 旧表名 renames to 新表名

(3) 表の削除

drop database の database を table に変えただけ。

drop table 削除する表名

３．データの挿入(insert)・削除

(1) データの挿入

insert 文によるデータの挿入です。

insert into 表名 (列名1, 列名2, …)
values (値1, 値2, …)

「列名1が値1、列名2が値2、…」となっているデータが挿入されます（列名1と値1、列名2と値2、のように同じ番号の列と値が1対1に対応しています。）。

例えば、下のように挿入を行うとします。

このような操作を行うSQLは以下で表せます。

insert into メニュー (番号, 名前, 値段) values ('N006', 'そば', 200)

[注意]

• 挿入対象は必ず1つの表（複数の表に同時挿入はできない）
• 文字列は必ず '' で囲うこと

[応用] select文との併用

データの挿入の際に select 文の結果をそのまま挿入することもできます。

select 文の結果を挿入する場合、values (値1, 値2,…) の部分に select 文が入ります。

insert into 表名 (列1-1, 列1-2, …) select 列2-1, 列2-2, … from 参照表名 where 条件

[注意]

• 列1-1と列1-2、列2-1と列2-2、…のように列の並びが1対1に対応するようにすること
• whereによる条件が不要であれば省略もOK

例えば、右側にある表「一覧」からジャンルが「うどん」であるものを表「メニュー」に追加する場合を考えましょう。

この処理は、以下のSQLで実現できます。

insert into メニュー (番号, 名前, 値段)
select 番号, 名前, 値段 from 一覧 where ジャンル = 'うどん'

(2) データの更新

列を指定する部分では、更新する列と値のみを記述すればOKです。

update 表名 set 列1 = 値1, 列2 = 値2, … where 条件

[注意]

• 条件には、select文で使える条件と同じものが使える（between やら in やら like なども使用OK）
• 必要がなければ where 条件 は不要

先程出てきた下の表で具体例を考えてみましょう。

表：メニュー

例えば、ラーメンの値段を20円下げるのであれば以下のSQLで実現できます。

update メニュー set 値段 = 値段 - 20 where 名前 = 'ラーメン'

同じように、全部のメニューを50円値下げするSQLは以下のように書けます。

update メニュー set 値段 = 値段 - 50

(3) データの削除

データの削除方法も確認しておきましょう。

delete from 表名 where 条件

例えば、先程の表「メニュー」から、Bランチを削除するのであれば以下のSQLで記述できます。

delete from メニュー where 名前 = 'Bランチ'

４．権限の変更

基本情報ではあまり重要ではないので、基本情報で受験するだけであれば読み飛ばしてもらってOKです。

権限名には、以下の5つを選ぶことができます。

(1) 権限の付与

grant 権限名 on 表名 to ユーザー名

例：owner には表「メニュー」に対しての全部の権限を付与する

grant all privileges on メニュー to owner

(2) 権限の取り消し

revoke 権限名 on 表名 to ユーザー名

例：momoyama には表「メニュー」に対しての削除の権限を剥奪する

revoke delete on メニュー to momoyama

５．さいごに

今回は、少しシンプルにSQLの中編として、以下の4つについて説明しました。

• データベースの作成、削除
• 表の定義, 構造変更, 削除
• データの挿入, 削除
• データベースの権限

後編では、さらに応用として、以下の3つを中心に説明する予定です。

• 複数の表を用いた select 文
• 副問合せ
• 仮想的な表「ビュー」の定義、利用

今回から3回に分けてSQLの基礎について勉強していきましょう。

初回となる今回は、表を検索するために使うselect文の使い方を、少し応用的なところまで見てきましょう。

なお、重要度は「基本情報で必要かどうか」を基準に設定しています。★の意味は、以下の通りです。

• ★★★：超重要、よく出る
• ★★☆：重要、結構出る
• ★☆☆：余裕があれば見とこうね

1．select文の基本　重要度：★★★

select文では、関係データベース内に保存されているデータ（つまり表）の中から、条件に合致したものを抽出するのが基本です。

まずは、select文の基本的な使い方を見てきましょう。

(1) 列の抽出（射影）

射影演算は、表の中から列を取り出す演算でしたね。

select文を用いて列を抽出する場合、列名の部分に抽出したい列名を列挙します。

select 列名 from 表名

例えば下の例の場合、関係「学生一覧」の中から、「名前」、「学年」の列を取り出し、表示します。

また、下のように列名部分に * をつけると、すべての列を抽出します。

select * from 学生一覧

(2) 全く同じデータを表示させない方法 (distinct)

射影演算の厳密な定義は全く同じデータを2回以上出力しません。

しかし、単にselect文で列を指定しただけだと、下のように重複したデータが2回以上出力されてしまう可能性があります。

そこで、下のように列名を列挙する前に distinct をつけることで、重複データを2回以上出力させなくすることができます。

select distinct 列名 from 表名

例えば下の例の場合、工学部と情報工学部が1度だけ出力されます。

(3) 行の抽出（選択）

選択演算は、表の中から行を取り出す演算でしたね。

select文を用いて行を抽出する場合、where 以降の「条件」に一致するものを抽出します。

select 列名 from 表名 where 条件

下の例の場合、関係「学生一覧」の中から、「学年が2であるもの（2年生）」を抽出します。

2．条件文の書き方　重要度：★★★

第2章では、where以降で指定できる条件の書き方について見ていきましょう。

(1) 条件の複数指定 (and, or)

Excelやプログラミングと同じように、複数の条件を and (かつ) や or (または) で指定することができます。

and（2つの条件をともに満たす行を出力）

where 条件1 and 条件2 と書くことで、条件1、条件2を両方とも満たすものを出力することができます。

select 列名 from 表名 where 条件1 and 条件2

下の例の場合、「学年が1(1年生)」と「取得単位が30未満」の両方を満たす行を出力します。

or（2つの条件を片方でも満たす行を出力）

where 条件1 or 条件2 と書くことで、条件1、条件2のうち、片方でも満たすものを出力することができます。

select 列名 from 表名 where 条件1 or 条件2

下の例の場合、「学年が1(1年生)」と「取得単位が70未満」のうち、片方もしくは両方満たす行を出力します。

(2) 条件の否定 (not)

条件の最初に not をつけると、条件を満たさないものを出力することができます。

select 列名 from 表名 where not 条件

下の例の場合、「学部が情報学部ではない」行を出力します。

また、下のように and, or と not と組み合わせて条件を記述することができます。

select * from 学生一覧 where not 学年 = 1 or 取得単位 < 70 

ただし、処理順序に気をつけましょう。(not → and → orの順に処理が行われます）

自分で記述をする際には、下のように括弧をつけて計算順序を明確化させておくことをおすすめします。

select * from 学生一覧 where (not 学年 = 1) or (取得単位 < 70) 

(3) 範囲の指定 (between)

条件の部分に 列名 between A and B と書くことで、A以上B以下のデータを取り出すことができます。

select 列名 from 表名 where 列名 between A and B

下の例の場合、取得単位が40以上80以下である行を取り出し、出力します。

また、notを付け加えて not between A and B とすることで、値がA以上B以下ではないデータを取り出すことができます。

(4) 指定した項目を抽出 (in)

条件の部分を 列名 in (値1, 値2, …) とすることで、括弧内で指定した値のどれかと一致するデータを出力することができます。

select 列名 from 表名 where 列名 in (値1, 値2, …)

下の例の場合、学部が「文学部」もしくは「経済学部」となっている行を出力します。

また、notを付け加えて not in (値1, 値2, …) とすることで、括弧内で指定した値と一致しないデータを出力することができます。

(5) 指定したパターンを出力 (like)

条件の部分を 列名 like '文字パターン' とすることで、特定の文字パターンと一致（部分一致）する行を出力することができます。

select 列名 from 表名 where 列名 like '文字パターン'

文字パターンの指定では、下の２つのワイルドカードを使うことができます。

% → 任意の文字列
_ → 任意の1文字

下の例の場合、番号が「Aで始まる」行を出力します。

また、notを付け加えて not like '文字パターン' とすることで、特定の文字パターンと一致しない行を出力することができます。

(6) 空からどうかの判定 (ls null)　重要度：★★☆

where 項目名 is null とすることで、項目が空になっているものを出力します。

ただし、実際には is not null のように not を付け加えて「項目が殻になっていない」ものを出力させることが多いです。

例えば、下のSQLの書き方であれば、番号（学生番号のこと）が空になっていない学生を出力することができます。

select 番号, 名前 from 受講一覧 where 番号 is not null 

３．結果のソート (order by)　重要度：★★★

条件を指定したあとに order by を付け加えることで出力結果に対して、昇順(asc)もしくは降順(desc)でソートを行うことができます。

select 列名 from 表名 where 条件 order by 列名 ソート方法(asc / desc)

下の例の場合、出力結果を点数の昇順(asc)でソートしたものを改めて出力します。

なお、昇順ソートを行う場合はソート方法を示す asc を省略することができます。そのため、下のSQLでも先程の例と同じ結果を得ることができます。

select * from 受講一覧 order by 点数

2つ以上の列を用いたソート

複数の列を用いてもソートすることができます。ただし、列名ごとに昇順(asc)か降順(desc)を指定する必要があります。（昇順であれば省略OK）

select 列名 from 表名 where 条件 order by 列名1 条件1, 列名2 条件2, …

複数の列を用いる場合、

• まずは1つ目の列の値でソート
• 1つ目の列の値が同じ行のみ、2つ目を確認し、ソート
• さらに同じであれば3つ目……

と行います。

下の例の場合、

• まずは国語の値が昇順になるように並べる
• 国語が同じ値の行に対し、数学の値が降順になるように並べる

の２段階の処理が行われます。

４．様々な集合関数　重要度：★★★

SQLでは集計を行う様々な関数（集合関数と呼びます）を使うことができます。

よく出てくる関数を下に載せておきます。

実際に関数を用いて計算をするときは、下のように 列名 の部分に関数名を入れることで、関数を用いた演算を行えます。

select count(*) from 受験一覧  # 表に格納されている行の数を出力
select avg(点数) from 受験一覧 #  点数の平均値を出力

５．集合関数の応用1（グループごとの出力 group by）重要度：★★★

ここからは、集合関数の応用的な使い方を見てきましょう。

group by 列名 とすることで、指定した列内にあるデータの種類それぞれに対して集合関数を適用することができます。

例えば、group by 学部 とすると、各学部ごとに集合関数を適用することができます。

select 学部, count(*) from 受験一覧 group by 学部   # 学部ごとに行をcountする
select 学部, avg(得点) from 受験一覧 group by 学部  # 学部ごとの得点の平均（平均点）を求める

なお、select 学部, count(*) のところを select count(*) のように「学部」を消してしまうと、数字だけが出力されるので要注意です。（どの数字がどの学部と対応しているかがわからなくなる）

条件をつけた絞り込み (having)

グループごとに集合関数を適用するときに、特定の条件を満たしたものだけを出力させたいと思うかもしれません。

このようにグループ化した後に、ある条件を満たしたものだけ出力する際には group by 列名 の後に having 条件 を付け加えます。

select 出力する列名, 集合関数 from 表名 group by 列名 having 条件

（group by に対する条件指定では where は使わないので注意！）

下の例の場合、学部ごとの平均点を求めたあと、70点以上の学部のみを出力しています。

having と where の違い

having と where はどちらも抽出条件を定めるものですね。

しかし、なぜ group by を使ったときにだけ where を使わずに having を使わなければならないのでしょうか。

まず、group by, where, having の3つはそれぞれ呼び出される優先順位があり、下のようになっています。

• where
• group by
• having

つまり、

• where は group by の前に実行されるため、グループ化する前の元々のデータに対して絞りこみ条件を指定する
• having は group by の後に実行されるため、グループ化後の表に対しての絞りこみ条件を指定する

ことになります。

そのため、グループ化後の表に対して条件を指定する際には、where ではなく having を使う必要があるのです。

逆に言うと、group by を使わなければ having も where も全く同じ働きをします。

そのため、多くの参考書では having は group by に対して使うものと説明されています。

６．集合関数の応用2（入れ子として使用）重要度：★★☆

集合関数の結果を、where や having の条件として使うことができます。

例えば、下のように「受験一覧」から平均点以上をとっている人の行を抽出することができます。

集合関数を絞り込みの条件として使う際には、条件文の中にselect文を入れる必要があることに注意しましょう。

例えば、抽出をする際に 点数 >= avg(点数) のように直接集合関数を用いて比較をすることはできません。

入れ子を用いたSQLについては、SQLの後編（応用）で詳しく説明します。

７．列名の付け替え (as)　重要度：★☆☆

select 列名 from 表名 で列名を指定する際に、as 新列名 とすることで、出力結果の列名を付け替えることができます。（※asは省略OK）

select 列名 as 新列名 from 表名
select 列名 新列名 from 表名  # as を省略

下の例の場合、列名 count(*) を 合計 と付け加えて出力しています。

as は上の例のように、集合関数の名前を付け替える際に使われることが多いです。

なお、複数の列名を指定している場合、付け替えたい列名のみに as 新列名 を付け加えます。（asは省略OK）

下の例の場合、列名1と列名2をそれぞれ新列名1、新列名2と付け替えて出力をします。

select 列名1 as 新列名1, 列名2 as 新列名2, 列名3 from 表名

名前の付け替えは、基本的にめったに出ないので「こんなことができるんだ～」程度の理解度でOKです。

８．複数の表から結果を得る（表の結合）重要度：★★★

2つ以上の表を読み込むことにより、複数の表から結果を得ることができます。

ただし、2つの表をくっつけるための結合条件を書く必要があります。

select 列名 from 表1, 表2 where 結合条件

例えば下の2つの表を結合させる場合、両方の表にある「学部コード」を結合条件として使います。

しかし、whereで結合条件を示す際に 学部コード = 学部コード と書いてしまうと、どっちの表の学部コードを読み込むかがわかりません。

そのため、読み込む表の中に同じ項目がある場合、表名.列名 とすることで、どの表の列名なのかを明らかにします。

なお、列名部分を * としても同じ結果を得ることができます*1。

select * from 学生, 学部 where 学生.学部コード = 学部.学部コード

９．まとめ

今回はSQL前編として、select文の使い方を少し応用的なところまで見ていきました。

最後に、今回出てきた select, from, where, group by, order by, having をどの順番で並べるか確認しましょう。

まず、select文を使う場合、最初に select 表示させる列名 from 使う表名 を必ず列挙する必要があります。その後必要であれば where, group by, having, order by の順に記します。

select 表示させる列名 from 使う表名 where 絞り込む条件 group by グループ化させる列名 having グループ化後の抽出条件 order by ソートに使う列名 (asc/desc)

次回は、表の作成、更新などの select 文以外のSQLを紹介します。

今回はデータベースで出てくる関係演算について一緒にお勉強しましょう！

関係演算には、集合でもよく使われる

• 和
• 積
• 差
• 直積

の4つと、データベースの関係演算独自の、

• 選択
• 射影
• 結合
• 商

の4つがあります。

特に今黄色い線を引いた3つは、基本情報の試験や期末試験にも頻出する超重要な演算です。必ず覚えましょう。

１．集合演算

まずは、集合演算について見ていきましょう。

(1) 和

2つの表に対して、論理和(OR)を行う演算です。

つまり、2つの表のうち、どちらか一方でも存在する行を出力します。

演算が成立するための条件

和、積、差の計算では、以下の2つの条件がそろっていない場合、そもそも計算を行うことができません。

(a) 2つの表の項目数が異なる場合

(b) 2つの表の項目名が異なる場合

基本的に、2つの表の項目が全く同じでないと演算ができないと思っていただけたらOKです。

(2) 積

2つの表に対して、論理積(AND)を行う演算です。

つまり、2つの表の両方に存在する行を出力します。

和演算と同じく、2つの表にある項目が全く等しいときのみ演算を行うことができます。

(3) 差

2つの表に対して、演算元にある行の中から、演算先の行にないものを出力します。

差の演算は、今まで紹介してきた和や積の演算と異なり、計算順序を変えると演算結果も変わるため、注意が必要です。

また、和演算・差演算と同じく、2つの表にある項目が全く等しいときのみ演算を行うことができます。

(4) 直積

2つの表にある項目のすべての組み合わせを出力します。

２．関係演算（データベース独自）

つぎに、データベース独自の関係演算について見ていきましょう。

ここからが超重要ですよ！

(1) 選択

ある条件に従って特定の行を取り出す演算が選択です。

（条件を \( c \)、表名を \( P \) とし、\( \sigma_c (P) \) と記号で表されます。）

（※記号については、基本情報などの情報処理試験では出ないので覚えなくてOKです） 

例えば、上の例の場合、表Pから「部活がサッカー部の人」を行単位で出力しています。

SQLでの選択の書き方

SQLの場合、以下の青線部分が「選択演算」に相当します。（where句以降ですね。）

※SQLについては第03羽で詳しく説明するので、まだわからなくてもOKです。

(2) 射影

ある条件に従って特定の列を取り出す演算が射影です。

（選択する項目(列)を \( i \)、表名を \( P \) とし、\( \pi_i (P) \) と記号で表されます。） 

例えば、上の例の場合、表Pから 名前, 部活 の列を抽出し、出力しています。

重複に注意！

射影の演算では、選択する列によっては、下のように行内のすべてのデータが全く同じになってしまうことがあります。

この場合、全く同じデータとなるものは最初の1回だけ出力し、2回目以上は出力しません。

射影演算では、重複するデータを2度以上出力しないと頭の中に入れておきましょう！

SQLでの射影の書き方

SQLの場合、以下の赤線部分が「射影」に相当します。

重複データを2回以上出力しない disctinct が必要な点に注意しましょう。 

※SQLについては第03羽で詳しく説明します。

(3) 結合

2つの表をある共通の列を用いてくっつける演算が結合です。

結合演算には、

• 等結合
• 自然結合

の2つがあります。それぞれ見ていきましょう。

(a) 等結合

等結合は2つの表をある共通の列を用いて単純にくっつける演算です。

ただし、単純にくっつけるため、同じ意味を持った項目（ピンクの枠部分）が2つあって冗長になってしまいます。

(b) 自然結合

等結合では、同じ意味を持った項目が2回出てきて冗長になってしまいます。

そこで、共通の列のうちの片方を削除する*1ことで冗長性を取り除いて結合したものが自然結合となります。

特に指示がない限り、結合と言われたら、こちらの自然結合を表していると思っていただけたらOKです。

(c) 結合演算の仕組み

結合演算は、直積と選択の2つを組み合わせた演算です。

どうしてこの2つを組み合わせたら結合演算になるのかを、実際に1つ例で試すことで確認しましょう。

Step1. 2つの表の直積を取る

まず、2つの表の直積を求めることですべての組み合わせを求めます。

Step2. くっつけるための条件

すべての組み合わせの中で、くっつけるための条件を満たすもの（結合元の列と結合先の列が等しい）を選択します。

（さらに、自然結合の場合、結合先の列を削除します。）

確かに、結合演算は直積と選択の2つで表せることを確認しましたね。

(d) 結合の際の注意

結合演算を用いる際には、結合するための列条件の書き方に注意が必要です。

例えば、下のP, Qの表を結合させる場合、条件で「部活=部活」と書いてしまうと、どちらの表にある部活なのかがわからなくなってしまいます。

このように項目名が2つの表で重複してしまう場合、どの表にある項目かを「表名.項目名」の形で書く必要があります。

例えば、上の例の場合、条件は、

学生.部活 = 部.部活

のように明記します。

SQLでの選択の書き方

SQLの場合、以下の青線部分が「結合」に相当します。

直積を意識せずに書けることが特徴ですが、項目名が2つの表で重複する場合は「表名.項目名」のようにどの表の項目であるかを明記する必要があります。

※SQLについては第03羽で詳しく説明します。

(4) 商

直積を逆算したものが商となります。

といきなり言われてもわかりにくいと思うので、実際に1つ例で確かめてみましょう。

例えば、下のような演算でできる表 \( R \) があります。

表 \( R \) は \( P \times Q \) の直積演算によってできた表ですね。

では、逆に直積によってできた表 \( R = P \times Q \) と表 \( P \) から表 \( Q \) を求めてみましょう、というのが商 \( R \div P \) の定義です。

同じように、\( R \) と \( Q \) から \( P \) を求めることもできます。

３．練習問題

では、前回と同じように基本情報の問題で3問ほど練習していきましょう。

練習1

関係データベースにおいて、表から特定の列を得る操作はどれか。

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

ア：結合
イ：削除
ウ：射影
エ：選択

練習2

関係XとYを自然結合した後、関係Zを得る関係代数演算はどれか。

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

ア：射影と和
イ：選択
ウ：選択と射影
エ：選択と和

練習3

関係Rと関係Sに対して、関係Xを求める関係演算はどれか。

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

ア：IDで結合
イ：差
ウ：直積
エ：和

４．練習問題の答え

解答1

解答：ウ

表から列を抜き出す演算は「射影」です。よって答えはウ。

[それぞれの選択肢]

ア：結合
→ 2つの表をくっつける演算

イ：削除
→ 関係演算ですらない。

ウ：射影
→ 表から特定の列を抜き出す演算

エ：選択
→ 表から特定の行を抜き出す演算

解答2

解答：ウ

まず、関係XとYを自然結合してみましょう。すると、下のような表となります。

ここで、表Zを見てみると、

• 学生番号2, 4の行が抽出されている（選択）
• 学部名、学生番号、氏名の列が抽出されている（射影）

が行われていることがわかりますね。よって、答えはウです。

実際に結合した表に対して、選択演算と射影演算をやってみましょう。

まず、選択演算を行います。すると、下のような結果となります。

さらに射影演算を行うことで、Zを得ることができます。

解答3

解答：エ

まず、関係R, S, Xで項目の種類、数が一致していますね。

そのため、集合演算の和、差、積のいずれかとなります。

よって、選択肢アとウが消えます。

あとは和か差を考えるのですが、差演算であれば、計算元Rよりも結果Xのほうが行数が少なくなりますよね。（関係Rにあって関係Sにないものを出力するので、当然結果Xは関係Rよりも表の行数が減る）

よって、答えは和のエとなります。

実際にRとSを和演算するとXになることを確認しましょう。

５．さいごに

今回は、データベースの関係演算について説明しました。

関係演算を使うことで、データベース内にある表から様々な表を一時的に作り出すことができます。

このような一時的に作られた仮想的な表のことをビュー表と呼びます。

普段は整合性を保つために表を小分けにしておき、ユーザーに見せる際にユーザーが見やすいようにビュー表を一時的に作ることで、整合性、利便性の両立が可能となります。

次回からは、データベースを操作するプログラミング言語SQLについて説明していきたいと思います。

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

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

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

１．関係データベース (ﾘﾚｰｼｮﾅﾙﾃﾞｰﾀﾍﾞｰｽ)

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

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

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

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

(2) 用語紹介

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

(a) 行と列

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

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

と呼ぶこともあります。

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

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

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

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

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

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

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

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

となります。

２．主キー

(1) 主キーとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

３．外部キー

(1) 外部キーとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

４．インデックス

(1) インデックスとは

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

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

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

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

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

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

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

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

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

５．練習問題

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

練習1

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

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

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

練習2

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

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

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

練習3

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

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

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

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

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

６．練習問題の答え

解答1

解答：ウ

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

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

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

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

解答2

解答：ア

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

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

解答3

解答：ア

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

よって答えはア。

７．さいごに

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

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

今回は、データベースの論理設計で使われるER図について説明します。

具体的には、

• ER図の読み方
• 多重度の説明、読み方
• ER図から実際にテーブルを作成する方法

 の3つについて説明しています。

前回のソフトウェア工学に関する記事はこちら！

www.momoyama-usagi.com

１．なぜER図が必要なのか

何かしらのデータを格納するデータベースを設計するとします。

しかし、いきなりデータベースの構造や仕様*1を設計するのはかなり難しいです。

そこで、「データベース上でデータをどうやって管理するか」を決める論理設計の前に、現実の世界をどのようにしてデータベース内に構築するかを決める概念設計を行います。

この概念設計の際によく使われるのがER図（ERD、実体管理図）なのです！

（実際には、ER図を書く前に、管理するデータに矛盾や重複が発生しないように正規化を行います。正規化の仕方についてはこちらから。）

次の章からは、ER図の読み方、書き方について説明していきます。

２．ER図の設計例

ER図では、人間が他のものと区別してする実体（エンティティ）と実体同士の相互関係を表す関連（リレーション）の2つを使って、データの構造を図に表します。

（※基本情報などの情報処理試験でER図の問題が出てくるとき、なぜかエンティティやリレーションのようなカタカナ表記で出てくることが多いので、カタカナ表記も頭に入れておくことを強くおすすめします。）

ER図の書き方には、様々な書き方があります。

今回は、ER図の元祖であるPeter Chen記法と、実世界や試験でもよく使われるIE記法の2つをメインに説明したいと思います。

(1) Peter Chen記法

Peter Chen記法では、以下のような記号を用いて属性、実体、関連を表します。

実際にER図を用いてデータの構造を表したものが下となります。

早速、このER図の意味を読み取っていきましょう。

(i) 実体と属性

まず、実体と属性の関係を見てみましょう。

例えば実体「学生」には、「学生番号」、「所属」、「名前」という3つの属性がありますね。

このように、実体が持つ性質を抽出していき、属性としていくことで実体と属性を抽出することができます。

もし、C言語を書いたことがある人は「構造体の名前」が実体、「構造体のメンバ（構造体の中にあるそれぞれの変数）」が属性と考えるとわかりやすいかもしれません。

(ii) 実体と関連

次に、実体と関連の関係を見てみましょう。

下の図は、学生と科目には「履修」という相互関係があることを示しています。

このように、2つの実体をひし形で挟むことにより、関連があることを示すことができます。

ここで、ひし形の横にNとMというよくわからないものが書かれていると思った人もいるかもしれません。

このNやMは、多重度と呼ばれ、それぞれの実体が何個の関連を持つかを表しています。

(iii) 関連に属性を持たせる

実体に属性を持たせることができることは先ほど説明しました。

同じようにして、関連にも属性を持たせることができます。

例えば、下の図の場合、関連「履修」に属性「成績」を持たせていることが読み取れます。

(2) IE記法 (Crow's Foot)

IE記法では、以下のような記号を用いて属性、実体、関連を表します。

実体と属性を1つにまとめて書くのがポイントです。

※紫色で示されている記号  が鳥の足に見えるのでCrow's Feet（カラスの足）記法とも言われます

※多重度の読み方が少し特殊なので、後程説明したいと思います。

実際にIE記法を用いて先程Peter Chen記法で出てきたデータの構造を表したものが下となります。

Peter Chen記法で出てきた「属性を持っている関連」もエンティティ（実体）とみなして記述するのがポイントです*2。

３．多重度（カーディナリティ）

ER図では、それぞれの実体が何個関連を持つのかを多重度（カーディナリティ）という形で表します。

（多重度の考え方はクラス図と同じです。）

ER図で出てくる多重度には、「1対1」、「1対多(1対N)」、「多対多(N対M)」の3種類があります。

ここからは、3つの対応関係「1対1」、「1対多(1対N)」、「多対多(N対M)」がどのような意味なのかを説明していきます。

(1) 1対1

1対1とは、どちらの実体からももう一方の実体を一意に特定できる状態のことを表します。

専属の家庭教師のような関係が「1対1」です。

例えば、下のような教員と学生の関係があるとします。

この場合、

• ある1人の教員は、1人の学生を指導する
  （つまり、教員が分かれば指導している学生も一意に特定できる）
• ある1人の学生は、1人の教員に指導してもらう
  （つまり、学生がわかれば指導してもらっている教員も一意に特定できる）

ことがわかります。

余談ですが、今の日本の結婚制度は一夫一妻制、つまり1人の夫に対して1人の妻が、1人の妻に対して1人の夫と結婚する「1対1」の結婚関係を結ぶ制度になっていますね。

(2) 1対多

1対多とは、ある一方の実体Aからもう一方の実体Bを一意に特定することはできるが、もう一方の実体Bからは実体Aを一意に特定することができない状態です。

学校や塾（個別指導を除く）の「先生」と「学生」のような関係が「1対多」です。

例えば、下のような教員と学生の関係があるとします。

この場合、

• ある1人の教員は、たくさんの学生を指導する
  （つまり、教員が分かっても指導している学生がたくさんいるため、一意に特定できない）
• ある1人の学生は、1人の教員に指導してもらう
  （つまり、学生がわかれば指導してもらっている教員も一意に特定できる）

ことがわかります。

余談ですが、一部の国の結婚制度は一夫多妻制、つまり1人の夫に対してたくさん（0人以上）の妻が、1人の妻に対して1人の夫と結婚する「1対多」の結婚関係を結ぶ制度になっていますね。

（もちろん一妻多夫制でも「1対多」の結婚関係になります。）

(3) 多対多

多対多とは、ある一方の実体Aからもう一方の実体Bを一意に特定することはできないし、逆に実体Bから実体Aも一意に特定することができない状態です。

例えば、下のような教員と学生の関係があるとします。

この場合、

• ある1人の教員は、たくさんの学生を指導する
  （つまり、教員が分かっても指導している学生がたくさんいるため、一意に特定できない）
• ある1人の学生も、たくさんの教員に指導してもらう
  （つまり、学生が分かっても指導してもらっている教員がたくさんいるため、一意に特定できない）

ことがわかります。

余談ですが、多夫多妻制、つまり1人の夫に対してたくさん（0人以上）の妻が、1人の妻に対してたくさんの夫と結婚する「多対多」の結婚関係を結ぶ制度がある国はない気がします。人間ではなく他の動物ならあったかもしれませんが。

他の記法での多重度の書き方

Peter Chen記法以外のERで「1対1」、「1対多」、「多対多」を記述する方法をまとめました。

※ IE記法での多重度の書き方は、下のほうでより詳しく説明します。

４．IE記法での多重度の書き方

IE記法では、多重度を書く際に1やNのような数字や変数を使わず、専用の記号が使われます。

基本的には、

• 0（〇を書く）
• 1（ | を書く）
• たくさん（<か>を書く*3）

の3つの基本表記が使われます。

ただし、IE記法では0を含むか含まないかを厳密に書くために基本表記の記号を2つ組み合わせた下のような多重度の表記が使われることが多いです。

IE記法で多重度を表した例が下の図となります。

（Twitterのアカウント、ツイート、投稿画像の関係をIE記法でまとめたものです。）

※本来は画像は4枚まで投稿できるのですが、IE記法の説明のために1枚までにしています。

５．多重度とリレーションスキーマの導出

（ここからはソフトウェア工学というよりはデータベースに関するお話になります。）

多重度を把握することで、ER図からリレーションスキーマ（テーブルを何個用意し、それぞれのテーブルに何を格納するか）を決めることができます。

ここでは、「1対1」、「1対多」、「多対多」それぞれの関連からリレーションスキーマを決める方法について説明します。

(1) 1対1のとき

1対1の関係の例としてTwitterにおける「ユーザー」と「プロフィール」の関係を例にし説明します。

まず、

• ユーザーの属性（ユーザーID、アカウント名、パスワード）を保存するテーブル
• プロフィールの属性（プロフィールID、本文）を保存するテーブル

の2つを作ります。

1対1の場合、次に2つのテーブルをリンク（関連付け）させるために2つのテーブルのどちらか（もしくは両方）に*4、もう一方の主キー属性*5となる属性を追加します。

今回の例の場合、

• テーブル「プロフィール」にユーザーIDを追加
• テーブル「ユーザー」にプロフィールIDを追加

することで2つのテーブルをリンクさせることができます。

なお、上のように2つのテーブルをリンクさせるために追加した他の表の主キーのことを外部キーと呼びます。

（プロフィール内にある「ユーザーID」もしくはユーザー内にある「プロフィールID」が外部キーとなります。）

(2) 1対多のとき

1対多の関係の例としてTwitterにおける「ユーザー」と「ツイート」の関係を例にし説明します。

まず、

• ユーザーの属性（ユーザーID、アカウント名、パスワード）を保存するテーブル
• ツイートの属性（ツイートID、ツイート本文）を保存するテーブル

の2つを作ります。

1対多の場合、ある一方の実体Aからもう一方の実体Bを一意に特定することはできるが、実体Bからは実体Aを一意に特定することができない状態でしたね。

そのため、次に2つのテーブルをリンク（関連付け）させるために、多の方（今回の場合はリレーション）に1の方の主キー属性となる属性を追加します。

なお、関連づけのために追加した属性は外部キーとなります。上の例の場合、テーブル「ツイート」にあるユーザーIDが外部キーとなります。

（間違えて1の方に主キー属性を追加すると、多の実体（今回の場合はツイート）を一意に特定することができないため、テーブルをリンクすることができない。）

(3) 多対多のとき

多対多の関係の例として先程出てきた「学生」と「科目」の関係を例にし説明します。

まず、

• 学生の属性（学生番号、所属、名前）を保存するテーブル
• 科目の属性（科目番号、科目名）を保存するテーブル

の2つを作ります。

多対多の場合、ある一方の実体Aからもう一方の実体Bを一意に特定することはできないし、逆に実体Bから実体Aも一意に特定することができない状態でしたね。

そのため、1対1や1対多のように「別のテーブルの主キー属性となる属性」を追加するだけでは、2つのテーブルをリンクすることができません。

（多対多の場合、一意に特定ができないため、リンクができない）

そこで、関連（履修）を保存する新たなテーブルを作り、合計3つのテーブルとします。

3つ目のテーブルに、2つのテーブルの主キー（学生番号、科目番号）を追加し、さらに履修が持っている属性（成績）も追加することで、学生と科目の2つのテーブルをリンクさせることができます。

（3つ目の表を作り、無理やり「学生と履修」の1対多の関係、「履修と科目」の多対1の関係を作ることで多対多の関係を「1対多」か「多対1」に分解していると思ってください。）

なお、関連づけるためにテーブル「履修」に追加した「学生」と「成績」は外部キーとなります。

多対多の場合、外部キーが少なくとも2つ必要な点に注意が必要です。

６．少し特殊な記法

ER図で使われる特殊な記法

• 弱実体
• 汎化関係

について確認しておきましょう。

（基本情報では出ないのでスキップしてOKです。）

(1) 弱実体

結ばれている関連自体が消滅すると同時に消える実体であることを強調する場合には、実体の枠を2重線で書きます。

クラス図でいうコンポジションがほぼ同じような働きを持っています。

ただし、弱実体にするためには関連の消滅と同時に実体も消滅するようにするために、もう一方の実体が持っている主キーの属性（上の場合は科目の主キーの属性）を追加する必要があります。

(2) 継承

ある上位の実体の具体的な例を下位の実体と考えます。

このとき、下位の実体が上位の実体の属性を引き継いで使う機能のことを継承と呼び、下のような記号であらわされます。

継承を行うことで、下位の実体は改めて属性を定義することなく、上位の実体の属性を使うことができます。

ただし、上位の実体の属性を追加するために、上位の実体が持っている主キーの属性を下位の実体にも追加する必要があります。

（例えば味噌ラーメンの例であれば、ラーメンが持っている主キーの属性を味噌ラーメンにも追加することで継承を実現できます。）

（継承は、オブジェクト指向にも出てくる重要な概念なので頭に入れておきましょう。）

７．練習問題

では、基本情報や応用情報の午前の問題でER図に関する知識を復習しましょう。

練習1

ER図の説明のうち、適切なものはどれか。

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

ア：エンティティタイプ間には、1対多、多対多などのリレーションシップがある。
イ：エンティティタイプ間の関連は、参照側から被参照側への方向の矢印線で表現する。
ウ：エンティティタイプには属性をもたせないで、リレーションシップタイプに属性をもたせる。
エ：エンティティタイプの中に関連先のエンティティ名を記述することによって、リレーションシップを表す。

練習2

ER図に関する記述として、適切なものはどれか。

[基本情報技術者平成24年春期 午前問28]

ア：関係データベースの表として実装することを前提に作成する。
イ：業務で扱う情報をエンティティ及びエンティティ間のリレーションシップとして表現する。
ウ：データの生成から消滅に至るデータ操作を表現できる。
エ：リレーションシップは、業務上の手順を表現する。

練習3

顧客は一般に複数の銀行に預金するものとして、顧客と銀行の関連を、E-R図で次のように表現する。このモデルを関係データベース上に"銀行"表、"口座"表、"顧客"表として実装する場合の記述として、適切なものはどれか。

[応用情報技術者平成22年春期 午前問29]

ア："銀行"表から"口座"表へのカーディナリティは多対1である。
イ："銀行"表中に参照制約を課した外部キーがある。
ウ："口座"表から"顧客"表へのカーディナリティは1対多である。
エ："口座"表には二つ以上の外部キーがある。

８．練習問題の答え

解答1

解答：ア

[それぞれの選択肢ごとの解説]

ア：エンティティタイプ間には、1対多、多対多などのリレーションシップがある
→ 正しい。他にも「1対1」のリレーションシップもある。

イ：エンティティタイプ間の関連は、参照側から被参照側への方向の矢印線で表現する。
→ 誤り。矢印線ではなく、ただの線。

ウ：エンティティタイプには属性をもたせないで、リレーションシップタイプに属性をもたせる。
→ 誤り。エンティティタイプも属性は持たせている。（というかエンティティタイプをメインに属性を持たせている。）

エ：エンティティタイプの中に関連先のエンティティ名を記述することによって、リレーションシップを表す。
→ 誤り。リレーションシップは2つのエンティティを線で結ぶことで表す。

解答2

解答：イ

[それぞれの選択肢ごとの解説]

ア：関係データベースの表として実装することを前提に作成する。
→ 引っ掛け選択肢。確かにER図は関係データベースの表として実装することが多いが、前提ではない！！

イ：業務で扱う情報をエンティティ及びエンティティ間のリレーションシップとして表現する。
→ 大正解。

ウ：データの生成から消滅に至るデータ操作を表現できる。
→ 誤り。これはDFDの説明。DFDについてはこちらの記事をご覧ください。

エ：リレーションシップは、業務上の手順を表現する。
→ 誤り。リレーションシップは、エンティティ同士の相互関係を表す。

解答3

解答：エ

銀行と顧客の関係は多対多なので、関係データベース上に実装する際には、銀行と顧客の表だけでなく、2つの主キーを格納した顧客の表も実装する必要がある。

（銀行と顧客をリンクさせるために2つの主キーを格納した別の表を用意する必要がある）

具体的には、

• 銀行の表（属性：銀行の主キー、…）
• 顧客の表（属性：顧客の主キー、…）
• 口座の表（属性：銀行の主キー、顧客の主キー、…）

の3つの表が必要。

ここで、銀行と口座、口座と銀行のカーディナリティを調べる。（選択肢アとウの正誤を確認するために）

3つの表の関係をIE記法（っぽい）ER図で書くと、下のようになる。

よって、銀行と口座は「1対多」の関係に、口座と銀行は「多対1」の関係になる。

ここで、選択肢を見ていこう。

[それぞれの選択肢]

ア："銀行"表から"口座"表へのカーディナリティは多対1である。
→ 1対多の間違い。

イ："銀行"表中に参照制約を課した外部キーがある。
→ 間違い。外部キー（表と表を関連づけるために他の表の主キーを参照する列のこと）は銀行ではなく、"口座" 表中にある。

ウ："口座"表から"顧客"表へのカーディナリティは1対多である。
→ 多対1の間違い。

エ："口座"表には二つ以上の外部キーがある。
→ 正しい。銀行と顧客の2つの表を関連づけるまえに銀行の主キー、顧客の主キーと最低でも2つ以上の外部キーを用意する必要があるため。

９．さいごに

今回は、データベースの論理設計で使われるER図について説明しました。

どちらかというとソフトウェア工学というよりはデータベースの記事でしたね…。

ちなみに、Part07で説明する「クラス図」はER図の拡張版みたいなものなので、ER図を頭に入れておくことでクラス図の理解が少し楽になるかもしれません。

次回は、オブジェクト指向についての説明をしていきたいと思います。