基本情報 平成26年度 春期 問24：テクノロジ系に関する問題

答えは d「担当者別の顧客別受注実績」 です。

4つのファイルから「当月＋過去3か月」の出力ができる組合せはどれか、を考える問題。

ポイント:

• 顧客マスタには「前月・2か月前・3か月前の受注額」と「担当者コード」が入っている
• 当月受注ファイルに「当月」の受注がある
• 担当者マスタに担当者名がある

だから「担当者ごとに、顧客ごとの受注実績」を当月＋過去3か月分まとめて出せる。

👉 覚え方：「過去データがどこに入っているかを見て、出せるレポートが決まる」。

ほかの選択肢：商品マスタの過去データは商品単位なので、顧客との組合せが出せない。

なぜこれが正解か

正解は d。各ファイルの構成を整理:

• 顧客マスタ: 顧客コード・名称・担当者コード・前月/2か月前/3か月前の受注額（顧客単位の月別履歴）
• 商品マスタ: 商品コード・名称・前月/2か月前/3か月前の受注額（商品単位の月別履歴）
• 担当者マスタ: 担当者コード・氏名
• 当月受注: 顧客コード・商品コード・受注額（明細）

各顧客の担当者は1人と固定されている。

「担当者別の顧客別受注実績」を当月＋過去3か月分出すには:

1. 当月: 当月受注を顧客コードで集計→顧客マスタの担当者コード→担当者マスタの氏名と結合

2. 過去3か月: 顧客マスタの月別受注額をそのまま使用→担当者マスタと結合

この2つを統合できるためdが可能。

各選択肢の解説

• a 顧客別の商品別受注実績：商品別データが当月受注にしかない（商品マスタは商品単位の合計のみ）ため、過去3か月の顧客×商品の交差点が出せない。
• b 商品別の顧客別受注実績：同上の理由でNG。
• c 商品別の担当者別受注実績：商品と担当者を結ぶキーが不在（顧客経由でしか辿れず、当月受注以外で集計困難）。
• d 担当者別の顧客別受注実績：上記のとおり可能。

覚え方・ひっかけ注意

「過去データがどの粒度で保持されているか」を最初に確認。本問は顧客マスタが顧客単位、商品マスタが商品単位で過去3か月の月別額を保持。保持粒度より細かい集計はできないのが鉄則。「各顧客の担当者は1人」という制約が担当者←→顧客の1対多関係を成立させ、d を可能にしている。

理論的背景

本問はファイル/データウェアハウスの設計におけるデータマートのカバレッジ問題。データ集計は「事実テーブル（Fact Table）の粒度で決まり、ディメンション（軸）を組み合わせて分析可能**」という大原則がある。本問では:

• 当月受注ファイル＝明細粒度のFact（顧客×商品の交差点）
• 顧客マスタの月別受注額＝集約済みFact（顧客粒度）
• 商品マスタの月別受注額＝集約済みFact（商品粒度）

粒度を下げる方向の集計はできず、より粗い粒度への集計のみ可能。よって過去3か月の顧客×商品分析は不可能、過去3か月の顧客別・商品別の単軸分析は可能、という制約が生じる。

実務での使われ方

データウェアハウスのスタースキーマでは中央のFact Tableを最も細かい粒度で保持し、Dimension Tableで属性を持つ。OLAPキューブはこの軸を組み合わせて分析（スライス＆ダイス、ドリルダウン、ロールアップ）する。実務では「事実の粒度をどこまで細かく保持するか」がデータマート設計の最重要決定で、ストレージ容量と分析柔軟性のトレードオフ。

本問のように「マスタファイルに月次累計を持つ」設計は、事前集計型（Pre-aggregated）データマートの特徴で、特定の集計クエリを高速化する一方、自由分析の柔軟性を犠牲にする。現代では明細データを常時保持し、必要に応じて集計する「明細保持型」が主流（HDFS、S3、Snowflake、BigQueryなどの大容量ストレージで実現）。

試験での位置づけ

FE/AP/DB（データベーススペシャリスト）のデータベース設計分野で頻出。①テーブル設計と参照整合性、②正規化・非正規化、③スター/スノーフレークスキーマ、④集計の粒度問題、⑤関連集約と従属（コッドの12規則・関数従属性）、が主要論点。本問は実務的な設計思考を問う良問。

選択肢の発展補足

現代のデータ基盤ではdbt（data build tool）でELTパイプライン構築、Snowflake/BigQuery/RedShiftで大容量明細データ保持、Looker/Tableau/Power BIで分析、というアーキテクチャが標準。データレイクハウス（Databricks Delta Lake、Apache Iceberg）はOLTPとOLAPの境界を曖昧にし、粒度問題の制約を緩和する。Change Data Capture（CDC）でリアルタイム同期、Slowly Changing Dimension（SCD Type 2）で履歴管理、が定石技術。本問のような「マスタに集計済み履歴を保持」は古典的設計だが、ストレージコストが急減した現代では「明細を全て保持し、集計はクエリ時に行う」アプローチが主流化している。