Início / dba / Perguntas / 23365
Accepted
8kb
Asked: 2012-08-30 08:45:18 +0800 CST

A atribuição de chave substituta para uma tabela de fatos exige que os dados de origem tenham chaves naturais?

  • 772

Digamos que eu tenha um banco de dados OLTP simples com pedidos, produtos e clientes:

insira a descrição da imagem aqui

E a partir dele, estou construindo um data mart com uma tabela de fatos de pedidos, dimensão de produto, dimensão de cliente e dimensão de data:

insira a descrição da imagem aqui

Ao carregar a tabela de pedidos em fact_orders (digamos que eu estivesse usando uma transformação de pesquisa SSIS para atribuir as chaves substitutas), isso significa que a fonte de dados para os pedidos também precisaria ter os valores naturais de "chave estrangeira" que foram associados com o pedido no sistema OLTP?

Em outras palavras, os dados que estão sendo carregados viriam de uma consulta como essa?

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
ssis data-warehouse

1 respostas

  1. Best Answer

    Não tenho certeza se você precisa de chaves "naturais", mas provavelmente precisa manter um tipo de mapeamento de chaves. Portanto, você precisa entender quais relacionamentos são mapeados entre seus sistemas de origem e destino, identificar as chaves para esses relacionamentos e criar seus mapeamentos de chaves a partir daí.

    Eu tinha uma pergunta anterior sobre isso chamada "Qual é a melhor prática para mapear de chaves naturais para chaves baseadas em números inteiros? (ETL)" .

    EDIT: Até agora estou vendo pelo menos três, senão quatro mapeamentos.

    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.

    E, por último, vejo o order_id como sua chave para a tabela de fatos. Então eu iria

    OrdersToFactOrders (order_id,dim_date_id,dim_customer_id,dim_product_id)

    No meu caso, renomeei os campos para o mart com dim_field_id porque não queria colisão de nomes em minhas tabelas ou confusão sobre qual Id eles apontavam. Seu ETL precisa saber que CustomersToDim_Customers.dim_customer_id realmente mapeia para Dim_Customers.customer_id e que CustomersToDim_Customers.customer_id realmente mapeia para Customers.customer_id.

    Eu também estaria inclinado a incluir o order_number na tabela de mapeamento OrdersToFactOrders, mas isso porque gosto de ter dados de rastreamento para fins de auditoria. Facilita minha vida. Mas, com base no que você me disse, order_number e order_id são um para um, então a inclusão de order_number seria redundante e necessária apenas se você tiver uma paranóia perfeccionista para garantir que seus dados estejam corretos em ambos os lados (eu realmente gosto para garantir que A no lado A e B no lado B estejam realmente corretos após a conclusão do ETL.).

    • 3

relate perguntas