6.2データウェアハウスと分析基盤

日々の受発注や在庫更新を処理するOLTP（オンライン・トランザクション処理）のデータベースは、更新の整合性と応答速度を優先して正規化された設計になっています。しかし「過去3年間の地域別・商品カテゴリ別の売上推移を集計する」といった分析クエリをOLTPのスキーマにそのまま投げると、複数表の結合が多重化し性能が悪化しがちです。データ基盤担当には、分析目的に応じてOLTPとは別のスキーマ・別の基盤（データウェアハウス）を設計し、どのタイミング・方式でデータを統合するかを判断する能力が求められます。この節ではその設計判断の型を学びます。

6.2.1スタースキーマとスノーフレークスキーマ

• ファクトテーブル＝分析対象となる数値の実績データ（売上金額・数量等）を格納する中心的な表。ディメンションテーブル＝分析の切り口（「いつ」「どこで」「誰が」「何を」にあたる時間・店舗・顧客・商品等の属性）を格納する表。ファクトテーブルは各ディメンションテーブルの主キーを外部キーとして持つ。
• スタースキーマ＝1つのファクトテーブルを中心に、複数のディメンションテーブルが直接放射状に接続する構造（星形）。ディメンションテーブルは非正規化されており（例：店舗表に地域名・都道府県名まで冗長に持つ）、結合数が少なく分析クエリの性能が高いが、冗長データの分だけ格納容量は増える。
• スノーフレークスキーマ＝ディメンションテーブルをさらに正規化し、階層構造（例：店舗表→地域表→都道府県表）に分割した構造（雪の結晶状）。格納容量は節約できるが、分析クエリで結合階層が増えスタースキーマより性能面で不利になりやすい。更新頻度が高いディメンションを持つ場合や格納容量を抑えたい場合に選ぶ。

6.2.2ETL/ELTとOLAP

• ETL（Extract, Transform, Load）＝OLTP等の複数の業務システムからデータを抽出（Extract）し、分析用スキーマに合わせて変換（Transform：名寄せ・単位統一・欠損値処理等）した上で、データウェアハウスに格納（Load）する処理。変換を専用のETLサーバ上で先に済ませてからロードする。ELT（Extract, Load, Transform）＝抽出後にまず生データをロードし、変換はロード先（DWHやデータレイク）の高い処理能力を使って後から行う方式で、クラウド上の大規模並列処理基盤の普及とともに広まった。
• OLAP（オンライン分析処理）＝多次元（時間・地域・商品等の軸）のデータを対話的に分析する処理。ドリルダウン＝集計データをより詳細な粒度（年→四半期→月）へ掘り下げる操作。ロールアップ＝逆に詳細データをより粗い粒度へ集約する操作。スライス&ダイス＝特定の次元で切り出したり（スライス）、視点を切り替えて多角的に見る（ダイス）操作。

6.2.3データマイニングとビッグデータ・データレイク

• データマイニング＝大量データから人手では気づきにくい統計的な相関・パターン・規則性を発見する手法群（相関ルール分析（バスケット分析）・クラスタリング・回帰分析等）。OLAPが分析者が仮説を持って多次元に切り分けるのに対し、データマイニングは仮説を持たずデータからパターンを発見的に見出す点が異なる。
• ビッグデータ＝従来のRDBMSでは扱いにくい量（Volume）・多様性（Variety：構造化/半構造化/非構造化データ混在）・速度（Velocity：リアルタイム性）を特徴とするデータ群。データレイク＝構造化・半構造化・非構造化を問わず、データを変換せず生の形式のまま大規模に格納するリポジトリ。データウェアハウスが「スキーマオンライト（格納前にスキーマを決める）」であるのに対し、データレイクは「スキーマオンリード（読み出し時にスキーマを適用する）」で、格納時点での柔軟性が高い。

あるアパレル小売企業のデータ基盤担当者が、経営陣から「過去5年間の店舗別・商品カテゴリ別・季節別の売上傾向を素早く多角的に分析したい」という要望を受けたとします。まずOLTPデータベース（正規化された受発注・在庫システム）に直接分析クエリを投げると、複数表の結合が多段になり応答が遅く、業務系の更新処理も圧迫してしまうため不適切と判断します。そこで分析専用のデータウェアハウスを新設し、売上金額・数量を持つファクトテーブルを中心に、店舗・商品・時間・顧客のディメンションテーブルを配置します。経営陣の要求が「多角的な分析を素早く」であり、格納容量よりもクエリ性能を優先したいため、ディメンションテーブルを非正規化したスタースキーマを選びます（もし逆に、店舗のディメンションが頻繁に更新される・格納容量を厳しく抑えたいという事情があれば、正規化したスノーフレークスキーマを検討したはずです）。データ統合の方式では、複数の業務システム（POS・在庫・会員管理）からデータを集める必要があり、名寄せや単位統一などの変換ルールが複雑なため、まずETLで変換を済ませてからロードする方式を採用します。運用が始まった後、経営陣が「まず年間の傾向を見て、悪かった四半期だけ月次まで掘り下げたい」と要望すれば、これはOLAPのドリルダウン操作で対応します。さらに、単なる集計を超えて「どの商品とどの商品が同時に購入される傾向があるか」という仮説を持たない相関の発見をしたい場合は、データマイニング（バスケット分析）の出番です。将来的にSNSの投稿やコールセンターの音声テキストなど非構造化データも取り込みたくなった場合は、スキーマを事前に固定しないデータレイクへ生データを蓄積し、必要な分析の都度スキーマオンリードで加工する設計を検討します。このように「分析の目的（速度優先か容量優先か）」「データ統合の複雑さ」「構造化か非構造化か」を見極めてスキーマ・統合方式・基盤を選び分けるのが実務の核心です。

6.2.4この節のまとめ

• ファクトテーブル＝数値実績、ディメンションテーブル＝分析の切り口。スタースキーマ＝非正規化・高性能、スノーフレークスキーマ＝正規化・省容量
• ETL＝変換してからロード、ELT＝ロードしてから変換。OLAPはドリルダウン/ロールアップ/スライス&ダイスで多次元分析
• データマイニングは仮説なしのパターン発見。ビッグデータ・データレイクはスキーマオンリードで非構造化データにも対応