令和５年度　春　応用情報技術者試験　データベース問題の雑な解説

社内勉強会用に雑解説。
別に記事に起こさなくてもいいんだけど、起こしたほうがちゃんとまとめるパワーがでる。

とく順番

まずは回答見よう。ざっとみて無理そうならほかの区分選ぶが吉。

読み方

キーワードを拾う。拾え。

序盤。
冒頭３行はストーリ膨らませるためのものだから無視でOK。

重要フレーズ：「従業員の職務区分には管理職、一般職の二つあり」
分類を示すようなものが名にでてるのでメモっておこう。DB上にどう適宜されるかも疑問として持っておくべき。
この分で少なくとも「職務区分」列が存在することわかり、２つあるとのことで列のカーディナリティもわかる。
DBを設計するうえで「どんな種類のデータか」は重要なのでここは確実におさえる。

重要フレーズ：「組織には１名以上の従業員が所属している」
これもカーディナリティに言及しているので重要。
というかここ冒頭３行はいらないけどほかの文書は全部重要。
テーブル単体としてのデータの性質と、テーブル同士の性質がわかる記述はほぼ必須。読み解く。

図は階層のイメージがつかめなかったら抑えとく。KPIうんぬんは説明なのでどうでもいいっす。

数字と方法はWHERE区の条件になりえるので「あーなんかかいとったなー」ぐらいは目を通しておく。
見落としがちな「含めない」系の条件は線を引いておくといい。大体クエリでこのあたりが抜けてるので、ほらやっぱりーってなる。
単純な集計条件を問うこともあるけど、条件あってるのにおかしなーってときは「排除する条件」が足りてないことがほとんど。

図。まーとくときでOK.何回も見返すからしゃーなす。

基本的に「クエリを書かせる」ので、文章から「条件」を引っ張り出しまくる。
１階層目の「NULL」と職務区分のデータ「9999/12/31」は敏感に反応できるといい。
基本的にSQLは「まとめてとる」のでこのあたりの境界に属する条件をどうやって処理するかで悩むから。当然設問もこの辺をおしてくくる。

解く

a , b
ＥＲ完成させましょう問題。文章からテーブルの関係性を読み取れば解けるはず。
まずは簡単そうなＢからいこう。
・よほどの事情がないかぎりテーブルには主キーとなる属性（アトリビュート）があるが、これはない。
・従業員テーブルの属性を見る限り、従業員の情報を格納しておくテーブルであることは推測できる。
・従業員テーブルを「一意に定める」条件が問題文中に見当たらない（あれば大体「一意になる」とかなんとか書いてるから。今回はなし）
以上から、ＥＲ図をみて空気よんでちょ。という問題になる。
属性の名称は特に明記がない限り通常問題文中の言葉を使うのが望ましい。
これすごく嫌なんだけど「従業員コード」以外に妥当なキーが見当たらない。
DBではよく「○○コード」（サロゲート）をキーとして持たせる。正直従業員コードが従業員テーブルの主キーじゃなかったら嫌なので。というひどい回答になる。

サロゲート
 ナチュラルキーに対して、業務上は意味を持つ値ではないが、システム的に一意な値をとるようオートインクリメントなどで連番を振り、PKとしているテーブルのPKのことをサロゲートキー（代理キー）と呼びます。

a リレーションのカーディナリティ
ここはリレーションを引く以外はないのだけれど。あとはカーディナリティ（１：１、多：１、１：多、多対多）をどうするか。である。
まず多対多はなくなる。設計が壊れてなければ（壊れていることを明示しているERでなければ）そもそも多対多は存在できないから。
あとは問題文中から「組織」と「所属」に関する関係を開いてみていくわけだが、文中に明に2テーブルの関連を明示する記載は見当たらない。

となるとあとは持っている属性から推測していくぐらいしかなかろうて。

組織テーブルを見てみる

組織テーブルのアトリビュートは「所属」テーブルのキーに該当する要素を持っていないため、独立していると考えられえる。
よって組織テーブルは側のカーディナリティは「１」。
役職テーブルを見てみる

外部キーありますね。属性名は微妙にちがいますが、組織テーブルの外部キーとみてよいでしょう。

外部キーを持ってる側は通常「多」になりすので「１：多（ー＞）」になります。
なぜ「外部キーだと多になるの？」ですが、
正規化される前の状態に戻すと納得すると思います。
組織と所属テーブルが１つだった時代は
めちゃくちゃ端折りますが
「従業員コード」
「役職コード」
「組織コード」
「組織名」
でした。従業員コードは主キーなので、同じものは何度もあらわれませんが、
組織コードは複数の従業員コードに同じ値が現れる可能性があります。
そして、
「組織コード」は従業員コードに推移的従属をしているので（従業員コードがわかると組織コードがわかる、組織コードがわかると組織名がわかる）
で、正規化されて「組織」テーブルとしてだされたわけですね。ということで。