応用情報技術者試験過去問を解いてみた R6年度 春期 問28

応用情報技術者試験

はじめに

今回も、応用情報技術者試験の過去問を解いていきます。
応用情報では データベースやデータウェアハウス（DWH） の問題が定期的に出題されます。特に「スター・スキーマ」や「ファクトテーブル」「ディメンションテーブル」といった用語は頻出です。

今回の問題は、データウェアハウスのテーブル構成について理解しているかを問う問題です。

問題

データウェアハウスのテーブル構成を スター・スキーマ とする場合、
分析対象のトランザクションデータを格納するテーブルはどれか。

選択肢内容
アサマリーテーブル
イディメンションテーブル
ウファクトテーブル
エルックアップテーブル

解答

ウ　ファクトテーブル

解説

データウェアハウスでは、分析を効率的に行うために スター・スキーマ（Star Schema） というデータ構造がよく使われます。

スター・スキーマでは、以下の2種類のテーブルが中心になります。

テーブル種類役割
ファクトテーブル売上・数量・金額などの 分析対象の数値データ（トランザクション） を格納
ディメンションテーブル商品・顧客・日時などの 分析の切り口となる情報 を格納

つまり、

  • 売上データ
  • 注文データ
  • アクセスログ
  • 購買履歴

などの 事実（Fact）データ は、すべて ファクトテーブル に格納されます。

問題の用語解説

ファクトテーブル（Fact Table）

分析対象となる 事実データ（数値データ） を格納するテーブル。

例

日付ID商品ID店舗ID売上金額販売数量
20240101P001S0130002

特徴

  • 数値データが中心
  • 行数が非常に多くなる
  • ディメンションテーブルのキーを持つ

ディメンションテーブル（Dimension Table）

分析の切り口となる 属性情報 を格納するテーブル。

例（商品ディメンション）

商品ID商品名カテゴリメーカー
P001ノートPCPCA社

サマリーテーブル

集計済みデータを保存するテーブル。

例

  • 月別売上
  • 年別販売数

パフォーマンス向上のために使われることがありますが、
トランザクションデータの元データではありません。

ルックアップテーブル

コード変換などに使う補助テーブル。

例

コード意味
1男性
2女性

そもそもデータウェアハウスとは？

そもそもデータウェアハウスとは何なのでしょうか。これについて解説したいと思います。

例えば、全国に店舗を持つ会社があるとします。

毎日、

  • どの商品が売れたのか
  • 何個売れたのか
  • いくらで売れたのか
  • どの店舗で売れたのか

といったデータが発生します。

当然、こうしたデータはシステムのデータベースなどに保存されます。

そして、ある日こんなことを調べたくなったとします。

「過去5年間で、夏になると売上が伸びる商品は何だろう？」

このような分析をするには、過去の大量のデータが必要です。

そこで、さまざまなシステムから分析に必要なデータを集め、分析しやすい形に整理して蓄積する仕組みを用意します。

それが、

データウェアハウス（Data Warehouse：DWH）

です。

Warehouseは「倉庫」という意味なので、最初は、

DWH＝分析に使うデータを集めておく倉庫

と考えるとイメージしやすいと思います。

ただし、単にデータを放り込んでおくだけではなく、分析に使いやすいようにデータを統合・整理して蓄積するところがポイントです。

でも、普通のデータベースに全部保存しておけばいいのでは？

ここで最初に疑問に思ったのがこれです。

「過去データを分析したいなら、普通のデータベースに全部残しておけばいいのでは？」

実際、それでも分析自体はできます。

また、業務で使うデータベースにも注文履歴や取引履歴などの過去データは普通に保存されています。

では、なぜわざわざDWHを用意するのでしょうか。

大きく分けると、3つの理由があります。

理由内容
処理の負荷大規模な分析処理が日常業務に影響する可能性がある
データの形業務で使いやすい構造と分析しやすい構造は異なる
データの統合複数のシステムに分散したデータをまとめて分析したい

一つずつ見てみます。

理由① 日々の業務と大量分析では求められる処理が違う

例えばコンビニのレジを考えてみます。

お客さんが商品を購入したら、

「商品Aを1個販売した」

「在庫を1個減らした」

「決済が完了した」

といった処理をすぐに行う必要があります。

一方で、本部からこんな依頼が来たとします。

過去10年間について、全国5,000店舗の商品別・地域別・月別の売上を集計してほしい。

これは大量のデータを読み込み、結合し、集計する処理になります。

同じデータベースでこうした大規模な分析を行うと、システムの構成によっては、日々の業務処理に影響を与える可能性があります。

そこで、

日々の業務
    ↓
業務用データベース
「注文登録・在庫更新などを処理」


分析用データ
    ↓
DWH
「大量の履歴データを集計・分析」

というように、役割を分けるわけです。

理由② 業務しやすいデータの形と、分析しやすいデータの形は違う

もう一つ重要なのがデータの構造です。

業務システムでは、データを正確かつ効率的に管理するため、

  • 顧客
  • 注文
  • 注文明細
  • 商品
  • 店舗
  • 在庫
  • 決済

など、情報が複数のテーブルに分かれていることがあります。

しかし分析担当者が知りたいのは、

「2026年7月に、東京都で、パソコンはいくら売れた？」

のような情報だったりします。

そのたびに複雑なテーブルを結合して集計するよりも、最初から分析しやすい形に整理しておいた方が扱いやすいわけです。

この「分析しやすいデータ構造」という考え方が、今回のスター・スキーマにつながってきます。

理由③ 会社のデータは一つの場所にあるとは限らない

会社で分析したいデータは、一つのデータベースにすべて入っているとは限りません。

例えば、

POSシステム ───────　　┐
                    　　　　　│
ECサイト ────────── ┤
                   　　　　　 │
顧客管理システム ───　　　 ┼──→ DWH ──→ 分析
                   　　　　　 │
在庫管理システム ───　　　 ┤
                   　　　　　 │
会計システム ─────── 　┘

ということもあります。

しかも、それぞれのシステムでデータの表現が違う場合もあります。

例えば、

POS：商品コード 001
EC ：商品ID A001

のような状態です。

DWHでは、こうした複数のデータを集め、必要に応じて形式をそろえ、横断的に分析できるようにします。

データベースとDWHは完全に別物なのか？

ここも少しややこしいところです。

「データベース」と「DWH」という名前を見ると、

データベースとは別の技術としてDWHが存在する

ようにも見えます。

しかし、そうとは限りません。

DWH自体も、データベース技術を使って構築できます。

そのため、

データベース vs DWH

という完全な対立関係として考えるより、

何のために、どのような形でデータを持つのかが違う

と考える方が分かりやすいと思います。

整理すると、

業務用データベースDWH
主な目的日々の業務処理データ分析
主な処理登録・更新・検索大量検索・集計
データ業務に必要なデータ分析に必要な統合・履歴データ
重視すること業務を正確・迅速に処理大量データを分析しやすくする

つまり、違いの中心は目的です。

DWHを作った。ではデータをどう保存する？

ここまでで、

「分析するためにDWHを用意する」

というところまで来ました。

ではDWHという倉庫を作って、データを適当に放り込めばいいのでしょうか。

もちろん、そうではありません。

次に考える必要があるのが、

「分析しやすいように、データをどんな構造で保存するか？」

ということです。

そこで登場するのがスキーマです。

なお「スキーマ」という言葉にはデータベース分野でさまざまな使われ方があります。

ここでは、

DWHのテーブルをどのような構造で配置するかという設計

くらいに考えてください。

そして、DWHで使われる代表的な設計方法の一つが、

スター・スキーマ

です。

スター・スキーマとは？

例えば、売上を分析したいとします。

分析したいのは、

  • 売上金額
  • 販売数量

などです。

一方で、

  • いつ売れた？
  • 何が売れた？
  • どこで売れた？
  • 誰が買った？

といった切り口から分析したくなります。

そこで、次のように分けます。

役割具体例
分析対象となる事実売上金額、販売数量など
分析の切り口日付、商品、店舗、顧客など

これをテーブルとして配置すると、例えば次のようになります。

                    日付
                     │
                     │
                     ▼
                  売上
                 （Fact）
                ／  │  ＼
              ／    │    ＼
           商品    店舗    顧客

分析対象となるファクトテーブルを中心に、その周囲にディメンションテーブルを配置します。

全体が星のように見えることから、

スター（Star）・スキーマ

と呼ばれます。

ファクトテーブルとは？

ファクト（Fact）は日本語にすると「事実」です。

ファクトテーブルには、売上や注文など、分析対象となる事実を格納します。

例えば、

日付ID商品ID店舗ID顧客ID販売数量売上金額
001P001S001C00126,000円
001P002S001C00214,000円

といったデータです。

売上金額や販売数量などの数値を持つことが多いですが、

「ファクトテーブル＝数値だけを保存するテーブル」

と覚えてしまうより、

ファクト＝分析対象となる事実

と覚えた方が正確です。

ディメンションテーブルとは？

一方、ディメンションテーブルには、分析するときの切り口となる情報を格納します。

例えば商品ディメンションなら、

商品ID商品名カテゴリメーカー
P001商品AパソコンA社
P002商品B家電B社

といった情報を持たせます。

これによって、

  • パソコンだけの売上を見る
  • A社の商品だけ集計する
  • 商品カテゴリ別に比較する

といった分析ができます。

今回の範囲では、

ファクト＝何を分析する？

ディメンション＝どんな切り口で分析する？

と考えると分かりやすいです。

スノーフレーク・スキーマとは？

スター・スキーマ以外にも、スノーフレーク・スキーマという設計方法があります。

スター・スキーマでは、商品に関する情報を比較的まとまったディメンションとして持たせます。

商品
├ 商品名
├ カテゴリ
└ メーカー

一方、スノーフレーク・スキーマでは、ディメンションをさらに正規化して分割します。

メーカー
   │
カテゴリ
   │
商品
   │
ファクトテーブル

つまり大まかには、

スター・スキーマスノーフレーク・スキーマ
ディメンション比較的まとめるさらに正規化・分割する
構造シンプル複雑になりやすい
見た目星形雪の結晶のように枝分かれ

今回の問題ではスター・スキーマがテーマなので、まずはこちらを理解しておけば十分です。

問題の用語解説

今回の選択肢を整理します。

用語内容
ファクトテーブル分析対象となる事実を格納する
ディメンションテーブル分析の切り口となる情報を格納する
サマリーテーブル集計した結果などを格納する
ルックアップテーブルコードと名称などの対応関係を格納する

今回の問題文には、

「分析対象のトランザクションデータ」

とあります。

分析対象となる事実を保存するのはファクトテーブル。

したがって答えは、

ウ：ファクトテーブル

となります。

体系的位置づけ

ここまで出てきた言葉を一度まとめます。

日々の業務
   │
   ▼
業務用データベース
   │
   │ 分析に必要なデータを集める
   ▼
データウェアハウス（DWH）
   │
   ├─ 分析しやすい構造を考える
   │
   ├── スター・スキーマ
   │      ├─ ファクトテーブル
   │      └─ ディメンションテーブル
   │
   └── スノーフレーク・スキーマ
          │
          ▼
       データ分析

今回の問題は、この中の、

「DWHをスター・スキーマで設計した場合、分析対象をどこに保存するのか？」

という部分を聞いています。

こうして全体の流れに置いてみると、単に「ファクトテーブル」という言葉だけを暗記するより理解しやすくなります。

今回の問題の重要ポイント

今回の問題で覚えておきたいのは、次の流れです。

データを分析したい
        ↓
分析用にデータを集める
        ↓
DWH
        ↓
分析しやすい構造にする
        ↓
スター・スキーマ
        ↓
 ┌───────────── ┬─────────────┐
 │                           │
分析対象                    分析の切り口
 │                           │
ファクト                  ディメンション

つまり、

DWH＝分析に必要なデータを統合・整理して蓄積する仕組み

スター・スキーマ＝DWHを分析しやすく構成する設計方法の一つ

ファクト＝分析対象となる事実

ディメンション＝分析の切り口

です。

ここまでつながって理解できれば、今回の問題だけでなく、関連する問題にも対応しやすくなりそうです。

まとめ

今回の問題の答えは、

ウ：ファクトテーブル

でした。

最初は、

「データウェアハウス」

「スター・スキーマ」

「ファクトテーブル」

「ディメンションテーブル」

と知らない言葉が立て続けに登場するので、かなりややこしく感じます。

ですが、

「大量のデータを分析したい」

↓

「分析用にデータをまとめよう」

↓

「DWHを用意する」

↓

「分析しやすいデータ構造にしよう」

↓

「スター・スキーマを使う」

↓

「分析対象はファクト、分析の切り口はディメンション」

という流れで考えると、それぞれの言葉の関係が見えてきます。

特に今回の問題では、

Fact＝事実

という言葉の意味を押さえておくと、答えにもたどり着きやすいと思います。

参考情報

コメント

タイトルとURLをコピーしました