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

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

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

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

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

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

結論: モデル C は親子を別の表（組織構造）に自由に書けるので、循環しないことはモデルの外で制約として課す必要があります。

なぜ: モデル C の組織構造は「親組織コード・子組織コード」の組を何行でも持てます。A の親が B、B の親が A、という組も書けてしまいます。モデル B には {階層} という制約が付いていますが、モデル C には付いていないので、別に制約を設けなければ循環を防げません。

• ア … モデル A は部・課・係を別々のクラスにしているので、組織レベルを 1 つ増やすにはクラスを足す必要があります
• イ … モデル C の組織構造は、同じ子組織に親を何行でも書けるので、複数の親から管轄される状況を記述できます
• ウ … モデル B では子 1 つに対して親は 0..1 個です。実装では、子の側が親の組織コードを外部キーとして持ちます（親の側が子を持つと、子の数だけ列が要ってしまいます）

結論: 第 3 正規形までは満たしますが、ボイス・コッド正規形は満たしません。

なぜ: 候補キーが {A, B} と {A, C} なので、A・B・C はどれもいずれかの候補キーに含まれる属性（キー属性）です。第 2・第 3 正規形の条件は「非キー属性が部分従属・推移従属しない」ことなので、非キー属性が 1 つも無い R は自動的に満たします。

ボイス・コッド正規形は、さらに「全ての関数従属の左辺が候補キーを含む」ことを求めます。C → B の左辺 C は単独ではどの候補キーも含まないので、ここで外れます。

結論: 外部キーを持つ側が「多」（＊）、参照される側が「1」です。

なぜ: 表ごとに、どの表を参照しているかを読みます。

• 医師 は診療科コードを外部キーに持つ → 1 つの診療科に医師は何人もいる。医師 ＊ — 1 診療科
• 診察 は診療科コードと患者番号を外部キーに持つ → 1 つの診療科・1 人の患者に診察は何回もある。診療科 1 — ＊ 診察、診察 ＊ — 1 患者

この 3 つがそろうのはイだけです。アは診療科と診察の向きが、ウ・エは医師と診療科の向きが逆です。

結論: 第 3 正規形までなら、情報無損失で、しかも関数従属性を保存したまま分解できます。

なぜ: 第 3 正規形への分解には、どんな関係でも「元に戻せる（情報無損失）」かつ「元の関数従属を分解後の表だけで確かめられる（従属性保存）」分解が必ず存在することが知られています。

• ア … ボイス・コッド正規形への分解では、関数従属性を保存できない場合があります
• イ … 「正規形にする分解は全て」が言いすぎです。分け方を誤れば、結合しても元に戻らない（情報が失われる）分解もできてしまいます
• エ … 第 5 正規形への分解は結合従属性を扱うもので、多値従属性の保存を言うものではありません

結論: K02 と K04 の 2 行です。

なぜ: EXCEPT は「左の結果から、右の結果にあるものを取り除く」演算です。

1. 左（商品の仕入先コード）は K01・K01・K02・K02・K03・K042. 右（当月商品仕入合計）は K01・K03・K053. 左から K01 と K03 を除くと K02・K02・K044. EXCEPT は結果の重複も取り除く（EXCEPT ALL と書かない限り）ので、K02・K04

ウは、右にあるものを取り除いたあと重複をまとめなかった場合の形です。⚠️ EXCEPT ALL とも違います。EXCEPT ALL は個数ごとに引くので、左に 2 つある K01 は右の 1 つぶんだけ減って残り、K01・K02・K02・K04 になります。アは左のうち右にもある行（重複あり）、イはそれをまとめた INTERSECT の結果です。

結論: ダーティリードは防ぐが、反復不能読み取りは防がない水準＝ READ COMMITTED です。

なぜ: SQL 標準の隔離性水準は、低い順に次のとおりです。

• READ UNCOMMITTED … ダーティリードも起こりうる → (1) を満たさない
• READ COMMITTED … ダーティリードは防ぐ。同じ行を 2 回読むと値が変わりうる → (1)(2) の両方に当てはまる
• REPEATABLE READ … 同じ行を読み直しても値が変わらないことを保証する → (2) に当てはまらない
• SERIALIZABLE … さらに強い → (2) に当てはまらない

(2) は「同じであることが保証されない」と言っているので、それを保証してしまう REPEATABLE READ 以上は外れます。

結論: 相手の条件（C2.資格 = 'AP'）は ON に、残したい行の条件（C1.資格 = 'FE'）は WHERE に書きます。

なぜ: 結果は「FE を持つ社員 3 人（S001・S002・S003）全員」と、その人が AP を持っていればその資格、持っていなければ NULL です。外部結合では、ON の条件は結合の前、WHERE の条件は結合の後に効きます。

• ア … ON で「同じ社員の AP の行」だけを相手にし、相手が無ければ NULL で残す。最後に WHERE で C1 を FE の行に絞る → 結果と一致
• イ … WHERE が IS NOT NULL なので、C1 の FE 以外の行（AP・DB・SM）も相手 NULL のまま残り、行が多すぎる
• ウ … WHERE で C2.資格 = 'AP' に絞るので、相手が NULL の S002・S003 が消える
• エ … AP の条件まで WHERE に書いたので、これも相手の無い S002・S003 が消える（内部結合と同じ結果になる）

結論: 2ⁿ 個です。

なぜ: 射影は「どの属性を残すか」を選ぶ演算です。n 個の属性それぞれについて「残す・残さない」の 2 通りがあるので、選び方は 2 × 2 × … × 2（n 回）＝ 2ⁿ 通りです。

問題文が「全部残す（元と同じ）」と「1 つも残さない」も数えると断っているので、両端を引く必要はありません。例えば属性が A・B の 2 つなら、{A, B}・{A}・{B}・{ } の 4 ＝ 2² 通りです。

結論: 3 か所の a はすべて MAX です。

なぜ: 3 か所それぞれで役割が違いますが、MAX ならどれも成り立ちます。

• 副問い合わせの MAX(行番号) … 会員番号と項目名ごとにいちばん大きい行番号を選ぶ。条件 (3)「より大きい行番号の値を採用」そのものです。0112 の最終購入年月日は行番号 4 と 5 があり、5（2021-02-01）が残ります
• 外側の MAX(CASE …) … 会員ごとにまとめると、CASE は該当する項目の行だけ値を返し、他の行は NULL になります。集約関数は NULL を無視するので、MAX で唯一の値が取り出せます。0113 は最終購入年月日の行が無いので NULL になります

ほかの選択肢では結果が合いません。

• エ MIN … 副問い合わせで小さい行番号（古い値）が選ばれ、0112 の最終購入年月日が 2021-01-30 になってしまいます
• ア COUNT … 件数（数）を返すので、副問い合わせは行番号ではなく件数を返し、外側も名前ではなく数になります
• イ DISTINCT … 関数ではないので、この位置には書けず構文エラーになります

結論: 直積は和両立でなくても計算できます。

なぜ: 和両立とは「属性の数が同じで、対応する属性の定義域も同じ」ことです。共通集合・差集合・和集合は同じ形の行どうしを比べたり、まとめたりする演算なので、形がそろっていないと意味を持ちません。

直積は、R の各行と S の各行を横につないだ組をすべて作る演算です。行を比べないので、R と S の列の数や種類がまったく違っても計算できます（結果の列は R の列 ＋ S の列）。

結論: 2 相コミットにも決着がつかない状態（ブロッキング）があります。

なぜ: 2 相コミットは「準備できたか」を全サイトに聞き（第 1 相）、全員が了承したらコミット、1 つでも駄目ならロールバックを指示します（第 2 相）。各サイトは「了承」と返したあと、主サイトの指示が来るまでコミットもロールバックも自分では決められません。その間に主サイトが止まったり通信が切れたりすると、指示を待ったまま宙に浮いてしまいます。

• ア … 全員が了承したら、主サイトは全員に同じ指示（コミット）を出します。サイトごとに違う指示は出しません
• ウ … 1 つでもロールバックされれば全体をロールバックします。それが 2 相コミットの目的です
• エ … 各サイトが勝手にコミットすると、あるサイトはコミット・別のサイトは失敗、という食い違いが起こりえます

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

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

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

⚠️ 「2 相」という同じ言葉が 2 相コミット（問 12）にも出てきますが、別のものです。

結論: 表全体の専有ロックは、その表のどこか 1 行にでも他人のロックがあれば取れません。

なぜ: 表への専有ロックは「表のすべての行を自分だけが使う」という宣言です。X が行 a に共有ロック（読んでいる最中）を持っているのに Y が表全体を専有できたら、Y が行 a を書き換えられてしまいます。

• ア … 別の行 b なら衝突しません。行単位のロックは、同じ行どうしでだけぶつかります
• ウ … 共有ロックと専有ロックは、同じ対象（ここでは A 表）の上では両立しません
• エ … 表全体が X に専有されている間は、その表のどの行も Y はロックできません

結論: O(n²) です。

なぜ: 入れ子ループ法は、外側の表の 1 行ごとに、内側の表を最初から最後まで読む方式です。外側が n 行、内側も n 行なので、比べる回数は n × n ＝ n² 回になります。

内側の表に索引があれば、1 行ごとの探索が速くなり O(n log n) 程度まで下がります（ウ）。並べ替えてから突き合わせるマージ結合も、並べ替えの分で O(n log n) です。何の工夫も無い入れ子ループが、いちばん素直で、いちばん遅い方式です。

結論: MVCC は、書き込むたびに新しい版を作り、読む側には古い版を見せることで、読みと書きが互いを待たないようにする方式です。

なぜ: ロックだけで制御すると、誰かが書いている行を読む人は、書き終わるまで待たされます。MVCC では書き込みが新しい版を作り、読む側はその時点で確定している版を読むので、待たずに済みます。

• ア … MVCC を採るデータベースでも、明示的なロック（SELECT … FOR UPDATE など）は掛けられます
• イ … どの版を見せるかはデータベースが決めます。アプリケーションが版を指定する必要はありません
• エ … 書き込みどうしは依然としてロックで制御するので、デッドロックは起こりえます

結論: Indexed Database API（IndexedDB）は、Web ブラウザの中にデータを保存する仕組みで、読み書きはトランザクションを通して行います。

なぜ: W3C の仕様は、ブラウザの中にキーと値の組を保存し、索引で探せるようにする API を定めています。データへのアクセスは必ずトランザクションの中で行い、その寿命（いつ始まり、いつ終わるか）も仕様で決められています。

ほかの選択肢は別の技術です。

• ア … JDBC
• イ … 埋込み SQL
• エ … ストアドプロシージャ

結論: Apache Spark は、RDD という分散したデータ集合に変換を重ねて処理します。

なぜ: RDD は、複数のマシンに分けて置かれた、書き換えずに変換だけを重ねるデータの集まりです。ある RDD に「絞り込む」「対応づける」といった変換をかけると、新しい RDD ができます。途中の結果をメモリに置いたまま次の処理へ渡せるので、ディスクを何度も読み書きする方式より速く動きます。

• ア … バッチ処理だけでなく、流れてくるデータの処理や機械学習なども扱えます。「MapReduce に特化」は Spark 以前の Hadoop MapReduce の説明に近いものです
• ウ … メッセージングの仕組み（メッセージブローカ）の説明です
• エ … マスタの無い分散データベースの説明です

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

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

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

⚠️ 設問が挙げているのは 2015 年版のマニュアルです。根拠には現行の 2021 年版を載せています。この順序は 2021 年版でも同じです。

結論: ベイジアンフィルタは、利用者が仕分けたメールから特徴を学び、確率で判定する方式です。

なぜ: 「迷惑メールに出やすい語」「正規のメールに出やすい語」を、利用者が振り分けた実例から数えておきます。新しいメールが届いたら、含まれる語からベイズの定理で迷惑メールである確率を計算し、高ければ迷惑メールと判定します。使うほど利用者の傾向に合っていくのが特徴です。

• ア … 許可リスト（ホワイトリスト）方式
• イ … 送信ドメイン認証（SPF や DKIM など）
• ウ … 第三者中継を許すサーバの一覧（ブラックリスト）を使う方式

結論: パケットフィルタリングは、パケットの見出し（ヘッダ）にある IP アドレスとポート番号で通すかどうかを決めます。

なぜ: パケットフィルタリング型は、パケットの中身（アプリケーションのデータ）までは読まず、送信元・宛先の IP アドレス、ポート番号、プロトコルといったヘッダの情報を規則と照らし合わせます。中身を見ないぶん速く、仕組みも単純です。

• ア・エ … POST データや URL は通信の中身で、これを見て判断するのは WAF やプロキシ（アプリケーションゲートウェイ）の役目です
• ウ … MAC アドレスは同じネットワークの中でしか意味を持たず、ルータを越えると書き換わるので、ファイアウォールの判断材料には向きません

結論: 1 ビットの訂正と 2 ビットの検出ができるのはハミング符号です。

なぜ: ハミング符号は、データに複数の検査ビットを足し、どのビットが誤ったかの位置まで分かるようにした符号です。位置が分かれば、そのビットを反転させて直せます。ECC メモリは、これにもう 1 ビットを足して 1 ビット訂正・2 ビット検出にした方式を使います。

ア・イのパリティは、誤りがあることは分かってもどのビットかは分かりません（しかも 2 ビット同時に誤ると気づけません）。ウのチェックサムも、誤りの検出に使うもので、訂正はできません。

結論: 32 台です。

なぜ: 全体で使っているリソースの量は、物理サーバが止まっても変わりません（条件 (1) で残りのサーバに配り直すだけ）。台数を N とすると:

1. 全台稼働のとき、使っている量は 0.6N 台分（条件 (2)）2. 8 台止まると、それを N − 8 台で受け持つ3. 1 台あたりの消費は 0.6N ÷ (N − 8)。これを 0.8 以下にしたい

0.6N ≦ 0.8(N − 8) → 0.6N ≦ 0.8N − 6.4 → 6.4 ≦ 0.2N → N ≧ 32。

確かめると、32 台なら 0.6 × 32 ＝ 19.2 台分を 24 台で受け持ち、19.2 ÷ 24 ＝ ちょうど 80% です。

結論: 使用性は「使いやすさ」です。使い方を理解しやすくするオンラインヘルプの充実は、そのまま使用性の向上です。

なぜ: 使用性は、利用者が迷わず、覚えやすく、効率よく使えるかを表す品質です。説明が見つけやすく分かりやすいことは、その大事な要素です。

ほかの選択肢は別の品質を高める施策です。

• イ … 他システムとの連携（相互運用性）
• ウ … 使える範囲を広げる（機能性・機能の充足）
• エ … 故障に備える（信頼性）

結論: マッシュアップは、公開されている複数のサービスを組み合わせて、新しいサービスを作ることです。

なぜ: 例えば、地図のサービスと店舗情報のサービスを組み合わせて「地図の上に店を表示する」サービスを作る、といった使い方です。それぞれのサービスが公開している API などを呼び出して組み合わせるので、すべてを自分で作るより少ない手間で新しいものを作れます。

• ア … リバースエンジニアリング
• イ … 部品化による再利用（コンポーネント指向の開発）
• ウ … ライブラリを使った開発