Dimensional modeling

Dimensional modeling is part of the Business Dimensional Lifecycle methodology developed by Ralph Kimball which includes a set of methods, techniques and concepts for use in data warehouse design.^[1]^:1258–1260^[2] The approach focuses on identifying the key business processes within a business and modelling and implementing these first before adding additional business processes, as a bottom-up approach.^[1]^:1258–1260 An alternative approach from Inmon advocates a top down design of the model of all the enterprise data using tools such as entity-relationship modeling (ER).^[1]^:1258–1260

Description

Dimensional modeling always uses the concepts of facts (measures), and dimensions (context). Facts are typically (but not always) numeric values that can be aggregated, and dimensions are groups of hierarchies and descriptors that define the facts. For example, sales amount is a fact; timestamp, product, register#, store#, etc. are elements of dimensions. Dimensional models are built by business process area, e.g. store sales, inventory, claims, etc. Because the different business process areas share some but not all dimensions, efficiency in design, operation, and consistency, is achieved using conformed dimensions, i.e. using one copy of the shared dimension across subject areas.

Dimensional modeling does not necessarily involve a relational database. The same modeling approach, at the logical level, can be used for any physical form, such as multidimensional database or even flat files. It is oriented around understandability and performance.

Design method

Designing the model

The dimensional model is built on a star-like schema or snowflake schema, with dimensions surrounding the fact table.^[3]^[4] To build the schema, the following design model is used:

Choose the business process
Declare the grain
Identify the dimensions
Identify the fact

Choose the business process

ディメンションモデリングのプロセスは、ディメンションモデルの使いやすさとデータウェアハウスの利用を確実にするための4段階の設計方法に基づいています。設計の基本は、データウェアハウスがカバーすべき実際のビジネスプロセスに基づいています。したがって、モデルの最初のステップは、モデルが構築されるビジネスプロセスを記述することです。これは、たとえば小売店での販売状況などが考えられます。ビジネスプロセスを記述するには、プレーンテキストを使用するか、基本的なビジネスプロセスモデリング表記法（BPMN）や統一モデリング言語（UML）などの他の設計ガイドを使用できます。

穀物を宣言する

ビジネスプロセスを記述した後、設計の次のステップはモデルの粒度を定義することです。モデルの粒度とは、ディメンションモデルが何に焦点を当てるべきかを正確に記述したものです。例えば、「小売店の顧客伝票にある個々の明細項目」などが挙げられます。粒度の意味を明確にするために、中心となるプロセスを選択し、それを1つの文で記述する必要があります。さらに、この粒度（文）を基にディメンションテーブルとファクトテーブルを構築します。モデルが提供すべき機能に関する新たな情報が得られた場合、このステップに戻って粒度を変更する必要が生じるかもしれません。

寸法を特定する

設計プロセスの3番目のステップは、モデルのディメンションを定義することです。ディメンションは、4ステッププロセスの2番目のステップで定義した粒度内で定義する必要があります。ディメンションはファクトテーブルの基盤であり、ファクトテーブルのデータが収集される場所です。通常、ディメンションは日付、店舗、在庫などの名詞です。これらのディメンションには、すべてのデータが格納されます。たとえば、日付ディメンションには、年、月、曜日などのデータが含まれる場合があります。

事実を特定する

ディメンションを定義したら、次のステップはファクトテーブルのキーを作成することです。このステップでは、ファクトテーブルの各行を埋める数値ファクトを特定します。このステップは、データウェアハウスに保存されているデータにアクセスできる場所であるため、システムのビジネスユーザーと密接に関係しています。したがって、ファクトテーブルの行のほとんどは、数量や単位あたりのコストなど、数値で加算可能な値になります。

次元正規化

次元正規化またはスノーフレーク化は、通常の次元で既知の冗長な属性を削除し、非正規化された次元を平坦化します。次元はサブ次元に厳密に結合されます。

スノーフレーキングは、多くのデータウェアハウスの哲学とは異なるデータ構造への影響をもたらします。^{[ 4 ]} 複数の記述的（ディメンション）テーブルに囲まれた単一のデータ（ファクト）テーブル

開発者がディメンションを正規化しない理由はいくつかあります。^{[ 5 ]}

正規化によってデータ構造がより複雑になる
テーブル間の結合が多いため、パフォーマンスが低下する可能性があります。
省スペース効果はごくわずかです。
ビットマップインデックスは使用できません
クエリのパフォーマンス。3NFデータベースは、分析が必要となる可能性のある多数の次元値を集計または取得する際に、パフォーマンスの問題を抱えることがあります。運用レポートのみを作成する場合は、運用ユーザーは非常に細かい粒度のデータを必要とするため、3NFでも問題ないかもしれません。

正規化が役立つ理由についてはいくつかの議論がある。^{[ 4 ]}階層の一部が複数の次元に共通している場合、正規化は有利になることがある。たとえば、顧客とサプライヤーの両方の次元で使用されている地理的次元は再利用できる可能性がある。

次元モデリングの利点

次元モデルの利点には以下が含まれます。^{[ 6 ]}

理解しやすさ。正規化モデルと比較して、ディメンションモデルは理解しやすく、より直感的です。ディメンションモデルでは、情報が一貫性のあるビジネスカテゴリまたはディメンションにグループ化されるため、読みやすく解釈しやすくなります。また、シンプルさによってソフトウェアがデータベースを効率的にナビゲートできます。正規化モデルでは、データは多数の個別のエンティティに分割され、単純なビジネスプロセスであっても、複雑な方法で結合された数十のテーブルが生成される可能性があります。
クエリのパフォーマンス。ディメンションモデルは非正規化されており、データクエリに最適化されています。一方、正規化モデルはデータの冗長性を排除し、トランザクションのロードと更新に最適化されています。ディメンションモデルの予測可能なフレームワークにより、データベースはデータについて強力な仮定を立てることができ、パフォーマンスにプラスの影響を与える可能性があります。各ディメンションはファクトテーブルへの同等のエントリポイントであり、この対称的な構造により、複雑なクエリを効率的に処理できます。スター結合データベースのクエリ最適化は、シンプルで予測可能かつ制御可能です。
拡張性。ディメンションモデルはスケーラブルで、予期せぬ新しいデータにも容易に対応できます。既存のテーブルは、新しいデータ行をテーブルに追加するか、SQLのALTER TABLEコマンドを実行するだけで、その場で変更できます。データウェアハウス上で動作するクエリやアプリケーションは、変更に対応するために再プログラミングする必要はありません。古いクエリやアプリケーションは、異なる結果を生成することなく引き続き実行されます。しかし、正規化モデルでは、データベーステーブル間の複雑な依存関係があるため、各変更を慎重に検討する必要があります。

次元モデル、Hadoop、ビッグデータ

Hadoopや同様のビッグデータフレームワークにおいても、ディメンションモデルの利点は依然として享受できます。ただし、Hadoopの一部の機能により、ディメンションモデリングの標準的なアプローチを若干調整する必要が生じます。

Hadoopファイルシステムは不変です。データの追加はできますが、更新はできません。そのため、ディメンションテーブルにはレコードを追加することしかできません。HadoopのSlowly Changing Dimensions がデフォルトの動作になります。ディメンションテーブルで最新のレコードを取得するには、3 つの方法があります。1 つ目は、ウィンドウ関数を使用して最新のレコードを取得するViewを作成することです。2 つ目は、最新の状態を再現する圧縮サービスをバックグラウンドで実行することです。3 つ目は、ディメンションテーブルを HBase などの可変ストレージに保存し、2 種類のストレージ間でクエリを連携させることです。
HDFS ではデータが分散されるため、データの結合はコストがかかります。分散リレーショナルデータベース ( MPP ) では、同じプライマリキーと外部キーを持つレコードをクラスタ内の同じノードに配置できます。これにより、非常に大きなテーブルの結合が比較的安価になります。結合を実行するためにネットワークを介してデータを転送する必要はありません。これは Hadoop と HDFS では大きく異なります。HDFS では、テーブルは大きなチャンクに分割され、クラスタのノード全体に分散されます。個々のレコードとそのキーがクラスタ全体にどのように分散されるかを制御することはできません。その結果、Hadoop で 2 つの非常に大きなテーブルを結合すると、データがネットワークを介して転送される必要があるため、非常にコストがかかります。可能な限り結合は避けるべきです。大きなファクトテーブルとディメンションテーブルの場合は、ディメンションテーブルを直接ファクトテーブルに非正規化できます。2 つの非常に大きなトランザクションテーブルの場合は、子テーブルのレコードを親テーブル内にネストし、実行時にデータをフラット化できます。

文学

キンボール、ラルフ；マーギー・ロス（2013）。データウェアハウスツールキット：ディメンションモデリングの決定版ガイド（第3 版）。ワイリー。ISBN 978-1-118-53080-1。
ラルフ・キンボール（1997）。「次元モデリング宣言」。DBMSとインターネットシステム。10 （9）。
マーギー・ロス（キンボール・グループ）（2005）。「ビジネスプロセスの特定」。キンボール・グループ、デザインのヒント（69）。 2013年6月12日にオリジナルからアーカイブ済み。

参考文献

1 2 3 Connolly, Thomas; Begg, Carolyn (2014年9月26日).データベースシステム - 設計、実装、管理への実践的アプローチ(第6版). Pearson. 第9部ビジネスインテリジェンス. ISBN 978-1-292-06118-4。
↑ Moody, Daniel L.; Kortink, Mark AR 「エンタープライズモデルからディメンションモデルへ：データウェアハウスとデータマート設計のための方法論」(PDF) . ディメンションモデリング。2017年5月17日のオリジナルからアーカイブ(PDF) 。 2018年7月3日取得。
↑ラルフ・キンボール、マーギー・ロス、ウォーレン・ソーンスウェイト、ジョイ・マンディ（2008年1月10日）。『データウェアハウスライフサイクルツールキット：データウェアハウスの設計、開発、展開のための専門家の手法』（第2版）。ワイリー。ISBN 978-0-470-14977-5。
1 2 3 Matteo Golfarelli; Stefano Rizzi (2009年5月26日).データウェアハウス設計：現代の原則と方法論. McGraw-Hill Osborne Media. ISBN 978-0-07-161039-1。
↑ラルフ・キンボール、マーギー・ロス（2002年4月26日）。『データウェアハウス・ツールキット：ディメンション・モデリング完全ガイド』（第2版）。ワイリー。ISBN 0-471-20024-7。
↑ラルフ・キンボール、マーギー・ロス、ウォーレン・ソーンスウェイト、ジョイ・マンディ、ボブ・ベッカー（2008年1月）。『データウェアハウスライフサイクルツールキット（第2版）』。ワイリー。ISBN 978-0-470-14977-5。

[ConBegg9-1] 1 2 3 Connolly, Thomas; Begg, Carolyn (2014年9月26日).データベースシステム - 設計、実装、管理への実践的アプローチ(第6版). Pearson. 第9部ビジネスインテリジェンス. ISBN 978-1-292-06118-4。

[MoodyKokink-1-2] Moody, Daniel L.; Kortink, Mark AR 「エンタープライズモデルからディメンションモデルへ：データウェアハウスとデータマート設計のための方法論」(PDF) . ディメンションモデリング。2017年5月17日のオリジナルからアーカイブ(PDF) 。 2018年7月3日取得。

[lifecycle-3] ラルフ・キンボール、マーギー・ロス、ウォーレン・ソーンスウェイト、ジョイ・マンディ（2008年1月10日）。『データウェアハウスライフサイクルツールキット：データウェアハウスの設計、開発、展開のための専門家の手法』（第2版）。ワイリー。ISBN 978-0-470-14977-5。

[Golfarelli-4] 1 2 3 Matteo Golfarelli; Stefano Rizzi (2009年5月26日).データウェアハウス設計：現代の原則と方法論. McGraw-Hill Osborne Media. ISBN 978-0-07-161039-1。

[refname4-5] ラルフ・キンボール、マーギー・ロス（2002年4月26日）。『データウェアハウス・ツールキット：ディメンション・モデリング完全ガイド』（第2版）。ワイリー。ISBN 0-471-20024-7。

[refname5-6] ラルフ・キンボール、マーギー・ロス、ウォーレン・ソーンスウェイト、ジョイ・マンディ、ボブ・ベッカー（2008年1月）。『データウェアハウスライフサイクルツールキット（第2版）』。ワイリー。ISBN 978-0-470-14977-5。

[1]

[2]

[3]

[4]

[ 5 ]

[ 6 ]