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

結論: シーケンスから取り出した値は、ロールバックしても戻りません。

なぜ: シーケンスは「番号を配る機械」で、トランザクションの外で動きます。取り消せるようにすると、同じ番号を 2 人が同時に受け取ってしまうためです。結果として、失敗したトランザクションが取った番号は欠番として飛びます。伝票番号などを「連続していること」前提で設計すると、ここで破綻します。

残りはいずれも「できない」と言っていますが、実際にはできます。

• ア … CYCLE を指定すれば、最大値に達したあと最小値へ戻って繰り返せます
• イ … ALTER SEQUENCE ... RESTART や setval で好きな値に置き直せます
• ウ … 増分は負でもよく、その場合は値が減っていきます

結論: 細かい単位でプロシージャ化しても速くなりません。むしろ遅くなります。

なぜ: ストアドプロシージャが速い理由は、まとめて 1 回で呼べることにあります（エ）。細かく分けてしまうと呼び出し回数が増え、その利点が消えます。1 回あたりの通信は短くても、回数が増えれば往復の待ち時間が積み上がるからです。

⚠️ 設問は「適切でないもの」を聞いています。ア・イ・エはいずれも正しい説明なので、正しいものを選んでしまわないよう注意してください。

• ア … 表を直接触らせず手続き経由に限定できるので、権限を絞れます
• イ … 共通処理を 1 か所に置けるので、書き方のばらつきを防げます

結論: A から C2 へのポインタが増え、リーフは B ⇄ C1 ⇄ C2 ⇄ D の順につながります。

なぜ: リーフが 2 つに割れたので、直さなければならないのは 2 か所です。

1. 親（中間ノード A） … 新しくできた C2 を指すポインタを足す。設問が「A には十分な空きがある」と断っているのは、A 自身は割れずに済むという意味です2. リーフどうしの並び … C1 と C2 は元の C の位置にそのまま入るので、B ⇄ C1 ⇄ C2 ⇄ D の順になります

この 2 つを両方満たしているのはイだけです。

• ア … リーフの並びは正しいものの、A から C2 へのポインタがありません。上から C2 に辿り着けず、索引として使えません
• ウ … 並びが B ⇄ C1 ⇄ D ⇄ C2 になっています。キーの順に並んでいないので、範囲検索でリーフを順にたどる、という B+木の使い方が壊れます
• エ … C2 が C1 の下にぶら下がっています。B+木はすべてのリーフが同じ深さでなければならないので、この形にはなりません

結論: 「単語 → その単語を含む文書」の向きに引ける索引が転置インデックスです。

なぜ: 普通に持っているのは「文書 → その中の単語」の向きです。これをひっくり返して「単語 → 文書」の対応表にしておくと、全文を走査せずに「その単語を含む文書」を一気に引けます。転置という名前はここから来ています。

アは関数インデックス、イは B 木インデックス、エはクラスタ化（実データそのものを並べ替える方式）の説明です。

⚠️ PostgreSQL の全文検索で使う GIN（Generalized Inverted Index）が、まさにこの転置インデックスです。

結論: 連番の列を 1 本足して主キーにする、いわゆる代理キー（サロゲートキー）です。

なぜ: 複合キーは、参照する側の表すべてに同じ列を全部持たせる必要があり、結合条件も長くなります。1 列の連番に置き換えれば、参照する側は 1 列で済みます。

ア・イは、複合キーの一部だけを主キーにしています。一部では行を一意に識別できないので、そもそも主キーになりません。エは元の複合キーを外部キーにするとしていますが、外部キーは他の表を参照するためのもので、自分の表の中の話ではありません。

⚠️ 代理キーにしても、元の複合キーには一意性制約を付けておく必要があります。連番だけにすると、中身がまったく同じ行が何行でも入ってしまいます。

結論: 組織に自己関連があり、従業員から見た組織が 1 つ——これがエです。

なぜ: 設問の条件は 2 つあります。それぞれが図のどこに出るかを見ます。

1. どの組織にも所属できる … 「所属する」の相手が組織そのものであること。上位組織と末端組織に分けて、末端組織にだけつなぐと末端にしか所属できません2. 兼務はしない … 従業員 1 人につき組織は 1 つ。つまり組織側の多重度が 1（1 つの組織に従業員が * 人）

階層は組織どうしの自己関連（上位 0..1 ／下位 *）で表せるので、上位組織・末端組織という下位クラスは要りません。

• ア … 「所属する」が末端組織につながっています。途中の組織には所属できません
• イ … 多重度が逆で、組織側が *・従業員側が 1 です。これは1 人の従業員が複数の組織に所属する＝兼務を許す形になります
• ウ … 自己関連がなく、階層そのものを表せていません。多重度もイと同じく逆です

⚠️ 多重度は、その端に書かれたクラスが何個対応するかを表します。組織の端の 1 は「従業員 1 人に対して組織は 1 つ」という意味で、「組織 1 つに従業員が 1 人」ではありません。ここを取り違えるとイとエが入れ替わります。

結論: 150 です。

なぜ: 順に絞り込みます。

1. 商品ランクが 'A' なのは S001・S002・S003 の 3 行2. 左外結合なので、売上実績が無い S002 は残り、売上合計金額が NULL になる3. AVG は NULL を数に入れません。足すのも数えるのも S001 と S003 の 2 行だけ

したがって (50 + 250) ÷ 2 = 150 です。

⚠️ ここが引っかけです。3 行あるのに割る数は 2 になります。(50 + 250) ÷ 3 = 100（ア）と考えると誤りです。NULL を 0 として扱いたいなら AVG(COALESCE(売上合計金額, 0)) と書く必要があります。

エの 275 は、商品ランクで絞らずに売上実績の 4 行すべてを平均した値（(50 + 250 + 350 + 450) ÷ 4）です。絞り込みを忘れるとこうなります。

結論: EXCEPT です。

なぜ: リーフノード（葉）とは「子をもたないノード」です。言い換えると

• 子ノードの一覧 … 表に現れるすべてのノード（A を除く全部）
• 親ノードの一覧 … 誰かの親になっているノード（A・B・C・F）

前者から後者を引けば、親になっていないノードだけが残ります。これがリーフです。実際に引くと D・E・G が残り、図と一致します。

他の演算では求まりません。

• イ INTERSECT … 両方に出るもの＝リーフ以外（B・C・F）が出てきます
• ウ・エ UNION / UNION ALL … 足し算なので、絞り込みになりません

⚠️ 「◯◯でないもの」を求めたいとき、全体から該当するものを引くのは集合演算の定番の使い方です。

結論: 5 行・6 列になります。

なぜ: 等結合の結果は、次の 2 つで決まります。

1. 行数 … 納品表の 5 行それぞれに、商品番号が一致する商品が 1 つずつあるので 5 行。S01 は納品が 2 件あるので、商品の S01 の行が 2 回現れます2. 列数 … 等結合は両方の表の列をすべて並べます。結合に使った商品番号も両方とも残るので、3 + 3 = 6 列

この 2 つを満たすのはエだけです。

• ア … 3 行しかありません。S01 と S02 の 2 件目が落ちています
• イ … 列は 6 列で正しいものの、行が 3 行しかありません
• ウ … 行は 5 行で正しいものの、商品番号が 1 列しかありません

⚠️ 商品番号が 2 列並ぶのは等結合だからです。重複する列を 1 つにまとめたものは自然結合といい、そちらならウの形になります。SQL では JOIN ... ON が等結合、NATURAL JOIN が自然結合にあたります。

結論: 同じ性別の中の最小の生年月日を返す相関副問合せです。

なぜ: 最年長＝生年月日がいちばん古い（小さい）人です。その人を除くには「自分の生年月日 > 同性の最小の生年月日」を条件にします。

ここで大事なのは、副問合せが外側の 1 行ごとに違う値を返さなければならないことです。ウは WHERE S1.性別 = S2.性別 で外側の行（S1）を参照しているので、男性の行を見ているときは男性の最小、女性の行なら女性の最小を返します。これを相関副問合せといいます。

• ア・エ … GROUP BY を使うと男女 2 行返ってきます。> の右側は 1 つの値でなければならないので、実行時にエラーになります
• イ … OR でつないでいるため、条件が緩すぎて同性に絞れません。また外側の生年月日そのものを条件に入れており、意図した比較になりません
• エ … さらに FROM 従業員 に別名 S2 を付けていないのに S2.性別 と書いており、その時点で解決できません

⚠️ 「グループごとの最大・最小と比べる」は相関副問合せの典型です。ウィンドウ関数（MIN(生年月日) OVER (PARTITION BY 性別)）でも同じことが書けます。

結論: 直積です。

なぜ: 和両立とは「列の数が同じで、対応する列の型も同じ」という条件です。和・差・共通集合は、2 つの表の行を同じ表の行として足したり引いたりする演算なので、形が揃っていなければ成り立ちません。

直積はまったく別で、R の各行と S の各行を横につないで 1 行にする演算です。列の数は R と S の合計になります。形が違っていても構わないので、和両立は要りません。

⚠️ SQL では、和両立が要る側が UNION / EXCEPT / INTERSECT、要らない側が CROSS JOIN にあたります。

結論: まだコミットされていない値を読んでしまうのがダーティリードです。

なぜ: エでは、A が書いた途中の値を B が読み、そのあと A がロールバックしています。B が読んだ値は、最終的にどこにも存在しない値になります。これがダーティ（汚れた）読取りです。

他は別の異状です。

• ア … 2 回目の検索で行が増えている ＝ ファントムリード
• イ … 同じ行を 2 回読んだら値が変わっていた ＝ 反復不能読取り
• ウ … デッドロックであって、読取りの異状ではありません

⚠️ ダーティリードは READ UNCOMMITTED でだけ起こります。PostgreSQL はこの水準を内部的に READ COMMITTED として扱うので、そもそも起こりません。

結論: B, C, D, F です。

なぜ: 永久待ちになるのは、閉路（ぐるりと一周する待ち）に入っているか、閉路の中の誰かを待っているトランザクションです。

まず閉路を探します。B → D → C → B が一周しています（B は D を、D は C を、C は B を待つ）。この 3 つは互いに待ち合っていて、どれも永久に進めません。

次に、この 3 つを待っている人を探します。F → D なので F も永久に待ちます。

残りは進めます。

• A … A → C ではなく C → A です。A は誰も待っていないので、自分は動けます
• E … E → G だけです。G は誰も待っていないので、G が終われば E も進めます
• G … 誰も待っていません

⚠️ 矢印の向きを取り違えるとアやエになります。X → Y は「X が Y を待つ」——待たれている側は止まりません。

結論: 単版なら待たされて 5、多版（MVCC）なら待たずに 4 です。

なぜ: 資源 X の値が 1 つしか無い（単版）場合、P が書き換えている最中は読む側もロックの解放を待つしかありません。P がコミットして初めて読めるので、得られるのは新しい値 5 です。

多版（MVCC）では、更新前の値を別の版として残しておくので、Q は待たずに済みます。READ COMMITTED は「コミット済みの値だけを読む」水準なので、Q が読むのはまだコミットされていない 5 ではなく、コミット済みの 4 です。

⚠️ ここが MVCC の要点です。読む側が書く側を待たない。 PostgreSQL はこの方式で、既定の READ COMMITTED がまさにこの挙動になります。

結論: 古い値のまま計算してしまい、データどうしのつじつまが合わなくなるのが不整合検索異状です。

なぜ: イでは、T2 が読んだ時点の x はまだ更新前です。そのあと T1 が x を新しくしたのに、T2 は古い x を根拠に y を書いてしまいます。結果として、データベースの中で x と y が食い違った状態になります。

他は別の問題です。

• ア … 2 つが同じデータを上書きし合う ＝ 更新消失
• ウ … 巻き添えで取り消すことになる ＝ 連鎖ロールバック
• エ … 取り消される値を読んでしまった ＝ ダーティリードの結果

結論: 流れてくるデータをその場で判定して処理するのが CEP です。

なぜ: 普通のデータベースは「貯めてから問い合わせる」順番ですが、CEP は逆に「条件を先に置いておいて、流れてくるデータを通す」形をとります。株価の急変やセンサーの異常のように、遅れて分かっても手遅れなものに使います。

アは OLAP、イは多版同時実行制御（MVCC）、ウは 2 相コミットなどの説明です。

結論: ファクトテーブルです。

なぜ: スタースキーマは、中心に 1 つの大きな表を置き、そのまわりに説明用の表を放射状に並べた形です。中心にあたるのがファクト（事実）テーブルで、「いつ・どの店で・何を・いくつ売った」という起きたことそのものを、期間ぶん貯めていきます。

まわりのディメンションテーブルは、店・商品・日付といった切り口を持ちます。分析はこの切り口でファクトを集計する形になります。

デシジョンテーブルは条件と動作の対応を整理した表、ハッシュテーブルはデータ構造で、どちらもスタースキーマの話ではありません。

結論: データがどこから来て、どう加工されて今の形になったかの記録がデータリネージです。

なぜ: リネージ（lineage）は「血統・来歴」という意味です。分析結果の数字がおかしいとき、どの元データのどの加工でずれたのかを遡れます。逆向きにも使えて、ある元データが壊れたときにどの結果まで影響が及ぶかを洗い出せます。

アはアクセス制御の情報、イはデータの管理責任者（オーナーシップ）、エはスキーマの公開の話で、いずれも来歴ではありません。

結論: 9 桁です。

なぜ: 変更前の総数は 10 の 16 乗です。変更後を n 桁とすると 95 の n 乗なので、95 の n 乗 > 10 の 16 乗となる最小の n を求めます。

両辺の常用対数をとると n × 1.98 > 16、つまり n > 8.08… です。n は整数なので 9 になります。

⚠️ 8 桁では足りません。8 × 1.98 = 15.84 で 16 に届かないためです。文字の種類が 10 から 95 へ 9 倍以上になっても、桁数は半分強までしか減らせない——ここが指数の効き方の勘どころです。

結論: 利用者の振り分けを学習して、統計で判定するのがベイジアンフィルターです。

なぜ: 「この単語が入っているメールは迷惑メールである確率が高い」という確率を、利用者が実際に振り分けた実績から計算します。使うほど、その人宛のメールの傾向に合っていきます。ベイズの定理を使うのでこの名前です。

アは許可リスト、イは送信ドメイン認証（SPF など）、ウはブラックリスト（DNSBL）で、いずれもあらかじめ決めた名簿による判定であり、学習はしません。

結論: ハッシュ関数が欠かせません。

なぜ: 各ブロックが直前のブロックのハッシュ値を持つことで、鎖のようにつながります。途中を書き換えるとハッシュ値が変わり、後ろのブロックが記録している値と食い違うので、改ざんが必ず露見します。この性質がブロックチェーンの土台です。

ア・イ・ウはいずれも「必須」ではありません。RADIUS は認証サーバの規格、SPF はメールの送信ドメイン認証、楕円曲線暗号は署名などに使われることはありますが、どれもブロックチェーンの成立条件ではありません。

結論: 速くなる——これが RAID5+0 の目的です。

なぜ: 読み書きを複数の組に分散して同時に走らせるので、一組だけのときよりまとめて流せる量が増えます。設問自身が「性能を改善させたもの」と言っています。

他はいずれも数が合いません。

• ア … パリティは組ごとに 1 台分要ります。二組なら 2 台分減るので「全体より 1 台少ない」にはなりません
• イ … RAID5 は一組につき 1 台までしか壊れても平気ではありません。同じ組で 2 台壊れればその時点で復旧できないので、「全体の半分まで」は成り立ちません
• ウ … 組み合わせても各組に最小 3 台ずつ要るので、二組なら 6 台必要です

結論: 共通のディスクにセッションを置き、他のサーバが引き継ぐ方式です。

なぜ: 設問の要点は「セッションを共有する」ことです。セッションを各サーバの中だけに持つと、そのサーバが落ちた時点で失われます。共通の置き場に持てば、別のサーバが続きから処理できます。

エも複数台で分担しますが、故障時の処理は消失すると書いてあります。これは共有していない形なので、設問の方式ではありません。

アは 1 台のサーバの中での二重化、イは待機系への手動切替えで、どちらも負荷分散ではありません。

結論: 共通の土台を作って使い回すことで、開発効率が上がります。

なぜ: プラットフォーム開発は、機器ごとに毎回ゼロから作るのをやめ、共通の土台を 1 つ作って各機種で使い回すやり方です。機種が増えるほど、作らずに済む部分が増えます。

アは逆で、機器ごとに作り込む場合の利点です（共通化すると、その機種では使わない機能も載るのでコードは大きくなりがちです）。イについて、ハードウェアは機器ごとに違うので結合テストは省けません。エも逆で、共通部分だからこそ複数機種に同じ不具合が出ます——むしろプラットフォームを真っ先に疑うべき場面です。

結論: テストを先に書く——これがテスト駆動開発です。

なぜ: 先にテストを書くと、そのコードが何を満たすべきかが、実行できる形で決まります。書き終わったコードを後から確かめるのではなく、「失敗するテストを書く → 通るコードを書く → 整理する」を小さく繰り返します。

残りはテストそのものの話であって、書く順番の話ではありません。

• ア … バグを多く見つけることが目的ではありません（何を作るかを先に決めるのが目的です）
• イ … テストケースを改善するのではなく、テストを先に書くのが特徴です
• ウ … カバレージは結果として上がることはありますが、目的ではありません