数仓シリーズ - データモデリング手法

データウェアハウスシリーズ - データモデリング手法#

内容整理自:

データウェアハウスにおけるデータモデリング手法

データウェアハウスの構築手法篇

データモデルの基本概念#

データモデルは現実世界を抽象的に記述するためのツールと方法であり、抽象的なエンティティとエンティティ間の関係を通じて、現実世界の事象の相互関係を表現するマッピングです。ここでは、データモデルが表現する抽象はエンティティとエンティティ間の関係であり、エンティティ間の関係の定義と記述を通じて、実際のビジネスにおける具体的なビジネス関係を表現します。以下のいくつかのレベルに分かれています:

上記の図から、データウェアハウスのモデリングプロセス全体で、一般的に 4 つのプロセスを経る必要があることが容易にわかります：

ビジネスモデリング、ビジネスモデルを生成し、主にビジネスレベルの分解とプログラム化を解決します。
ドメインモデリング、ドメインモデルを生成し、主にビジネスモデルを抽象処理し、ドメイン概念モデルを生成します。
論理モデリング、論理モデルを生成し、主にドメインモデルの概念エンティティとエンティティ間の関係をデータベースレベルの論理化を行います。
物理モデリング、物理モデルを生成し、主に論理モデルが異なるリレーショナルデータベースに対する物理化や性能などの具体的な技術的問題を解決します。

正規化モデリング#

データウェアハウスのモデル設計では、一般的に第 3 正規形が採用されています。これは厳密な数学的定義を持っています。その表現の意味から見ると、第 3 正規形に適合する関係は以下の 3 つの条件を満たさなければなりません：

各属性値は一意であり、多義性を持たないこと；
各非主属性は全体の主キーに完全に依存し、主キーの一部には依存しないこと；
各非主属性は他の関係の属性に依存してはならず、その場合、その属性は他の関係に属するべきです。

次元モデリング#

最も簡単な説明は、ファクトテーブルとディメンションテーブルに従ってデータウェアハウスやデータマートを構築することです。例えばスタースキーマ、スノーフレークモデルなどです。

スタースキーマ (Star-schema)#

上図のアーキテクチャは典型的なスタースキーマです。スタースキーマは非正規化された構造であり、多次元データセットの各次元はファクトテーブルに直接接続され、漸進的な次元は存在しないため、データには一定の冗長性があります。例えば、地域次元テーブルに、国 A の省 B の都市 C と国 A の省 B の都市 D の 2 つのレコードが存在する場合、国 A と省 B の情報はそれぞれ 2 回保存され、冗長性が存在します。

特徴

ファクトテーブルは 1 つだけで、各次元には個別のテーブルがあります。
ファクトテーブルの各タプルは、次元テーブルの主キーを指す外部キーです。
各次元テーブルの列は、その次元を構成するすべての属性です。
ファクトテーブルと次元テーブルは主キーと外部キーで関連付けられ、次元テーブル同士には関連がなく、多くの星が恒星の周りを回るように、スタースキーマと呼ばれます。

利点

スタースキーマは最もシンプルで、最も一般的に使用されるモデルです。
スタースキーマは 1 つの大きなテーブルのみで構成されているため、他のモデルに比べて大規模データ処理に適しています。
他のモデルは一定の変換を経てスタースキーマに変換できます。

スノーフレークモデル (Snow Schema)#

1 つまたは複数のディメンションテーブルがファクトテーブルに直接接続されず、他のディメンションテーブルを介してファクトテーブルに接続される場合、その図解は複数の雪の結晶がつながっているように見えるため、スノーフレークモデルと呼ばれます。
スノーフレークモデルはスタースキーマのディメンションテーブルをさらに階層化したもので、元の各ディメンションテーブルは小さなファクトテーブルに拡張され、いくつかの局所的な「階層」領域を形成します。これらの分解されたテーブルはファクトテーブルではなく、主次元テーブルに接続されています。

上図のように、地域ディメンションテーブルを国、州、都市などのディメンションテーブルに分解します。その利点は、データストレージ量を最大限に減少させ、小さなディメンションテーブルを結合してクエリ性能を改善し、データ冗長性を排除することです。

データウェアハウスは大多数の場合、スタースキーマを使用して基盤となるデータ Hive テーブルを構築するのに適しており、大量の冗長性を通じてクエリ効率を向上させます。スタースキーマは OLAP の分析エンジンに対して比較的友好的であり、これは Kylin で特に顕著です。一方、スノーフレークモデルはリレーショナルデータベース、例えば MySQL や Oracle で非常に一般的であり、特に e コマースのデータベーステーブルで見られます。

ファクトコンステレーションモデル（Fact Constellation）#

コンステレーションモデルはより複雑なモデルであり、複数のファクトテーブルを含み、ディメンションテーブルは共用され、複数のファクトテーブルがディメンションテーブルを共有することができます。このようなモデルは星座モデルの集まりと見なすことができるため、銀河スキーマ（galaxy schema）またはファクトコンステレーション（fact constellation）と呼ばれます。

まとめ#

次元モデリング法の利点:
次元モデリングは非常に直感的で、ビジネスモデルに密接に関連しており、ビジネスモデル内のビジネス問題を直感的に反映できます。特別な抽象処理を経ることなく、次元モデリングを完了できます。

次元モデリング法の欠点:

スタースキーマを構築する前に大量のデータ前処理が必要なため、大量のデータ処理作業が発生します。
ビジネスが変化し、次元の定義を再度行う必要がある場合、次元データの前処理を再度行う必要があり、この処理過程で大量のデータ冗長性が発生することがよくあります。
単純な次元モデリングだけに依存する場合、データソースの一貫性と正確性を保証できず、データウェアハウスの基盤では、次元モデリングの方法が特に適用されません。

次元モデリングの領域は主にデータマート層に適しており、その最大の役割はデータウェアハウスモデリングにおける性能問題を解決することです。次元モデリングは、実際のビジネスエンティティ間の複雑な関係を完全に記述する抽象的な方法を提供することは難しいです。