modelEditの設計
次元モデルは、ファクトテーブルを囲む次元を持つ星のようなスキーマまたはスノーフレークスキーマ上に構築されます。 スキーマを構築するには、次の設計モデルが使用されます。
- ビジネスプロセスの選択
- 穀物の宣言
- 次元の識別
- 事実の識別
ビジネスプロセスの選択
次元モデリングのプロセスは、次元モデルの使いやすさとデータウェアハウスの使用を保証するのに役立つ4段階の設計方法に基づいています。 設計の基本は、データウェアハウスがカバーすべき実際のビジネスプロセスに基づいています。 したがって、モデルの最初のステップは、モデルが構築するビジネスプロセスを記述することです。 これは、例えば、小売店での販売状況である可能性があります。 ビジネスプロセスを記述するには、プレーンテキストでこれを行うか、基本的なビジネスプロセスモデリング表記法（BPMN）または統一モデリング言語（UML）のような他の設計ガイドを使用することを選択することができます。
穀物を宣言
ビジネスプロセスを記述した後、設計の次のステップは、モデルの穀物を宣言することです。 モデルの粒度は、次元モデルが何に焦点を当てるべきかの正確な記述です。 これは、たとえば、”小売店からの顧客伝票の個々の広告申込情報”である可能性があります。 穀物が何を意味するのかを明確にするには、中央のプロセスを選択し、それを1つの文で記述する必要があります。 さらに、穀物（文）は、あなたの次元とファクトテーブルを構築しようとしているものです。 あなたのモデルが提供できるはずのものについて得られた新しい情報のために、このステップに戻って穀物を変更する必要があるかもしれません。
寸法を特定する
設計プロセスの第三のステップは、モデルの寸法を定義することです。 次元は4ステッププロセスの第2ステップからの穀物の内で定義されなければならない。 ディメンションは、ファクトテーブルの基礎であり、ファクトテーブルのデータが収集される場所です。 通常、寸法は日付、店舗、在庫などのような名詞です。 これらのディメンションは、すべてのデータが格納される場所です。 たとえば、dateディメンションには、年、月、曜日などのデータを含めることができます。
ファクトを識別する
次元を定義した後、プロセスの次のステップは、ファクトテーブルのキーを作成することです。 この手順では、各ファクトテーブル行に値を設定する数値ファクトを識別します。 このステップは、データウェアハウスに格納されているデータにアクセスできるため、システムのビジネスユーザーと密接に関連しています。 したがって、ファクトテーブルの行の大部分は数値であり、数量や単位あたりのコストなどの加算的な数値です。
次元正規化編集
次元正規化またはスノーフレーキングは、通常の非正規化された次元を平らにすることで知られている冗長な属性を削除します。 次元は補助的な次元で厳しく一緒に結合される。
Snowflakingは、データウェアハウスの多くの哲学とは異なるデータ構造に影響を与えます。複数の記述（ディメンション）テーブルに囲まれた単一のデータ（ファクト）テーブル
開発者は、多くの場合、いくつかの理由のためにディメンションを正規化しない。
- 正規化は、データ構造をより複雑にする
- テーブル間の結合が多いため、パフォーマンスが遅くなる可能性があります
- スペースの節約は最小限です
- ビットマップインデックスを使用することはできません
- クエリのパフォーマンス。 3NFデータベースは、分析を必要とする可能性のある多くの次元値を集計または取得するときにパフォーマンスの問題に悩まされます。 運用レポートのみを実行する場合は、運用ユーザーが非常に細かいデータを探しているため、3NFを使用することができます。正規化が有用である理由にはいくつかの議論があります。 階層の一部が複数のディメンションに共通している場合は、利点があります。 たとえば、地理的ディメンションは、customerディメンションとsupplierディメンションの両方で使用されるため、再利用可能です。