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

結論: 整合性・可用性・分断耐性の 3 つは同時に満たせません。

なぜ: ネットワークが分断されて連絡が取れなくなったとき、選べる道は 2 つしかありません。

• 返事をしない（可用性を捨てる）… 他のノードと揃っている確信が持てないので答えない
• 古いかもしれない値を返す（整合性を捨てる）… とにかく答える

分断そのものは避けられない以上、残りの 2 つのどちらかを諦めるしかないというのが CAP 定理です。

アは結果整合性（BASE）の説明、イは ACID の一貫性、ウは直列化可能性の説明で、いずれも CAP 定理そのものではありません。

⚠️ 「3 つのうち 2 つを選ぶ」と要約されがちですが、正確には分断が起きたときに整合性か可用性かを選ぶという話です。分断が起きていない平常時は両方満たせます。

結論: シャーディングです。

なぜ: 1 つの大きなデータを、決めた規則で切り分けて複数のノードに分けて置くのがシャーディングです。設問の規則（先頭文字が A〜G ならノード 1、H〜N ならノード 2…）がまさにその切り分け方にあたります。1 台に収まらない量を扱えるようになり、読み書きも分散します。

• ア … 2 相コミットは、複数ノードにまたがる更新を全部成功か全部失敗かにそろえる手順です
• イ … コンシステントハッシングも分散の方法ですが、ハッシュ値で割り当てます。設問は「先頭文字の範囲」というあらかじめ定めた規則なので、こちらではありません
• エ … レプリケーションは同じデータの複製を複数ノードに置くことで、分けて置くのとは逆です

⚠️ シャーディングは分けて置く、レプリケーションは同じものを複数置く。目的も違い（容量と性能 / 可用性）、実際のシステムでは両方を組み合わせます。

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

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

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

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

結論: log X です。

なぜ: B+木は、1 つのノードから何本も枝が出る木です。根から葉まで降りるのに読むノード数は木の高さと同じで、データが何倍になっても高さはわずかしか増えません。

枝が n 本なら、1 段降りるごとに候補が n 分の 1 に絞られます。X 件を 1 件まで絞るのに必要な段数が、そのまま log X です。

だからこそ、件数が 100 万件でも 1 億件でも、数回のアクセスで目的の行にたどり着けます。ウの X は全件を順に見る場合（インデックスを使わない全表走査）で、B+木を使う意味がありません。

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

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

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

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

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

結論: 第 2 正規形 → 第 3 正規形だけが、両方を必ず満たせます。

なぜ: 正規化の分解には 2 つの望ましい性質があります。

• 情報無損失分解 … 分解した表を自然結合すると元に戻せる
• 関数従属性保存 … 元の表にあった関数従属が、分解後の各表の中だけで検査できる

第 3 正規形までは、この 2 つを同時に満たす分解が必ず存在することが知られています。

⚠️ イのボイス・コッド正規形（BCNF）は違います。情報無損失分解はできますが、関数従属性保存は犠牲になることがあります。だから「必ず存在する」とは言えません。第 3 正規形で止める設計がよく採られるのは、この差が理由です。

ウの第 1 正規形化は繰り返し項目をなくす操作で、そもそも分解の話ではありません。エの第 4 正規形は多値従属を除く段階で、こちらも関数従属性保存は保証されません。

結論: {便名, 客室乗務員名} と {便名, 搭乗者名} の 2 つに、元に戻せる形で分解できます。

なぜ: この表では、客室乗務員と搭乗者は互いに無関係です。便名が決まると乗務員の集合と搭乗者の集合がそれぞれ決まり、表にはそのすべての組合せが並びます（BD501 は乗務員 2 人 × 搭乗者 2 人で 4 行）。これが多値従属です。

多値従属があるときは、便名を軸に 2 つへ分解しても、自然結合で元どおりに戻せます。これが情報無損失分解です。

他の選択肢を順に見ます。

• ア … 乗務員を 1 人追加するだけで、搭乗者の数だけ行を足す必要があります。更新時異状は起こります
• イ … 全属性の組が主キー（すべてがキー）なので、自明でない関数従属は 1 つも存在しません
• エ … 非自明な関数従属が無い以上、ボイス・コッド正規形の条件は満たしています。満たしていないのは第 4 正規形のほうです

⚠️ 「BCNF なのに問題がある」——これが第 4 正規形が必要になる理由です。関数従属だけを見ていると、この重複は見つけられません。

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

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

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

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

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

結論: RANK です。

なぜ: OVER (PARTITION BY クラス ORDER BY 得点 DESC) は「クラスごとに区切り、得点の高い順に並べる」という指定です。その並びの中で何番目かを返すのが RANK です。

結果を見ると、クラス A で 1・2・3、クラス B で 1・2 と、クラスごとに 1 から振り直されています。PARTITION BY がこれをしています。

• ア CUME_DIST … 累積分布。0 より大きく 1 以下の割合を返します
• イ MAX … 最大値そのもの。順位にはなりません
• ウ PERCENT_RANK … 順位を 0〜1 の割合にしたもの。整数の順位ではありません

⚠️ 同点があるときの振る舞いが RANK と DENSE_RANK で違います。RANK は 1, 2, 2, 4 と番号が飛び、DENSE_RANK は 1, 2, 2, 3 と詰まります。

結論: FULL OUTER JOIN です。

なぜ: 「どちらか一方にだけ」を求めるには、両方の表の行をすべて残したうえで、相手が見つからなかった行を拾う必要があります。それができるのは完全外部結合だけです。

完全外部結合すると、相手がいない行は反対側が NULL になります。WHERE A.ID IS NULL OR B.ID IS NULL がその行だけを取り出し、COALESCE(A.ID, B.ID) が NULL でないほうの ID を返します。

実際にこの 2 つの表なら、A にしかない 100・300 と、B にしかない 600・800 が得られます。

• イ INNER JOIN … 両方にあるものだけ。求めたいものと正反対です
• ウ LEFT OUTER JOIN … A にしかない行は拾えますが、B にしかない行が落ちます
• エ RIGHT OUTER JOIN … 逆に、A にしかない行が落ちます

⚠️ FULL OUTER JOIN はどの製品にもあるわけではありません。本サイトで実際に動かして測ったところ、MySQL と MariaDB は構文エラーになりました（PostgreSQL・SQLite・SQL Server は通ります）。無い製品では、左外部結合と右外部結合を UNION でつないで代用します。

結論: 店 B だけです。

なぜ: 商演算 R÷S は「S のすべての行と組になっているR の行」を求めます。ここでは「a・b・c の 3 商品をすべて扱っている店」という意味になります。

店ごとに扱っている商品を並べて確かめます。

• A … a, b（c が無い）
• B … a, b, c ← 3 つそろっている
• C … c だけ
• D … c, d（a と b が無い）
• E … d, e（1 つもそろっていない）

そろっているのは B だけなので、結果は 1 行です。

⚠️ 「1 つでも扱っている店」ではなく「すべて扱っている店」です。アやイのように複数の店が並ぶのは、条件を「どれか 1 つでも」と読み違えた場合です。

結論: ロックを掛け終わってから、外し始める。 これが 2 相の意味です。

なぜ: トランザクションを、ロックを増やすだけの前半と減らすだけの後半の 2 つの相に分けます。いったん外し始めたら、もう新しくは掛けません。この規則だけで直列化可能性が保証されます。

他は成り立ちません。

• ア … 2 相ロックでもデッドロックは起こります（互いに相手のロックを待つ形になりうる）。防ぐのではなく、検出して片方を中断する方式が使われます
• イ … コミットの順番は開始時刻とは関係ありません
• ウ … 順序が逆です。コミットするまでロックを持ち続けるのが普通の運用（厳密 2 相ロック）で、先に外すと他のトランザクションが未コミットの値を読めてしまいます

⚠️ 「2 相」という同じ言葉が 2 相コミットにも出てきますが、別のものです。2 相ロックは同時実行制御、2 相コミットは分散トランザクションの合意手順です。

結論: 範囲を指定した検索が、B+木のいちばん得意な形です。

なぜ: B+木は葉がキーの順に並び、横につながっています。「4001 以上」の位置まで木を降りたら、あとは葉を横に順にたどるだけで 4003 まで拾えます。全体の件数がいくら多くても、読むのは該当する範囲だけで済みます。

他は絞り込めません。

• ア・イ … 「〜以外」は該当しない値以外のすべてが対象です。値の種類が十分あって均一に分散しているので、ほぼ全件が該当します。インデックスを経由するとかえって遅くなり、全表走査が選ばれます
• エ … NULL なのはごく少数の行だけなので、「NULL 以外」もやはりほぼ全件です

⚠️ インデックスが効くのは「少数に絞り込めるとき」です。結果が全体の大部分になる条件では、索引をたどる手間のぶん不利になります。

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

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

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

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

結論: a はロールバック、b は両方、c はロールフォワードです。

なぜ: 障害の種類ごとに、失われたものが違います。

• a トランザクション障害（デッドロック）… 巻き込まれた 1 つを取り消せば済みます。ロールバックだけ
• b システム障害（ハードウェアの誤動作）… メモリの内容は消えますが、ディスクは無事です。コミット済みで書き出せていない分はロールフォワード、未コミットの分はロールバック。つまり両方要ります
• c 媒体障害（記録媒体が使用不可能）… ディスクそのものが読めません。バックアップを戻し、そこからログで進めるしかないので、ロールフォワードです

⚠️ c でロールバックが要らないのは、戻したバックアップの時点には未コミットのものが無いからです。取り消すべきものが最初から存在しません。

結論: どちらも減ります。

なぜ: 隔離性水準を高めるとは、他のトランザクションの影響をより強く遮断することです。遮断が強くなるので、おかしなデータを読む機会は減ります。

一方、遮断はロックや版の管理で実現するので、待たされる時間が増えます。その結果、単位時間に流せる本数（スループット）は落ちます。

つまり正しさと速さのトレードオフです。どちらも良くなる組合せ（ウ）は存在しません。

⚠️ 「とりあえず一番厳しくしておけば安心」とはいきません。業務が許す範囲でいちばん低い水準を選ぶ、というのが設計の考え方です。

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

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

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

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

⚠️ 直列化可能性は ACID の「隔離性（Isolation）」を最も強くした状態にあたります。

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

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

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

結論: 送信元を偽って第三者に問い合わせ、その返事を標的に浴びせる攻撃です。

なぜ: DRDoS の R は Reflection（反射）です。攻撃者は標的に直接送りません。誰でも使える DNS サーバ（オープンリゾルバ）に、送信元 IP アドレスを標的のものに偽装した問い合わせを大量に送ります。返事はすべて標的に届き、標的の回線を埋め尽くします。

この方式には攻撃者にとって 2 つの利点があります。攻撃元が隠れることと、問い合わせより応答のほうが大きいので少ない通信量で大きな攻撃になる（増幅）ことです。

アは単なる DDoS の組合せ、イはボットネットを使ったパスワード攻撃、エはマルウェアによる破壊で、いずれも反射を使っていません。

結論: 検知／連絡受付 → トリアージ → インシデントレスポンスの順です。

なぜ: まず気づく／報告を受ける（検知・連絡受付）。次にそれが本当にインシデントか、どれくらい急ぐかを選り分ける（トリアージ）。そのうえで実際に対応する（インシデントレスポンス）。

トリアージが真ん中にあるのが要点です。報告のすべてが本物の事故とは限らず、限られた人手をどこに向けるかを先に決めないと、重大なものが後回しになります。医療の現場で使われる言葉がそのまま使われているのはこのためです。

結論: 脆弱性を突くために作られたプログラムがエクスプロイトコードです。

なぜ: exploit は「つけこむ」という意味です。見つかった脆弱性が実際に悪用できるものかを確かめるために作られ、攻撃にもそのまま使えます。

⚠️ 攻撃専用のものとは限りません。 脆弱性の報告に添えて「本当に危ないこと」を示すために作られたり、修正が効いているかの検査に使われたりします。だから設問も「検査又は攻撃するために」と両方を挙げています。

ア・イ・ウはそれぞれ、データ移行ツール・ディスク管理ソフト・プロトタイピングの説明で、脆弱性とは関係ありません。

結論: RAID6 です。

なぜ: 決め手は「2 台まで壊れても復旧できる」です。そのためにはパリティが 2 種類要ります。RAID6 は 2 種類のパリティを分散して書くので、2 台までの同時故障に耐えられます。最低 4 台という条件もここから来ます。

• ア RAID0 … ストライピングのみ。冗長性が無く、1 台でも壊れたら終わりです
• イ RAID1 … ミラーリング。同じものを 2 台に書くので 1 台の故障には耐えますが、パリティは使いません
• ウ RAID5 … パリティは 1 種類なので、耐えられるのは 1 台までです

⚠️ RAID はバックアップの代わりにはなりません。誤って消したデータは、すべてのディスクから同時に消えます。

結論: 将来にわたって性能を保てるように、長期的に見張って備えることです。

なぜ: キャパシティプランニングは「足りなくなる前に手を打つ」ための活動です。いまの応答時間を測り続け、利用が増えたときにどこが先に限界に来るかを見通して、増設や設計変更の時期を決めます。

他はいま起きている問題への対処であって、将来への備えではありません。

• ア … ボトルネックの解消。目の前の問題を直す活動です
• ウ … チューニング。現状の性能を引き出す活動です
• エ … リソースの有効利用。これも現状の改善です

⚠️ 「速くする」ではなく「遅くならないようにし続ける」——時間軸が違うのが要点です。

結論: データに着目し、実体関連モデル（E-R モデル）で整理するのがデータ中心アプローチです。

なぜ: 機能は業務の変化に合わせてよく変わりますが、扱うデータの構造は比較的変わりません。そこで先にデータの構造を固め、機能はその上に載せる、という順番をとります。これがデータ中心アプローチ（DOA）です。

• ア … オブジェクト指向アプローチ
• イ … プロセス中心アプローチ（データフローに着目する）
• ウ … 並行プロセスとしてのモデル化

⚠️ 「データに着目」という点はアとも紛らわしいのですが、アはクラス・多態・継承というオブジェクト指向の道具立てを挙げています。実体関連モデルと書いてあるエが、データ中心アプローチです。

結論: 本番とほぼ同じ構成を用意して、リリース前の最終確認をする環境です。

なぜ: 開発環境と本番は、たいてい構成が違います（データ量・設定・つながる先など）。そのため開発環境では出なかった不具合が本番で出ます。本番に限りなく近い環境を 1 つ挟んで最後に確かめる——それがステージング環境です。

アは開発環境、イはベータテスト、ウは DMZ を使ったネットワーク構成の説明で、いずれもリリース前の最終確認の場ではありません。

⚠️ 「ほぼ同じ」であることが値打ちです。本番と違うところがあるほど、確認できたことの意味が薄れます。