株式会社エイトハンドレッド テクノロジー本部 データエンジニアの三宅です。
普段、業務で分析システムの論理設計をどのように進めているでしょうか？
分析システムでよく採用される設計手法にディメンショナル・モデリングがあります。
ディメンショナル・モデルをデータアーキテクチャに組み込むことにより、分析システムのパフォーマンスとメンテナンス性を高め、これまで以上に柔軟に分析を進めることができるようになります。
本日は、ディメンショナル・モデリングの進め方 前編として、ディメンショナル・モデルとはどんなものか、データアーキテクチャにどのような戦略でディメンショナル・モデルを組み込んでいくか、プロジェクト進行上の注意点とは、と言ったところ説明していきます。
分析システムにおける論理設計
データベースを利用するシステムの開発において、論理設計が非常に重要なプロセスの一つということは、システム開発に関わった経験のある方はよく知るところかと思います。
業務システムでは、一般に第三正規形(3NF)を基準に据え、必要に応じて非正規化やさらに高次の正規化を行いながら論理設計を進めます。
では、分析システムで使用されるデータウェアハウスでも、同様に3NFに基づいて設計を進めてもよいのでしょうか？
3NFの特徴と業務システム・分析システムそれぞれのデータの取り扱いに着目しながら考察したいと思います。
第三正規形(3NF)と業務システムとの相性
3NF自体の説明はここでは省略し、3NFの特徴について説明します。
3NFの特徴はいくつかありますが、特に大きな特徴と考えられるのは次の2つです。
- データの整合性の担保：データベース内の全ての情報が矛盾なく一貫性を持つ状態を作ることができます。
- データの冗長性の排除：データの冗長性を極力排除し、無駄なデータ領域の使用と面倒な更新処理の発生を防ぎます。
業務システムは処理の正確性と効率性が最優先され、一貫したデータ整合性の維持が求められるため、3NFの上記の特徴は非常に相性がいいことが分かります。
第三正規形(3NF)と分析システムの相性
では、3NFと分析システムの相性はどうでしょうか？
分析システムは、大量のデータに対する高速なクエリ応答と、ユーザーがデータ間の関連性を直感的に理解できることを要求されます。
3NFでは、整合性の担保と冗長性の排除を実現するため、正規化理論に従いテーブルを細かく分解します。
テーブルが細分化された結果、以下のデメリットが生じ、分析システムの要求を満たせない可能性が出てきます。
- クエリに多数の結合が必要となり複雑化し応答が遅くなる。
- データの関連性を直感的に理解し辛くなる。
また、分析システムはソースデータとして業務システムのデータを使うことがしばしばありますが、業務システムが3NFで設計されていれば、分析システムのデータも必然的に整合性が保たれるため、分析システムを3NFで設計する意味合いは弱まります。
こうした事情から業務システムと比較すると分析システムでは正規化のデメリットが顕在化しやすい上、メリットも得られにくい傾向があることが分かります。
分析システムのために考案された設計手法"ディメンショナル・モデリング"
そのため、分析システムにはディメンショナル・モデリングという異なるアプローチをよく採用します。
ディメンショナル・モデリングとは、Ralph Kimball氏によって提唱されたデータの設計手法で、ビジネスインテリジェンス（BI）やデータ分析のシステムで利用することを念頭に置いて考案されました。
3NFがデータの整合性担保と冗長性排除を目的としているのに対し、ディメンショナル・モデルでは、データ構造の把握を容易にすること、分析処理のパフォーマンスを向上することを主目的に置いています。
こうした目的の違いからディメンショナル・モデルでは、データをファクトテーブルとディメンションテーブルの2種類のテーブルに分解していくのですが、3NFまでは分解しません。
一定の冗長性を許容することで各テーブルを分析業務に適した形にとどめます。
このような構造から、ディメンショナル・モデルは3NFと比較し次のような特徴を持ち、3NFの抱える問題を解決、あるいは緩和することが可能です。
分析クエリの実行パフォーマンスが高いデータの非正規化によりテーブル結合が減少し、クエリパフォーマンスが向上します。また、複合キーに対してサロゲートキーを付与することで、結合や集計のパフォーマンスが向上します。
データを直感的に理解しやすい非正規化により、データがエンティティ単位でより一覧性が高くなり、データを直感的に理解しやすくなります。
分析要件拡張に柔軟に対応しやすい新たなディメンションの追加や既存ディメンションへの属性追加により、分析要件の拡張に柔軟かつ簡潔に対応できます。
特に、分析要件の拡張に対応しやすいため、長期的に運用するデータ基盤で採用すると大きなメリットがあります。
なお、更新時異常については、3NFのように仕組みとして発生しないよう制限をかけることはできないため、ディメンショナル・モデルの前段である業務システムやETL・ELT処理の中で排除されているという前提で進めます。
表: 第三正規形とディメンショナル・モデルの比較
| 比較項目 | 第三正規形 | ディメンション・モデル |
|---|---|---|
| 目的 | 整合性担保・冗長性排除 | 効率的な分析処理・直感的なデータ構造理解 |
| テーブルの分割 | 正規化理論に従い細分化 | 一定のルールで非正規化 |
| 分析クエリのパフォーマンス | 低い | 高い |
| データ構造の理解しやすさ | 多数の結合が必要 | 結合が少な目、直感的 |
| 冗長性 | 仕組みで排除 | ある程度許容 |
| 整合性 | 仕組みで保証 | 保証しない(前段のプロセスでの保証を前提) |
ディメンショナル・モデルを実現する上で、ファクトとディメンションの分解のアプローチが複数存在します。
- スタースキーマ
- ディメンショナル・モデルの中で最もシンプルで一般的な構造
- 中心に配置されるファクトテーブルは、ビジネスプロセスの量的な測定値を格納
- ファクトテーブルの周りに配置されるディメンションテーブルは、事実を説明する属性（時間、地理、顧客など）を保持
- この配置が星の形に似ているため「スタースキーマ」と呼ばれる
- データのアクセスが直接的であり、分析クエリの作成が容易
- スノーフレークスキーマ
- スノーフレークスキーマは、スタースキーマをさらに正規化した構造
- ディメンションテーブルがさらに細分化され、階層的な構造を形成（例: 地理ディメンションが国、州、市のテーブルに分割）
- この細分化が雪の結晶に似ているため「スノーフレークスキーマ」と呼ばれる
- スノーフレークスキーマは、データの重複をさらに減らすことができ、データの整合性を高めるが、クエリの複雑性が増すことがある
- ギャラクシースキーマ（またはコンステレーションスキーマ）
- ギャラクシースキーマは、複数のファクトテーブルが共通のディメンションテーブルを共有する形式
- このアプローチは、異なるビジネスプロセスが関連している場合や、複数のファクトテーブルが同じディメンションデータに対して分析を行う必要がある場合に適している
- ギャラクシースキーマでは、データウェアハウスの柔軟性と拡張性が向上するが、データモデルの複雑さも増す
ディメンショナル・モデルがないとどうなる？
ディメンショナル・モデルがないとどうなるでしょうか？何か困ったことが起きるでしょうか？
ディメンショナルモデルがない場合、と言っても色々なケースが考えられるのでいくつか例を挙げて考えてみます。
ソースデータそのまま
データの仕様を把握するための調査フェーズなどプロジェクトの初期であるケースです。 シンプルでデータ量が少なければ問題がないこともありますが、以下のような問題の発生が想定されます。
パフォーマンスの低下 分析クエリの作成に多数のCASE文や複雑な結合条件が必要になることで、クエリが非常に複雑になることがあります。クエリが複雑になることでパフォーマンスが悪化し、分析のスピードと効率が低下する要因となります。
保守性の低下 新たな分析要件への対応の度に複雑なクエリをメンテナンスしなければならず、保守が困難になります。
作業者のモチベーションの低下 設計の不良による非効率は作業者のモチベーションを下げ、人材の流出につながります。"ちゃんと考えて作れば避けられた"事態でもあるため、優秀な人材ほどモチベーションが低下してしまう懸念もあります。
ソースデータそのままの形で運用を続けることは工数も無駄にしますし、分析メンバーは精神的に疲弊します。
こうした状況はプロジェクト初期の調査フェーズなど、やむを得ない場合を除いて避けるべきです。
やむを得ず、ソースデータそのままの形で分析業務を開始することになったときは、工数の無駄遣いとメンバーの消耗を抑えるため、早い段階でこの状況から抜け出すためのロードマップをステークホルダ全体で共有することが重要です。
ソースデータから直接ワイドテーブルを構築
ソースデータそのままの形から何らかの分析要件に特化したワイドテーブルを構築するケースです。
ワイドテーブルでは、データが一箇所に集約されるため、多くのクエリでテーブル間の結合が不要になります。
また、行指向型のアーキテクチャとは相性が悪い反面、DWH製品でよく採用される列指向型のアーキテクチャとは相性が良く、 さらにビジネスユーザーが直感的に理解しやすいため、よく設計していれば、パフォーマンス、ユーザビリティの両面でメリットがあります。
一方で、次のような問題が発生する可能性があります。
カラムが増えすぎて分かりにくくなる 複数の分析要件に対応しようとして"全部入り"の巨大なワイドテーブルにしてしまうと、カラムの構成や定義が分かりにくくなります。ソースデータとワイドテーブルしか持たない場合は、目的に特化してカラム構成をできるだけシンプルに保つことが重要です。
保守性と運用性の低下 ソースデータからワイドテーブルを構築するクエリは複雑になりがちです。 分析要件の追加、変更があるたびに目的に特化したワイドテーブルを構築・メンテナンスするとやはり多くの工数を使用してしまいます。工数の増加に伴って、分析担当者の数を増やした結果、似たようなワイドテーブルが乱立してしまうといった問題に発展することも珍しくありません。
以上のことを踏まえると、ソースデータとワイドテーブルのみで構成するデータアーキテクチャは、分析要件が限定的な短期の業務では有効ですが、分析要件の拡張が見込まれる長期の業務では避けるべきと考えられます。
ソースデータとワイドテーブルの間に3NFを構築
ソースデータからワイドテーブルの直接的な変換で疲弊した人は、クエリの複雑さを解消するために3NFで設計した中間レイヤを設けるかもしれません。
実際に3NFの中間レイヤによってソースデータ形式やワイドテーブルで発生する問題に対して一定の解決を図ることは可能です。
しかし、前述の結合の増加によるパフォーマンス低下、テーブルの細分化による直感的な分かり易さの低下という問題があるため、3NFは分析システムの設計において最善とは言えません。
分析依頼者視点で起こること
以上のようにシステムの特性にあったデータモデリングができなければ様々な問題が発生する可能性があります。
共通するのは、分析要件の拡張に工数が多くかかるという点です。
分析依頼者の視点でこの問題はどのように顕在化するでしょうか？
恐らく、多くのビジネスユーザーが何らかのシステムに関連して、類似の課題により、憤りを感じたり、やりたいことが実現できなかったという経験があるのではないかと思います。
社内のエンジニアや開発ベンダーに「ちょっとしたお願い」をしたつもりが「少なくとも開発期間は〇カ月、費用はうん千万円かかります」と言われたことはないでしょうか？
分かり易く言えば、分析業務において、これが頻発します。
上記のような設計手法の選択ミスで発生した問題が、「ちょっとしたお願い」の実現を困難にするケースは珍しくありません。
こうした事態を避けるためにも、システムの特性に合った適切な設計手法を選択できるようにしておくことは重要です。
ディメンショナル・モデルを活用したプロジェクトの進め方
データモデルの強みを活かしたデータアーキテクチャ設計
データアーキテクチャの中にデータモデルを一つしか採用してはいけないというルールはありません。
データアーキテクチャを複数のレイヤでとらえ、それぞれで異なるデータモデルを採用することで、それぞれの強みを活かすというのはよくあるアプローチです。
例えば、ソースデータをそのままの形で取り込むステージング層、ディメンショナル・モデル層、ワイドテーブル層と3層構造にするなどです。
データに不整合が多く、一度整理する層を挟みたい場合はステージング層とディメンショナル・モデル層の間に3NF層を挟むなどのアプローチも有効かもしれません。
もちろん、中間層が増えれば、その分、データ処理のオーバーヘッドは増加しますのでバッチ等の処理実行時間も考慮する必要はあります。
このような構成にすると、ワイドテーブルの作成クエリをソースデータからでなく、ディメンショナル・モデルを元に書けるようになります。
そのため、クエリがシンプルになり、比較的少ない工数で分析要件拡張に対応することが可能です。
ディメンショナル・モデリングの初期設計における注意点
ここまでディメンショナル・モデルのいいところばかりを書いてきましたが、ディメンショナル・モデルにもデメリットがあります。
そのなかでも、プロジェクトの進行に大きく影響するのが初期の設計・構築に時間がかかりやすいという点です。
ディメンショナル・モデリングでは複数のビジネス要求への対応を網羅した形式を目指します。
そのため、ある程度ビジネス要求を整理した後に開発が始まります。
また、ディメンショナル・モデルに対するクエリがシンプルになる一方で、ソースデータをディメンショナル・モデルに変換する処理はかなり複雑になります。
こうした要因から初期の設計・構築に時間がかかりやすく、リリースの遅れにつながってしまうことがあります。
長期的にデータ基盤を運用する上でディメンショナル・モデリングは非常に良い選択肢ですが、初期の設計・構築に十分時間をかける必要があることは、プロジェクトを進行する上で認識しておかなくてはいけません。
初期リリースを急ぎながらディメンショナル・モデリングを進める
では、長期的な運用を想定している場合、初期リリースをデータモデリング都合で待たなくてはならないのでしょうか？
ここで重要なのは最初から基盤全体が完成していなくてもよく、フェーズによってレイヤを増やしてもよいという点です。
つまり、初期リリース時には最も優先度の高い分析要件に対応したワイドテーブルだけを作っておき、同時並行でディメンショナル・モデルの設計を行うアプローチも可能です。
こうしたアプローチを取ることで可能な限り初期のリリースを早めながら、パフォーマンス性とメンテナンス性の高いアーキテクチャを実現することが可能になります。
プロジェクト進行上の注意点
データアーキテクチャ、データモデルを段階的に構築していくアプローチが有効なことはご説明しました。
しかし、これを実際のプロジェクトで適用していくにはいくつかの障壁があります。
必要になった時に検討するという考え方でやっても、必要性を感じた時には、多数の複雑なクエリのメンテナンス作業で工数が埋まり、 ディメンショナル・モデルの設計に取り掛かれないといった事態が発生し、まずうまくいきません。
以下の点に注意を払い、段階的な構築や継続的な改善を考慮した戦略を立てる必要があります。
- 最初に分析要件を定義する
ワイドテーブル、ディメンショナル・モデル、3NFのどの場合でも分析要件によって設計が決まるため、最初に分析要件を定義します。
- 目指すべきデータアーキテクチャを設定する
当初の段階で見えている範囲で構わないので、目指すべきデータアーキテクチャを設定します。
- ロードマップの共有
目指すべきデータアーキテクチャに至るロードマップをステークホルダと共有します。
- 継続的な評価と改善
プロジェクトを通じて定期的にデータアーキテクチャとデータモデルの評価を行い、 新たなビジネス要求の追加、パフォーマンスの最適化、データ品質の向上を加えます。
これらの原則に従ってプロジェクトを進行することで、データ基盤の構築と運用の両面において成功を収める可能性が高まります。
データアーキテクチャの構築は一度で完了するものではなく、ビジネスの成長とともに進化し続けることを念頭に置くことが重要です。
弊社ではデータ基盤の構築から運用まで伴走した経験のあるコンサルタント、エンジニアが多数在籍しており、 確実にデータ基盤を継続改善していくことが可能です。
効果的なデータ基盤構築と継続的な改善に不安のある方は一度弊社までお問い合わせいただければと思います。
最後に
今回は分析システムに適したデータモデリング手法であるディメンショナル・モデリングの概要を前編としてご紹介しました。 後日、ファクトテーブルやディメンションテーブルの設計手法について、もう少し具体的な説明を後編としてご紹介する予定です。
本記事が少しでも分析システムのデータモデリングの参考になれば幸いです。
