Como um widget obtém dados

Antes de construir consultas, vale a pena saber o caminho que os dados percorrem. Explica várias coisas que de outra forma parecem arbitrárias.

O conjunto de dados

Um widget não lê "de uma tabela". Lê de um conjunto de dados que lhe pertence, com um nome (vendasMensais, indicadores, topProdutos) e uma consulta por trás.

O widget só vê o resultado: um conjunto de colunas com nome. Um gráfico com um conjunto que devolve mes e vendas oferece essas duas colunas no mapeamento do eixo e do valor. Não sabe que tabelas existem, nem que junções foram feitas.

É por isso que, no inspector, se começa sempre por dar um nome ao conjunto: é o nome que passa a identificar aqueles dados dentro do ecrã.

Um widget, vários conjuntos

A maior parte dos widgets tem um conjunto. Dois tipos têm vários:

• o KPI, porque cada indicador pode vir de uma consulta diferente;
• o Progresso vs limite, pela mesma razão.

Os conjuntos de todos os widgets do ecrã são juntos num registo único por nome. Isso significa que um conjunto declarado num widget pode ser consumido por outro — útil quando dois widgets mostram o mesmo número de formas diferentes, e desnecessario de outra forma.

Nomes únicos por ecrã

Dois conjuntos com o mesmo nome no mesmo ecrã colidem. Se um widget parece mostrar dados de outro, e quase sempre isto.

O que o navegador sabe

Este é o ponto que explica a arquitectura toda.

Quando um dashboard carrega, o navegador não recebe a definição da consulta. Não recebe nomes de tabelas, nem junções, nem SQL. Recebe apenas:

• o nome do conjunto e as colunas que ele devolve;
• se carrega automaticamente e de quanto em quanto tempo se refresca;
• a lista de valores que tem de resolver (o valor de um filtro, o parâmetro do ecrã, a linha seleccionada noutro widget).

Para obter dados, o navegador diz: deste dashboard, deste widget, o conjunto chamado vendasMensais, com estes valores. O servidor lê a definição autoritativa do ecrã do lado dele, aplica os valores e executa.

Três consequências práticas:

1. Ver dados não exige permissão de edição. Quem só vê nunca recebe nada que descreva a estrutura da base de dados.
2. Um dashboard público funciona sem sessão sem alcançar nada além daquele ecrã.
3. Não há SQL vindo do cliente. Mesmo no modo avançado, o SQL que corre é o que está gravado no ecrã.

Quando a consulta volta a correr

Uma consulta corre outra vez sempre que algo de que depende muda:

Mudanca	Efeito
Um filtro do dashboard muda de valor	Todas as consultas alcancadas por esse filtro recorrem
A selecção de um widget muda	Recorrem as consultas com uma condição ligada a essa selecção
Um parâmetro do ecrã muda	Recorrem as consultas que o usam
O intervalo de refrescamento passa	Recorre essa consulta
Carrega-se no botão de recarregar	Recorre tudo

Não há nada a programar para isto acontecer: a dependência é deduzida das condições da própria consulta.

Carregamento automático e refrescamento

Cada conjunto tem duas opções de comportamento:

Carregar automaticamente — ligado por omissão. Desligado, o conjunto só carrega quando o código o mandar carregar, o que serve para dados pesados que só interessam depois de uma escolha.

Refrescar a cada N segundos — desligado por omissão. Um dashboard de operação pode querer 30 ou 60 segundos; um relatório mensal não quer nenhum.

Refrescamento tem custo

Cada refrescamento é uma consulta a base de dados por cada widget. Num dashboard com dez widgets a 30 segundos são vinte consultas por minuto, por cada pessoa que o tenha aberto.

Limites

Linhas devolvidas por página	Até 5000, mesmo que a consulta peça mais
Tamanho de página por omissão	Definido em cada conjunto
Statements permitidos	Apenas leitura (SELECT)

O tecto de 5000 linhas não é uma limitação ao que se pode analisar — é um limite ao que faz sentido transferir para um navegador. Um gráfico com 5000 pontos já não se lê; o que se quer nesse caso e agregar mais.

A seguir

• O construtor de consultas — a interface
• Dimensões e medidas — o modelo de agregação
• Junções entre tabelas — cruzar tabelas