HOME»基本情報技術者平成29年春期問題»午後問3
基本情報技術者過去問題 平成29年春期 午後問3
⇄問題文と設問を画面2分割で開く⇱問題PDF問3 データベース
住民からの問合せに回答するためのデータベースに関する次の記述を読んで，設問1～3に答えよ。
W市役所の生活環境課では，職員は住民からのごみの出し方に関する問合せがあったとき，対象物(ごみ)を検索条件としてルール表を検索し，出し方のルールを回答する業務を行っている。
問合せごとに一意な受付Noを割り当て，受付日，回答日，回答したルールの区分ID及び対象物IDを入力したレコードを問合せ記録表に登録する。問合せがあった対象物が対象物表になかった場合，回答日，区分ID及び対象物IDはNULLにして，メモ欄に当該対象物をテキストで入力したレコードを登録する。後日，問合せ記録表から，回答日，区分ID及び対象物IDがNULLのレコードを選択し，メモ欄に入力されている当該対象物の分別区分を決定し，一意な対象物IDを割り当て，対象物表に新たな対象物のレコードを登録する。ルール表に新たなルールのレコードを登録して，問合せ記録表の選択したレコードに，追加したルールの区分IDと対象物IDを設定する。
データベースの表構成とデータ格納例は，図1のとおりである。下線付きの項目は主キーを表す。
業務を行っている過程で幾つかの課題が明らかになった。これらのうちから対策すべき課題を選び，それを実現するために，データベースの表構成の見直し案を作成した。その結果を，表1に示す。
W市役所の生活環境課では，職員は住民からのごみの出し方に関する問合せがあったとき，対象物(ごみ)を検索条件としてルール表を検索し，出し方のルールを回答する業務を行っている。
問合せごとに一意な受付Noを割り当て，受付日，回答日，回答したルールの区分ID及び対象物IDを入力したレコードを問合せ記録表に登録する。問合せがあった対象物が対象物表になかった場合，回答日，区分ID及び対象物IDはNULLにして，メモ欄に当該対象物をテキストで入力したレコードを登録する。後日，問合せ記録表から，回答日，区分ID及び対象物IDがNULLのレコードを選択し，メモ欄に入力されている当該対象物の分別区分を決定し，一意な対象物IDを割り当て，対象物表に新たな対象物のレコードを登録する。ルール表に新たなルールのレコードを登録して，問合せ記録表の選択したレコードに，追加したルールの区分IDと対象物IDを設定する。
データベースの表構成とデータ格納例は，図1のとおりである。下線付きの項目は主キーを表す。
設問1
ルールIDの項目を追加する理由として適切な答えを，解答群の中から選べ。
解答群
- 同じ区分IDの同じ対象物IDに対する出し方のルールを複数件登録できるようにする。
- 同じ区分IDの異なる対象物IDに対する出し方のルールを登録できるようにする。
- 異なる区分IDの同じ対象物IDに対する出し方のルールを登録できるようにする。
解答選択欄
解答
- ア
解説
表1を見るとルール表へのルールIDの追加は、「同じ対象物でも大きさなどによって出し方を分ける必要が出てきた」への対策になっています。
たとえ大きさが違えど同じ対象物であれば対象物IDは同じになります。また同じゴミですから区分IDも当然同じです。見直し前のルール表は{区分ID，対象物ID}が主キーになっているので、区分IDと対象物IDが同一である行、例えばある対象物の"大きいサイズ用ルール"と"通常サイズ用ルール"などは一緒に格納できません。
ルールIDを追加し、区分IDと対象物IDの主キー制約をはずすことによって区分IDと対象物IDが同一の行を複数登録できるようになります。
また「イ」「ウ」に関しては見直し前のルール表でも登録可能なので誤りです。
∴ア：同じ区分IDの同じ対象物IDに対する出し方のルールを複数件登録できるようにする。
たとえ大きさが違えど同じ対象物であれば対象物IDは同じになります。また同じゴミですから区分IDも当然同じです。見直し前のルール表は{区分ID，対象物ID}が主キーになっているので、区分IDと対象物IDが同一である行、例えばある対象物の"大きいサイズ用ルール"と"通常サイズ用ルール"などは一緒に格納できません。
ルールIDを追加し、区分IDと対象物IDの主キー制約をはずすことによって区分IDと対象物IDが同一の行を複数登録できるようになります。
また「イ」「ウ」に関しては見直し前のルール表でも登録可能なので誤りです。
∴ア：同じ区分IDの同じ対象物IDに対する出し方のルールを複数件登録できるようにする。
設問2
次の記述中の に入れる適切な答えを，解答群の中から選べ。
ルール表のレコードを特定するために，問合せ記録表にルールIDの項目を追加するとき，ルールIDを外部キーとしたルール表に対するa制約を設定する。追加するルールIDの項目には，b。
ルール表のレコードを特定するために，問合せ記録表にルールIDの項目を追加するとき，ルールIDを外部キーとしたルール表に対するa制約を設定する。追加するルールIDの項目には，b。
a に関する解答群
- 非NULL
- NULL
- UNIQUE
- 参照
- 検査
- 主キー
b に関する解答群
- 非NULL制約は適用できない
- UNIQUE制約を適用する
- 更新操作を行うことはできない
- 主キー制約を適用する
解答選択欄
- a:
- b:
解答
- a=エ
- b=ア
解説
〔aについて〕
問合せ記録表に追加される"ルールID"列は、ルール表の主キーである"ルールID"列を参照するので外部キーになります。外部キーとなる列には参照制約(外部キー制約)を付与します。外部キーには参照制約を付けるのは、参照先の行が存在することを保証しデータベースの不整合を防ぐためです。
参照制約は、行の追加・更新および削除に次の制限を課します。
〔bについて〕
問合せのあった対象物が対象物表になかった場合、問合せ記録表には区分IDおよび対象物IDにNULLを設定した行が登録されます。このとき対象物が未登録であればルールも未登録のはずなので、ルールIDにもNULLが設定されることになります。もし"ルールID"列に非NULL制約が指定されていたならば、適用するルールが未確定の対象物に関する問合せを記録できなくなってしまいます。このため"ルールID"列には非NULL制約を適用できません。
∴b＝ア：非NULL制約は適用できない
問合せ記録表に追加される"ルールID"列は、ルール表の主キーである"ルールID"列を参照するので外部キーになります。外部キーとなる列には参照制約(外部キー制約)を付与します。外部キーには参照制約を付けるのは、参照先の行が存在することを保証しデータベースの不整合を防ぐためです。
参照制約は、行の追加・更新および削除に次の制限を課します。
- 行の登録・更新時に設定される外部キー列の値は、参照先の主キーの値として存在するものでなければならない。
- 参照先の表において、主キーの値が別表から参照されている行は削除できない。
〔bについて〕
問合せのあった対象物が対象物表になかった場合、問合せ記録表には区分IDおよび対象物IDにNULLを設定した行が登録されます。このとき対象物が未登録であればルールも未登録のはずなので、ルールIDにもNULLが設定されることになります。もし"ルールID"列に非NULL制約が指定されていたならば、適用するルールが未確定の対象物に関する問合せを記録できなくなってしまいます。このため"ルールID"列には非NULL制約を適用できません。
∴b＝ア：非NULL制約は適用できない
- 正しい。
- UNIQUE制約を付与すると、複数の対象物に同一のルールを対応させられなくなってしまいます。
- 更新後の値がルール表のルールID列に存在していれば更新可能です。(NULLにも更新可能)
- 問合せ記録表内の行は受付Noで一意に特定できるため"受付No"列が主キーです。"ルールID"列は外部キー属性なので主キー制約を付与するのは不適切です。
設問3
ルール表作成用DDLの見直しについて，次の記述中の に入れる適切な答えを，解答群の中から選べ。
図2に示す，ルールIDの項目と登録状態の項目追加後のルール表作成用DDLのレビュー時に，cは削除すべきとの指摘を受けた。また，登録状態の項目に対する制約が不足しているとの指摘もあり，dを追加することになった。
図2に示す，ルールIDの項目と登録状態の項目追加後のルール表作成用DDLのレビュー時に，cは削除すべきとの指摘を受けた。また，登録状態の項目に対する制約が不足しているとの指摘もあり，dを追加することになった。
c に関する解答群
- 区分IDの項目及び対象物IDの項目のUNIQUE制約
- 対象物IDの項目の非NULL制約
- 対象物IDの項目の参照制約
- ルールIDの項目の主キー制約
d に関する解答群
- CHECK(登録状態 IN('未公開'，'公開'))
- CHECK(登録状態 IS NULL)
- UNIQUE('未公開'，'公開')
- WHERE 登録状態 IN('未公開'，'公開')
解答選択欄
- c:
- d:
解答
- c=ア
- d=ア
解説
〔cについて〕
見直し後の表では、区分IDと対象物IDが同一である複数の行が登録される予定です。しかし区分IDと対象物IDの組合せにUNIQUE制約が付けられていると、このような行の登録ができず目的を果たせません。したがってUNIQUE制約を削除する必要があります。
∴c＝ア：区分IDの項目及び対象物IDの項目のUNIQUE制約
"登録状態"列は表定義で以下のように定義されています。
CHECK制約(検査制約)は、設定された値が有効範囲に収まっていることや、定められたフォーマットに従っていることなどを保証するために表や列に対して付与される制約です。構文は以下のようになっており、{条件}にはWHERE句で使用する条件式と同じように記述できます。
∴d＝ア：CHECK(登録状態 IN("未公開", "公開"))
見直し後の表では、区分IDと対象物IDが同一である複数の行が登録される予定です。しかし区分IDと対象物IDの組合せにUNIQUE制約が付けられていると、このような行の登録ができず目的を果たせません。したがってUNIQUE制約を削除する必要があります。
∴c＝ア：区分IDの項目及び対象物IDの項目のUNIQUE制約
- 正しい。
- もしある行の対象物IDがNULLならば、その行は何に対するルールなのかわかりません。このため非NULL制約は削除すべきではありません。
- 参照制約を削除すると、表間のデータ不整合が生じる可能性があります。
- 主キー制約を削除すると、主キーが存在しなくなってしまいます。
"登録状態"列は表定義で以下のように定義されています。
登録状態 VARCHAR(10) NOT NULL
表1には「"登録状態"列の値は"未公開"または"公開"のいずれかである」と記述されています。しかしこの定義は「10文字以内の任意の文字列」を意味するため、誤って2つ以外の文字列が登録されてしまう恐れがあります。CHECK制約(検査制約)は、設定された値が有効範囲に収まっていることや、定められたフォーマットに従っていることなどを保証するために表や列に対して付与される制約です。構文は以下のようになっており、{条件}にはWHERE句で使用する条件式と同じように記述できます。
CHECK ({条件})
CHECK制約の条件にIN句を使えば"登録状態"列の値をIN句で"未公開","公開"に制限できます。∴d＝ア：CHECK(登録状態 IN("未公開", "公開"))
- 正しい。
- 登録状態にNULL以外の値を設定できなくなってしまいます。
- UNIQUE制約の引数には列名を指定します。存在しない列名を指定することになるため構文エラーとなります。
- CREATE TABLE文内でWHERE句を使用できるのはSELECT文を伴う表定義を行う場合だけです。