0

レストランの配達情報を含むデータウェアハウスを構築しています。データはSQLServer2005に格納されてから、SQL Server AnalysisServices2005キューブに配置されます。

配信情報は、次の表で構成されています。

FactDeliveres

  • BranchKey
  • DeliveryDateKey
  • プロダクトキー
  • InvoiceNumber（DD：縮退ディメンション）
  • 量
  • 単価
  • ラインコスト

ノート：

  • FactDeliveresの粒度は、請求書の各行です
  • 製品ディメンションには、サプライヤー情報が含まれます

そして問題：ファクトテーブルの主キーがありません。主キーは、各配信とProductKeyを一意に識別するものである必要があります。しかし、配達を一意に識別する方法はありません。

ソースOLTPデータベースには、すべての配信に固有のDeliveryIDがありますが、これはユーザーにとって意味のない内部IDです。InvoiceNumberはサプライヤーの請求書番号です。これは手動で入力されるため、重複します。

キューブでは、FactDeliveresのInvoiceNumberフィールドのみに基づいてディメンションを作成しました。つまり、InvoiceNumberでグループ化すると、（誤って）同じInvoiceNumberを持っているという理由だけで、2つの配信が組み合わされる可能性があります。

DeliveryID（DeliveryKeyと呼ばれる）を含める必要があると感じましたが、その方法がわかりません。

私もそうです：

  1. これをInvoiceNumberディメンションの基になるキーとして使用しますか？
  2. 新しい配信があるたびに増加するDimDeliveryを作成しますか？これは、DeliveryDate、Supplier、InvoiceNumberなど、一部の属性がFactDeliveriesから出てDimDeliveryに入るということを意味している可能性があります。

結局のところ、私はあなたに尋ねることができます：ソースデータベースに次の情報がある場合、Deliveriesキューブを作成するにはどうすればよいですか？

DeliveryHeaders

  • DeliveryID（PK）
  • 配送日
  • サプライヤーID（FK）
  • InvoiceNumber（手動で入力）

配達の詳細

  • DeliveryID（PK）
  • ProductID（PK）
  • 量
  • 単価
4

2 に答える 2

3

Quantity、UnitCode、InvoiceNumber、DeliveryID をすべてファクト テーブルに含めます。InvoiceNumber と DeliveryID は、すべての事実 (または非常に少数の事実) で変化するため、どちらも縮退ディメンションです。各注文に多数のアイテムがある場合は、それらを独自の次元に入れることができます。請求書に複数の配送がある場合、以下のモデルは 100% 正しいとは限りませんが、ほぼ一致します。Kimball をチェックしてください。彼は、このビジネス シナリオのスター スキーマの例を持っているかもしれません。

Fact table:
OrderDateID (not in your model, but probably should be, date dimension in a role)
DeliveryDateID (date dimension in a role)
SupplierID (supplier dimension surrogate key)
InvoiceID (invoice dimension surrogate key)
ProductID (product dimension surrogate key)
Quantity (fact)
UnitCost (fact)
InvoiceNumber (optional)
DeliveryID (optional)

通常の日付ディメンション テーブルと次のディメンションを使用します。

Supplier Dim:
SupplierID (surrogate)
SupplierCode and data

Invoice Dim:
InvoiceID (surrogate)
InvoiceNumber (optional)
DeliveryID (optional)

Product Dim:
ProductID (surrogate)
ProductCode and Data

(スター スキーマ) データ ウェアハウスは、OLTP データのように構造化されることはまったくないということを常に覚えておいてください。重要なのは事実と、それを説明するディメンションです。

于 2008-09-29T18:11:48.287 に答える
0

ファクトテーブルPKは、ほとんどの場合、代理キーです。各ファクトはいくつかの次元の一部であるため、ファクトには次元に対するFKがありますが、それ自体の実際のキーはありません。

配達ファクト（ラインアイテム）は支店に属し、製品があり、より大きな配達の一部であり、特定の日に発生します。4つの独立した次元のように聞こえます。

配信ディメンションには独自のPKがあり、請求書番号のディメンション属性があります。さらに、おそらく、全体としての配信の他の属性。

各デリバリーラインアイテムファクトは、1つのデリバリーとそのデリバリーの請求書番号に関連付けられています。

于 2008-09-29T19:42:18.880 に答える