Re: [pgbr-geral] Alimentação de ODS para Data Mini ng

2007-06-05 Por tôpico Alessandro Pedroso (Pedrosinho)
Tiago

Prefiro puxar os dados para a Staging Area através de uma ferramenta de 
integração de dados e ETL.

No Pentaho ela está presente através do Kettle que usa JDBC como interface.

http://www.pentaho.com/products/data_integration/

[]'s Pedrosinho



  - Original Message - 
  From: Tiago José Adami 
  To: Comunidade PostgreSQL Brasileira 
  Sent: Tuesday, June 05, 2007 9:11 AM
  Subject: Re: [pgbr-geral] Alimentação de ODS para Data Mining


  Certo amigos, a discussão foi ótima. Vocês já responderam as perguntas que eu 
iria fazer na seqüência ;).

  Entretanto, estou ainda projetando uma base OLAP e a dúvida esta na forma de 
replicar as informações do banco de dados OLTP para o ODS ou o banco de dados 
OLAP. 

  Estou usando como referência uma ótima literatura sobre bancos de dados 
distribuídos (Özsu e Valduriez [1]), mas mesmo mencionando situações de 
distribuição entre bases OLTP e/ou arquivos, não há explicação de como as 
informações devem ser transportadas em um ODS. 

  Procurei algumas referências a mais na internet [2] e acho que entendi.

  Vou citar um exemplo: para informações de faturamento, tenho uma VIEW que 
compõe várias tabelas, entre elas: NOTAS, ESTOQUE, CLIENTE, PRODUTO. O 
resultado da View é um cubo de informações (repetindo o numero da nota e o nome 
do cliente, por exemplo, para cada item da nota fiscal). 

  A minha dúvida era se, para armazenar as informações em um ODS, eu teria que 
replicar todas as tabelas na forma original até o ODS, ou se deveria criar 
tabelas com a estrutura das VIEWS, e replicá-las criando uma éspecie de view 
materializada (como foi citado). 

  Mas... eu havia esquecido do Staging Area.

  Me corrijam se eu estiver errado, mas o Staging Area é onde eu recebo as 
informações das diversas fontes de dados, não importando a forma (se são views 
materializadas, cópias das tabelas de um OLTP ou tabelas geradas a partir de 
.XLS) e a partir deste SA eu condenso e trabalho as informações de forma a 
dimensiona-las conforme as necessidades do DW, para somente depois alimentar o 
ODS, certo? É como trabalhar em camadas em um DW. 

  Resta saber a forma de trabalhar estas informações e como transportá-las, se 
eu poderia utilizar o PostgreSQL para fazer isso através do Slony, ou se as 
ferramentas de DW já o fazem (Pentaho, por exemplo).

  Eu dei uma olhada no Pentaho [3], mas não encontrei resposta para esta dúvida.

  E obrigado a todos que contribuíram com esta thread, foram contribuições 
muito valiosas.

  [1] 
http://www.livrariacultura.com.br/scripts/cultura/resenha/resenha.asp?isbn=0136597076sid=125186254965322314451732
  [2] http://www.dwbrasil.com.br/html/artbi_20030602.html 
  [3] http://www.pentaho.com/

  -- 
  Tiago J. Adami

  Dois Vizinhos - PR
  Brazil

  Use linux, and set your soul free! 


--


  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Re: [pgbr-geral] Alimentação de ODS para Data Mini ng

2007-06-04 Por tôpico Alessandro Pedroso (Pedrosinho)
Wallace,

Ao meu ver seu comentário está perfeito, concordo em número gênero e grau. 

Embora haja algumas exceções, a regra é esta.

[]'s Pedrosinho


  On 6/3/07, Leandro Guimarães Faria Corcete DUTRA
  [EMAIL PROTECTED] wrote:
   O que pouca gente se toca é que a normalização também oferece um
   desempenho decente para a grande maioria das consultas.  A chamada
   desnormalização (péssimo nome) ou modelagem dimensional atende apenas
   uma pequena percentagem, que pode ser extremamente importante nalguns
   casos; mas mesmo aí, nem sempre é necessário desnormalizar, visões
   materializadas podendo atender muita coisa.

  Acho que vc se confundiu nas coisas. O que acontece é exatamente o
  contrário do que vc falou. Uma base normalizada tem ótimas consultas
  para operações de atualização. Para geração de relatórios (mais
  eficientes) uma das alternativas é fazer desnormalização, entre outras
  temos tabelas: prejoined, report, mirror, split e combined. Vide
  Craig[1], capítulo Database Design no subtópico Denormalization.

   Não dá para comparar com Date, Darwen, Pascal e McGoveran.

  Claro, eles falam sobre coisas totalmente diferentes. Os autores que
  citei não falam sobre modelagem relacional, mas sobre modelagem
  dimensional.

  [1] 
http://www.amazon.com/Database-Administration-Complete-Practices-Procedures/dp/0201741296/ref=pd_bbs_sr_1/002-1032991-4965644?ie=UTF8s=booksqid=1180958116sr=1-1

  -- 
  wallace reis/wreis
  Núcleo de Biologia Computacional e
  Gestão de Informações Biotecnológicas/LABBI
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral