3

2 つの異なる出所を持つデータがあります。一部は顧客からのもので、一部は別のベンダーからのものです。現在、このデータを物理的に "マージ" して、ほぼ 100 列、数万行の巨大なテーブルを作成し、2 つの次元を形式的に分離していません。したがって、実際にはこのテーブルをあまり使用できません。

この混乱を適切な、しかし小さなスター スキーマに再設計します。

2 つの次元は明らかです。たとえば、時間もその 1 つです。

顧客提供のデータは、多くの事実値を提供します。各ベンダーは、同じディメンションに適合する追加のファクト値を提供する場合と提供しない場合があります。

このファクト データはすべて同じ粒度です。すべてのベンダーから情報を取得することはあまりないため、「スパース」と呼ぶことができます。

これが私のジレンマです。

この 1 つのファクト テーブル (いくつかの null を含む) は、さまざまなソースから入力されたものですか?

それとも、このn +1 個のファクト テーブル (1 つは顧客から入力され、他は各ベンダーから入力されたもの) ですか?

それぞれのデザインには長所と短所があります。「マージ」または「個別にロード」の選択について、セカンドオピニオンが必要です。

顧客は、収益、コスト、カウント、重量、およびトランザクションの終了について知っているその他の情報を提供します。

ベンダー 1 は、一部のトランザクションに関する追加の詳細 (重量、コスト、期間) を提供します。他のトランザクションは、ベンダー 1 からの価値はありません。

ベンダー 2 は、トランザクションの一部について追加の詳細 (ボリューム、期間、長さ、外貨レート) を提供します。他のトランザクションは、ベンダー 2 にとって価値がありません。

一部のトランザクションには、両方のベンダーが含まれます。いくつかのトランザクションには、どちらのベンダーもありません。

ヌルを持つ 1 つのテーブル? 3つのテーブル？

4

3 に答える 3

3

私は単一のファクトテーブルに行きます。このアプローチの最大の長所は、クエリ時ではなくロード時にすべてのハードワークを任せることです。

于 2008-10-23T10:35:36.743 に答える
1

両方のソースが同じ粒度を共有しているので、答えは 1 つのファクト テーブルを持つべきだということだと思います。エンドユーザーが情報をどのように操作するかを考えてください。それが理にかなっており、これらのデータを同じ場所に配置することでビジネス レポートが恩恵を受けるのであれば、それがあなたの答えです。ただし、ファクト テーブルで null を避けるようにしてください。ゼロを入力できる場合 (そしてゼロがデータにとって意味がある場合、つまり温度を考える場合) は入力してください。ユーザーの混乱を避けることができ、TrickyNixon が指摘したように、集計の問題が発生します。

実際、あなたは「ブラウンフィールド」アプリケーションの素晴らしいポイントにいます。現在存在するものを見て、経験を活用してより良い設計を作成できます。これは、DW の生涯にわたって変わらないことを願って最良の穀物を選択するための最も重要な時期です。

于 2008-11-04T14:05:09.563 に答える
1

あなたが説明したことから、単一のファクトテーブルが進むべき道のように思えます。

ファクト テーブルには、時間単位 x トランザクション x 顧客 (?) があるように思えます。

以前の質問は、ベンダー データの一部が独自のディメンションの候補であるかどうかを実際に調べようとしていたものでした。それを決めるのはあなたに任せます。しかし、それは実際にはそうではありません。

Null ファクトは、(プラットフォームによっては) 集計中に警告をスローする可能性がありますが、誤解を招く可能性のあるゼロを入力するという別の方法はより悪いものです。

于 2008-10-28T19:55:29.507 に答える