I85PREP
⌘ K
Database Specialist Examination study materials
Database Specialist Examination study resources

Database Specialist Examination practice questions

One question at a time. Build your Database Specialist Examination understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルの目的として最も適切なものはどれか。

  1. 特定のDBMSの記憶域構成や索引を詳細に定義する。
  2. アプリケーションの画面遷移と入力チェック仕様を確定する。
  3. データの意味とエンティティ間の関連を、DBMSに依存せず表現する。 Correct answer.
  4. 本番環境のバックアップ手順と目標復旧時間を決定する。

Explanation

概念データモデルは、業務上のエンティティ（entity）と関連（relationship）を、実装技術から独立して整理するためのモデルである。DBMS固有の記憶域や索引は物理データモデルで扱い、画面仕様や運用設計とは目的が異なる。

Question 2Data resource management and data modeling (概念データモデル, data standardization, repository)

データ標準化の活動として最も適切なものはどれか。

  1. 同じ意味のデータ項目に、共通の名称・定義・形式・コード体系を定める。 Correct answer.
  2. 各部門が独自に定めた項目名をそのまま維持し、画面ごとに自由に使えるようにする。
  3. データベースの性能を上げるために、すべての項目に重複して索引を作成する。
  4. 外部キー制約を削除して、データ投入順序の自由度を高める。

Explanation

データ標準化は、同じ意味のデータを同じ名前・定義・形式で扱えるようにする活動である。名称の統一だけでなく、データ型、桁数、コード体系、業務上の意味の定義を含む。

Question 3Data resource management and data modeling (概念データモデル, data standardization, repository)

リポジトリ（データディクショナリ）に格納する情報として最も適切なものはどれか。

  1. データ項目の定義やデータ型、業務ルールなどのメタデータを格納する。 Correct answer.
  2. アプリケーションのソースコードをコンパイルした実行形式ファイルだけを格納する。
  3. データベースサーバのCPU使用率の監視ログだけを格納する。
  4. 本番データベースの表データそのものだけを格納する。

Explanation

リポジトリは、データモデルやデータ項目の定義、業務ルール、モデル間の対応関係などのメタデータを一元管理する。本番の表データや実行形式ファイル、監視ログそのものを主目的に格納する場所ではない。

Question 4Data resource management and data modeling (概念データモデル, data standardization, repository)

代理キー（surrogate key）を主キーに採用する理由として最も適切なものはどれか。

  1. 外部キー制約を不要にして参照整合性の管理を放棄するため。
  2. すべての検索を全表走査に変えて性能を安定させるため。
  3. 業務ルールの変更を一切データモデルに反映しなくて済むようにするため。
  4. 自然キーの値が変わっても行の識別子を安定させるため。 Correct answer.

Explanation

代理キーは業務上の意味を持たない識別子であり、自然キーの値が変更されたり再利用されたりしても行を安定して識別できる。ただし自然キーの一意性制約が不要になるわけではなく、外部キーによる参照整合性も別途必要である。

Question 5Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルで多対多の関連を表現し、これをリレーショナル論理モデルへ変換する際の作業として最も適切なものはどれか。

  1. 多対多の関連を、両端の主キーを組み合わせた関連エンティティに変換する。 Correct answer.
  2. 両方のエンティティの主キーを同じ名前に変更して、1つの主キーに統合する。
  3. 関連の多重度をすべて1対1に変更し、外部キーを排除する。
  4. 多対多の関連を削除し、片方のエンティティにすべての属性を統合する。

Explanation

リレーショナルモデルでは多対多の関連を直接外部キーで表現できないため、両端の主キーを組み合わせた関連エンティティに変換する。この関連エンティティの主キーは通常、両端の主キーの組となり、必要に応じて関連自体の属性を追加する。

Question 6Data resource management and data modeling (概念データモデル, data standardization, repository)

データスチュワード（data steward）の役割として最も適切なものはどれか。

  1. 担当データ領域の用語定義や品質ルールを維持し、利用部門と調整する。 Correct answer.
  2. 経営層としてデータ活用の投資判断だけを行い、現場のデータ定義には関与しない。
  3. データベース管理者として、表領域の追加やロールバックセグメントのサイズを決定する。
  4. 外部監査人として、財務諸表の適正性について意見を表明する。

Explanation

データスチュワードは、担当データ領域の定義、用語集、品質ルールなどを業務側で維持し、利用部門と調整する役割を担う。データベースの物理運用や経営投資判断、外部監査は、それぞれ別の役割である。

Question 7Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルを論理データモデルへ変換する際の方針として最も適切なものはどれか。

  1. 特定DBMSのデータ型や索引を確定し、記憶域パラメータを設定する。
  2. 主キーや外部キー、正規化を導入し、DBMS非依存の論理構造を定める。 Correct answer.
  3. 画面項目の色や配置を決定し、帳票レイアウトを固定する。
  4. 業務用語を排除し、物理的なページ配置だけを記述する。

Explanation

論理データモデルでは、概念モデルのエンティティと関連をリレーショナル構造へ写像し、主キーや外部キー、正規化を検討する。特定DBMSの記憶域やページ配置は物理データモデルで扱い、画面や帳票の見た目はモデリングの中心ではない。

Question 8Data resource management and data modeling (概念データモデル, data standardization, repository)

複数の業務システムで使われている顧客コードを全社で統合する際の設計として最も適切なものはどれか。

  1. 各システムの既存コードをそのまま異なるコードとして併存させ、変換表を持たない。
  2. 全社共通の顧客識別子を定め、既存コードを別名として対応付ける。 Correct answer.
  3. 顧客コードの桁数を各システムで自由に変更できるようにし、照合は目視で行う。
  4. 顧客コードに常に現在の住所や電話番号を含め、変更時はコードを再採番する。

Explanation

コード統合では、全社で一意な共通識別子を定め、既存システムのコードは対応表や別名として管理するのが基本である。住所や電話番号のように変わりやすい値をコードに埋め込むと、変更のたびに識別子が不安定になる。

Question 9Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルで汎化・特化を導入する判断として最も適切なものはどれか。

  1. サブタイプ間で属性や関連が異なり、共通概念として扱う場合に導入する。 Correct answer.
  2. 物理表の数を必ず増やし、結合処理を複雑にして性能を落とすために導入する。
  3. 外部キー制約を回避し、参照整合性の設計を省略するために導入する。
  4. すべてのエンティティに共通属性が1つもない場合に、無条件で導入する。

Explanation

汎化・特化は、複数のサブタイプに共通する性質を上位のスーパータイプにまとめ、差異をサブタイプに分けて表現する。サブタイプ間で属性や関連が大きく異なり、共通概念として扱う利点があるかを基準に判断する。

Question 10Data resource management and data modeling (概念データモデル, data standardization, repository)

顧客の住所変更履歴を保持する概念データモデルとして最も適切なものはどれか。

  1. 住所を主キーの一部に含め、変更のたびに顧客の識別子を変更する。
  2. 住所の変更回数だけ顧客表の列を追加し、上限を設けずに横持ちで保持する。
  3. 顧客と住所の関連に適用開始日と終了日を持たせ、履歴を関連エンティティで管理する。 Correct answer.
  4. 顧客表の住所列を上書きし、変更前の値はバックアップから復元する。

Explanation

履歴を保持するには、住所を上書きするのではなく、いつからいつまで有効かを表す時間属性を関連に持たせる設計が基本である。関連エンティティや履歴エンティティとして管理すると、変更前後の住所を同じ顧客識別子のまま追跡できる。

Question 11Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデル（概念スキーマ）の説明として最も適切なものはどれか。

  1. 利用者グループごとのアクセス権限と表示形式を定義したもの
  2. 個々の業務アプリケーションから見たデータの見え方と画面項目を定義したもの
  3. データの物理的な格納位置、索引、分散配置を定義したもの
  4. 組織全体で共有するデータの構造を、実装技術から独立した形で表したもの Correct answer.

Explanation

概念スキーマは三層スキーマ構造の最上位に位置し、組織全体で共有されるエンティティや関連、業務ルールを、特定のDBMSや物理配置に依存しない形で表現する。外部スキーマは利用者ごとの見え方、内部スキーマは格納構造を表すため、「実装技術から独立」という点が概念スキーマの特徴となる。

Question 12Data resource management and data modeling (概念データモデル, data standardization, repository)

ER図において、関連の線の端にカラスの足（crow's foot）が描かれている場合、その端が示す意味として最も適切なものはどれか。

  1. その端のエンティティは主キーを持たない
  2. その端のエンティティは関連に参加しない
  3. その端のエンティティのインスタンスは高々1個である
  4. その端のエンティティのインスタンスは複数存在し得る（多側） Correct answer.

Explanation

カラスの足はIE記法で「多」を表し、その端のエンティティのインスタンスが複数存在し得ることを示す。1側は足のない線や縦棒で表し、任意か必須かは縦棒や丸の有無で区別する。

Question 13Data resource management and data modeling (概念データモデル, data standardization, repository)

リレーションの属性が第1正規形を満たすための条件として最も適切なものはどれか。

  1. 候補キーがただ一つに絞り込まれている
  2. 非キー属性が主キーに完全関数従属している
  3. 非キー属性間の推移的関数従属が取り除かれている
  4. 各属性が単一値であり、繰返し項目や入れ子構造をもたない Correct answer.

Explanation

第1正規形は、すべての属性が単一値で繰返し項目を含まないこと（非正規形の排除）を条件とする。完全関数従属は第2正規形、推移的関数従属の排除は第3正規形の条件であり、候補キーの絞り込みは正規形の条件ではない。

Question 14Data resource management and data modeling (概念データモデル, data standardization, repository)

注文と注文明細のように、明細の識別番号が注文ごとにしか一意でない依存エンティティがある。概念データモデルでこのエンティティの識別子を表す方法として最も適切なものはどれか。

  1. すべての属性の値を連結したものを識別子とする
  2. 所有者である注文の識別子と、注文内で一意な部分キーを組み合わせる Correct answer.
  3. 明細番号だけを識別子とし、注文との関連は属性として持たせない
  4. 所有者である注文の識別子だけを識別子とする

Explanation

依存エンティティの識別子は、所有者エンティティの識別子と、所有者の範囲内でのみ一意な部分キーを組み合わせて表す。明細番号単独では注文をまたぐと重複し得るため、識別子としては不十分である。

Question 15Data resource management and data modeling (概念データモデル, data standardization, repository)

業務機能とエンティティのCRUDマトリクスを作成したところ、あるエンティティにC（作成）がどの業務機能にも付かなかった。この結果の解釈と対応として最も適切なものはどれか。

  1. すべての業務機能にCを追加して、作成が一箇所に集中しないようにする
  2. UとDを削除し、当該エンティティを参照専用として定義する
  3. 生成をデータ移行や外部システムが担っている可能性を確認し、必要なら移行元や外部インタフェースをCの発生源として明示する Correct answer.
  4. 当該エンティティは不要と判断し、マトリクスから削除する

Explanation

CRUDマトリクスでCが欠けるのは、データの生成が画面業務以外（初期移行や外部システム連携）で行われていることを示すことが多い。削除や無理な追加ではなく、生成元を特定してマトリクスに明示するのが正しい対応である。

Question 16Data resource management and data modeling (概念データモデル, data standardization, repository)

リポジトリでデータリネージ（data lineage）をメタデータとして管理する主な目的として最も適切なものはどれか。

  1. バックアップの取得間隔と保存世代を自動で決定すること
  2. 表の物理的な断片化を抑えるための領域割当てを決めること
  3. データ項目がどのシステムや変換処理を経て現在の値になったかを追跡できるようにすること Correct answer.
  4. 利用者ごとの行レベルセキュリティの条件を定義すること

Explanation

データリネージは、項目やデータセットの由来と変換の履歴をメタデータとして保持するもので、障害時の原因追跡や影響範囲調査、監査対応に用いる。物理配置やセキュリティ条件、バックアップ計画を決めるための情報ではない。

Question 17Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルで属性ごとにドメイン（値域）を定義しておく目的として最も適切なものはどれか。

  1. 取り得る値の集合や単位を統一し、同じ意味の値を比較できるようにするため Correct answer.
  2. インデックスを張る列をモデルから自動的に選定するため
  3. 表の行数を抑えるために値の種類を制限するため
  4. 属性値の暗号化方式をモデル上で確定させるため

Explanation

ドメイン定義は、属性が取り得る値の集合、データ型、単位、コード体系などを統一するもので、異なるエンティティやシステム間で意味の揃った値を比較・結合できるようにする。暗号化や索引選択は物理設計寄りの論点である。

Question 18Data resource management and data modeling (概念データモデル, data standardization, repository)

「1件の注文は必ず1人の顧客に属し、1人の顧客は注文を0件以上持つ」という業務ルールを概念データモデルに表した記述として最も適切なものはどれか。

  1. 注文から見た顧客は必須で1、顧客から見た注文は0以上（多）である Correct answer.
  2. 注文と顧客は双方とも1対1である
  3. 注文から見た顧客は0または1、顧客から見た注文は必ず1である
  4. 注文と顧客は双方とも0以上（多対多）である

Explanation

業務ルールから、注文側の関連端は顧客が必須で1、顧客側の関連端は注文が0以上となる。必須性は注文から顧客への参照が必ず存在することを意味し、多対多や1対1ではない。

Question 19Data resource management and data modeling (概念データモデル, data standardization, repository)

氏名・住所・電話番号の表記ゆれが存在する顧客データで、重複レコードの同一性を判定して統合する仕組みの設計として最も適切なものはどれか。

  1. 複数項目の一致度に基づくマッチング規則とスコアの閾値を定め、閾値未満の候補は人による確認に回す Correct answer.
  2. 顧客コードの採番規則を変更して、今後重複が発生しないようにする
  3. すべての項目が完全一致した場合に限り同一の顧客とみなす
  4. 重複が見つかるたびに、より新しく登録されたレコードを無条件に正とする

Explanation

表記ゆれを含むデータの同一性判定では、複数項目の一致度を組み合わせたマッチング規則と閾値を設計し、自動判定が難しい候補は人によるレビューに送る。完全一致のみでは取りこぼしが多く、採番規則の変更や無条件の最新優先は既存の重複を解決しない。

Question 20Data resource management and data modeling (概念データモデル, data standardization, repository)

正規化された論理モデルに対し、参照性能のため意図的な非正規化（集計値や名称の重複保持）を導入する場合、あわせて必ず設計すべきものとして最も適切なものはどれか。

  1. 更新元との整合性を保つ手段（トリガ、バッチ等）と反映遅延・責任範囲を定める Correct answer.
  2. 非正規化列の更新権限を複数アプリケーションに配布し、差異は事後に分析する
  3. 非正規化した列は更新せず、必要時に全件を作り直す夜間バッチだけを用意する
  4. 整合性の確認はアプリケーション側の責任とし、データベースには制約を置かない

Explanation

非正規化は冗長性を許容する設計判断であり、更新時に元データとの不整合が生じ得るため、整合性を保つ更新手段と反映遅延、責任範囲をあわせて決める必要がある。更新を禁止したり権限を拡散したりすると、かえって不整合と属人化を招く。

Question 21Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルのER表記において、関連の線の端に○（円）が付いている場合、その端が示す意味として最も適切なものはどれか。

  1. その端のインスタンスが0個でもよいことを示す Correct answer.
  2. その端が主キー側であることを示す
  3. その端のインスタンスが必ず1個以上存在することを示す
  4. その端が多側であることを示す

Explanation

IE表記法では、関連線の端の記号はカーディナリティ（最小・最大）を表します。○は最小カーディナリティが0、つまり相手が存在しなくてもよい任意の関連であることを示します。必ず1件以上存在する場合は○を付けず、最大数はカラスの足などで表します。

Question 22Data resource management and data modeling (概念データモデル, data standardization, repository)

全社でデータ項目の標準化を進める際の命名規則として、最も適切なものはどれか。

  1. 画面の項目名をそのまま論理名として採用する
  2. 名詞形で統一し、全社の標準略語集に従う Correct answer.
  3. 英字はすべて小文字にし、日本語は使わない
  4. 業務部門ごとに独自の略語を使って短くする

Explanation

標準化された命名規則では、データ項目は名詞形で意味が一意になるようにし、全社で承認された標準略語集を用いる。部門ごとの略語や画面名の流用は、同義語・同音異義語の発生源になる。英字の大文字小文字だけを統一しても意味の標準化にはならない。

Question 23Data resource management and data modeling (概念データモデル, data standardization, repository)

リレーションが第3正規形を満たすための条件として、最も適切なものはどれか。

  1. すべての決定項が候補キーである
  2. すべての属性が原子値である
  3. 非キー属性が主キー全体に完全関数従属する
  4. 非キー属性間に推移的関数従属がない Correct answer.

Explanation

第3正規形は、第2正規形を満たしたうえで、非キー属性が他の非キー属性に関数従属する推移的関数従属を排除した状態である。たとえば、社員番号→部署コード→部署名のような従属が残っていると第3正規形ではない。すべての属性が原子値であることは第1正規形の条件である。

Question 24Data resource management and data modeling (概念データモデル, data standardization, repository)

組織の上位・下位関係のように、同じエンティティのインスタンス同士が親子関係を持つ業務を概念データモデルで表す方法として、最も適切なものはどれか。

  1. 上位組織の識別子を持たせた自己参照関連を定義する Correct answer.
  2. 組織と上位組織の間に多対多の関連エンティティを定義する
  3. 組織エンティティと上位組織エンティティを別々に定義する
  4. 上位組織名を組織エンティティの繰り返し属性として定義する

Explanation

組織の上位・下位のように同じエンティティ同士が関係する場合は、自己参照関連（再帰関連）として表現する。組織エンティティに上位組織の識別子を持たせ、同じエンティティの別インスタンスを参照させる。これにより階層の深さに依存せず、任意の階層を表現できる。

Question 25Data resource management and data modeling (概念データモデル, data standardization, repository)

商品分類のように業務上の意味をコードの桁に埋め込んだ分類コードを全社標準として採用する場合の課題として、最も適切なものはどれか。

  1. 分類変更のたびにコード値の変更が必要になり、過去データと整合しにくい Correct answer.
  2. 桁数が固定できるため、データベースの項目長を変更する必要がなくなる
  3. 採番の自動化ができず、必ず手作業になる
  4. 同じコードに複数の意味を持たせられるため、コードの重複や解釈の揺れが増える

Explanation

区分コードや分類コードのように桁の意味を業務分類に結び付けたコードは、分類体系の変更時にコード値そのものを変更しなければならない。その結果、既存の取引データや外部連携との整合を崩しやすい。コードは識別子として安定させ、分類は別の属性やコード表で管理するのが望ましい。

Question 26Data resource management and data modeling (概念データモデル, data standardization, repository)

リポジトリに格納されたメタデータを用いてインパクト分析を行う目的として、最も適切なものはどれか。

  1. 利用者ごとのアクセス権限を管理する
  2. データベースのバックアップ取得時刻を記録する
  3. データ項目に格納されている現在のレコード件数を集計する
  4. 変更する項目を参照する画面やプログラムを特定する Correct answer.

Explanation

リポジトリのインパクト分析では、変更対象のデータ項目と、それを参照・更新する画面、帳票、プログラム、他システムとの関連をたどる。これにより変更の影響範囲を事前に把握し、改修漏れや障害を防ぐ。件数集計やバックアップ記録はメタデータ管理の目的とは異なる。

Question 27Data resource management and data modeling (概念データモデル, data standardization, repository)

複数部門がそれぞれ作成した概念データモデルを全社モデルに統合する際の作業として、最も適切なものはどれか。

  1. すべてのエンティティ名を部門コード付きの別名に変更する
  2. 同義語・同音異義語を調整し、同一の実体を一つのエンティティに統合する Correct answer.
  3. 部門ごとのモデルをそのまま重ね合わせ、同名のエンティティも別物として残す
  4. 共通と思われる属性をすべて削除して統合する

Explanation

複数部門のモデルを統合する際は、同じ意味の用語（同義語）と、同じ表記で意味が異なる用語（同音異義語）を調整する。同一の実体は一つのエンティティに統合し、属性の定義やドメインも合わせて標準化する。単純に重ねるだけでは重複や矛盾が残る。

Question 28Data resource management and data modeling (概念データモデル, data standardization, repository)

全社共通で利用するコード値（ドメイン）の追加・変更を管理する方法として、最も適切なものはどれか。

  1. 各利用部門が業務都合に合わせて自由にコード値を追加できるようにする
  2. コード値は一度決定した後は、変更も追加も一切禁止する
  3. コード値ごとに個別のテーブルを作成する
  4. 追加・変更を申請・承認のうえ標準コード表に登録する Correct answer.

Explanation

標準コード値の追加や変更は、利用部門の申請と承認を経て標準コード表に登録し、リポジトリで版管理する。これにより、部門ごとの勝手なコード追加や表記ゆれを防ぎ、全社で同じ値を参照できる。禁止一辺倒では業務変更に対応できない。

Question 29Data resource management and data modeling (概念データモデル, data standardization, repository)

概念データモデルにおいて、関連は定義するが外部キー属性を明示しない理由として、最も適切なものはどれか。

  1. 概念データモデルではすべての属性を省略するため、外部キーは存在しない
  2. 概念データモデルでは主キーを定義しないため、外部キーも定義できない
  3. 関連として表現されるため、外部キー属性を明示する必要がない Correct answer.
  4. 概念データモデルでは物理設計の情報だけを管理するため、外部キーは対象外である

Explanation

概念データモデルは業務上の実体と関連を表すもので、外部キーは論理モデルや物理モデルで関連を実装するために付与する。概念モデルでは関連そのものが参照関係を表すため、外部キー属性を明示する必要はない。主キーや外部キーの具体化は下流の設計工程で行う。

Question 30Data resource management and data modeling (概念データモデル, data standardization, repository)

リレーションがBCNF（ボイス・コッド正規形）を満たすための条件として、最も適切なものはどれか。

  1. すべての関連が1対多である
  2. 非キー属性が主キー全体に完全関数従属する
  3. すべての決定項が候補キーである Correct answer.
  4. すべての属性が原子値である

Explanation

BCNFは、関数従属のすべての決定項が候補キーであることを要求する。第3正規形でも残る、候補キー以外の決定項による関数従属を排除できる。たとえば、候補キーが複数ある関係で、非キー属性が別の候補キーを決定する場合などにBCNFへの分解が必要になる。

Question 31Data resource management and data modeling (概念データモデル, data standardization, repository)

データ辞書（data dictionary）に登録して管理する情報として最も適切なものはどれか。

  1. データ項目の意味・型・桁数・値域・関係 Correct answer.
  2. プログラムのコンパイル手順と依存ライブラリの一覧
  3. 画面レイアウトのデザイン案と配色ルールの一覧
  4. サーバのCPU使用率とメモリ使用量の監視ログ

Explanation

データ辞書は、データ項目の名称・意味・データ型・桁数・値域・他の項目との関係などをメタデータとして管理する。業務部門と開発部門が同じ解釈でデータを利用するための基礎となる。

Question 32Data resource management and data modeling (概念データモデル, data standardization, repository)

リレーションが第2正規形を満たすための条件として最も適切なものはどれか。

  1. すべての属性が単一値であり、繰り返し項目がない
  2. 第1正規形を満たし、主キーの一部にのみ依存する非キー属性が存在しない Correct answer.
  3. 第1正規形を満たし、非キー属性が他の非キー属性に依存しない
  4. すべての決定項が候補キーである

Explanation

第2正規形は第1正規形を満たしたうえで、主キーが複合キーの場合に、主キーの一部だけに依存する非キー属性（部分関数従属）が存在しない状態をいう。部分従属を排除するために、必要に応じてリレーションを分解する。

Question 33Data resource management and data modeling (概念データモデル, data standardization, repository)

学生と科目のように、1人の学生が複数科目を履修し、1科目を複数学生が履修する多対多の関連を概念データモデルで表す方法として最も適切なものはどれか。

  1. 履修エンティティを導入し、学生と科目に1対多の関連を持たせる Correct answer.
  2. 科目エンティティに複数学生の学生番号を格納する繰り返し属性を追加する
  3. 学生と科目の間に1対多の関連を2本引き、どちらからも参照できるようにする
  4. 学生エンティティに複数科目の科目コードを格納する繰り返し属性を追加する

Explanation

多対多の関連は、両側のエンティティを1対多で参照する関連エンティティ（交差エンティティ）に分解すると表現できる。履修エンティティには学生番号と科目コードを外部キーとして持たせ、履修日や成績などの関連固有の属性を置ける。

Question 34Data resource management and data modeling (概念データモデル, data standardization, repository)

顧客を「個人顧客」と「法人顧客」に分け、共通属性（顧客番号、住所、電話番号）を持たせたい。概念データモデルでの表現として最も適切なものはどれか。

  1. 顧客スーパータイプに共通属性を置き、個人・法人顧客をサブタイプに特化する Correct answer.
  2. 顧客エンティティに個人用と法人用の全属性を並べ、未使用項目はNULLにする
  3. 顧客エンティティを削除し、住所エンティティだけを残して共通属性を住所に持たせる
  4. 個人顧客と法人顧客を別々のエンティティにし、共通属性はどちらにも重複して持たせる

Explanation

共通属性をスーパータイプに集約し、個人顧客と法人顧客の固有属性をサブタイプに置くことで、重複を避けつつ共通の制約を一箇所で管理できる。サブタイプが排他的であれば、識別子（ディスクリミネータ）で種類を判別する。

Question 35Data resource management and data modeling (概念データモデル, data standardization, repository)

社員がプロジェクトに参加するとき、参加開始日と役割を保持する必要がある。概念データモデルでの表現として最も適切なものはどれか。

  1. 社員エンティティに参加開始日と役割の属性を追加し、社員ごとに保持する
  2. 社員とプロジェクトの関連に参加開始日と役割を属性として持たせる Correct answer.
  3. プロジェクトエンティティに社員番号・参加開始日・役割の組を繰り返し属性として持たせる
  4. 参加開始日と役割は関連の線にコメントとして記載し、属性としては定義しない

Explanation

参加開始日や役割は、社員にもプロジェクトにも固有ではなく、両者の組み合わせによって決まる。したがって関連に属性を持たせるか、関連エンティティとして独立させ、参加単位の属性を管理する。

Question 36Data resource management and data modeling (概念データモデル, data standardization, repository)

商品コードが改番される可能性がある業務で、商品エンティティの主キー設計として最も適切なものはどれか。

  1. 代理キーを主キーとし、商品コードは一意制約で管理し履歴を別に持つ Correct answer.
  2. 商品名を主キーにし、商品コードは一意制約を付けずに属性として持つ
  3. 主キーを設けず、商品コードと商品名の組み合わせでレコードを識別する
  4. 商品コードを主キーにし、改番時は関連するすべての外部キーを漏れなく更新する

Explanation

自然キーが改番などで変更されうる場合、代理キーを主キーにすると関連する外部キーの更新を避けられ、識別子が安定する。商品コードは一意制約を付けた自然キーとして管理し、改番履歴は別途保持する。

Question 37Data resource management and data modeling (概念データモデル, data standardization, repository)

複数部門が「顧客CD」「得意先コード」「取引先番号」と呼ぶ同一意味のデータ項目を全社標準化する際、最初に行う作業として最も適切なものはどれか。

  1. 各部門のシステムを直ちに改修し、画面と帳票の項目名を統一する
  2. 項目の意味を定義し、シノニムと差異を整理して標準項目を決める Correct answer.
  3. 最も桁数の大きいデータ型に全システムの項目を合わせ、格納領域を確保する
  4. 各部門の項目をすべて残したまま、相互変換するための変換表だけを作成する

Explanation

標準化では、まず項目の業務上の意味を定義し、同義語（シノニム）や部門間の差異を整理して全社で一つに統合する標準項目を決める。そのうえで型・桁・値域や変換ルールを定め、既存システムへの影響を評価する。

Question 38Data resource management and data modeling (概念データモデル, data standardization, repository)

組織改編が頻繁にあり、社員の所属部門の履歴を概念データモデルで保持したい。最も適切な設計はどれか。

  1. 社員エンティティに部門コードを履歴分だけ繰り返し属性として持たせる
  2. 社員エンティティに現在の部門コードだけを持たせ、過去はバックアップファイルで保管する
  3. 社員と部門の関連に有効期間を持たせ、期間付き関連として履歴を管理する Correct answer.
  4. 部門エンティティに所属社員の氏名をすべて保持し、異動のたびに更新する

Explanation

所属履歴は、社員と部門の関連に有効開始日と有効終了日を持たせる期間付き関連で表すと、いつどの部門に所属したかを正確に保持できる。期間の重複や欠落を防ぐ制約を設け、現在の所属は終了日が未設定の行として扱う。

Question 39Data resource management and data modeling (概念データモデル, data standardization, repository)

全社リポジトリで複数プロジェクトの概念データモデルを管理する際、モデル変更のトレーサビリティを確保する方法として最も適切なものはどれか。

  1. 各プロジェクトが個別にファイル共有サーバへモデルを置き、命名規則だけを統一する
  2. 最新版のモデルだけを保持し、変更前の版はリポジトリから削除する
  3. モデルに版番号を付け、変更理由・影響範囲・承認者を記録する Correct answer.
  4. 変更のたびに物理データベースを再作成し、過去のモデルは残さない

Explanation

リポジトリでモデルの版番号と変更履歴を管理し、変更理由・影響範囲・承認者をメタデータとして関連付けると、いつ誰がなぜ変更したかを追跡できる。これにより複数プロジェクト間の変更の整合性確認と監査対応が可能になる。

Question 40Data resource management and data modeling (概念データモデル, data standardization, repository)

受注明細のように、親となる受注が存在しなければインスタンスが存在し得ないエンティティを概念データモデルで表現する方法として、最も適切なものはどれか。

  1. 受注との間に識別関連を定義し、親の主キーと明細の連番で明細を識別する。 Correct answer.
  2. 受注明細を独立したエンティティとし、受注番号を非キー属性として保持する。
  3. 受注と受注明細の間に多対多の関連を定義し、関連に明細番号と数量を持たせる。
  4. 受注明細に全社で一意な人工キーを付与し、受注との関連を任意（0..1）とする。

Explanation

存在依存のあるエンティティは、親との識別関連（依存関連）で結び、親の主キーを部分識別子として主キーに取り込むことで表現する。これにより、親が存在しなければ子も存在し得ないという業務上の制約と、親が異なれば同じ連番を再利用できるという識別範囲をモデルに反映できる。

Question 41Database design (logical and physical design, normalization)

A relation has a composite candidate key (order_id, line_no), and a non-key attribute product_name depends on line_no alone. Removing that dependency by placing product_name in its own table moves the relation into which normal form?

  1. Boyce-Codd normal form (BCNF)
  2. Second normal form (2NF) Correct answer.
  3. First normal form (1NF)
  4. Third normal form (3NF)

Explanation

Second normal form requires every non-prime attribute to depend on the whole of every candidate key, so a dependency on only part of a composite key (a partial dependency) breaks it. Eliminating that partial dependency is exactly the step from 1NF to 2NF. Third normal form and BCNF are stricter and address transitive dependencies and non-superkey determinants instead.

Question 42Database design (logical and physical design, normalization)

Relation R(A, B, C, D) has functional dependencies AB → C and C → D, and AB is the only candidate key. Which characterisation of R is correct?

  1. It satisfies 3NF but violates BCNF, because C is not a candidate key of R
  2. It satisfies 2NF but violates 3NF, because D depends transitively on the key through C Correct answer.
  3. It satisfies only 1NF, because D is partially dependent on B alone
  4. It satisfies BCNF, because AB determines every attribute of R

Explanation

No non-prime attribute depends on a proper subset of AB, so the relation is in 2NF. The dependency C → D is transitive with respect to the key because C is not a superkey, which violates 3NF and therefore BCNF as well. Normalising would extract the relation (C, D).

Question 43Database design (logical and physical design, normalization)

Which description best characterises a surrogate key in physical table design?

  1. A key copied from an external source system and reused unchanged
  2. A key derived from business attributes that identify the row
  3. A key formed by combining two foreign keys in an associative table
  4. A system-generated value with no business meaning, such as a sequence or UUID Correct answer.

Explanation

A surrogate key is an identifier assigned by the system, typically from a sequence, identity property, or UUID generator, carrying no business meaning. Because it is decoupled from business data it stays stable when natural key values are corrected or reused. Natural keys, by contrast, come from business attributes and are exposed to such changes.

Question 44Database design (logical and physical design, normalization)

A B-tree index exists on orders(customer_id, order_date, status). Which predicate can use the index for a single contiguous range seek under the leftmost-prefix rule?

  1. WHERE customer_id = 42 OR status = 'SHIPPED'
  2. WHERE status = 'SHIPPED' AND order_date = DATE '2024-05-01'
  3. WHERE customer_id = 42 AND order_date >= DATE '2024-01-01' Correct answer.
  4. WHERE order_date = DATE '2024-05-01' AND status = 'SHIPPED' AND total > 100

Explanation

A composite B-tree index is seekable when the predicate supplies a leading prefix of the indexed columns, here an equality on customer_id followed by a range on order_date. The remaining column status cannot be used for the range bound but does not prevent the seek. Predicates without the leading column, or connected by OR across columns, cannot bound one contiguous index range.

Question 45Database design (logical and physical design, normalization)

A logical model contains a many-to-many relationship, Enrolment, between Student and Course, and the relationship itself carries the attribute enrolled_on. What is the correct relational mapping?

  1. Create an Enrolment table with a surrogate key and no foreign keys at all
  2. Create an Enrolment table keyed by (student_id, course_id) holding enrolled_on Correct answer.
  3. Place a course_id foreign key plus the enrolled_on attribute inside the Student table
  4. Place a student_id foreign key plus the enrolled_on attribute inside the Course table

Explanation

A many-to-many relationship becomes its own table containing the two foreign keys, and attributes that belong to the relationship are stored there rather than on either entity. The combination (student_id, course_id) is the natural primary key, and a surrogate key may be added without changing that uniqueness constraint.

Question 46Database design (logical and physical design, normalization)

Relation R(A, B, C) satisfies AB → C and C → B, and its candidate keys are AB and AC. Which characterisation is correct?

  1. R is in 1NF only because C determines B
  2. R is not in 2NF because B depends on part of the key
  3. R is in 3NF but not BCNF because C is not a superkey Correct answer.
  4. R is in BCNF because every attribute is part of a candidate key

Explanation

For 3NF each functional dependency must either have a superkey determinant or a dependent attribute that is prime. C → B has a non-superkey determinant but B is prime, belonging to key AB, so 3NF holds. BCNF drops the prime-attribute allowance, and because C is not a superkey the relation is not in BCNF.

Question 47Database design (logical and physical design, normalization)

A warehouse team merges three related customer lookup tables into one wide customer dimension. What is the primary benefit and the accompanying cost of this decision?

  1. Fewer joins at query time, at the cost of redundancy and update anomalies Correct answer.
  2. Elimination of all data redundancy, at the cost of losing historical records
  3. A smaller storage footprint, at the cost of extra join operations per query
  4. Stricter enforcement of third normal form, at the cost of slower star-join queries

Explanation

Denormalisation trades write-time consistency for read-time speed: pre-joining the lookup tables removes joins from reporting queries but duplicates attribute values across rows. That redundancy must be maintained by ETL or triggers, and inconsistent updates become possible. The purpose is faster reads, not stricter normalisation or reduced storage.

Question 48Database design (logical and physical design, normalization)

Which statement correctly contrasts a star schema with a snowflake schema in dimensional modelling?

  1. A star keeps each dimension denormalised in one table, while a snowflake splits hierarchies into several tables Correct answer.
  2. A star schema normalises dimension tables into hierarchy levels, while a snowflake keeps each dimension flat and wide
  3. A star schema requires natural composite keys, while a snowflake requires surrogate keys on every dimension
  4. A star schema stores the full change history of dimensions, while a snowflake stores only current values

Explanation

In a star schema each dimension is a single denormalised table joined directly to the fact table, which keeps queries simple and join counts low. A snowflake schema normalises dimension hierarchies, for example product to category to department, into separate related tables, trading extra joins for less redundancy. History handling and key choice are independent of this structural contrast.

Question 49Database design (logical and physical design, normalization)

Which statement defines a candidate key of a relation?

  1. Any set of attributes that uniquely identifies each tuple
  2. An attribute permitted to hold null values in every tuple
  3. A set of attributes referenced by a foreign key in another relation
  4. A minimal set of attributes that uniquely identifies each tuple Correct answer.

Explanation

A candidate key is a superkey with no redundant attribute: it uniquely identifies each tuple and removing any attribute destroys that uniqueness. This minimality condition is what distinguishes it from a general superkey. One candidate key is usually chosen as the primary key, with the others kept as alternate keys.

Question 50Database design (logical and physical design, normalization)

Relation R(A, B, C) is decomposed into R1(A, B) and R2(A, C). Under which condition is this binary decomposition guaranteed to be lossless?

  1. When the common attribute set {A} is a superkey of R1 or of R2 Correct answer.
  2. When A is declared a foreign key in both R1 and R2
  3. When both R1 and R2 are in third normal form before the join
  4. When the decomposition is dependency preserving and both fragments are normalised

Explanation

For a binary decomposition the lossless-join test requires that the attributes common to both fragments functionally determine all attributes of at least one fragment, that is, form its superkey. If that fails, rejoining R1 and R2 can pair tuples that never coexisted and produce spurious rows. Dependency preservation is a separate and independent property.