Data Structure for DWH

データウェアハウス（DWH）のデータ構造に関して

データウェアハウスにおけるデータ構造は、用途や目的に応じて詳細情報と集計情報の2種類に大別されます。

• 詳細情報は、スター・スキーマやスノーフレーク・スキーマを採用することで、大量のトランザクションデータを効率的に格納し、必要に応じた柔軟な分析を可能にしています。
• 集計情報は、データキューブとして保存され、事前集計による高速なクエリ応答を実現します。

このように、DWHではそれぞれのニーズに応じた最適なデータ構造を採用することで、膨大なデータの管理と迅速な分析を両立させているのです。

以下では、詳細情報と集計情報の保存方法について、リレーショナルモデルを中心に、Star Schema（スター・スキーマ）とSnowflake Schema（スノーフレーク・スキーマ）、さらに多次元データ（データキューブ）について解説します。

---

はじめに

データウェアハウス（DWH）は、企業や組織が大量のデータを効率的に蓄積・管理・分析するための基盤システムです。
DWHでは、現場で発生する膨大なトランザクションデータや業務データを集約し、分析や意思決定のために利用できる形に整形することが求められます。ここでは、データを大きく「詳細情報」と「集計情報」に分け、それぞれに適したデータ構造について説明します。

---

1. 詳細情報の保存

リレーショナルデータベースモデルの採用

詳細なトランザクション履歴や各種イベントデータは、主にリレーショナルデータベースで管理されます。リレーショナルモデルは、データの整合性や更新の一貫性が求められる業務システムにおいて、その柔軟性と拡張性から広く利用されています。

スタースキーマ

スター・スキーマ（Star Schema）は、DWHにおける詳細情報の保存方法として非常に一般的なモデルです。以下の2つのテーブルを中心に構成されます。

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

  • 取引履歴や業務の実績データを保持します。
  • 各レコードは、実際のトランザクションやイベントの「履歴」を示しており、通常は非常に大量のタプル（行）を持ちます。

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

  • 製品、顧客、時間、地域などのマスターデータを保持します。
  • ファクトテーブルの各エントリーは、対応するディメンションテーブルの主キーによって参照され、データの属性やコンテキスト情報を提供します。

この構造により、分析クエリではファクトテーブルとディメンションテーブルを結合し、任意の切り口でデータを集計・分析できるようになります。

具体例

ファクトテーブル（売上取引テーブル）

売上ID	製品ID	顧客ID	日時ID	地域ID	売上金額	数量
1	101	201	301	401	10,000	2
2	102	202	302	402	20,000	1
3	101	203	303	401	15,000	3

ディメンションテーブル

製品ディメンション

製品ID	製品名	カテゴリー	価格
101	家電A	家電	5,000
102	家電B	家電	20,000

顧客ディメンション

顧客ID	顧客名	年齢	性別	地域情報
201	山田太郎	35	男	東京
202	鈴木花子	28	女	大阪
203	佐藤次郎	42	男	東京

日時ディメンション

日時ID	日付	曜日	月	四半期	年
301	2024-01-15	月	1	Q1	2024
302	2024-02-20	火	2	Q1	2024
303	2024-03-10	金	3	Q1	2024

地域ディメンション

地域ID	地域名	国	州
401	東京	日本	関東
402	大阪	日本	関西

この構造により、「2024年の第一四半期における、東京都内で販売された家電製品の総売上金額」などの分析クエリが容易に実行できます。

スノーフレーク・スキーマ

スノーフレーク・スキーマ（Snowflake Schema）は、スター・スキーマの一種の拡張形態です。特徴としては：

• 階層構造のディメンションテーブル
  • ディメンションテーブルがさらに正規化され、階層構造を形成するため、冗長なエントリーを削減できます。
  • これにより、ディスク容量の節約や、データの一貫性維持が期待できます。

ただし、正規化が進むことで結合クエリの複雑性が増すため、パフォーマンスとのバランスを考慮する必要があります。

具体例

スター・スキーマで用いた地域ディメンションを正規化し、階層構造を明確にする例です。

正規化前（地域ディメンション）

地域ID	地域名	国	州
401	東京	日本	関東
402	大阪	日本	関西

正規化後のテーブル例

地域テーブル

地域ID	地域名	国ID
401	東京	501
402	大阪	501

国テーブル

国ID	国名	通貨	言語
501	日本	円	日本語

州テーブル（必要に応じて）

州ID	州名	国ID
601	関東	501
602	関西	501

正規化することで、国や州の情報が一元管理され、データの一貫性が向上します。ただし、テーブル間の結合が増えるため、パフォーマンスとのバランスを考慮する必要があります。

---

2. 集計情報の保存

多次元データ（Data Cube）による集計

DWHでは、詳細なデータをそのまま分析するだけでなく、あらかじめ集計処理を施した「集計情報」を用意することで、頻繁に行われるクエリの応答速度を向上させることが可能です。これがいわゆるデータキューブの概念です。

• データキューブの構造

  • 複数のディメンション（例：時間、地域、製品など）に沿ってデータを集計し、立体的（多次元）の形で保存します。
  • 集計には、GROUP BYやその他の集約関数（SUM、AVG、COUNTなど）を事前に適用します。

• 主なメリット

  • よく利用されるクエリのパフォーマンスを大幅に向上させる。
  • 複雑な計算や集計処理をリアルタイムで行わず、事前に計算された値を利用することで、応答時間が短縮される。
  • 一部の操作（例えば、ドリルダウンやロールアップなど）が容易に実現できる。

多次元データ（Data Cube）による集計の具体例

詳細なデータを事前に集計し、クエリ応答速度を向上させるためのデータキューブの例です。

サンプル：月別売上データキューブ

ディメンションの例

• 時間ディメンション： 月、四半期、年
• 地域ディメンション： 地域名（東京、大阪など）
• 製品ディメンション： カテゴリー（家電など）

集計データ例

年	月	地域名	製品カテゴリー	売上総額	平均売上金額	取引件数
2024	1	東京	家電	25,000	12,500	2
2024	2	大阪	家電	20,000	20,000	1
2024	3	東京	家電	15,000	15,000	1

このデータキューブにより、例えば「2024年1月に東京都での家電売上の推移」など、複数の切り口で高速に分析することができます。ユーザーは集計済みのデータを用いて、ドリルダウンやロールアップといった多次元分析を直感的に行えます。

---

English

Storing Detailed Information

• Mainly in Relational Database Model
• Star Schema
  • A Fact Table and Dimension Tables
    • Fact Table: History of transaction
    • Dimension Table: Master data
  • Each entry in a Fact Table is a primary key of some Dimension Table
  • A Fact Table has a great number of tuples

An Example of Star Schema

• Snowflake Schema
  • Hierarchical structure of a Dimension Table
    • Capable of reducing redundant entries

##Storing Summary Information

• Multidimensional Data
  • also called as a Data Cube
• Applying Group‐By and other aggregate functions for the Fact Table by some attributes of Dimension tables, beforehand.
  • to speed up the performance of common queries
  • some operations are available for Data Cubes

An Example of Data Cube

参考

• What is multidimensional database (MDB)? - Definition from WhatIs.com
• 2 The Multidimensional Data Model
• OLAP and Multidimensional Model - Data Warehouse Tutorial