Lições que Falhamos em Aprender sobre DW

Se eu abri um blog, é porque eu acredito que tenho algo a acrescentar ao infinito que é a Internet. Para mim é um pecado particular trazer aqui o que outros já fizeram. Mas… há aquelas explicações tão claras e poderosas, tão iluminadoras, que eu estaria incorrendo em um pecado igual ao não dividir com vocês algo que me ajudou tanto.

E é sobre o post do Ian Nicholson que eu preciso contar: Data Warehousing: Lessons We Have Failed to Learn.

Ele lista e comenta um pouco sobre as principais pragas dos projetos de DW, de ontem, de hoje e de sempre. Não deixem de lê-lo e vocês se vêem como profissionais sérios do ramo de BI. Para dar um gostinho, eis a lista itemizada:

  1. User Adoption: a verdadeira métrica!
  2. Users Don’t Know What They Don’t Know: a verdade suprema!
  3. All BI Solutions Will Require Change: a verdade inevitável, e o maior obstáculo aos projetos!
  4. Everybody Loves Kimball: é óbvio, não fuja dele!
  5. Everybody Ignores Inmon and Linstedt: é óbvio, escape da ignorância, leia alguns livros!
  6. ETL Tools Do Not Build Data Warehouses: a bomba! Meu deus, como eu nunca percebi isso antes??

Eu já venho repetindo algumas dessas coisas (2, 3 e 4) há alguns anos, mas o item 6, para mim, caiu como uma bomba óbvia.

Como assim, ferramentas de ETL não constroem DWs?? E é óbvio que não! Um DW é, no mínimo,  um modelo de dados (físico e lógico, se quiserem), mais uma renca de regras de transformação (“regras de negócio”, mas eu abomino esse termo porque ele é um muleta emprestada de outro domínio, o transacional), mais um banco de dados físico. Um DW não é um processo de ETL, nem é um diagrama no é-ruim (hehe, ERWin, sorry), nem é a lista de requisitos – é muito mais. Não existe uma única ferramenta que gerencie um DW!! (Na verdade, o próprio Nicholson destaca que ele acreditava nisso até ver a empresa na qual foi trabalhar, a BI Ready; logo eu preciso conhecer esse produto também.)

E é isso. Esse post abriu minha mente mais um pouco. Recomendo fortemente que leiam-no.

Anúncios

Tabelas Boneco para Prompts no PRD

Recebi um problema novo para tratar, que já veio com solução. Me passaram um relatório a ser desenvolvido no Pentaho Report Designer (PRD) que deve ter vários prompts (parâmetros.) Alguns são caixas de texto simples, como nome do projeto, e outros vêm de consultas, como lista de departamentos. Dois ou três deles, porém, são listas que não vêm de nenhuma tabela. O PRD só popula drop-downs, radio buttons e check boxes a partir de um SQL (ou eu acredito que só faz assim – não investiguei muito mais.)

O fato é que eu precisava de uma consulta dummy (boneco) que retornasse algumas linhas, tais como “sim, não, talvez” para alimentar um radio-button. Como eu disse, recebi o relatório, e ele veio com um desses casos resolvidos. Eu examinei a consulta:

SELECT TEXTO,VALOR
FROM
(SELECT ‘Sim’ AS TEXTO,’1′ AS VALOR
UNION
SELECT ‘Não’AS TEXTO,’2’ AS VALOR
UNION
SELECT ‘Talvez’ AS TEXTO,’3′ AS VALOR) AS DUMMY
ORDER BY 2

Oras! Essa eu não sabia! É uma tabela dummy!! A consulta foi escrita para Postgres, mas com certeza existem comandos equivalentes para MS SQL Server, Oracle, MySQL e outros bancos.

Genial, não? :-) E nem fui eu quem fez isso!

Então é assim: sempre que precisar de uma lista que não existe em uma tabela para popular um prompt no PRD, construa a consulta boneco acima e seja feliz.

É isso.

ADENDO: a consulta tinha dois erros, um de nome de campo e outro de aspas simples em volta dos valores. Corrigido. Nada como tomar o próprio remédio…