none
Performance RRS feed

  • Pergunta

  • Bom dia,

    Tenho um cubo que tem informação financeira.

    Num caso necessito da informação agregada e em outro caso preciso do detalhe da infromação.

    Ou seja,

    Exemplo:

    Num caso

    3211  3000

    No caso do detalhe tenho

    3211 1500

    3211 1500

    No segundo caso pode envolver novas dimensões.

    A questão é:

    Ao nível da performance é melhor ter duas tabelas fatuais em que uma contém o agregado e a outra contém o detalhe ou manter só uma com todos os registos e ligada a mais algumas dimensões.


    Obrigado, Élio Godinho

    terça-feira, 12 de novembro de 2013 11:41

Respostas

  • Élio, partindo da premissa que o valor agrupado bate com a soma do valor detalhado, basta manter apenas os valores detalhados em uma única fato.

    Provavelmente no detalhado ainda existe mais alguma informação que mostre qual a linha do lançamento, o número do título ou algo do tipo certo?

    Dessa forma, na hora do usuário visualizar, se ele quiser ver o agrupado da conta, ele irá apenas adicionar a conta na abstração, e caso queira a informação mais detalhada, irá adicionar o nº do título, a linha do lançamento, etc..

    No momento que ele for visualizar o consolidado, a performance será boa, porém conforme ele for realizando o drill down, poderá ficar mais demorado.

    O ideal seria a criação de alguns índices que ajudassem na performance, talvez até algum particionamento do seu cubo.


    "A vida é um paraíso, mas os homens não o sabem e não se preocupam em sabê-lo." Fiodor Dostoievski

    terça-feira, 12 de novembro de 2013 12:35

Todas as Respostas

  • Élio, de acordo com o seu exemplo, seria interessante manter uma única fato.
    Porém não entendi ao certo do que se tratam esses dados.
    Ao que se refere o '3211'? e o '1500'?


    "A vida é um paraíso, mas os homens não o sabem e não se preocupam em sabê-lo." Fiodor Dostoievski

    terça-feira, 12 de novembro de 2013 12:10
  • Olá,

    A conta 3211 numa base de dados vem com o valor agrupado no valor de 2500€.

    De uma outra fonte de dados vem detalhado, por exemplo ao nível da maturidade.

    conta 3211 valor 1500

    conta 3211 valor 1000

    Os dados da duas base de dados distintas vão entrar diretamente na mesma base de dados, o que pode provocar duplicação de valores.

    A solução poderia passar por ter duas tabelas de fatos em que uma tinha o agrupado e a outra teria o detalhe. Se mantiver tudo numa só teria que retirar as contas agrupadas que tivessem detalhe para não duplicar valor. Isto vai aumentar o número de registos.

    Por isso ao nível de performance qual seria a melhor opção ter duas com menos registos ou ter só uma com muitos registos.


    Obrigado, Élio Godinho

    terça-feira, 12 de novembro de 2013 12:24
  • Élio, partindo da premissa que o valor agrupado bate com a soma do valor detalhado, basta manter apenas os valores detalhados em uma única fato.

    Provavelmente no detalhado ainda existe mais alguma informação que mostre qual a linha do lançamento, o número do título ou algo do tipo certo?

    Dessa forma, na hora do usuário visualizar, se ele quiser ver o agrupado da conta, ele irá apenas adicionar a conta na abstração, e caso queira a informação mais detalhada, irá adicionar o nº do título, a linha do lançamento, etc..

    No momento que ele for visualizar o consolidado, a performance será boa, porém conforme ele for realizando o drill down, poderá ficar mais demorado.

    O ideal seria a criação de alguns índices que ajudassem na performance, talvez até algum particionamento do seu cubo.


    "A vida é um paraíso, mas os homens não o sabem e não se preocupam em sabê-lo." Fiodor Dostoievski

    terça-feira, 12 de novembro de 2013 12:35
  • Tens algum exemplo de particionamento?

    Obrigado, Élio Godinho

    terça-feira, 12 de novembro de 2013 13:33
  • Cara, não tenho nenhum exemplo aqui, mas dá uma olhada aqui e aqui 

    Isso já deve dar uma ajuda para começar.



    "A vida é um paraíso, mas os homens não o sabem e não se preocupam em sabê-lo." Fiodor Dostoievski

    terça-feira, 12 de novembro de 2013 13:43
  • Elio, bom dia.

    No exemplo citado:

    conta 3211 valor 1500

    conta 3211 valor 1000

    Existe algum dado que diferencie as duas linhas citadas? Se não existir, não faz sentido ter este dado neste nível de granularidade. É melhor vc trabalhar com o dado agrupado. Agora se tiver algum atributo que diferencie os dois dados (como por exemplo a data). Vc pode centralizar em apenas uma tabela. O SSAS já faz a agregação pra vc, da forma que desejar visualizar.

    A idéia do Kanaan em trabalhar com partições é boa, a partir do momento em que a sua tabela fato tem pelo menos uns 30 milhões de linhas pra cima (dependendo também da configuração do seu servidor).

    Abs.


    Eduardo Gomes - http://www.h1solucoes.com.br - Twitter: @edugp_sp

    quinta-feira, 14 de novembro de 2013 12:07