[解決済み] FactテーブルとDimensionテーブルの違い？

質問

ビジネスオブジェクトの本を読んでいて、ファクトテーブルとディメンションテーブルという言葉を目にしました。

DimensionテーブルとFactテーブルの違いは何ですか？

インターネット上の記事をいくつか読みましたが、はっきり理解できませんでした。

何か簡単な例があれば、より理解しやすくなりますか？

どのように解決するのですか？

この部分にお答えします。

ディメンジョン・テーブルがファクト・テーブルになり得るかどうかを理解しようとしたのです。 ということですか？

2つのタイプのテーブルは異なる理由で作成されるからです。しかし、データベース設計の観点からは、ファクト・テーブルが常に親としてディメンション・テーブルを持つように、ディメンション・テーブルも親テーブルを持つ可能性があります。また、ファクト・テーブルは集計されることがありますが、ディメンジョン・テーブルは集計されません。もう 1 つの理由は、ファクト・テーブルはその場で更新されないことになっていますが、ディメンジョン・テーブルは場合によってはその場で更新される可能性があるためです。

詳細はこちら

ファクト・テーブルとディメンジョン・テーブルは、一般にスター・スキーマと呼ばれる形式で表示されます。スター・スキーマの主な目的は、複雑な正規化テーブルのセットを単純化し、データ (異なるシステムからの場合もある) を非常に効率的な方法で照会できる 1 つのデータベース構造に統合することです。

最も単純な形では、ファクト・テーブル (例: StoreSales) と 1 つ以上のディメンジョン・テーブルが含まれます。各ディメンジョンのエントリには、0 個、1 個、またはそれ以上のファクト・テーブルが関連付けられています (ディメンジョン・テーブルの例。各ディメンジョン項目には、0,1 個以上のファクト・テーブルが関連付けられています (ディメンジョン・ テーブルの例 ： Geography, Item, Supplier, Customer, Time など)。ディメンジョンが親を持つことも有効で、その場合、モデルは "Snow Flake" 型になります。しかし、このような設計は結合が多くなり、パフォーマンスが低下するため、設計者はこのような設計を避けようとします。StoreSales の例では、Geography ディメンジョンは、列 (GeoID, ContenentName, CountryName, StateProvName, CityName, StartDate, EndDate) で構成される場合があります。

Snow Flakesのモデルでは、Geo情報のために2つの正規化されたテーブルを持つことができます。すなわち、コンテンツテーブル、国テーブルです。

Star Schemaでたくさんの例を見ることができます。また、スター・スキーマ・モデルの別のビューを見るには、こちらをご覧ください。 インモン vs キンブル . Kimbalは良いフォーラムを持っているので、こちらもチェックしてみてください。 キンブルフォーラム .

Edit: 4NFの例についてのコメントへの回答です。

• 4NFに違反するファクト・テーブルの例。

売上ファクト（ID、支店ID、SalesPersonID、ItemID、金額、TimeID)

• 4NFに違反しないファクト・テーブルの例。

売上集計（支店ID、合計金額）

ここでリレーションは4NFである

最後の例は、ちょっと珍しいですね。