www.youtube.com 本動画では、令和2年度秋期 データベーススペシャリスト試験 午後Ⅰ 問3を題材に、RDBMS上に構築されたデータウェアハウスを前提として、次元テーブル統合の設計判断、分析SQLのJOINと述語配置の要点、そしてサマリテーブル（データマート）設計における性能見積りと最小化の考え方を、設問の意図と採点講評で指摘された典型的な誤りに沿って解説します。本問は全体として正答率が高いとされますが、それは「解きやすい」という意味ではなく、データウェアハウスの基本原理を知っている受験者ほど、図表とSQLの細部まで丁寧に読み、最小列数・最小行数という設計目標に向けて論理的に詰められたかどうかが問われる問題だったということです。午後Ⅰとしての読解ポイントは、用語暗記ではなく、参照制約や派生可能性の判断、LEFT OUTER JOINのON句とWHERE句の役割差、次元間の導出可能性を利用した冗長排除といった、設計とSQLの“約束事”を、与件に即して正確に適用できるかにあります。 設問1のテーブル統合は、個人会員と法人会員を会員へ、個人売上と法人売上を売上へ統合する方針のもとで、参照制約の参照先や統合時に必要な属性、制約の妥当性を確認する問題です。参照制約の参照先を特定する設問1(1)では、会員地域コードが参照するのは地域コードを主キーとする地域テーブルであり、法人会員の担当社員IDが参照するのは社員IDを主キーとする社員テーブルです。ここは単純な図表読み取りに見えますが、採点の観点では、参照先が「テーブル名」だけではなく「参照する列」まで含めて正確に書けているか、参照制約である以上、その列が参照先の主キーまたは一意制約であることを理解しているかが暗黙にチェックされています。 会員区分を追加しない場合の不都合を問う設問1(2)は、統合の設計で最も起きやすい落とし穴を突いています。個人会員番号と法人会員番号がそれぞれ独立に採番されているなら、同じ8桁が両者で衝突する可能性があります。会員区分をキーに含めずに会員番号だけで統合後の会員を識別しようとすると、主キー重複が発生して登録できない、あるいは識別不能になるという不都合が生じます。データウェアハウスの統合は「列を寄せる」だけでなく「識別子の意味を揃える」ことが本質であり、ここを会員区分という属性で補強するという判断が、業務上の一意性とDB制約の整合性として妥当であることを説明できるかが要点になります。 設問1(3)の会員テーブル定義は、NOT NULL制約と参照制約、検査制約（CHECK）の役割を混同していないかが問われる部分です。会員区分が主キーの一部になるなら当然NOT NULLであり、会員地域コードは地域参照の外部キーとしてNOT NULLにする設計が自然です。性別や年代、担当社員IDの扱いが難所で、個人会員と法人会員で意味を持つ属性が異なるため、NULL許容と整合性制約をセットで設計しなければなりません。性別は法人会員では意味を持たずNULLになり得るためNOT NULLではなく、かつ外部キーではないので、取り得る値を限定するためにCHECKで‘M’/‘F’に制約するのが設計意図になります。これに対して年代は外部キーで参照制約を持つため、取り得る値は参照先テーブルにより既に制約されており、そこへIN述語やBETWEENで重複する値制約を掛けるのは、採点講評が指摘する典型的な誤りです。必要なのは値域の二重制約ではなく、会員区分に応じてNULLを許すかどうかという整合性であり、法人会員なら年代はNULL、個人会員なら年代は非NULLといった条件を、検査制約として表現できているかが問われています。担当社員IDも同様に、法人会員のみが持ち得る属性であり、参照先社員が削除された場合にSET NULLで整合性を保つ設計を採るなら、個人会員ではNULLであることをCHECKで担保する筋になります。ここでの合否を分ける論点は、外部キーによる参照整合性と、CHECKによる業務ルール整合性の役割分担を理解した上で、重複や矛盾のない制約設計を書けたかどうかです。 設問2は見直し後の販売情報の分析で、LEFT OUTER JOINを用いた分析SQLの基本を問うています。設問2(1)は、店舗コードと商品コードの特定集合に対して、売上が存在しない組合せも含めて結果を出す必要があるため、店舗リスト側を左表に置き、売上を右表に置くLEFT OUTER JOINにするという設計意図を読み取れるかが中心です。ここで難しいのは、結合条件と抽出条件の置き場所で、LEFT OUTER JOINではON句に置く条件とWHERE句に置く条件を誤ると、左表の行が落ちてしまい、売上がない店舗が結果から消えるという典型的なバグになります。2020年3月、商品P1/P2といった「売上側を限定する条件」はON句に置くべきであり、分析対象店舗M1/M2/M3のように「最終結果の対象を絞る条件」はWHERE句で掛けるのが筋です。これにより、売上Uに該当行がない場合でも店舗Mの行は保持され、売上関連列がNULLになることで“売上ゼロの組合せ”を表現できます。採点講評で多い誤りがON句とWHERE句の逆転であり、これはLEFT OUTER JOINの意味を構造として理解していないと起きやすい失点要因です。 設問2(2)のNULL発生条件は、LEFT OUTER JOINと列の意味制約の両方を押さえる必要があります。販売額がNULLになるのは、左表（店舗）に対して右表（売上）に結合できる行が存在しない、すなわち指定期間と指定商品で売上実績がない組合せの場合です。一方、クーポン額がNULLになるのは、結合の有無ではなく、売上行が存在しても「クーポンを適用しなかった」という業務上の意味でNULLが許される列であるためです。ここを区別して説明できれば、COALESCEが「外部結合による欠損」と「業務上NULLが意味を持つ欠損」を同じNULLとして扱ってしまうことを防ぎ、分析SQLの設計意図が明確になります。 設問3はサマリテーブル作成で、性能改善のためにどの粒度で集計済みデータを持つべきかを、行数見積りと列の最小化で判断させます。設問3(1)の最大結果行数は、集計のGROUP BYキーの組合せ数の最大値を掛け合わせる基本で、B3は対象月数2、店舗地域10、大分類10より200行、B5は対象月1、店舗300、性別2、年代7より4,200行と見積もるのが筋になります。ここでの読解ポイントは、期間中にコード体系や店舗数が変動しないという前提を素直に使うことと、法人会員が含まれない分析では性別・年代の組合せが個人会員に限定されることを忘れないことです。 設問3(2)のサマリテーブル設計は、本問の核心で、最小列数かつ最小行数でB2～B6を一つのサマリテーブルで賄うために、どの次元をサマリに保持し、どの次元は次元テーブルから導出するかを判断する問題です。結論としてAに入れるべきは性別、年代、小分類コードであり、大分類コードを追加するのは冗長になり得ます。理由は、小分類コードがあれば小分類テーブルから大分類コードを導出できるため、同時に保持する必要がないからです。データマート設計の難しさは、分析要件を満たすために“何でも入れる”方向へ流れがちで、結果として列が増え、行の粒度が細かくなり、ストレージも集計負荷も増える点にあります。採点講評が指摘する冗長な大分類コード追加はこの典型で、次元テーブルの階層関係を使って導出可能性を見極め、サマリに保持するキーを最小化できるかが、設計判断として評価されています。 この令和2年度秋期データベーススペシャリスト試験 午後Ⅰ 問3を通して学べるのは、次元統合では識別子の衝突回避と制約設計が不可欠であること、LEFT OUTER JOINでは述語配置が結果集合の意味を変えるためON句とWHERE句の役割を厳密に使い分けること、サマリテーブル設計では導出可能な次元を冗長に保持せず、最小列数で分析要件を満たす判断が性能と保守性を左右することです。正答率が高いとされる一方で、これらの論点を曖昧に理解したままだと、JOINの条件位置の取り違えや、外部キー列に不要な検査制約を付けてしまうなど、実務でも起きやすい誤りに直結します。本動画では、単なる答え合わせに留めず、採点講評が示す失点パターンを回避するための読解手順と、設計を最小化するための考え方を、設問の流れに沿って一貫して説明します。最後まで視聴することで、データウェアハウス問題を「SQLの穴埋め」や「表の計算」として処理するのではなく、制約と導出可能性に基づく設計判断として整理し直せるようになり、同種の午後Ⅰ問題で安定して得点できる再現性の高い解法を身に付けることができます。
