Por que usar um modelo estrela em um dashboard de planejamento de obras?

01Separar eventos de suas classificações

Tabelas fato registram eventos ou observações, como medição diária por serviço. Dimensões descrevem projeto, serviço, fornecedor e calendário. Essa separação organiza os relacionamentos e evita repetir descrições em todas as linhas. O ponto de partida é definir o que cada linha representa; misturar medições mensais e diárias na mesma granularidade causa problemas de totalização.

02Entenda as condições do conceito

Um modelo estrela separa os dados em duas partes. A tabela de fatos guarda os eventos mensuráveis, como avanço, custo realizado ou horas trabalhadas, uma linha por ocorrência. As tabelas de dimensão guardam o contexto: calendário, obra, atividade, recurso e fornecedor. Cada dimensão se liga à tabela de fatos por uma chave, e o desenho lembra uma estrela, com a fato no centro. Esse desenho torna o modelo mais simples de entender, mais rápido de calcular e mais fácil de manter.

Cada dimensão filtra a tabela de fatos por meio de uma chave única. As medidas ficam simples, porque cada filtro segue um caminho previsível do lado de cima para o lado de baixo. A tabela de datas permite comparar meses, semanas e acumulados sem repetir lógica em cada visual. Os dados das atividades ficam guardados uma vez só, o que reduz o tamanho do arquivo e erros de digitação.

Novas análises podem ser feitas adicionando dimensões, sem reconstruir a tabela de fatos. Crie a dimensão de calendário, com uma linha por dia, cobrindo todo o período do projeto. Extraia as dimensões de atividade, obra e recurso a partir do cronograma e dos cadastros. Crie os relacionamentos de um para muitos, do lado da dimensão para o lado do fato, com filtro em uma direção.

Colocar todos os dados em uma tabela só, o que repete textos e infla o modelo. Criar relacionamentos em cadeia desnecessários, que confundem os filtros.

03Por que o modelo ajuda nos filtros

Uma dimensão de projeto pode filtrar medições e custos mantendo identificadores consistentes. O relatório pode comparar fatos sem ligar diretamente duas tabelas cheias de registros duplicados. Se a chave de serviço não for única na dimensão, a análise perde a estrutura esperada e pode exigir soluções que aumentam a ambiguidade.

04Exemplo comentado e interpretação

Defina o que cada linha da tabela de fatos representa, por exemplo, um avanço por atividade e data.

05Montar a base com rastreabilidade

Defina chaves, granularidade e datas de cada fato. Verifique unicidade nas dimensões e registros sem correspondência. Prefira direção de filtro que permita entender a propagação e teste um projeto conhecido. Guarde unidades e critérios de medição: somar metros, toneladas e percentuais numa mesma coluna não produz um avanço físico válido, mesmo num modelo estruturalmente correto.

06Caso guiado: descobrir a granularidade antes dos vínculos

A base de medição possui várias linhas por serviço e por dia. A dimensão de serviço deve identificar cada serviço de maneira única na granularidade adotada. Se códigos se repetem entre contratos, uma chave apenas pelo código pode ligar registros a uma classificação errada.

Defina identificadores consistentes e confira fatos sem correspondência. Relacione dimensões compartilhadas às fatos e teste um contrato conhecido, evitando ligar diretamente tabelas cheias de duplicações para obter um visual. O exercício mostra que a estrutura do modelo começa no significado da linha e da chave. Criar relacionamentos sem essa definição pode multiplicar valores ou filtrar informações de outra obra.

07Aplicação e conferência no projeto

Teste as medidas com segmentadores de obra e de período. Não criar tabela de datas e tentar comparar períodos com funções improvisadas.