40

OLAP とデータ ウェアハウジングについて学習しようとしていますが、リレーショナル モデリングとディメンション モデリングの違いについて混乱しています。ディメンション モデリングは基本的にリレーショナル モデリングですか?

たとえば、(製品、都市、売上高) に関する過去の売上データがあるとします。以下はリレーショナルな観点であることを理解しています。

製品 | 都市 | # 売上
リンゴ、サンフランシスコ、400
リンゴ、ボストン、700
リンゴ、シアトル、600
オレンジ、サンフランシスコ、550
オレンジ、ボストン、500
オレンジ、シアトル、600

以下は、より次元的な視点です。

製品 | サンフランシスコ | ボストン | ボストン | シアトル
りんご、400、700、600
みかん、550、500、600

しかし、それにもかかわらず、両方の観点が同一のスター スキーマに実装されるようです。

ファクト テーブル: 製品 ID、地域 ID、売上高
製品ディメンション: 製品 ID、製品名
City ディメンション: City ID、City Name

そして、違いが現れ始めるのは、各次元に追加の詳細を追加し始めるまではありません. たとえば、地域も追跡したい場合、リレーショナル データベースは、すべてを正規化するために、別の地域テーブルを持つ傾向があります。

City ディメンション: City ID、City Name、Region ID
地域ディメンション: 地域 ID、地域名、地域マネージャー、地域店舗数

次元データベースでは、データのスライスを容易にするために、非正規化によって地域データを都市次元内に保持できます。

City ディメンション: City ID、City Name、Region Name、Region Manager、# Regional Stores

これは正しいです？

4

4 に答える 4

23

スター スキーマは、データのリレーショナル モデルとデータの次元モデルが交差するところにあります。これは実際には、次元モデルから始めて、それをリレーショナル モデルから始めた場合に得られる SQL テーブルに似た SQL テーブルにマッピングする方法です。

多くのリレーショナル デザイン方法論は、正規化された設計、または少なくともほぼ正規化された設計になるため、多少似ていると言います。スター スキーマは、完全な正規化から大幅に逸脱します。

完全な正規化から逸脱するたびに、結果としてデータ更新の異常が発生します。(挿入、更新、および削除操作に関する異常を 1 つの傘の下に含めています)。これらの異常は、開始時のデータ モデルとは何の関係もありません。

ここでは、OLTP と OLAP の比較に関するコメントが重要です。これら 2 つの状況では、更新の異常がパフォーマンスやプログラミングの難易度に異なる影響を与えます。

SQL データベースのスター スキーマに加えて、その製品に固有の物理的な形式でデータを格納する次元データベース製品があります。これらの製品では、スター スキーマはあまり見られませんが、次元モデルの直接実装と、製品に特有の可能性があるインターフェイスが見られます。これらのインターフェイスの一部では、OLAP 操作を完全にポイント アンド クリックすることができます。

あなたの質問からの余談ですが、トランザクション ベースのアプリケーションをサポートする OLTP データベースと Cognos PowerPlay 内のデータ キューブとの間の中間ステップとして、スター スキーマを構築したことがあります。標準の ETL 手法を使用すると、OLTP データベースからスター スキーマへの転送とスター スキーマからデータ キューブへの転送を組み合わせた方が、OLTP データベースからデータ キューブへの直接転送よりも優れたパフォーマンスを示しました。これは予想外の結果でした。

お役に立てれば。

于 2010-05-09T21:02:04.913 に答える
20

簡単に言えば、OLTP 正規化データベースは、最適な「トランザクション」の観点から設計されています。データベースは、トランザクション システムに対して最適に動作するように正規化されています。私がトランザクションシステムの最適化と言うとき、削除、挿入、更新、選択などのすべてのトランザクション操作がバランスが取れており、いつでもそれらすべてに同等または最適な重要性を与えるデータベース構造の設計状態に到達することを意味します..トランザクション システムでは同等に評価されるためです。

そして、正規化されたシステムが提供するもの..データ更新のための最小限の更新、新しいエントリのための最小限の挿入、カテゴリ削除のための1箇所の削除など(たとえば、新しい製品カテゴリ)...これはすべて可能であり、作成マスターを分岐しますテーブル....しかし、これには「選択」操作の遅延が伴います..しかし、私が言ったように、その（正規化）すべての操作に対して最も効率的なモデルではありません..その「最適」...他の方法を取得すると言いましたデータのフェッチ速度を向上させる..インデックス作成など

一方、次元モデル (主にデータ ウェア ハウスの設計に使用) は、データの選択... データ ウェア ハウスのように、データの更新/挿入が定期的に行われる 1 種類の操作のみを重要視することを意味します。 .そしてその 1 回限りのコストです。

したがって、正規化されたデータ構造を微調整して、任意の時点で選択のみが最も重要な操作になるようにすると、最終的に非正規化された (部分的に非正規化された) 次元のスター構造になります。

  • すべての外部キーは 1 か所 Fact - ディメンション間の結合はありません (つまり、マスター テーブルとマスター テーブルの結合).snowflake は同じディメンションを表します
    • 理想的に設計されたファクトは数値のみを保持します.メジャーまたは外部キー
    • ディメンションは、説明と集計不可能な情報を運ぶために使用されます
    • データの冗長性は無視されます ...しかし、ディメンション自体が大きくなりすぎる場合はまれです.スノーフレーク デザインがオプションと見なされます..しかし、それでも回避可能です

詳細については、このトピックに関する詳細な書籍を参照してください。

于 2010-08-20T10:25:04.937 に答える