Selo de estado:
Preview(teto atual do produto) · Curso ACD-310 — Modelo semântico e modelagem dimensional · Aula 1 de 10 · Atualizado em 2026-10-04.
Objetivo#
Ao final desta aula você vai entender por que o modelo semântico é a única fonte de verdade dos seus números — nos dashboards e nas respostas da IA — e o papel das releases e do grounding em garantir isso.
Vídeo#
Identificador no manifesto: acd-310-01-por-que-um-modelo-semantico · duração-alvo 5 min · tela do produto: /dashboards.
Roteiro:
00:00–00:50— O sintoma: três gráficos, três números de "receita" diferentes · tela:/dashboards(lista de painéis da Aurora Varejo)00:50–02:00— O que é o modelo semântico: tabelas, relações e medidas descritas uma vez · tela:/dashboards/[id](editor, diagrama do modelo)02:00–03:10— Hoje: modelo por dashboard; amanhã (Preview): modelo central por workspace com releases imutáveis · tela:/dashboards/[id](painel "Modelo semântico do workspace")03:10–04:20— A mesma definição alimentando a IA: grounding em Q&A e text-to-SQL · tela:/ia(Perguntar aos dados)04:20–05:00— Por que isso importa para quem decide: um número, uma vez, auditável · tela:/dashboards/[id](card "Receita" citado no painel e na resposta da IA)
Conteúdo#
Antes de desenhar a primeira tabela, vale entender por que existe um modelo semântico — porque sem esse "porquê", as próximas nove aulas parecem burocracia.
O problema: cada gráfico decide "receita" de um jeito
Numa planilha ou num dashboard montado sem modelo, cada visual repete, à sua maneira, a mesma decisão de negócio. Um widget soma valor. Outro soma valor_liquido. Um terceiro esquece de excluir devoluções. O resultado é o clássico problema de BI: "o relatório do financeiro mostra R$ 1,2 milhão, o do comercial mostra R$ 1,35 milhão — qual está certo?" Nenhum dos dois está "errado" tecnicamente; eles só nunca combinaram o que "receita" significa.
O modelo semântico resolve isso decidindo, uma vez, como as tabelas se ligam e o que os números significam — para que todo visual, todo relatório e toda resposta de IA falem a mesma língua. Essa é a definição que a documentação de Modelo semântico usa, e é o fio que atravessa as dez aulas deste curso.
Onde isso vive no produto hoje
No ingestia.bi, o modelo vive dentro do editor de cada dashboard (/dashboards/[id], aba do modelo): lá você liga tabelas, define cardinalidade e cria medidas. É o que as aulas 2 a 7 deste curso ensinam a operar.
Mas um modelo por dashboard tem um limite: se dois painéis precisam da mesma "Receita líquida", cada um a reconstrói — e um dia elas divergem. Por isso existe, em Preview, o modelo semântico centralizado por workspace: a mesma definição de tabelas, relações e medidas publicada uma vez e consumida por referência por quantos dashboards precisarem. A publicação gera uma release imutável — uma cópia congelada, numerada (version = anterior + 1) e identificada por checksum — nunca um "sobrescrever silencioso". Editar de novo e publicar cria a versão seguinte; a anterior continua exatamente como estava, para quem ainda a referencia. É esse mecanismo de releases que as aulas 8 e 9 (biblioteca de medidas e governança) detalham.
Nota
O motor de relações, cardinalidade e medidas é GA-candidato — congelado por um conjunto de testes de referência, com resultado idêntico a cada execução. Já o modelo central por workspace (com releases) está em Preview: o mecanismo de publicação existe e é testado, mas o "encaixe" dele em todos os dashboards de um workspace ainda está em consolidação. Nenhuma das duas camadas é GA de produto — o teto continua Preview, como em toda a plataforma.
O mesmo modelo, agora alimentando a IA
A segunda metade do título desta aula — "vale no BI e na IA" — é o motivo pelo qual modelar bem compensa duas vezes. Quando existe um modelo semântico publicado, as capacidades de IA (texto para SQL, perguntas e respostas sobre o painel) usam os ids do modelo — tabelas, relações, medidas — em vez de adivinhar a partir de colunas cruas. A página Como a IA entende seus dados chama isso de grounding: dar ao modelo de linguagem a estrutura e as definições certas antes de pedir uma resposta.
O grounding traz dois ganhos concretos, direto da documentação:
- Menos ambiguidade. Se um termo como "receita" casa com duas medidas diferentes, a IA recusa responder antes de gastar token e pergunta qual delas você quis dizer — em vez de chutar uma.
- Verificabilidade. Se uma resposta citar um id que não existe no modelo publicado, a saída é descartada. SQL sem fundamento no modelo real não chega até você.
Na prática, isso quer dizer: a medida central Receita que você vai criar na aula 8 não é só um número bonito num cartão de KPI — é a mesma definição que a IA cita quando alguém pergunta "qual foi a receita de julho?" em /ia. Um modelo bem feito melhora o BI e a IA ao mesmo tempo, porque os dois bebem da mesma fonte.
Erros comuns de quem ainda não pensa em "modelo"
- Tratar modelo como etapa opcional. Para um gráfico isolado sobre uma tabela só, você pode ignorar modelagem — o wizard de texto para SQL resolve perguntas pontuais sem exigir um modelo. Mas qualquer dashboard que cruza duas tabelas ou mais já se beneficia de ter isso formalizado.
- Confundir "modelo do dashboard" com "modelo central do workspace". Hoje o primeiro é o caminho normal (GA-candidato no motor); o segundo é Preview e serve para quando várias dashboards precisam da mesma definição.
- Esperar que o modelo central seja automático. Publicar uma release não migra os dashboards existentes sozinho — o "encaixe" por referência é trabalho em andamento, por isso o selo continua Preview.
Por que isso justifica as próximas nove aulas
Cada conceito que vem a seguir — fato e dimensão (aula 2), a estrela da Aurora (aula 3), cardinalidade e anti-fan-out (aula 4), papéis e pontes (aula 5), calendário (aula 6), colunas calculadas e hierarquias (aula 7), a biblioteca de medidas (aula 8) e a governança de releases (aula 9) — existe para que a "uma verdade" desta aula seja real, não um slogan. A aula 10 fecha o curso te ensinando a diagnosticar quando algo nessa cadeia quebra.
Faça você mesmo#
Esta é uma aula de conhecimento (kind: conhecer): não há exercício operacional no console — o objetivo é consolidar o conceito antes de colocar a mão na massa a partir da aula 2.
- Abra
/dashboardse escolha um painel existente da Aurora Varejo (ou o de exemplo, se ainda não criou nenhum). - Observe dois visuais que usem a mesma grandeza (por exemplo, dois cartões de "receita" em páginas diferentes) e confira se os números batem.
- Abra a aba do modelo do dashboard e localize onde a medida que alimenta esses visuais está definida.
- Releia a seção "O mesmo modelo, agora alimentando a IA" acima e, se o workspace tiver IA habilitada, abra
/iae pergunte algo simples sobre um número que você já conhece (ex.: "qual a receita total?"). - Compare a resposta da IA com o número do dashboard.
Você terminou quando conseguir explicar, sem olhar a aula, por que um modelo semântico bem definido evita "cada relatório com um número diferente" tanto num gráfico quanto numa resposta de IA.
Checagem rápida#
Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.
Documentação relacionada#
Capacidades ensinadas#
C02.1 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".