データベーススペシャリスト 令和7年度 秋期 午前Ⅱ

結論: プロパティグラフは「ノード」「リレーションシップ」「プロパティ」の 3 つで表します。

なぜ: プロパティグラフでは、ノード（点）とリレーションシップ（点と点を結ぶ辺）のどちらもプロパティ（属性）をもてます。したがってイは誤りです。

ウが説明しているのは RDF です。主語・述語・目的語の 3 つ組（トリプル）でデータを表すのは RDF のモデルで、プロパティグラフとは別のものです。

エについて、リレーションシップは開始ノードと終了ノードを 1 つずつもつ辺です。複数のノードに同時につながることはできません。

結論: 概念データモデルは、対象世界（現実の業務）の情報構造を抽象化して表したものです。

なぜ: 概念・論理・物理の 3 層のうち、概念データモデルは製品にも実装方式にも依存しません。したがってウのように DBMS の種類で内容が変わることはありません。

アの階層・ネットワーク・関係は、どうデータを格納・操作するかを決める論理データモデルの分類です。

イは業務プロセス（処理の流れ）の話で、データの構造ではありません。概念データモデルが表すのは「何があって、何とどう関係しているか」です。

結論: 在庫商品は「商品 × 倉庫」ごとに 1 件なので、2 つの倉庫に入れれば 2 件できます。

なぜ: 図で在庫商品は、商品（1 側）と倉庫（1 側）の両方につながる関連そのものを表すクラスです。商品 1 種類・倉庫 2 か所なら組合せは 2 つ、つまり在庫商品も 2 件になります。

他の選択肢を多重度から確かめます。

• イ … 入庫は在庫商品 1 件に対して 1..*。商品が 2 種類なら在庫商品も 2 件になり、入庫データもそれぞれに付くので 1 件では足りません
• ウ … 商品から在庫商品への多重度が 1..* なので、商品には必ず 1 件以上の在庫商品があり、その在庫商品は必ず倉庫 1 つにつながります。倉庫が決まっていない商品は、この図では表せません
• エ … 出庫側は 0..* です。0 を含むので、出庫実績がない在庫商品は存在できます

⚠️ 在庫数量の前の / は導出属性の印です（入庫と出庫から計算できる、という意味）。

結論: 主キーは {従業員番号，プログラム言語} の 2 列です。

なぜ: 「2 種類以上使用できる従業員がいる」ので、同じ従業員番号の行が何行も並びます。したがって従業員番号だけでは行を区別できません（ウが誤り）。同じく、あるプログラム言語を複数の従業員が使えるので、プログラム言語だけでも区別できません（イが誤り）。

2 列を組にして初めて 1 行が定まります。これが多対多の関連を表す表の基本形です。

アは氏名を主キーにしていますが、氏名は同姓同名がありえるので識別子になりません。

⚠️ 「プログラム言語を全く使用できない従業員もいる」——この人はこの表に 1 行も現れません。従業員表とは別の表に分けているからこそ、0 件を自然に表せます。

結論: A → (B ∪ C) が成り立つなら、A → B と A → C もそれぞれ成り立ちます。

なぜ: A の値が決まれば B ∪ C の値の組が 1 つに定まる、ということは、その一部である B だけを見ても 1 つに定まるからです（分解則）。

アは成り立ちません。A → B と A → C が言えるのは「A が決まれば B も C も決まる」ということだけです。A が違っても B が同じ値になることはあり、そのとき C は違う値になりえます。つまり B から C は決まりません。

イも成り立ちません。B が A の一部にすぎない以上、B だけでは A ほど強く値を決められず、C を一意に定められるとは限りません。

ウは逆です。B が A の部分集合なら、成り立つのは B ⊆ A ならば A → B（反射則）で、A が B に関数従属するのではありません。

結論: 4 つに分割されます。

なぜ: この表の主キーは {受注番号, 商品コード} です。ここから段階的に切り出します。

• 顧客（顧客コード → 顧客名）… 主キーではない属性から決まる（推移的関数従属）
• 商品（商品コード → 商品名, 単価）… 主キーの一部（商品コード）だけで決まる部分関数従属
• 受注（受注番号 → 顧客コード, 受注日）… 主キーの一部（受注番号）だけで決まる部分関数従属
• 受注明細（受注番号, 商品コード → 受注数）… 主キー全体で決まるもの

第 2 正規形で部分関数従属（商品・受注）を切り出し、第 3 正規形で推移的関数従属（受注番号 → 顧客コード → 顧客名）から顧客を切り出すので、合わせて 4 つになります。

⚠️ 受注金額は「単価 × 受注数」で計算できる導出可能な属性です。持たないのが普通ですが、持つとしても受注明細に入るので表の数は 4 のままです。

結論: 「真 AND 不定」は不定、「偽 AND 不定」は偽です。

なぜ: AND は「両方が真のときだけ真」です。片方が不定（unknown）のとき、もう片方が何かで結果が変わります。

• もう片方が真なら、不定の側が真なら全体は真、偽なら全体は偽 → 決まらないので不定
• もう片方が偽なら、不定の側が真でも偽でも全体は偽 → 決まるので偽

これは「NULL が混ざれば必ず NULL になる」わけではない、という点が肝です。偽が 1 つあれば AND は確定します。

⚠️ WHERE 偽の条件 AND NULL の条件 は 1 行も返しませんが、それは「不定」だからではなく「偽」に確定しているからです。WHERE 句は「真の行だけ」を通すので、不定でも偽でも通らない——結果が同じに見えるぶん、途中の値の違いが隠れます。

結論: SET CONSTRAINTS UK_担当者番号 DEFERRED です。

なぜ: 2 つの UPDATE は担当者番号 111 と 222 を入れ替えています。1 文目を実行した時点では 222 が 2 行に並ぶので、一意性制約に反した状態が途中で発生します。2 文目まで実行すれば解消しますが、既定の即時検査（IMMEDIATE）では 1 文目で落ちます。

そこで検査を コミット時まで遅らせる（DEFERRED） ことで、途中の状態を許して最後にだけ確認させます。

遅らせられるのは DEFERRABLE と宣言した制約だけです。この表定義で DEFERRABLE が付いているのは UK_担当者番号 だけなので、主キー側（ア・イ）は選べません。エは即時のままなので状況が変わりません。

⚠️ DEFERRABLE INITIALLY IMMEDIATE は「遅らせられるが、既定では即時」という意味です。だから明示的に SET CONSTRAINTS … DEFERRED を書く必要があります。

結論: a = UNION，b = EXCEPT，c = INTERSECT です。

なぜ: 2 つの表が完全に一致するかは、対称差（どちらか片方にしかない行）が 0 件かで判定できます。

• 名簿1 UNION 名簿2 … どちらかにある行の全体
• 名簿1 INTERSECT 名簿2 … 両方にある行
• 前者から後者を EXCEPT で引く … 片方にしかない行だけが残る

これが 0 件なら 2 つの表は一致します。COUNT(*) = 0 で「等しい」と判定しているのはそのためです。

⚠️ UNION も INTERSECT も既定で重複を除きます。だから比べているのは「行の集合」で、同じ行が何件あるかまでは見ていません。b を UNION ALL にしているアが誤りなのはこのためで、重複を残したまま引くと、一致しているのに 0 件にならない場合が出ます。

結論: 直積・射影・差の 3 つで商演算を書き換えられます。

なぜ: 商演算 R ÷ S は「S のすべての行と組になっている R の行」を求める演算です。基本演算だけで表すと次の形になります。

1. 射影で R から候補（S の列を除いた部分）を取り出す2. その候補と S の直積を作る … 「揃っていればあるはず」の組合せの全体3. そこから実際の R を差で引く … 残ったのは足りない組合せ4. それを射影して「揃っていない候補」の一覧にする5. 候補の全体からそれを差で引く … 残るのが答え

和演算や選択演算は不要です。したがってア・ウ・エは誤りです。

⚠️ 商演算は SQL に専用の構文がありません。実務では NOT EXISTS を二重に使う書き方（いわゆる「全称」の表現）に置き換えます。

結論: ON DELETE CASCADE です。

なぜ: CASCADE は「親の行が消えたら、それを参照している子の行も一緒に消す」という指定です。設問が求めているのはまさにこの動きです。

RESTRICT は逆で、参照している子の行がある間は親を削除させません（エラーにして守る）。既定はこちら側の考え方で、参照が壊れる操作を拒否します。

INTERSECT は集合演算、UNIQUE は一意性制約で、どちらも削除規則の語句ではありません。

⚠️ CASCADE は便利ですが、消したつもりのない行まで連鎖して消えます。既定では、参照している行があるうちは親を消せません。実際に打って確かめられます。

結論: ロールフォワード＝T2，T5、ロールバック＝T6 です。

なぜ: 判断の材料は 2 つあります。チェックポイントより後にコミットしたかと、そもそも書き込んでいるかです。

• T1 … チェックポイント前にコミット済み。結果はもうディスクにあるので何もしない
• T2 … チェックポイント後にコミット。書き込みがあるのでロールフォワード
• T3 … 未コミットだが Read 100 だけ。1 回も書いていないので何もしない
• T4 … T3 と同じく読むだけ。何もしない
• T5 … チェックポイント後にコミット。ロールフォワード
• T6 … 未コミットで書き込みあり。ロールバック

⚠️ この問題の勘どころは T3・T4 が Read 100 だけで、1 回も Write していないことです。更新していないのだから、取り消すもの（ロールバック）がありません。未コミットというだけで機械的にロールバックへ入れると、イ・エを選んでしまいます。

結論: クラスタ化インデックスは、行そのものをその列の順に並べて格納するしくみです。

なぜ: 通常のインデックスは「値 → 行の位置」の対応表を別に作るだけで、行の置き場所は変わりません。クラスタ化インデックスは行の並び順そのものを決めるので、範囲検索でディスクの読み取りがまとまり、速くなります。

並び順は 1 つしか決められないので、1 つの表に 1 つだけです。したがってイは誤りです。

アについて、外部キーに張るインデックスが自動でクラスタ化されるわけではありません。ウについて、クラスタ化インデックスと非クラスタ化インデックスは同じ表に併存できます（排他ではありません）。

⚠️ PostgreSQL の CLUSTER はその時点で並べ替えるだけで、以後の更新では並びが維持されません。「クラスタ化インデックス」という常時維持される機能をもつ製品（SQL Server など）とは挙動が違います。

結論: 何回やっても結果が変わらない、という性質がべき等です。

なぜ: 障害回復そのものが途中で落ちることがあります。そのとき最初からやり直せなければ回復できません。REDO がべき等なら、どこまで進んでいたか分からなくても頭から流し直せるので、安全にやり直せます。

そのために DBMS は、ページに「どこまで反映済みか」の印（ログ順序番号）を持たせ、既に反映済みの更新は読み飛ばします。

アはチェックポイント、ウはバックアップからの復旧（メディア障害の回復手順）、エは WAL（ログ先書き）の説明で、いずれもべき等の説明ではありません。

結論: REPEATABLE READ です。

なぜ: 設問の異状は「同じ行を 2 回読んだら値が変わっていた」＝反復不能読取り（non-repeatable read）です。

• READ UNCOMMITTED … 未コミットの読取りすら防がない
• READ COMMITTED … コミット済みしか読まないが、読むたびに最新を見るので値は変わりうる
• REPEATABLE READ … ここで初めて防げる
• SERIALIZABLE … 防げるが、より強い（＝水準が高い）

設問は「防げるもののうち最も水準の低いもの」なので REPEATABLE READ になります。

⚠️ 水準の名前は規格の用語で、実際にどこまで防ぐかは製品差があります。PostgreSQL の READ UNCOMMITTED は内部的に READ COMMITTED として扱われます。

結論: 直列化可能（serializable）です。

なぜ: 同時に動かしたのに、どれか 1 つの順番で 1 件ずつ実行したのと同じ結果になる。これが直列化可能の定義そのものです。設問の「T1 → T2 の結果、又は T2 → T1 の結果と等しい」がまさにそれです。

残りは ACID の性質で、スケジュールの性質ではありません。

• 一貫性… 実行の前後で整合性の制約が保たれる
• 原子性… 全部反映されるか、全く反映されないかのどちらか
• 耐久性… コミットしたら障害が起きても失われない

⚠️ 直列化可能は ACID の「隔離性（Isolation）」を最も強くした状態にあたります。並列に速く動かすほど直列化可能から外れやすくなり、ここが同時実行制御の設計どころです。

結論: 待ちグラフです。

なぜ: 「T1 が T2 の解放を待っている」という待ち関係を、トランザクションを点・待ちを矢印としたグラフで表します。このグラフに閉路（ぐるりと一周する経路）ができたら、互いに待ち合って永久に進めない＝デッドロックです。DBMS は定期的に閉路を探し、見つけたらどれか 1 つを強制的に中断します。

2 相ロックはデッドロックの検出ではなく、直列化可能性を保証するためのロックの掛け方の規則です（むしろデッドロックは起こりえます）。時刻印アルゴリズムはデッドロックを起こさせない予防側のしくみ、チェックポイントは障害回復のためのもので、いずれも検出には使いません。

結論: 各ブロックが直前のブロックのハッシュ値をもち、鎖のようにつながっているのが特徴です。

なぜ: 過去のデータを 1 文字でも書き換えると、そのブロックのハッシュ値が変わります。すると次のブロックが記録している「直前のハッシュ値」と合わなくなり、そこから先が全部食い違います。改ざんすると必ず露見する——この性質がハッシュの連鎖から生まれています。

アは B 木インデックス、ウはビットマップインデックスで、いずれも RDBMS の索引の話です。イは多版同時実行制御（MVCC）のスナップショットの説明です。

結論: サイドチャネル攻撃です。

なぜ: 暗号アルゴリズムそのものを破るのではなく、動作しているときに漏れ出す物理的な情報——消費電力、処理時間、電磁波、動作音など——から鍵を推定します。設問の「消費電力を測定する」がまさにこれにあたります。

キーロガーは打鍵を記録するソフト／機器、スミッシングは SMS を使ったフィッシング、中間者攻撃は通信経路に割り込んで盗聴・改ざんする攻撃で、いずれも装置の物理的な情報を測るものではありません。

結論: 送信者の公開鍵を、受信者が検証に使います。

なぜ: デジタル署名の流れは次のとおりです。

1. 送信者がメッセージのハッシュ値（ダイジェスト）を求める2. それを送信者の秘密鍵で変換する → これが署名3. 受信者は送信者の公開鍵で署名を戻し、ダイジェストを取り出す4. 自分で計算したダイジェストと一致すれば、本人が送ったもので改ざんもないと分かる

設問が聞いているのは「検証鍵」なので、3 の側、すなわち送信者の公開鍵です。

⚠️ エは正しい説明ですが、それは署名鍵（作る側）であって検証鍵ではありません。「作る＝秘密鍵、検証＝公開鍵」と、どちらを聞かれているかで答えが変わります。ア・イは受信者の鍵を使うとしている点が誤りです（受信者の鍵を使うのは暗号化のほうです）。

結論: 前方秘匿性（forward secrecy）です。

なぜ: 通信のたびに使い捨ての鍵を作り、終わったら捨てる方式にすると、長期の秘密鍵が後から漏れても、過去の通信を復号するための鍵はもう存在しません。だから遡って解読されません。TLS 1.3 が鍵交換を一時鍵に限定しているのは、この性質を必ず満たすためです。

アの一方向性とウの第二原像計算困難性はハッシュ関数に求められる性質で、鍵の漏えいの話ではありません。エの等価安全性は、方式の違う暗号どうしの強度を突き合わせるための考え方です。

結論: (1−r)・x ＋ r・y です。

なぜ: r は「キャッシュに存在しない確率」＝ミス率です。したがって

• 確率 (1−r) でキャッシュに当たり、x ナノ秒で済む
• 確率 r で外れて主記憶を読みに行き、y ナノ秒かかる

平均は、それぞれの時間をその確率で重み付けして足したもの——つまり (1−r)・x ＋ r・y です。

⚠️ 引っかけが 2 つあります。1 つは r がヒット率ではなくミス率であること（エは r と 1−r が逆）。もう 1 つは、容量 a・b は平均アクセス時間には効かないことです（ア・ウは容量の比で重み付けしていますが、当たるかどうかを決めるのは確率 r であって容量比ではありません）。

結論: D1，AP，AV の 3 つです。

なぜ: 磁気ディスク 2 と 3 が壊れたので、残っているのはディスク 1（AP，B1，CP，D1）とディスク 4（AV，BV，CV，DV）だけです。この中だけで A1 と A2 を組み立てます。

1. AV = D1 ⊕ A2 を A2 について解くと A2 = AV ⊕ D1（AV と D1 はどちらも生き残っている）2. AP = A1 ⊕ A2 を A1 について解くと A1 = AP ⊕ A2（AP も生き残っている）

使ったのは D1，AV，AP の 3 つです。

⚠️ 排他的論理和は同じものを 2 回 ⊕ すると元に戻るので、X ⊕ Y から片方を消して残りを取り出せます。RAID6 が2 台まで同時に壊れても復元できるのは、この式を 2 種類（AP 系と AV 系）持っているからです。

ア・イの B1 や BV は A 行の復元には使えません。

結論: 抽象クラスはインスタンスを生成できません。

なぜ: 抽象クラスは中身が決まっていない操作（抽象操作）を含むことができ、それだけでは動くものになりません。サブクラスに実装させるための土台として置くものなので、直接オブジェクトを作ることはできません。

逆に、それ以外は普通にできます。

• サブクラスをもつ… むしろ持たせるために存在します
• スーパークラスをもつ… 抽象クラスが別のクラスを継承しても構いません
• 属性をもつ… 共通の属性をまとめて置けるのが利点の一つです

⚠️ 「抽象クラス＝空っぽ」ではありません。実装済みの操作も属性も持てて、未実装の部分だけをサブクラスに委ねるのが抽象クラスです。

結論: できたらすぐ結合してテストする——継続的インテグレーションです。

なぜ: 結合を後回しにすると、最後にまとめて大量の食い違いが出ます。XP は逆に、小さく作ってすぐ合流させ、壊れたらその場で直すことで、問題を小さいうちに見つけます。

他の 3 つは、いずれも XP のプラクティスと逆です。

• ア … XP は「週 40 時間（持続可能なペース）」を原則にします。チームで自由に決めるものではありません
• イ … コードはチーム全員のもの（コードの共同所有）で、誰でも直せます
• エ … ペアプログラミング、つまり 2 人 1 組で書きます