web-dev-qa-db-ja.com

ファクトテーブルの代理キー割り当てでは、ソースデータに自然キーが必要ですか？

簡単なOLTP注文、製品、顧客のデータベースがあるとします：

enter image description here

それから、注文ファクトテーブル、製品ディメンション、顧客ディメンション、および日付ディメンションを含むデータマートを構築しています。

enter image description here

注文テーブルをfact_ordersに読み込むとき（たとえば、SSISルックアップ変換を使用して代理キーを割り当てていたとしましょう）は、注文のデータのソースにも、関連付けられた自然な「外部キー」値が必要であることを意味しますかOLTP system？

つまり、読み込まれているデータは次のようなクエリから取得されますか？

SELECT 
  order_date,                   -- needed to get date surrogate key
  customer_name,                -- needed to get customer surrogate key
  product_name,                 -- needed to get product surrogate key
  order_number,                 -- denegenerate dimension,
  qty_ordered AS order_qty,     -- measure
  total_amount AS order_amount  -- measure
FROM orders o 
  INNER JOIN customers c 
    ON o.customer_id = c.customer_id
  INNER JOIN products p 
    ON o.product_id = p.product_id
ssisdata-warehouseetlfacttabledimension
3
8kb

「自然な」キーが必要かどうかはわかりませんが、おそらく、種類のキーマッピングを維持する必要があります。したがって、ソースシステムとターゲットシステムの間でどのような関係がマッピングされているかを理解し、それらの関係のキーを識別して、そこからキーマッピングを構築する必要があります。

これについて "自然キーから整数ベースのキーへのマッピングのベストプラクティスは何ですか？（ETL）" について以前に質問しました。

編集：これまでのところ、4つではなくても少なくとも3つのマッピングが表示されています。

CustomersToDim_Customers (customer_id, dim_customer_id)
ProductsToDim_Products (product_id, dim_product_id)
OrderDatesToDim_Date (order_date, date_id) or (map_id,order_date,date_id) if you want to use a key to map.

そして最後に、order_idをファクトテーブルのキーとして表示します。だから私は行きます

OrdersToFactOrders (order_id,dim_date_id,dim_customer_id,dim_product_id)

私の場合、マートのフィールドの名前をdim_field_idに変更しました。これは、テーブル内での名前の衝突や、フィールドが指しているIDの混乱を避けたいためです。 ETLは、CustomersToDim_Customers.dim_customer_idが本当にDim_Customers.customer_idにマップされ、CustomersToDim_Customers.customer_idが本当にCustomers.customer_idにマップされることを知っている必要があります。

また、OrdersToFactOrdersマッピングテーブルにorder_numberを含めるように半傾斜させますが、これは、監査目的でデータを追跡したいためです。私の生活を楽にします。しかし、あなたが私に言ったことに基づいて、order_numberとorder_idは1対1であるため、order_numberを含めることは冗長であり、完全主義のパラノイアがあり、データが両側で正しいことを確認する場合にのみ必要です（私は本当に好きです） ETLが完了した後、サイドAのAとサイドBのBが本当に正しいことを確認します。

3
Chris Aldrich