1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

DWH データモデリング まとめ

Posted at

概要

データウェアハウスモデリング入門(ダイジェスト版)(事前公開版)というSlideShareを読んだ
DWHについては概要を何となく理解したけど、DWHのデータモデリングが気になったので検索してたら上記のソースを発見したので
読みながら調べた結果をまとめてみる

↓参考

スライドの主目的

・データ分析に必要なデータモデリングについて理解する
・主業務で利用しているデータをデータ分析向けのデータモデルに変換できるようになる
 →ここが気になっていたので重要

データモデルとは

データモデルの主な目的は、データの定義とフォーマットを提供することによって、情報システムの開発を支援すること

データモデルには目的や意図があり、業務システムのDBのデータモデル(正規化されている)とDWH等のデータモデルでは用途が異なる

データモデルの分類

当スライドでは以下のように分類

・オンライン系データモデル
 OLTPに特化したモデル
 ACID(Atomicity,Consistency,Isolation,Durability)を保つための機構がある
 正規化を行う過程で参照関係が複雑になりやすい(エンドユーザーが理解するのは不可能)

・大福帳データモデル
 システムで発生するデータを要約せずにそのまま蓄積するデータモデル
 BIツールなどを使うときに好まれやすいモデル
 カラムの数が膨大になりやすい(正規化も何もないため)

・ディメンショナルデータモデル
 データ分析のためのデータモデル(参照のみで更新されることを想定しない)
 時系列の数値を持つファクトと呼ばれるテーブルと、分析軸(支社別、品目別等)となるディメンションと呼ばれるテーブルから構成される
 →スタースキーマと呼ばれる
 →ファクトとディメンションを掛け合わせて分析を行うことができる多次元データベースの様なもの

データウェアハウスモデリングが必要な理由

・オンライン系データベースはユーザーが分析するにあたって敷居が高い(前述のとおり複雑だから)
 →というか、オンライン系データベースにクエリ投げるのはそもそもご法度(本番系のリソースを食いつぶす恐れがある)
・ユーザーの意図に対して都度最適化されたオペレーション(データマートの作成、BIレポート作成)をしていくと幸せになれない
 →データマートはユーザーの局所的なニーズにこたえすぎるとメンテがつらい
  →上記のケースではそもそもユーザーがマートを見てない(ニーズをとらえきれていないEtc)が考えられる
・以上の理由からスケールが難しい状況に陥る

解消するには

・ユーザーレベルで理解できるデータモデル
・汎用性、拡張性に優れるデータモデル

ディメンショナルデータモデル

先述した内容の補足
・スタースキーマを主軸とするシンプルでわかりやすい、拡張性と柔軟性を備えたデータモデル

スタースキーマ

ファクトテーブルとディメンションテーブルから構成される
・ファクトテーブルとリレーションを張ったディメンションテーブル
(よくある真ん中にファクトテーブルがあってディメンションテーブルが外側にあり、キーで結合している様子がスタースキーマの所以?)

用語

・ファクトテーブル
 集計対象となる金額や数値の入った、索引と数値カラムで構成されるテーブル
 →分析のために集計処理をするため、ディメンションテーブルに分割したキーと数値データのみで構成されるのが望ましい 
 参考:https://www.necto.jp/keywords/fact_table.html
 
・分析軸として利用するデータを含んだテーブル
 ディメンションは一つの次元のみを持つ構成にする(次元を含んだテーブルのため)

ディメンショナルデータモデルの利活用

・BIツールは、ファクトに対してディメンションを掛け合わせて分析し、可視化する
 →ディメンショナルデータモデルで切り出した集計対象と分析対象をBIの目的に合わせて掛け合わせるだけで利用できる
 →さらにフィルターやグループ化といった処理をして集計、分析処理をする

ディメンショナルモデルで集計対象と分析対象を切り出せていないと、
ユーザーが掛け合わせる対象が分からない&扱いづらいということで利用されない、不満が出る

スタースキーマ設計の基本的なプロセス

・どのビジネスプロセスをモデル化するか決める
 
・ファクトテーブルの粒度を決める
 「いつ、だれが、どこで、何を、どのように購入したか」等の、ファクトテーブルが持つディメンションの数
 この集約によって、潜在的には有用だった情報を失うかもしれないので、実は重要なプロセス
 →できる限り粒度が細かいほうが後がラク(必要な粒度での計測が難しくなり、再構築する必要があるかもしれない)

・分析軸/ディメンションを決める
 →上記の粒度を決めたら決まったようなものだと思う

・ファクトテーブルの項目を決める
 →集計対象となる数値データ等

まとめ

・DWHではディメンショナルデータモデルをテーブル設計に取り入れる
・スタースキーマ設計に沿ってテーブル設計を行う
・DWHのデータモデリングがデータ利用者から見た使いやすさ等に起因するのでしっかり勉強する

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?