Como criar tabela de fatos do histórico?

9

Eu tenho algumas entidades no meu data warehouse:

  1. Pessoa - com os atributos personId, dateFrom, dateTo e outros, esses podem ser alterados, por exemplo, sobrenome, data de nascimento e assim por diante - mudando lentamente a dimensão

  2. Documento - documentId, número, tipo

  3. Endereço - addressId, cidade, rua, casa, apartamento

As relações entre (pessoa e documento) são um-para-muitos e (pessoa e endereço) é muitos-para-muitos.

Minha meta é criar uma tabela de fatos de histórico que possa responder às seguintes perguntas:

  1. Quais pessoas com quais documentos viviam no endereço definido em uma data definida?

2, Que histórico de residentes tem endereço definido no intervalo de tempo definido?

Isto não é apenas para o que o DW é projetado, mas eu acho que é a coisa mais difícil no design do DW.

Por exemplo, Miss Brown com personId = 1, documentos com documentId = 1 e documentId = 2 foram mantidos no endereço com addressId = 1 desde 01/01/2005 a 02/02/2010 e depois movidos para addressId = 2 onde foi vivido desde 02/03/2010 até a data atual (NULL?). Mas ela mudou o sobrenome para Mrs Green desde 04/05/2006 e seu primeiro documento com documentId = 1 para documentId = 3 desde 06/07/2007. Mr Black com personId = 2, documentId = 4 foi vivido em addressId = 1 desde 02/03/2010 até a data atual.

O resultado esperado em nossa consulta para a pergunta 2, em que addressId = 1 e o intervalo de tempo desde 01/01/2000 até agora, deve ser como:

Linhas:

last_name="Brown", documentId=1, dateFrom=01/01/2005, dateTo=04/04/2006

last_name="Brown", documentId=2, dateFrom=01/01/2005, dateTo=04/04/2006

last_name="Green", documentId=1, dateFrom=04/05/2006, dateTo=06/06/2007

last_name="Green", documentId=2, dateFrom=04/05/2006, dateTo=06/06/2007

last_name="Green", documentId=2, dateFrom=06/07/2007, dateTo=02/01/2010

last_name="Green", documentId=3, dateFrom=06/07/2007, dateTo=02/01/2010

last_name="Black", documentId=4, dateFrom=02/03/2010, dateTo=NULL

Eu tive uma ideia para criar uma tabela de fatos com chave composta (personId, documentId, addressId, dateFrom), mas não tenho ideia de como carregar essa tabela e depois obter o resultado esperado com essa estrutura.

Ficarei contente por qualquer ajuda!

    
por Argnist 21.05.2011 в 09:54
fonte

1 resposta

3

Pergunta interessante @Argnist!

Então, para criar uma linguagem comum para o meu exemplo, você quer um

  • DimPerson (PK = kcPerson, chave de sugestão para pessoas únicas = kPerson, tipo 2 dim)
  • DimDocument (PK = kcDocument, chave de sugestão para documentos exclusivos = kDocument, tipo 2 dim)
  • DimAddress (PK = kcAddress, sugestão de chave para endereços únicos = kAddress, tipo 2 dim)

Um colega escreveu um pequeno blog sobre o uso de duas chaves substitutas para explicar a obscuridade acima ' Usando duas chaves substitutas em dimensões '.

Eu sempre adiciono DimDate com PK na forma yyyymmdd para qualquer data warehouse com colunas de atributos extras.

Então você teria sua tabela de fatos como

  • FactHistory (FKs = kcPerson, kPerson, kcDocument, kDocumento, kcPerson, kPerson, kDate) mais quaisquer medidas adicionais.

Em seguida, juntando-se aos "kc" você pode mostrar as informações atuais da dimensão Pessoa / Documento / Endereço. Se você entrou nos "k" s, pode mostrar as informações históricas da dimensão Pessoa / Documento / Endereço.

A desvantagem disso é que essa tabela de fatos precisa de uma linha para cada combinação de pessoa / documento / endereço / data. Mas é realmente uma tabela muito estreita, uma vez que a tabela tem apenas um número de chaves estrangeiras.

A vantagem disso é que é muito fácil consultar os tipos de perguntas que você estava fazendo.

Como alternativa, você pode ter sua tabela de fatos como

  • FactHistory (FKs = kcPerson, kPerson, kcDocumento, kDocumento, kcPerson, kPerson, kDateFrom, kDateTo) mais quaisquer medidas adicionais.

Isso é obviamente muito mais compacto, mas a consulta se torna mais complexa. Você também pode ver a tabela Fact para facilitar a consulta!

A escolha da solução depende da frequência de alteração dos dados. Eu suspeito que isso não mudará tão rapidamente, então o design alternativo da tabela de fatos pode ser melhor.

Espero que ajude.

    
por Marcus D 27.05.2011 / 17:23
fonte