Como Estragar um Painel

O título é um tanto quanto mal-educado, mas ele tem a virtude de ser claro.

Veja o dashboard abaixo, retirado de um caso real encontrado na Internet:

Como distribuir um controle ruim de forma inadequada.

Eu removi todos os nomes dos dials, apaguei os números e, para não facilitar, eu repliquei um mesmo dial algumas vezes. Eu quero apenas mostrar o layout, não os dados, porque eu não vou citar a fonte. Se o cliente desse painel não reclamou, então quem sou eu para apontar o dedo? E depois, duvido que o autor decida mudar, que o próprio cliente entenda a razão – acho mais provável eu ser atacado que agradecido (ou mesmo ignorado.) Mas a vocês, meus leitores fiéis que buscam algum conhecimento, eu deixo aqui a dica.

Stephen Few, no livro Information Dashboard Design, explica porque o controle de dial (ponteiro) é ruim: ele ocupa muito espaço para mostrar uma informação pequena, e é difícil de comparar. Para se ter uma idéia, todos os dials acima tinham os limites diferentes. A única informação tirada da visualização de quase todos ao mesmo tempo era… nenhuma.

Observe a figura de novo: você conseguiria, em um relance, dizer quais e quantos indicadores ultrapassaram cada meta? NÃO! É preciso olhar um por um, guardando os casos especiais de cabeça, rolar a página e continuar o processo!!! É ridículo! Um painel desses pode ser muito mais útil se colocado em um gráfico de barras! Ao invés de ajudar o cliente, e facilitar tudo, ele dá mais trabalho!

A página inteira tem 13 dials. Stephen Few sugere o uso de outro controle para esse tipo de apresentação: bullet graph. Usando o Gimp e imagens do bullet chart coletadas da Wikipedia, eu refiz o dashboard. Veja abaixo duas opções de como poderia ter sido:

Recuperando um painel estragado: bullets charts na vertical.

Recuperando um painel estragado: bullets charts na horizontal.

E agora? Pode me dizer, de um relance, quais e quantos indicadores ultrapassaram as metas? Quais requerem ação? Eu não apenas tornei o painel útil e prático (que são suas funções básicas – ser útil e ser prático), como ainda adicionei informação, enriquecendo a experiência!

E tudo que eu precisei foi deixar de lado uma idéia velha, que nunca funcionou direito. É isso.

Interface para o HSQLDB

Essa é fantástica! Um ex-aluno meu, e grande amigo, Rômulo Souza descobriu uma interface gráfica para o HSQLDB dentro do BI Server:

• Abra um terminal (DOS prompt no Windows)
• Mude para o diretório do HSQLDB: ./biserver-ce/data/lib
• Comande:

java -cp hsqldb-1.8.0.jar org.hsqldb.util.DatabaseManagerSwing --noexit

A seguinte janela vai se abrir:

Essas janelas se abrirão ao rodar o comando.

Preencha os campos da janela Connect com os seguintes dados:

• Setting name: Pentaho Hibernate
• URL: jdbc:hsqldb:hsql://localhost:9001/hibernate
• User: hibuser
• Senha: password

A janela de conexão deve ficar assim:

Janela de conexão com o HSQLDB.

Clique em Ok, e a janela de exploração do banco de dados aparecerá. Você pode examinar o layout das tabelas e executar comandos SQL diretamente, como por exemplo:

Exemplo de layout de tabela e SQL.

É isso! Grande dica, Rômulo!

Pentaho Marketplace

Uau!

http://wiki.pentaho.com/display/PMOPEN/Pentaho+BI+Server+Marketplace+Plugin

Fantástico! Imagine só, agora vai ser muito mais fácil criar e disponibilizar plugins, e talvez até vendê-los!

Parece que isso já é notícia velha, mas eu só fiquei sabendo agora, ao conversar com um amigo do trabalho.

Porque Data Vault

Essa é uma questão que ainda me tira o sono: se a sua empresa tem poucos departamentos e eles têm processos estáveis, se seu modelo dimensional tem poucas estrelas e está bem feito, se o seu ETL não dá pau, então porque adotar Data Vault?

Bom, para começo de conversa, se você está na condição acima, parabéns! Empresa com poucos departamentos nem é tão raro, mas processos estáveis, claros e bem conhecidos, sistemas de origem e dados bem comportados, ETL maduro… Nossa, isso é o sonho de qualquer gerente de BI!

Logo, porque alguma empresa iria querer Data Vault?

1. Porque os processos – que são a base da Modelagem Dimensional – nem sempre são claros.
2. Esses mesmos processos podem ser maduros, mas raramente são estáveis. Na melhor das hipóteses mudam para se adaptar a mudanças de legislação. Na pior, mudam para garantir a sobrevivência da empresa.
3. Nem sempre os processos são claramente entendidos. Quando o entendimento muda, o Modelo Dimensional precisa mudar.
4. Sistemas de origem e dados bem comportados são coisa rara. O mais comum é o contrário: dados errados pululando por sistemas selvagens.
5. Finalmente, ETL é um processo que demanda muita inteligência. Com tratamento de erros, demanda ainda mais. Quando algo muda na origem, o ETL precisa mudar, o que normalmente introduz novos bugs e novas necessidades de tratamentos de erros.

Isso já seria o suficiente para justificar a adoção de um Data Vault, mas não é esse o motivo que me levou a escrever esse post – acredite se quiser!

Semana passada estive com dois grandes amigos, que trabalham em um departamento da TI com projetos de BI. Eles me contaram que, em termos de modelagem de dados, eles têm uma visão muito mais pragmática que a da Modelagem Dimensional. Na visão corrente em um dos projetos, eles dizem que:

O Negócio X é o relacionamento de D1, D2, … e Dn.

E esse é o motivo que me levou a escrever hoje: mesmo havendo um processo de negócio que amarra os dados de uma forma que faz sentido para o negócio, no fundo tratam-se de dados que se inter-relacionam. Ou seja, um negócio ou assunto é registrado/caracterizado pelo relacionamento entre seus dados.

Não significa que eles descartam a Modelagem Dimensional. Pelo contrário, eles têm um Modelo Dimensional para o cliente explorar os dados, mas primeiro esses dados aterrisam numa camada intermediária, cujo desenho é muito parecido com um Data Vault.

E isso bate 100% com um dos paradigmas do Data Vault: como os dados serão consultados pelo cliente é uma questão para depois, normalmente melhor resolvida com um Modelo Dimensional. Primeiro é preciso guardá-los, e a seus relacionamentos. Esse é justamente o propósito do Data Vault: arquivar dados não-criticados, para preservá-los.

Assunto resolvido: um Data Vault é necessário porque os dados de uma organização se relacionam entre si, de maneiras que podem mudar ao longo do tempo. Para preservar os dados E a capacidade de analisá-los, precisamos de um Data Vault.

É isso!