システム監査技術者 2023年午前2 問21

問題文

UMLを用いて表した図のデータモデルを関係データベース上に実装する際の解釈のうち、適切なものはどれか。

🖊️ 解答を隠して解いてみる

選択肢

ア：“指定送付先”を指定する際、“付加情報”表のどの行でも選択できる。

イ：“付加情報”表と“顧客”表の行数は一致していなければならない。

ウ：“付加情報”表には“顧客”表に対する参照制約を指定する。（正解）

エ：“付加情報”表には“注文”表に対する参照制約を指定する。

🔒 解説は解答すると表示されます

UML関連の外部キー実装【午前2解説】

正解の理由

ウが適切です。顧客と付加情報の関連では、顧客側が「1」、付加情報側が「*」です。つまり、一つの顧客に複数の付加情報が対応し、各付加情報は一つの顧客に属します。

この関係を関係データベースで表すには、通常、「付加情報」表に顧客番号を外部キーとして追加し、「顧客」表の顧客番号を参照させます。図に顧客番号が属性として明記されていなくても、関連を表現するために外部キーを設けます。

解法ステップ

関連の多重度を確認します。
顧客側が「1」、付加情報側が「*」なので、一つの顧客に付加情報が複数対応します。
「1対多」の実装方法を考えます。
1対多の関係では、通常、「多」側の表に「1」側の主キーを外部キーとして持たせます。
「多」側の表を特定します。
今回は付加情報が「多」側なので、「付加情報」表に顧客番号を持たせます。
注文と付加情報の関連とは区別します。
注文が指定送付先を持つ場合の制約もありますが、それだけを見て「付加情報」表が「注文」表を参照すると判断しないようにします。顧客との関連の多重度から、付加情報表が顧客表を参照することが分かります。

選択肢別の誤答解説

ア：誤りです。
指定送付先として、付加情報表のどの行でも選べるわけではありません。注釈により、指定送付先を持つ注文の顧客と、指定送付先の注文主は一致する必要があります。したがって、別の顧客に属する付加情報は選択できません。
イ：誤りです。
顧客一件に対して付加情報が複数対応できるため、顧客表と付加情報表の行数が一致する必要はありません。顧客によっては付加情報がない場合も、複数ある場合もあります。
ウ：適切です。
各付加情報は一つの顧客に属するため、付加情報表に顧客表への外部キーを設けます。
エ：誤りです。
図の注文と付加情報の関連では、一つの注文に対応する付加情報は「0..1」です。付加情報が注文に従属して注文番号を持つ、と多重度から判断することはできません。なお、この関連を表す外部キーは、通常、注文表に付加情報の識別番号を持たせる形で表現できます。付加情報表が注文表を参照する形とは、外部キーの置き場所が逆です。

よくある誤解

「関連線があるなら、どちらの表に外部キーを置いても同じ」と考えること
1対多の関連では、通常、「多」側に「1」側の主キーを置きます。多重度を見て外部キーの置き場所を判断します。
注文と付加情報の関連だけで、外部キーの置き場所を決めること
図には複数の関連があります。それぞれの関連について、多重度や制約を分けて確認する必要があります。
図に属性として書かれていないキーは、表にも追加できないと考えること
関連を実装するため、クラスの属性に明記されていなくても外部キーを追加することがあります。

補足コラム

顧客側の黒塗りの菱形は、UMLの**コンポジション（合成）**を表します。全体である顧客と、その構成要素である付加情報の強い所有関係を示します。

ただし、コンポジションであることだけから、データベースでの削除動作まで一意に決まるわけではありません。削除時に付加情報も削除するかどうかは、外部キー制約の設定などで別途定めます。

FAQ

Q. 顧客番号が付加情報クラスの属性にないのに、なぜ外部キーを追加するのですか？
A. UML上の関連を関係データベースで表現するためです。図で属性として明記されていなくても、表の間の関係を維持するために外部キーを追加できます。

Q. 注文が指定送付先を持つとき、注文表は何を参照しますか？
A. 注文と付加情報の関連は、注文が付加情報を「0個または1個」持つ形なので、通常は注文表に付加情報の識別番号を外部キーとして設ける方法があります。ただし、顧客と付加情報の関連を表す外部キーは、別途、付加情報表に顧客番号を持たせます。

関連キーワード: UML、多重度、外部キー、参照制約、コンポジション