none
Projecto de BI - ETL SISS RRS feed

  • Pergunta

  • Ola, gostaria de saber qual a melhor forma de implementar meu projecto de BI. 

     

    Eu tenho um ERP com milhares de tabelas, mas apenas 20% são utilizadas. Sendo o objectivo do BI passa por controlar melhor as Vendas, Compras, Stock e RMA.

    Criei várias VIEWS que permitem ter acesso as Tabelas e Atributos que terão mais interesse para o estudo.

    Sendo assim, a minha fonte de dados operacional, em SQL Server 2008, serão as VIEWS. Neste sentido passarei agora a implementar o meu DATA WAREHOUSE, que já defini e construí em SQL Server 2008.

    De momento as tabelas de dimensões e factos encontram-se basias, pois pretendo fazer o processo ETL no SISS. Tenho 4 tabelas de Facto e cerca de 25 dimensões.

    Para tal estou com algumas duvidas, basicamente, como devo proceder para o fazer? Como devem ser definidos os Packages? Devo criar um package para cada dimensão e factos? e um package geral para correr todos os outros? Não sei como começar.

    E como funcionam e implementar as Slowly Changing Dimensions?

     

    Qual a melhor forma de o fazer?

    Preciso de alguma ajuda.


    quarta-feira, 21 de dezembro de 2011 16:03

Respostas

  • A imagem abaixo, é de um pacote que foi gerado de um pacote modelo, mas o pacote modelo nada mais é que a mesma estrutura, com data sources e variaveis já configurados, os selects dos data sources ou sql tasks e as tabelas de destination eu já configuro dinamicamente via variaveis, alimentando estas com o nome do meu pacote proprieamente dito, ou seja, se meu pacote se chama TB_FAT_EXEMPLO, a minha tabela também e chamará assim, logo a variável recebe o nome do pacote, e por sua vez o destination recebe a variável.

    Logo no próx. pacote que eu desenvolver, copio o modelo, renomeio ele, e já terei variaveis preenchidas, conexões feitas, destination preenchidos, o máximo que tenho é abrir os data flow para ele remapear, ou em algum caso particular adotar um tratamento especifico.

    quinta-feira, 22 de dezembro de 2011 12:17
  • Construo da mesma forma, na minha área de tratamento minha fato é composta de N campos varchar ou int que serão usados no cruzamento com as dimensões e as métricas, sempre númericas obviamente.

    Na área de publicação, que serve de base para minha solução analysis a minha tabela fato é composta exclusivamente de campos inteiros, númericos e afins, todos os campos de referencia são ligados às dimensões através de FKs... algo assim...

     

     

    Tratamento que eu aplico, em todas as tabelas fatos e dimensões:

    - Deduplicação.

    - Verificação de data type.

    - Analise de consistencia.


    E faço analise de volumetria, ou seja, se uma carga tem padrão de carregar 5 mil registros dia, se um dia ela só carregar mil registros provavelmente houve algum erro com minha fonte de dados, tento ser pro-ativo no erro...

     

    Se a resposta foi útil, qualifique!

    quinta-feira, 22 de dezembro de 2011 12:45

Todas as Respostas

  • Bom dia,

     

    Eu construo minhas soluções com pacotes individuais por dimensão e fato, criando antes um pacote modelo que sirva de base para os demais, logo, como digo à minha equipe, gastemos tempo pensando na modelagem do negócio e poupemos com o desenvolvimento. A opção por pacotes individuais é meramente para melhor administração e manutenção deles, seguindo a sua idéia de depois ter um pacote "pai" que chame todos os pacotes, de forma encadeada ou paralela, ai vai depender do seu cenários.

     

    Particularmente não utilizo o componente Slowly Changing Dimensions por motivo de performance, meus volumes de dados não apresentam um tempo de processamento esperado, controle de mudança eu faço via t-sql mesmo, para limitar meu range de carga eu antes de tudo gero binarys dos registros e comparo com binarys gerados pelos registros já existentes, de forma que, se um registro não sofreu alteração eu não carrego ele nem na query inicial, logo, nao gasto tempo, processamento, com ele, para no fim ser descartado ou não atualizar nada.

     

    Se a resposta foi útil, qualifique!

     

    Abraço,

    PG

    quinta-feira, 22 de dezembro de 2011 10:41
  • Eu construo minhas soluções com pacotes individuais por dimensão e fato, criando antes um pacote modelo que sirva de base para os demais, logo, como digo à minha equipe, gastemos tempo pensando na modelagem do negócio e poupemos com o desenvolvimento. A opção por pacotes individuais é meramente para melhor administração e manutenção deles, seguindo a sua ideia de depois ter um pacote "pai" que chame todos os pacotes, de forma encadeada ou paralela, ai vai depender do seu cenários.

     

    O que quer dizer com um pacote modelo que serve de base para os restantes?

    quinta-feira, 22 de dezembro de 2011 11:38
  • A imagem abaixo, é de um pacote que foi gerado de um pacote modelo, mas o pacote modelo nada mais é que a mesma estrutura, com data sources e variaveis já configurados, os selects dos data sources ou sql tasks e as tabelas de destination eu já configuro dinamicamente via variaveis, alimentando estas com o nome do meu pacote proprieamente dito, ou seja, se meu pacote se chama TB_FAT_EXEMPLO, a minha tabela também e chamará assim, logo a variável recebe o nome do pacote, e por sua vez o destination recebe a variável.

    Logo no próx. pacote que eu desenvolver, copio o modelo, renomeio ele, e já terei variaveis preenchidas, conexões feitas, destination preenchidos, o máximo que tenho é abrir os data flow para ele remapear, ou em algum caso particular adotar um tratamento especifico.

    quinta-feira, 22 de dezembro de 2011 12:17
  • Sim, eu nao estou costumado a fazer isso assim.

     

    Normalemente eu crio um package e fazia tudo no mesmo, a diferença é que crio data flow task para cada dimensao e fatos.

     

    Como constróis a tua tabela de factos? exemplifica-me por favor...

     

    Obrigado pela ajuda!! 

    quinta-feira, 22 de dezembro de 2011 12:30
  • Construo da mesma forma, na minha área de tratamento minha fato é composta de N campos varchar ou int que serão usados no cruzamento com as dimensões e as métricas, sempre númericas obviamente.

    Na área de publicação, que serve de base para minha solução analysis a minha tabela fato é composta exclusivamente de campos inteiros, númericos e afins, todos os campos de referencia são ligados às dimensões através de FKs... algo assim...

     

     

    Tratamento que eu aplico, em todas as tabelas fatos e dimensões:

    - Deduplicação.

    - Verificação de data type.

    - Analise de consistencia.


    E faço analise de volumetria, ou seja, se uma carga tem padrão de carregar 5 mil registros dia, se um dia ela só carregar mil registros provavelmente houve algum erro com minha fonte de dados, tento ser pro-ativo no erro...

     

    Se a resposta foi útil, qualifique!

    quinta-feira, 22 de dezembro de 2011 12:45
  • O print da tabela acima foi tirado do banco AdventuresWorkDW, é sempre bom ter essas bases e solução para referencias!
    quinta-feira, 22 de dezembro de 2011 12:46
  •  

     

    Me ajude aqui em outra coisa...Por favor.

     

    Eu tenho uma Tabela Armazem (NumeroArmazem(Numeric); NomeArmazem(varchar))

    Agora quero fazer o processo ETL para carregar a Dimensão.

    Neste caso eu preciso do Quê?

    Já tenho o package da DIMAmrazem e também já tenho a tabela DimensãoArmazem (ArmazemID(INT) e Nome(varchar)), vazia, no DW.

     

    Primeiro quero converter o NUmeroAramzem para Inteiro, depois quero considerar o SCD=1 (Overwrite)...etc..

     

    Como aconselhas a fazer?

     

    E este erro têm a ver com que?

     

    Cannot map columns of different types.

    Column 'IDArmazem' is of type 'System.UInt32' and column 'numarmazem' is of type 'System.Decimal'.

    Humm...ok

    Utiliza o ID da Base de dados operacional? ou cria um inteiro (identity) para cada chave dos factos e dimensão? está a perceber a minha duvida? 

     

    Vc como faz esta transformação?



    quinta-feira, 22 de dezembro de 2011 14:28