リレーショナルデータベースとディメンションデータベースの違いは何ですか？
OLAPとデータウェアハウジングについて学習しようとしています。リレーショナルモデリングとディメンションモデリングの違いについて混乱しています。ディメンションモデリングは基本的にリレーショナルモデリングですが、冗長/非正規化は可能です。データ？
たとえば、（product、city、＃sales）の過去の販売データがあるとします。私は次のことがリレーショナルな視点になることを理解しています。
製品|市| ＃Sales Apples、San Francisco、400 Apples、Boston、700 Apples、Seattle、600 Oranges、San Francisco、550 Oranges 、ボストン、500 オレンジ、シアトル、600
以下は、より次元の観点です：
製品|サンフランシスコ|ボストン|シアトル リンゴ、400、700、600 オレンジ、550、500、600
しかし、それでも両方の観点が同一のスタースキーマに実装されるようです。
ファクトテーブル：製品ID、地域ID、＃販売 製品ディメンション：製品ID、製品名 都市ディメンション：都市ID、都市名
そして、各ディメンションにいくつかの追加の詳細を追加し始めてから、違いが現れ始めます。たとえば、地域も追跡したい場合、リレーショナルデータベースは、すべてが正規化された状態を維持するために、別の地域テーブルを持つ傾向があります。
都市ディメンション：都市ID、都市名、地域ID 地域ディメンション：地域ID、地域名、地域マネージャー、＃地域店舗
次元データベースでは、非正規化により地域データを都市次元内に保持できますが、データをスライスしやすくするために：
都市ディメンション：都市ID、都市名、地域名、地域マネージャー、＃地域ストア
これは正しいです？
スタースキーマは、データのリレーショナルモデルとデータの次元モデルの交差点にあります。これは、実際にはディメンションモデルから開始し、リレーショナルモデルから開始する場合に取得するSQLテーブルに多少似たSQLテーブルにマッピングする方法です。
多くのリレーショナル設計方法論が正規化された設計、または少なくともほぼ正規化された設計をもたらすため、私は多少似ていると言います。スタースキーマは、完全な正規化とは大きく異なります。
完全な正規化から逸脱するたびに、結果としてデータ更新の異常が発生します。 （挿入、更新、削除の操作に関する1つのアンブレラを1つの傘の下に含めています）。これらの異常は、最初に使用したデータモデルとは何の関係もありません。
OLTP vs OLAPはここに関連します。更新の異常は、この2つの状況でパフォーマンスやプログラミングの難易度に異なる影響を与えます。
SQLデータベースのスタースキーマに加えて、その製品に固有の物理的な形式でデータを格納するディメンションデータベース製品があります。これらの製品では、ディメンションモデルの直接の実装や、製品に固有のインターフェイスを見るほどスタースキーマは表示されません。これらのインターフェイスの一部では、OLAP操作を完全にポイントアンドクリックすることができます。
質問から脱線したように、トランザクションベースのアプリケーションをサポートするOLTPデータベースとCognos PowerPlay内のデータキューブの間の中間ステップとしてスタースキーマを作成しました。標準ETL技術を使用して、 OLTPデータベースからスタースキーマへ、そしてスタースキーマからデータキューブへの複合転送は、実際にOLTPデータベースからデータキューブへの直接転送よりも優れていた。これは予想外の結果でした。
お役に立てれば。
簡単な言葉でOLTP正規化されたデータベースは、最も最適な「トランザクション」の観点で設計されています。データベースは、トランザクションシステムに最適に機能するように正規化されます。削除、挿入、更新、選択などのすべてのトランザクション操作は、トランザクションシステムで同等に評価されるため、任意の時点でそれらすべてに等しいまたは最適な重要性を与えるようにバランスがとられたデータベース構造の設計状態になります。
そして、正規化されたシステムが提供するもの..データ更新のために可能な最小更新、新しいエントリのために可能な最小挿入、カテゴリ削除などのための1箇所削除など（例えば、新しい製品カテゴリ）...これはすべて可能です。テーブル.....しかし、これは「選択」操作遅延の代償を伴います..しかし、（正規化）すべての操作に対して最も効率的なモデルではないことを述べました。インデックス作成などのデータ取得速度を向上させる
一方、次元モデル（主にデータウェアハウスの設計に使用されます）..データウェアハウスのように、データの選択....データの更新/挿入が定期的に発生する1種類の操作のみを重要視するために重要です。そしてその一回限りの費用。
正規化されたデータ構造を微調整して、選択のみが任意の時点で最も重要な操作になるようにしようとすると...最終的に非正規化されます（部分的に非正規化されます）。
- すべての外部キー1つの場所ファクト-ディメンション間ディメンション結合（つまり、マスターテーブルからマスターテーブルへの結合）.. snowflakeは同じディメンションを表します
- 理想的に設計された事実は数字のみを運ぶ..対策または外部キー
- ディメンションは、説明と非集計情報を保持するために使用されます
- データの冗長性は無視されます...しかし、まれにディメンション自体が大きくなりすぎる場合は.snowflakeデザインがオプションとして表示されますが、それでも回避できます
詳細については、このトピックに関する詳細な本をご覧ください。
エンタープライズデータウェアハウス（EDW）を保存するビジネスで主にリレーショナルモデルを使用しているため、ディメンションデータモデリングとリレーショナルデータモデリングの違いについて最近調べました。
Steve Hobermanの著書「Data Modeling Made Simple」によると、2種類のモデルの違いは次のとおりです。
- リレーショナルデータモデルは、ビジネスの一部（ビジネスプロセス）の仕組みに関するビジネスソリューションをキャプチャします
- ディメンションデータモデルは、ビジネスがどの程度うまくいっているかという質問に答えるためにビジネスが必要とする詳細をキャプチャします
リレーショナルモデルは、ビジネス上の質問に答える基盤としても使用できますが、戦術的なレベルで使用できると言えます。 「クレジット保留のために、顧客xの未履行状態の注文はいくつですか？」しかし、違いは、レポートの質問がテーブルの「ネイティブな粒度」を必要とする場所と、要約されたデータでレポートの質問に回答できる場合です。
上記の2つの例では、どちらも2つのテーブルのどちらも「ネイティブグレイン」で販売注文を保存していないため、ディメンションデータモデリングの実例です。したがって、販売注文を作成するビジネスプロセスをキャプチャしません。 2つのテーブルの唯一の違いは、2番目のテーブルで都市ディメンションがファクトテーブルに置き換えられていることです。
http://www.orafaq.com/node/2286 で見つかった説明は、リレーショナルスキーマからスタースキーマにアクセスするときに非常に役立つことがわかりました。
完全に正規化されたデータモデルを検討します。反対に、リレーショナルデータモデルを完全に非正規化して、非常に広い行を持つbig'olスプレッドシートのようなフラットレコードが1つだけになるようにします。次に、このフラットレコードから少しだけバックアップして、2レベルの深さのデータモデルを作成します。 1つの大きなテーブルと、大きなテーブルが指す複数の小さなテーブル。これはSTARスキーマです。したがって、真のスターデータモデルには2つの属性があり、常に2レベルの深さであり、真のスターモデルには常にモデルの焦点である1つの大きなテーブルのみが含まれます。