none
Relacionamento das dimensões com a tabela fato RRS feed

  • Pergunta

  • Boa tarde Pessoal.

     

    Apresentei na semana passada a minha monografia da Pós-Graduação Latu Senso em Banco de Dados.

    Na minha apresentação um professor me questionou pq que eu fiz o relacionamento fisico entre as dimensões e a minha tabela fato. Achei estranho a pergunta dele.

    Ele está com a razão? Ele disse que o relacionamento é somente logico e não pode fazer o relacionamento físico porque vai deixar as consultas lentas.

    Eu não concordei com ele! Como que será a integridade dos dados sem o relacionamento físico!?

    Att,


    Fabio Jacomini
    quarta-feira, 13 de julho de 2011 17:21

Respostas

  • Boa tarde Fábio,


    Trabalho com BI há quase 5 anos, passando por 3 empresas diferentes, com filosofias de trabalho e metodologias de trabalho totalmente diferentes.

    Numa dessas empresas um dia o arquiteto pregou essa mesma teoria, de que o relacionamento físico não seria necessário, uma vez que essa relação que manteria a integridade deveria ser garantida no seu ETL, ou seja, se no momento de inserção nas suas dimensões e fatos não houvesse uma relação entre os dados o erro foi no processo de cargo que permitiu chegar até esse momento ou não está configurado para trabalhar com dados não identificados.

    Sobre as consultas ficarem mais lentas, isso não concordo, pode ficar mais lento no processo é justamente a carga, pois quando existe o relacionamento físico entre as tabelas, a existencia de constraints faz com que todo registro inserido passe por uma verificação.

    Eu, particularmente, gosto da construção com relacionamento físico, e nunca tive a necessidade por motivos de performance remover constraints, mas como boa parte das coisas na vida existem mais de um caminho que levam a um mesmo resultado, e as variantes para definir o melhor são muito mais abrangentes que simplesmente definir um como certo ou errado.

    Logo diria que seu professor foi parcialmente correto na pergunta, vocês poderiam ter feito sem o relacionamento físico, mas as brechas que isso daria de falha de carga e de performance em consulta diretamente no banco, e não na performance da carga, não consideraria pertinente.

     

    Abs,

    PG

    • Marcado como Resposta Fábio Jacomini terça-feira, 19 de julho de 2011 21:02
    quarta-feira, 13 de julho de 2011 18:23
  • Boa tarde Jacomini,

        Nunca ouvi falar em um DW modelado sem o relacionamento entre as tabelas. Com relação a deixar a consulta mais lenta é um engano do seu professor. Se tiver com o modo de armazenamento MOLAP por exemplo não vai influenciar de modo algum. Eu particularmente acredito que seu professor esteja ABSOLUTAMENTE EQUIVOCADO rsrsrs.. Vamos esperar mais alguns comentários.

     

     


    Nayron Araújo - Desenvolvedor BI - Setor de TI - Universidade Potiguar - UnP
    • Marcado como Resposta Fábio Jacomini terça-feira, 19 de julho de 2011 21:02
    quarta-feira, 13 de julho de 2011 17:36

Todas as Respostas

  • Boa tarde Jacomini,

        Nunca ouvi falar em um DW modelado sem o relacionamento entre as tabelas. Com relação a deixar a consulta mais lenta é um engano do seu professor. Se tiver com o modo de armazenamento MOLAP por exemplo não vai influenciar de modo algum. Eu particularmente acredito que seu professor esteja ABSOLUTAMENTE EQUIVOCADO rsrsrs.. Vamos esperar mais alguns comentários.

     

     


    Nayron Araújo - Desenvolvedor BI - Setor de TI - Universidade Potiguar - UnP
    • Marcado como Resposta Fábio Jacomini terça-feira, 19 de julho de 2011 21:02
    quarta-feira, 13 de julho de 2011 17:36
  • Boa tarde Fábio,


    Trabalho com BI há quase 5 anos, passando por 3 empresas diferentes, com filosofias de trabalho e metodologias de trabalho totalmente diferentes.

    Numa dessas empresas um dia o arquiteto pregou essa mesma teoria, de que o relacionamento físico não seria necessário, uma vez que essa relação que manteria a integridade deveria ser garantida no seu ETL, ou seja, se no momento de inserção nas suas dimensões e fatos não houvesse uma relação entre os dados o erro foi no processo de cargo que permitiu chegar até esse momento ou não está configurado para trabalhar com dados não identificados.

    Sobre as consultas ficarem mais lentas, isso não concordo, pode ficar mais lento no processo é justamente a carga, pois quando existe o relacionamento físico entre as tabelas, a existencia de constraints faz com que todo registro inserido passe por uma verificação.

    Eu, particularmente, gosto da construção com relacionamento físico, e nunca tive a necessidade por motivos de performance remover constraints, mas como boa parte das coisas na vida existem mais de um caminho que levam a um mesmo resultado, e as variantes para definir o melhor são muito mais abrangentes que simplesmente definir um como certo ou errado.

    Logo diria que seu professor foi parcialmente correto na pergunta, vocês poderiam ter feito sem o relacionamento físico, mas as brechas que isso daria de falha de carga e de performance em consulta diretamente no banco, e não na performance da carga, não consideraria pertinente.

     

    Abs,

    PG

    • Marcado como Resposta Fábio Jacomini terça-feira, 19 de julho de 2011 21:02
    quarta-feira, 13 de julho de 2011 18:23
  • Paulo Gomes,

    Também sou Professor de Cursos Universitários e de Pós-Graduação, concordo plenamente com seus comentários e observações.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
    sábado, 16 de julho de 2011 15:51
  • Paulo Gomes,

    Também sou Professor de Cursos Universitários e de Pós-Graduação, concordo plenamente com seus comentários e observações.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    Diga me uma coisa, se eu quizer implementar um DW, devo primeiro criar as dimensões, comas as respectivas chaves.

    Depois construo as de factos com as chaves que se encontravam na BD operacional, ou seja, mostrando um exemplo:

    Tenho as BD oepracional:

    -Cliente(idcliente, nome)

    -Empregado(idempregado, nome)

    -Produto (idproduto, nome, preçouni)

    -Encomendas(idEncomenda, idcliente, idempregado, valortotal, quantidadetotal, dataencomenda, dataentrega, ...)

    -Linhas de Encomenda(idEncolinha, idEncomenda, idproduto, preço unitario, quantidade, ...)

     

    O meu DW vai ficar assim:

    Construindo vários jobs:

    1- Dimensão Cliente:  BD cliente-> dimcliente

    2- Dimensão Produto:  BD produto-> dimprod

    3- Dimensão empregado:  BD empregado-> dimemp

    4- Dimensão Tempo: Script dim tempo e relacao com as duas datas em encomendas nos factos.

    5-Tabela de Factos: BDs (Encomendas e Linhas de Encomendas) onde fazemos o JOIN: Tabela de factos vendas com (idproduto, idcliente, idempregado, idtempo(Dataencomenda e DataEntrega), Preço de venda, Quantidade) 

     

    A construção da tabela de factos não implica um ligação directa com as dimensões. É assim que eu faço os meus DW.

    Neste caso não ha relacionamento fisico, pois não? apenas vai ser visto no cubo OLAP, com o cruzamento dos dados. 

    quinta-feira, 22 de dezembro de 2011 11:59