Free Press

Dimensional Modeling (DM) は Ralph Kimball によって開発された Business Dimensional Lifecycle 方法論の一部で、データウェアハウス設計で使用する一連の方法、テクニック、コンセプトが含まれています。 このアプローチは、ビジネス内の主要なビジネスプロセスを特定し、ビジネスプロセスを追加する前にまずこれをモデル化し実装する、ボトムアップアプローチに重点を置いています。

データウェアハウス・モデリングの目的とは何ですか？

RossとKimballによって示された目的は簡単です。

• 情報に簡単にアクセスできるようにする
• 一貫した情報を提供する
• 変化に適応し受容する
• タイムリーに情報を提供する
• 情報資産を保護する

。

• 意思決定を改善するための権威ある信頼できる基盤として機能する（データエンジニアリング用語で「真実の単一ソース」）
• VIPはシステムを受け入れる必要がある

ETLシステムに携わった、または使用した場合、次のようなことが考えられます。 情報の一貫性は適合策によって、適時性はETLサイクルによって、適応性はETL設計によって大きく左右されることにお気づきでしょうか。

なぜモデリングなのか

データ エンジニアとして、あなたは SQL をよく知っていて、おそらく一日中 SQL クエリを書くことができるでしょう。 しかし、一般的なエンド ユーザーが SQL クエリを書く専門家であると仮定することはできません。 そこで、私たちの目的は、アナリストが分析クエリを迅速かつ効果的に書くことができる DW を構築することです。

アナリストに実行させたくないこと:

• ID に基づくクエリ
• Cascading outer joins (あなたもやりたくないでしょう)
• grouped or joined multiple subqueries
• recursive subqueries (Hackerrank SQL で、その難しさを理解していただけます)
• Subquery correlation.Isは、サブクエリの相関です。
• PK/FK なしでの結合: 私 (1.0mm)にとっても、PK/FK なしで複数の列のデータをフェッチできます。5 年の DE 経験がある私でも、可視化するのは難しいです。

アナリストに期待できること、期待すべきこと。

• 単純な結合
• 名前と包括的なテキストを含む列
• 単純な集約
• 分析ウィンドウ関数
• DISTINCT

注意：上記のポイントは簡単なものではなく、システムはこれらすべての種類のクエリのために十分にスケーラブルでなければならないということです。

OLTP データベースは、前述の目的により、事実と次元に変換されます。

トランザクション データベースから事実への移行

ほとんどの企業は、ある種のデータを測定することにより、成功と効率を測定しています。 このデータは、実際のビジネス活動や進捗状況を把握するものです。 このデータはファクトと呼ばれます。

OLTP指向のデータベースは、イベントストリーミングのようなものですが、トランザクションを中心に集中的に、一度にトランザクションを記録します。 DWは違います。 DWはトランザクション・レベルの詳細を記録する必要はない。 DWには、ビジネスのさまざまな基準にわたる事実が必要です。 DWはビジネスを改善するために必要な情報を集約する（あるいはアナリストに集約させる）必要があります。

メジャーとは何か、そしてなぜファクト テーブルをメジャーで埋める必要があるのか。

データ ウェアハウスでは、メジャーは計算を行うことができるプロパティです。 これらは、アナリストまたは分析を見る経営者が、ファクトの価値を理解するためのファクトの側面です。

なぜ一貫した粒度を維持する必要があるのでしょうか。 そこで、このギャップを埋めるために、2 つの方法があります。

• Periodic Snapshot Fact Tables

Periodic Snapshot Fact Tables

名前のとおり、一定の時間間隔で収集されます。 ガスの消費量、監査、および検査は、定期的なスナップショットが有効になっているデータ収集の例です。

Accumulating Snapshot Fact Tables

ビジネスパフォーマンス指標が複数ステップのビジネスプロセスの完了率の場合、プロセス全体の粒度で捕捉して、開始、完了、およびその間のステップを記録したいと考えるかもしれません。 これはトランザクションの粒度かもしれませんが、その間に多くの測定値があります。 つまり、ファクトとファクトの間に時間の経過があるビジネス・インテリジェンスでは、蓄積型スナップショット・ファクト・テーブルを使って、複雑な質問に答えるわけです。 6045>

ディメンジョンによるファクトの検索

ユーザーやアナリストは、ファクトからビジネス インテリジェンスを引き出すために、どのようにクエリおよびフィルタリングするかを知っておく必要があります。 この目的は、ディメンジョンによって果たされます。

参照および生のメタデータからのディメンジョンの作成

ディメンジョンは、ほとんどの場合、代理キーで作成されます。代理キーは当然、ファクト テーブルの外部キー (またはキー) で参照されます。 私たちは、関心のあるディメンジョンを検索することで、テーブルを検索します。 タイムスタンプ、顧客エージェント、店舗の場所、製品、顧客など、ファクトを記述する他のすべてのデータは、ディメンジョンに変わります。 これは Star Schema を生み出します。

次元に一意性を持たせることは非常に重要なポイントです。 ファクト間でクエリを実行する場合、ディメンジョンの組み合わせで重複があると大変なことになります。 6045>

ディメンジョンにおける階層

次の 2 つの画像を考えてみましょう。

アナリストは、2次元テーブルを設定してあげれば、楽な人生を送れるでしょう。

そこで、2つ目のテーブルを使用すると、次のような階層になります：

複数の階層、単一の階層などあらゆる階層が存在するのです。 このブログ記事でそれらには触れていません。

1 つだけ指摘しておきたいのは、時間次元は本当に面倒だということです。 マジックデー、会計カレンダー、タイムゾーン、サイクル(四半期ごとの利益タイプ)などに気を配らなければなりません。 また、時系列データベースでもETLがめちゃくちゃだと階層化で役に立ちませんので、この点についてはお粗末というか過信は禁物です。 Outriggerディメンションを見てみるとよいでしょう。 また、あるディメンジョンが他のディメンジョンに自然に依存する場合もあります。 このような場合、設計者は一方から他方への外部キーを置くことができます。 これが、”アウトリガー・ディメンジョン “を構成するものです。

Outrigger では、ファクト・テーブルで使用する日付とは異なる粒度で日付を使用することはできません。 アウトリガー・ディメンジョンに対する集計を許可することはできません。 必要な場合は、アウトリガー内の数値をテキストの接頭辞または接尾辞でマスクして、これを妨害してください。

ゆっくりと変化するディメンジョン

このことについて書きたいのは山々ですが、やはりここからこの概念を徹底的に理解した方が読者のためになると思います。

Snowflakeのディメンションについては触れませんが、OLAPデータベースではまだ使われていることを指摘しておきます。

ビッグデータをETLシステムに統合する

表形式のビッグデータを、標準の抽出フェーズで取得したものとして扱います。 したがって、transform で行ったのと同じ手順を適用します。

1. データ クレンジング
2. 単位とフォーマットの適合
3. 重複排除
4. 再構築
5. ステージング

概要

データベース設計の理論面を理解したいと思い、ロスおよびキンボールという本を読んでみました。 そして、Netflix、Airbnb、Uber などの今日の主要なデータ駆動型企業と彼らの手法の違いと類似性を描くことに興味を持ちました。 なぜなら、この方法では、BI チームは、他のインサイトごとに新しい DAG を作成するために Slack であなたを呼び出すことはなく、正しいモデリングによって、あなたの必要なく自由に行動し探索できるようになるからです。

どうしたら改善できるか、フィードバックをお願いします。

Footnotes

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross and Kimball, ch 2 and ch 18

Kimball/Ross pp103-109

お時間ありがとうございます。