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

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

内容整理自:

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

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

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

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

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

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

正規化モデリング#

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

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

次元モデリング#

最も簡単な説明は、事実表と次元表に従ってデータウェアハウスやデータマートを構築することです。例えばスタースキーマ、スノーフレークモデルなどです。

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

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

特徴

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

利点

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

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

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

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

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

事実星座モデル（Fact Constellation）#

星座モデルはより複雑なモデルであり、複数の事実表を含み、次元表は共通であり、複数の事実表が共用の次元表を持つことができます。このようなモデルは星座モデルの集合と見なすことができるため、銀河スキーマ（galaxy schema）または事実星座（fact constellation）と呼ばれます。

まとめ#

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

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

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

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