Skip to content

Receita: Calendário e Filtros Dinâmicos

Esta receita resolve um fluxo recorrente: fazer o filtro de data da Dashboard chegar aos Widgets, usar datas diferentes em Widgets diferentes (emissão em um, entrega em outro) e fazer cada Widget responder na sua própria granularidade (um por dia, outro pelo mês inteiro da data escolhida).

O exemplo condutor é um Fato Faturamento com duas datas: DATA_EMISSAO e DATA_ENTREGA.

Pré-requisitos

  • Uma Aplicação criada no Horus DataViz.
  • O Fato Faturamento já carregado no HorusDW, com as colunas DATA_EMISSAO, DATA_ENTREGA e VALOR.

Passo 1: Um único Fato e uma única data

Se a análise usa um Fato e uma só data, não é preciso Tabela Calendário. Basta definir um Filtro Padrão na Aplicação para que ela já abra na data desejada.

  1. Abra a edição da Aplicação e vá na Aba Geral.
  2. Em Filtros Padrão, adicione um filtro sobre a coluna de data do Fato (por exemplo DATA_EMISSAO).
  3. Salve. A Aplicação passa a abrir já filtrada, e o usuário ainda pode alterar o período durante a navegação.

TIP

O Filtro Padrão é reaplicado toda vez que a Aplicação é reaberta.


Passo 2: Fazer o filtro da Dashboard chegar a todos os Widgets

Quando há mais de um Widget (ou mais de um Fato), o filtro precisa de uma ponte: a Tabela Calendário. Ao filtrar pela Dimensão Calendário, o filtro se propaga para todos os Fatos conectados a ela.

  1. Crie a Tabela Calendário (veja o Passo 5).
  2. Na Aba Tabelas, ligue Calendário.DATA à coluna de data do Fato (Faturamento.DATA_EMISSAO).
  3. Nos Widgets e na Barra de Filtros da Dashboard, use Calendário.DATA (não a coluna de data do Fato). Assim um único filtro alimenta todos os Widgets.

Por que um KPI pode "ignorar" o filtro da Dashboard

Se um Widget tem um Filtro Pré-Aplicado de data próprio, esse filtro vale só para aquele Widget, independentemente do filtro global da Dashboard. É a causa mais comum de "mudei o filtro da Dashboard e o KPI não respondeu".

Para o KPI responder à Dashboard:

  • Remova o filtro de data fixo do próprio Widget, e
  • Garanta que ele consulta dados ligados ao Calendário, deixando o filtro global cuidar do período.

Se o Widget precisa mesmo de um período próprio derivado do filtro global, use a abordagem do Passo 4.


Passo 3: Datas diferentes em Widgets diferentes (Relacionamento Fantasma)

Para um Widget analisar por emissão e outro por entrega, mantenha uma única Tabela Calendário e cadastre uma chave de Relacionamento secundária. Veja o conceito em Relacionamento Fantasma.

  1. Na Aba Tabelas, selecione o Relacionamento entre Calendário e Faturamento.
  2. Clique em "+ Adicionar Chave" e inclua Calendário.DATA = Faturamento.DATA_ENTREGA. A primeira chave (DATA_EMISSAO) continua sendo a padrão.
  3. No Widget que deve usar a entrega, escreva a métrica com use():
sql
use([Calendário], [Faturamento].DATA_ENTREGA) SUM([Faturamento].VALOR)

Agora o filtro da Dashboard (sobre Calendário.DATA) alimenta os dois Widgets, cada um pela sua data.


Passo 4: Cada Widget na sua granularidade

Cenário do "quem for mês mantém mês": o usuário escolhe um dia no filtro da Dashboard, e um Widget configurado por mês mostra o mês inteiro daquela data.

Um filtro é um valor só. Filtrar Calendário.DATA em um dia restringe tudo àquele dia. Para um Widget reinterpretar essa seleção na sua própria granularidade, use duas peças de Expressões:

  1. Ler a data escolhida na Dashboard com a sintaxe <...>: <[Calendário]."DATA":START, CURRENT_DATE> devolve o início do período filtrado (ou CURRENT_DATE se não houver filtro).
  2. Reescrever o período com a Expressão Analítica ${ EXPRESSÃO, FILTRO } e as funções de data.

Exemplo (Widget que sempre mostra o mês da data selecionada):

sql
${
  SUM([Faturamento]."VALOR"),
  [Calendário]."DATA" BETWEEN
    MONTHSTART(<[Calendário]."DATA":START, CURRENT_DATE>)
    AND
    MONTHEND(<[Calendário]."DATA":START, CURRENT_DATE>)
}

Mapa de granularidade

Trocando as funções de data, o mesmo padrão cobre qualquer granularidade. Abreviando <[Calendário]."DATA":START, CURRENT_DATE> como <sel>:

Comportamento desejado no WidgetFiltro dentro do ${...}
Sempre o mês da data selecionada[Calendário]."DATA" BETWEEN MONTHSTART(<sel>) AND MONTHEND(<sel>)
Sempre o ano da data selecionada[Calendário]."DATA" BETWEEN YEARSTART(<sel>) AND YEAREND(<sel>)
Sempre a semana da data selecionada[Calendário]."DATA" BETWEEN WEEKSTART(<sel>) AND WEEKEND(<sel>)
Últimos 3 meses a partir da seleção[Calendário]."DATA" BETWEEN SUBMONTHS(<sel>, 3) AND <sel>
Últimos 12 meses a partir da seleção[Calendário]."DATA" BETWEEN SUBMONTHS(<sel>, 12) AND <sel>

Para combinar granularidade própria com uma data alternativa (entrega), use as duas técnicas juntas: use() para a chave e ${...} para o período.

TIP

A lista completa de funções (MONTHSTART, YEARSTART, SUBMONTHS, ADDYEARS, etc.) está em Funções de Data.


Passo 5: Criar a Tabela Calendário no ETL

A Tabela Calendário é gerada uma vez no HorusETL com um nó Python (Pandas). O script pronto, que cria um calendário dos últimos 5 anos com colunas de ano, mês, trimestre e dia da semana, está documentado no hub de modelagem:

➡️ Gerando uma Tabela Calendário

Depois de gerar e publicar a Tabela no DW, volte ao Passo 2 para ligá-la ao Fato.


Resumo

NecessidadeRecurso
Abrir já filtrado por uma dataFiltro Padrão na Aba Geral
Filtro da Dashboard chega aos WidgetsTabela Calendário + filtrar por Calendário.DATA
Widget ignora o filtro globalRemover Filtro Pré-Aplicado fixo do Widget
Datas diferentes por WidgetRelacionamento Secundário + use()
Granularidade própria por Widget<...> + ${...} + funções de data