データベーススペシャリスト試験 2013年 午後1 問01

模範解答

解説

解答の論理構成

1. 【問題文】の図３は「関係“名寄せ”，“利用者”の属性間の関数従属性」と明記されている。
2. 図２の凡例より，矩形Ａ→矩形Ｂの矢印は “Ａ → Ｂ” を意味する。
3. 図３で中央の太枠に格納された｛プロバイダID，利用者ID｝から，上部の「名寄せID」へ矢印が伸びているため
   $\{\text{プロバイダID},\text{利用者ID}\}\to \text{名寄せID}$
   が成立する。
4. 名寄せID からプロバイダID・利用者ID に向かう矢印は存在しない。従って
   $\text{名寄せID}\nrightarrow \{\text{プロバイダID},\text{利用者ID}\}$
   である。
5. 関係“名寄せ”（プロバイダID，利用者ID，名寄せID）で全ての属性を関数的に決定できる最小属性集合を列挙すると，｛プロバイダID，利用者ID｝のみが該当し，これが候補キーとなる。

誤りやすいポイント

• 「名寄せID は一意に識別するID」とあるため単独キーと決め付ける。矢印の向きを無視すると誤答になる。
• ｛プロバイダID，利用者ID｝のどちらか片方だけでキーになると誤解する。図３では二つがセットになって初めて名寄せID を決定している。
• 関数従属性の集合全体ではなく，図３に描かれた部分のみを見て候補キーを判定すべき点を見落とす。

FAQ

模範解答

解説

解答の論理構成

1. “利用者” の候補キーを確認
   • 図３より「プロバイダID」「利用者ID」「特性ID」が複合キーになっている。
2. 関数従属性から異常を導出
   • 「プロバイダID」「利用者ID」 → 「生年月日」「性別」「郵便番号」
   • 「特性ID」 → 「特性名」「特性タイプ」
   • しかし表自体は「プロバイダID」「利用者ID」「特性ID」が主キーなので、
     「特性ID」が NULL の状態では行を持てず、利用者基本情報だけを先に登録できない。
3. したがって挿入時の問題は
   “特性ID未確定の利用者を登録できない” という挿入異常である。
4. 正規化
   部分従属性・推移従属性を除去し、第３正規形に分解。

利用者（ ━プロバイダID━ , ━利用者ID━ , 生年月日, 性別, 郵便番号）

利用者特性（ ━特性ID━ , 特性名, 特性タイプ）

利用者特性値（ ━プロバイダID━ , ━利用者ID━ , ━特性ID━ , 特性値）

誤りやすいポイント

• 「特性値」ごとに「生年月日」などが重複する重複異常を“挿入異常”と混同する。
• 「特性名」「特性タイプ」まで主キーに含めてしまい、更に複雑な複合キーを作る。
• 第２正規形までの分解で止め、推移従属性（「特性ID」→「特性名」など）を残す。

FAQ

模範解答

解説

解答の論理構成

1. 所属関係の決定項を特定
   • 【表１】所属の説明
     「利用者の所属する組織及び職種は、履歴が管理される。」
     「利用者が所属する組織は、同時期には一つだけ登録できる。」
   • 履歴のキーは｛プロバイダID, 利用者ID, 所属登録日付｝
   • よって
     ｛プロバイダID, 利用者ID, 所属登録日付｝→｛組織ID, 職種｝
2. 組織関係の決定項を特定
   • 【表１】組織の説明
     「組織情報（組織名称、郵便番号）は、履歴が管理される。」
   • 履歴のキーは｛組織ID, 組織登録日付｝
   • よって
     ｛組織ID, 組織登録日付｝→｛組織名称, 郵便番号｝
3. 図２の表記法に合わせる
   • 決定項を太枠の大きな長方形にまとめ、矢印を被決定項へ。
   • ①の被決定項は「組織ID／所属登録日付」ブロックと「職種」
   • ②の被決定項は「組織名称／郵便番号」ブロック
   • 図４（完成版）は模範解答と一致する。

誤りやすいポイント

• 時間属性を外してしまう
  履歴管理と書かれている場合、登録日付を含めないと一意性が保てません。
• 「職種」から他属性が決まると勘違い
  実際には逆で、履歴キーが「職種」を決定します。
• 「組織ID」単独で名称が決まると考える
  登録日付で名称が変わる可能性があるため、必ず「組織登録日付」を合わせます。

FAQ

模範解答

解説

解答の論理構成

1. 図5の中央長方形には
   プロバイダID，サービス機能ID，利用者ID｜リソースID，タイムスタンプ
   という配置が示されている。上下２段で区切られているが，その中間の縦線は論理的な境界を示すだけで，各行は１レコードである。
2. 【問題文】「関係 “サービス提供リソース”（プロバイダID, サービス機能ID, 利用者ID, …）」より，行を一意に識別できる最小組合せを探す。
   • プロバイダID 単独では，同じプロバイダが複数機能・利用者を持つ。
   • サービス機能ID 単独でも，同一機能を複数プロバイダが提供し得る。
   • 利用者ID 単独はプロバイダ内でしか一意でない。
     結果，３属性を合わせた {プロバイダID，サービス機能ID，利用者ID} が最小の一意識別子＝候補キー。
3. 部分関数従属性の判定
   部分関数従属性は “候補キーの真部分集合 → 非キー属性” が存在するときに生じる。図5にその矢印は描かれていないため なし。
4. 推移的関数従属性の判定
   • 図5下部の矢印
     {プロバイダID，サービス機能ID，利用者ID} → リソースID
     リソースID → {URI，リソース種別，リソース名称，配信スキーマ}
     ２段階で非キー属性が別の非キー属性を決定しており，推移的関数従属性 あり。
5. 以上より模範解答と一致する。

誤りやすいポイント

• 「サービス名称／管理者名」→サービス機能ID の矢印を見て“部分従属性あり”と誤判定。これは候補キーの一部ではなく別集合からの従属性なので該当しない。
• リソースID を候補キーに含めて {プロバイダID，サービス機能ID，利用者ID，リソースID} としてしまう。リソースID は他の３属性によって一意に決まる（従属性側）ため冗長。
• 推移的従属性を “URI → リソースID” と逆向きに読んでしまう。図では矢印の向きが決定側→従属側である点に留意。

FAQ

模範解答

解説

解答の論理構成

1. 候補キーの決定
   図5では “プロバイダID”，“サービス機能ID”，“利用者ID” をまとめた箱から “リソースID”， “利用者登録日付” へ矢印があります。よって
   {プロバイダID, サービス機能ID, 利用者ID} → リソースID, 利用者登録日付
   が成り立ち、この3項目が候補キーになります。
2. 第1正規形確認
   いずれも単一値属性なので第1正規形は満たします。
3. 第2正規形確認
   部分従属を調べると、キーの真部分集合（例：プロバイダIDだけ 等）が非キー属性を決定する矢印は存在しません。したがって第2正規形を満たします。
4. 第3正規形違反の検出
   リソースID → URI, リソース種別, リソース名称, 配信スキーマ
   が存在し、リソースIDは候補キーではありません。これは推移従属性に該当し第3正規形違反です。
5. 分解
   ① キーに従属する属性を残した
   サービス提供（プロバイダID, サービス機能ID, 利用者ID, リソースID, 利用者登録日付）
   ② 推移従属性を受け止める新関係
   リソース（リソースID, リソース名称, URI, リソース種別, 配信スキーマ）
   分解後は
   ・情報損失なし（自然結合で元に復元可能）
   ・関数従属性保存（②の従属を新関係に残存）
   ・各関係ともキー以外の属性がキーに完全従属し、推移従属がない
   ため第3正規形が成立します。

誤りやすいポイント

• 「リソースIDを候補キーの一部」と思い込み、第1正規形どまりと判断してしまう。
• “利用者登録日付” を “リソースID” で決まると誤解し、分解を誤る。
• “プロバイダID” と “サービス機能ID” の組でリソースが一意と誤認し、候補キーを縮小してしまう。

FAQ

模範解答

解説

解答の論理構成

1. 前提
   • 関係“所属”は履歴管理されるため、同一キーで複数レコードが保持される（表２）。
   • 「アクセスした時点の利用者の所属を前提」とは、タイムスタンプ 時点で有効な 1 件に限定することを意味する。
2. 内自然結合の結果（表４）
   • 内自然結合は キー属性「プロバイダID」「利用者ID」で単純に結合するため、有効・無効を区別せずタプルを生成する。
   • 取得後に「アクセス時点の有効性」フィルタを掛けなければならない。
3. 各タプルの検証

   タプル	属する“アクセスログ”	検証対象“所属”	判定
   ①	タイムスタンプ 2013-04-10 12:00:00	所属登録日付 2013-01-10	有効（登録日が先）
   ②	タイムスタンプ 2013-04-10 12:00:00	所属登録日付 2013-04-15	無効（登録日が後）
   ③	タイムスタンプ 2013-04-03 14:00:00	所属登録日付 2013-03-10	有効
   ④	タイムスタンプ 2013-04-17 16:00:00	所属登録日付 2013-02-10	有効
   ⑤	タイムスタンプ 2013-04-18 18:00:00	所属登録日付 2013-02-10	有効

4. 結論
   有効性を満たさないのはタプル ② のみ。

誤りやすいポイント

• 所属登録日付 と タイムスタンプ の大小関係を見落とし、「最新＝最大日付」と短絡してしまう。
• 履歴管理の有効判定を忘れ、内自然結合だけで正答だと判断する。
• 複数の“所属”レコードがある利用者（A,1）を例外なく評価対象とする必要に気付かない。

FAQ

模範解答

解説

解答の論理構成

1. 問題文は次の通り述べています。
   ――【問題文】「関係“所属” 及び関係 “アクセスログ”に対して内自然結合演算及び射影演算を行い,関係 “利用実績” を作成した。」
2. 内自然結合は，指定された属性値が両関係で一致する行だけを残し，片方にしかない行は削除します。
3. したがって，
   ・“所属”には行があるが，“アクセスログ”に行が無い利用者
   は結合条件を満たさず“利用実績”に現れません。
4. 具体例
   表2にある「プロバイダID=B・利用者ID=2」は表3に無く，表4にも現れません。
5. よって「“アクセスログ”にタプルが無い＝まだアクセスしていない」利用者が条件となります。

誤りやすいポイント

• 「自然結合＝外部結合」と誤解して，片方に無い行も残ると思い込む。
• “所属”側に無い利用者が落ちると考え，“アクセスログ”側だけを見落とす。
• 表4の欠損を単なる抜粋だと誤認し，結合演算の性質を見逃す。

FAQ

模範解答

解説

解答の論理構成

1. 現状の演算
   ①【問題文】「関係“所属” 及び関係 “アクセスログ” に対して内自然結合演算 … を行い,関係 “利用実績” を作成」とある。
   ② その結果，表４では“所属”に存在する (プロバイダID=A, 利用者ID=1, 職種=営業, 所属登録日付=2013-04-15) などは写っているが，「表３に行が無い利用者」は出力されない。
2. 要件の確認
   【小問説明】「現れない利用者も…タプルに現れるように」とある。つまり“所属”の行は全て残す必要がある。
3. 外部結合の性質
   • 左外自然結合演算：左関係の全組を保持し，右に対応する組が無ければ NULL を付与する。
   • 右外・完全外では左側の残り方が要件を満たさない／冗長。
4. 結論
   よって「内自然結合演算」を「関係“所属”を左とする左外自然結合演算（または“所属”のタプルを全て出力する外自然結合演算）」に変更する。

誤りやすいポイント

• 単に「外部結合」と書いて左右を示さない
  ⇒ 右外結合にすると目的を達成できない。
• 「完全外結合」を選択
  ⇒ 余計に“アクセスログ”のみの行まで加わり，設問の趣旨とずれる。
• SQL 用語の LEFT JOIN だけを書く
  ⇒ リレーショナル代数の記号論である「左外自然結合演算」を明示すべき。

FAQ