問題タブ [fact-table]

ファクト テーブルでは pk が必要ないという参考文献をいくつか聞いたことがあります。すべてのテーブルに pk が必要だと思います。

pk がなく、10 個以上の外部キーがない場合、ファクト テーブルの行をどのように理解できますか。

データ ウェアハウスのファクト ディメンション スキーマを設計したいのですが、ファクト テーブルにはいくつかの外部キー、Aid、Bid、Cid が必要です。それぞれディメンション テーブル A、B、C を参照してください。ただし、ディメンション テーブル C には一意のキー (Aid、Cid) があります。この場合、ファクト レコードを次元テーブル C に 2 つのキー (Aid と Cid) でリンクすることは可能ですか? または、主キーのみを含む別のディメンション テーブルを適用する必要がありますか? どうもありがとう！

私はデータ ウェアハウスとディメンション モデリングにまったく慣れていないため、いくつかの点を明確にする必要があります。現在、次の寸法があります。

• DimProducts - 製品に関する情報。
• DimMaterials - 製品に使用される材料に関する情報。
• DimLocation - さまざまな店舗の場所
• DimTime - 年、四半期、月、週、日の標準時間ディメンション。

ここで、ファクト テーブルに関する混乱が生じます。現在、以下の対策を講じています。

• 収益
• 経費

質問:

1. 純利益もメジャーにしたいのですが、これは計算メジャーなので、ファクト テーブルの列にする必要がありますか、それともレポート レベルで計算する必要がありますか? 計算されたメジャーに関する慣習については少しわかりません。
2. また、どのくらいの製品を製造できるかを計算できるように、ある時点で利用可能な原材料の数も知りたいです (たとえば、1 台の自転車に 2 つの車輪がある場合、3 月に 50 台の車輪が利用可能であるということは、25 台の自転車が生産されることを意味します)。 3月）。原材料の数量という事実を追加する必要がありますか?

質問 2 に間違ってアプローチしているように感じます。この問題に対処するには、別のファクト テーブルを作成する必要があります。私が正しい軌道に乗っているかどうかについてのアドバイス/ヒントを本当に感謝します. ありがとう！

SQL Server 2012 で次の構造のファクト テーブルを使用しています。

列に 100 のFILL FACTOR のクラスター化インデックスがあります。このテーブルに挿入されるデータは、ほとんどの場合、とDateの昇順です。DateMinuteNumber

1. 知りたい - 特定のシナリオで Id 列が必要かどうか パフォーマンスへの影響はありますか？または、安全に削除できますか。

2. また、列にクラスター化インデックスを使用するだけで十分かどうかDate(同じ日付、同じ日付、同じ分数のレコードが多数存在することになります)、または複数の列を組み合わせたクラスター化インデックスを使用する方がよいかどうかも知りたいです。また、どちらのアプローチのパフォーマンスとストレージへの影響は何ですか?

私はこれに慣れていないので、どんな助けでも大歓迎です。

顧客ディメンション テーブルがファクト テーブルよりも大きいデータ ウェアハウス プロジェクトに取り組んでいます。ディメンションとファクト テーブルは、CRM システムから作成されます。

ファクト テーブルは、手紙が顧客に送信されたり、顧客が支援を求めたりするなどのアクティビティを監視します。顧客の半分は活動がなく、残りの顧客は活動がほとんどありません。アクティビティを持っている顧客のほとんどは、単一のアクティビティを持っています。

スター スキーマがプロジェクトにとって最適なソリューションであるかどうかはわかりません。同様のプロジェクトに取り組んだことがありますか?その解決策は何ですか?

古いデータ ウェアハウスを調べていると、ファクトレス ファクト テーブル (Fact_contact) と Dim_Incident の間の異常な 1 対 1 の関係に遭遇しました。

通常、Fact_Contact はケース/チケット/問い合わせの記録に使用されます。一部の顧客は匿名です。したがって、一意のカウントに使用される uniqueCustRef および CustomerRef の「ファクト」があります。

ファクト テーブルとディメンション テーブルの 1 対 1 の関係は適切ではありません。それは推奨される解決策ですか？現在、なぜこのように設計されたのかについてのドキュメントはありません。

ありがとうございました。

スター スキーマ データ ウェアハウスにデータをインポートする方法を見つけるために、Web 上のあらゆる場所を検索しました。スター スキーマとデータ ウェアハウスの設計についてはオンラインで多くの情報が説明されていますが、データがどのように DW に読み込まれるかについては説明されていません。これが私がこれまでに行ったことです：

各選手の高校バスケットボールの統計を応用しようとしています。

私は持っている：

1. すべての選手の名前、身長、ポジション、背番号のリスト
2. すべての高校のリスト
3. すべてのスケジュールのリスト
4. 会議のリスト
5. 今年の各プレーヤーの統計 (ポイント、リバウンド、スティール、プレイしたゲームなど)。

統計は私のファクト テーブルであり、残りは私の暗いテーブルであると仮定します。

今、百万ドルの質問 - 一体どのようにしてデータをそのフォーマットに適切に変換するのでしょうか?

それらをそれぞれのテーブルに単純にインポートしようとしましたが、それらがどのように接続されているかわかりません。

例: 800 人のプレーヤーと 400 の学校があります。各学校には一意の ID (主キー) があります。プレイヤーを薄暗いプレイヤーにアップロードし、学校を薄暗い学校にアップロードします。では、それらをどのように接続すればよいでしょうか。

助けてください。前もって感謝します。とりとめのない申し訳ありません:)

OLTP データベースを使用してデータ ウェアハウスを構築しようとしていますが、最初にファクト テーブルを定義する必要があるのか​​、それともディメンションを定義する必要があるのか​​疑問に思っていました。

助けてください？

よろしくヨギ

PowerPivot を使用して金額を分析しようとしています。

データバス マトリックスを準備し、データ モデルを作成し、すべてのディメンション テーブルを作成して入力しました。

これで、ディメンションと金額のすべての外部キーを使用して、ファクト テーブルがどのように表示されるかがわかりました。

それとは別に、ソースファイルとしてCSVファイルがあります。この csv ファイルの各列は、ディメンション内の値 (行) に関連付けられており、最後の 3 列は分析値を持つ金額です。

ここでの問題は、この csv ファイルから、必要なすべての FK + 金額をファクト テーブルに入力する方法がわからないことです。