データウェアハウス初心者の第一歩として/『データウェアハウスがわかる本』を読んだ
普段仕事ではデータレイク基盤の構築をメインで行っているが、そもそもデータウェアハウス（DWH）について知らない要素もあるので、その穴埋めに読んでみた。
- 作者:鈴木 健司
- 発売日: 2000/06/01
- メディア: 単行本
この本自体は2000年初版のかなり古い本にあたり、今のAWSやGCPなどのクラウドコンピューティングの要素は一切入っていない。
だけど、DWH自体の考え方は大きくぶれていないので、古いと思う要素は少なかった。
（むしろ2000年の時代からDWHを使用して機械学習しようというような要素も含まれており、20年たってもやりたいこととやれることは変わっていないんだなと思えた）
データウェアハウスというワードが仕事で急に出てきて困っているみたいな人が読むにはうってつけの書籍だと思う。
100ページ以内でさくっと読めるのもいいポイントだと思う。
目次
1章 データウェアハウスの概念2章 データウェアハウスの基本構成
3章 データウェアハウスの設計と構築
4章 多次元データウェアハウス／データマートの設計と構築
5章 データウェアハウスの活用
6章 データウェアハウス構築の開発手順
データウェアハウス（DWH)とは
基幹系データベースに蓄積されたデータをもとに、基幹系データベースとは別に構築される情報系データベース。
DataWareHouseの略がDWH。
つまり、販売戦略などの意思決定のために基幹系データベースの過去データや企業外の外部データ（経験上、OANDAなど）の情報を加工して、意思決定のために使用されるデータである。
データウェアハウスの狙いは、データから今まで知られなかった知識を得て意思決定に活用されること。
簡単に言うと雨の日は売り上げが落ちているというのは、普段気づけないが、データウェアハウスとして月単位年単位で表示するとそれが分かるようになる、ということ。
基幹系データベースをそのまま使用しない理由としては、意思決定において不要な項目があるという点や、集計軸が通常、日ベースで行われるが意思決定においては月ベースである場合がある。
そのため、そのままでは使用できないので、加工（集計や集約）してあげる必要がある。
データウェアハウスの特性
ベースとする基幹系データベースがOLTP（On-Line Transaction Processing）ということもあり、時系列データなので、データウェアハウスも時系列で集計することが多い。データウェアハウスの概念として、
・サブジェクト志向
・統合
・時系列
・普遍性
の4点が定義されている。
基幹系データベースとの違い
基幹系データベース
・定型業務処理（在庫管理や航空機の座席予約など）
・業務処理1回の受付（トランザクション）は客を待たせないようデータアクセスは最低限、高レスポンス、高スループット
・データの追加・変更・削除が可能
データウェアハウス
・意思決定支援の材料なので、定型業務は存在しない
・分析処理メインなので、大量データへのアクセス、ある程度レスポンスやスループットは低くても問題ない
・データの削除は基本的に行わない（全量洗替か差分追加（更新）となる）
サブジェクト志向
データウェアハウスの目的は上でも書いた通り企業の意思決定支援に使われるものである。例えばAmazonであなたにおすすめと商品を紹介されるケースがあるが、これは自分の購買履歴やアクセス履歴から特定されている。
snofra.hatenablog.com
これは主題（サブジェクト）が自分（顧客）であって、購買テーブルや、GoogleAnalyticsの回遊情報を組み合わせて、プロモーションしている。
これがサブジェクト指向。
基幹系データベースでいう受発注や、在庫管理などプロセスではなく、それらを使って商品や商品を利用した顧客の分析を行うこと。
統合
データウェアハウスは、色々なデータを組み合わせてテーブルとしていくが、複数社あって基幹系データベースが異なる場合はそれ毎にルールがある。例えばあるグループ会社は品目コード10桁だが、別のグループ会社は8桁など。
この各社のルールをある程度整備してデータウェアハウスとして統一した基準を作ること言う。
そこを適当にやると経験上、桁あふれでエラーになったり、割と大きい桁修正の手戻りが発生したりと面倒くさいことになる。
時系列
これはそのまま。数年単位で集計して、昨対比などを見ていくことになる。不変性
基本的に時系列データを取り扱うので、Insertがメインとなる。UpdateやDeleteは取り扱わないことで、データの恒常性を担保している。
データの世界でも現実世界と同じで過去は書き換えできないということ。
ただし、経験上データ上流側のミスなどがあるので、過去を書き換えが必要なタイミングがあるので、以下をやることが多い。
・全量削除して全件Insert（全量洗替）
→マスター系で多いやり方。上流から連携されるファイルに常に全データがある場合に多い。
・ある期間をDeleteして、その期間分Insert（差分追加）
→トランザクションデータがメイン。リカバリーを考慮。
データマートとしてのマテリアライズドビュー
データマートは上で説明していたデータウェアハウスよりも粒度の細かい部門やエンドユーザレベルに向けたデータウェアハウスになる。経験上、大きなデータウェアハウスを作って、そこから各部門ごとへデータマートを切り出していることがあった。
その際のデータマートはビューであった。
この書籍でもデータマートはビュー、マテリアライズドビューであると説明されている。
マテリアライズドビューとは
データベース管理システムは関係モデルに従うため、ビュー は仮想的な テーブル であり、データベースに対するクエリの結果を表す。ビューを参照または更新すると、その処理はビューの対象となった実際のテーブルへの参照または更新へ変換され、実行される。
マテリアライズドビュー (Materialized View; 体現ビューともいう)はこれとは異なるアプローチを取り、クエリの結果を実際のテーブルにキャッシュする。キャッシュされたデータは元のテーブルが変更されるたびに更新される。そのため、最新でない状態を取得する可能性はあるが、効率的なアクセスが可能になる。特にデータウェアハウスでは実際のテーブルに対して頻繁にクエリを実行することは非常にコストが高いため、マテリアライズドビューが有効である。
マテリアライズドビュー - Wikipedia
ビューはアクセスしたときにinputのテーブルから情報を抽出してくるが、マテリアライズドビューはデータをキャッシュしておける。
分析を行た目に結合や集計などが行われているため、パフォーマンス懸念があった。そのため、マテリアライズドビューを使用してあらかじめ実行結果を格納しておくことによりパフォーマンス問題を解決できる。
Redshiftでは2020/03/12現在、プレビュー中だが今後使用可能になるよう。
データマート構築した際もビューでパフォーマンス懸念があったので、マテリアライズドビューが使えるようになると楽だなーと。
多次元データモデル
これを見るのが分かりやすい。www.atmarkit.co.jp
多次元データモデルは、販売戦略などの意思決定のためのデータとしてどのようなデータが必要なのか、という点において活用される。
ここからわかるように、データマートで部門ユーザが分析したい軸はたくさんあるし、粒度もそれぞれ違う。
このような要約や詳細など多次元的にみられるデータを指す。
スタースキーマ
多次元データベースで分析したいデータの粗さは定めることはできるが、実際は売上なら、売上テーブルを中心に、商品情報があるテーブルや、購入したユーザ情報テーブルなどデータが存在しており、それらと紐づいてようやく販売戦略などの意思決定のためのデータとなりえる。イメージとしては以下となる。
*2
このような構造をスタースキーマと呼ぶ。
またその中心（売上テーブル）をファクトテーブル（事実表）、そのファクトテーブルを修飾するテーブルをディメンションテーブル（次元表）と呼ぶ。
データマートを構築するときに最後TableauなどBIツールを使用して可視化することになる。
経験上、そのデータマートのビューの結合の際にこのスタースキーマを考えることが多かったように思える。
基幹系データベース
基幹系データベースは受注や発注、在庫管理、経理などのメイン処理を行っているデータとなる。業態や組織の構成、システム化の度合いなどによりどのようなシステムが該当するかは異なるが、止まると業務自体がストップしてしまったり、事業に深刻な影響が及ぶようなものをこのように呼ぶ。
e-words.jp
