www.youtube.com 平成30年度春期データベーススペシャリスト試験の午後Ⅰ問3は、温浴施設の運営システムを題材に、論理設計で終わらない実務レベルの物理DB設計と、実装・運用プロセスまで含めた性能設計の勘所を問う問題です。午後Ⅰとしては珍しく、制約や索引、容量見積りといった「設計結果」だけでなく、作業工程の組み方や統計情報取得のタイミングといった「作り方・運用の仕方」までが得点対象になっており、SQLが書けるだけでは届かない領域を、本文の条件から読み切れるかが合否を分けます。出題趣旨の中心は、業務ルールとデータの意味・制約を正確に読み取り、それを一意性制約や検査制約として過不足なく定義できること、さらにDMLの登録パターンから索引のユニーク性やクラスタ性を判断してI/O見積りに落とし込めること、最後に、RDBMSが統計情報に基づいてアクセスパスを選ぶという前提に立って、作業順序そのものを性能設計の一部として組み替えられることにあります。 本問で最初に差がつくのは、制約設計を「列名の暗記」ではなく「業務上の識別単位」に落として考えられるかどうかです。店舗テーブルで追加すべきUNIQUE制約は、内線番号が施設内で識別されるという定義に忠実に従えば、施設IDと内線番号の組合せが候補キーになります。逆に精算テーブルでは、主キー以外に一意性を成立させる組合せがないことを、精算機が複数台あり、客がどの精算機で精算するかが固定されないという業務ルールから導く必要があります。採点講評でも、ここを「精算機番号」などで一意にできそうだと誤解したり、別の列の組合せで候補キーを作ってしまう誤答が指摘されやすい論点で、本文の“行が一意になる根拠が業務上存在するか”という観点で判断できるかが問われています。CHECK制約も同様で、年齢区分と年齢の整合性は、単なる範囲指定の練習ではなく、データ品質をDB側で担保するという目的を理解して、定義された区分の境界をそのまま条件式に落とすことが求められます。ここで曖昧な条件や抜けを作ると、以降の集計や課金の前提が崩れるため、物理設計の問題でありながらデータ意味の読み取りが根底にある点が、午後Ⅰらしい読解ポイントになります。 次に索引の論点では、索引の種類やクラスタ性を、アクセス頻度や検索条件の一般論で語るのではなく、DMLの発生形態から具体的に判断できるかが鍵です。店舗利用テーブルの索引1は、鍵番号が同一でも滞在中に飲食やサービス利用が繰り返され、同じキー（施設ID・鍵番号・未精算フラグ）に該当する行が増え得るため、ユニークにはなりません。ここで「鍵番号は客を表すから一意になりそうだ」と短絡すると誤りになります。精算明細テーブルの索引2のクラスタ性が高いと判断できるのも、索引キーの形を眺めるだけではなく、精算時に未精算データをまとめて抽出して一括で追加するという登録順序が本文で与えられているからです。同じ券番号、同じ施設ID、同じ利用年月日に属する明細行が連続してINSERTされるなら、索引キー順と物理配置が一致しやすく、結果として同一精算の明細を読むときのページ読み込みが少なくなるという因果を、きちんと説明できることが重要です。採点講評で差がつくのは、ここを「高クラスタだから速い」と結論だけで終わらせず、「なぜ高クラスタになるのか」をDML2の登録単位と順序で理由付けできるかどうかで、午後Ⅰとしての読解力がそのまま得点に反映されます。 容量見積りとDML性能予測は、式の穴埋め問題に見えて、本質は「RDBMSがページという単位で格納し、読み込む」という物理の前提を踏まえて、最大行長と有効ページ長で格納可能性を確認し、平均行長とページ当たり平均行数で所要ページ数を見積もる、という手順を一貫して説明できるかにあります。可変長列がある場合、最大行長で最悪ケースを押さえずに平均だけで計算すると、そもそもページに収まらない行が発生して設計が破綻しますし、逆に最大だけで見積もると過剰見積りになります。平均と最大を使い分ける意味を言語化できることが実務的です。DML性能予測も、表探索なら必要ページ数、低クラスタな索引探索なら探索行数に近いページ読み込み、そして高クラスタなら探索行数をページ当たり平均行数で割った程度のページ数で済むという、I/Oの見立てをアクセスパスとクラスタ性に結び付けて説明できるかがポイントになります。ここを読み違えると、索引を作ったのに性能が出ない、あるいは全表スキャンのほうが速いのに索引を強制してしまうといった実務の失敗に直結するため、出題趣旨としては「ページI/Oの感覚」を午後Ⅰで再確認させる狙いが強いといえます。 そして本問の最大の山場が、設問2の実装・運用プロセスの改善、特に統計情報取得のタイミングです。W1が確定した後に、アクセス権限設計や性能測定用データ設計を並行して進め、クリティカルパスを短縮するという工程設計は、単なるプロジェクト管理ではなく、DB実装に必要な前提条件が何かを理解しているかを問うています。権限設計はテーブル定義が固まらないとGRANTを設計できず、性能測定データも列型や制約が確定しないと作れないため、W1後に着手可能である一方で、実装のタイミングとしてはW7やW10と整合させる必要がある、という前後関係を本文から構造化できるかが読解ポイントになります。統計情報の落とし穴はさらに実践的で、テーブル作成直後に統計情報を取得すると、RDBMSがテーブルを空だと判断して表探索に決めるという仕様が適用され、後からデータをロードしても実行計画が不適切なままになり得る、という因果を押さえる必要があります。影響を受けるDMLがDML2やDML3であることも、単に番号を当てるのではなく、「本来は索引を使うべき処理が、統計情報の誤りで全表スキャンになってしまう」という性能劣化の筋道を説明できて初めて意味が出ます。だからこそ正しい作業順序として、統計情報取得はデータロードであるW10の後に置くべきだ、という結論が導かれます。採点講評で強調されやすいのは、統計情報を“儀式的に取るもの”として扱うのではなく、“実行計画の入力データを作る工程”として捉え、データ投入後に取るという当たり前を本文根拠で言い切れるかどうかで、ここが午後Ⅰの合否を分ける代表論点になります。 この動画では、平成30年度春期データベーススペシャリスト試験午後Ⅰ問3を、制約設計では「業務上の識別単位」を根拠に候補キーを判断する視点、索引設計では「DMLの登録単位と順序」からユニーク性とクラスタ性を導く視点、性能見積りでは「ページI/O」という物理の前提で式の意味を理解する視点、そして工程設計では「統計情報が実行計画を左右する」という運用の勘所を、本文の記述に沿って一つの流れとして整理します。単発の正解を覚えるのではなく、同型の午後Ⅰ問題で再現できる読解と理由付けの手順に落とし込むことが目的です。動画を見る意義は、物理DB設計と運用設計が分断された知識ではなく、同じ性能目標に向けて連動する設計要素であることを理解し、制約・索引・容量・統計情報・工程を一貫した根拠で説明できる力を身に付けられる点にあります。
