Owner, aprovador, certificação, release

Selo de estado: Preview (teto atual do produto) · Curso ACD-310 — Modelo semântico e modelagem dimensional · Aula 9 de 10 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai publicar uma release imutável do modelo semântico e certificar uma medida como número oficial do workspace.

Vídeo#

Identificador no manifesto: acd-310-09-governanca-do-modelo-releases · duração-alvo 6 min · tela do produto: /dashboards.

Roteiro:

1. 00:00–01:00 — Rascunho × release: por que publicar não é a mesma coisa que salvar · tela: /dashboards/[id] (editor do modelo, rascunho)
2. 01:00–02:30 — Publicando a versão 1: checksum e número de versão imutáveis · tela: /dashboards/[id] (ação "Publicar", confirmação com versão/checksum)
3. 02:30–03:30 — Quem pode publicar: papel de dono/admin · tela: /dashboards/[id] (aviso de permissão)
4. 03:30–05:00 — Certificando Receita em /linhagem: o selo que o leitor vê no topo do painel · tela: /linhagem (ação de certificação)
5. 05:00–06:00 — Editando de novo e publicando a versão 2, sem afetar quem ainda usa a v1 · tela: /dashboards/[id] (histórico de versões)

Conteúdo#

As oito aulas anteriores ensinaram a construir o modelo. Esta aula ensina a governá-lo — decidir quem pode mudar o quê, publicar com segurança e sinalizar ao leitor qual número é oficial. A referência principal é a seção "Modelo semântico centralizado por workspace" de Modelo semântico, complementada por Linhagem e impacto.

Rascunho × release: por que a diferença importa

Enquanto você edita o modelo, está trabalhando no rascunho (draftJson) — mudanças ali são suas, privadas, e podem ser desfeitas sem custo para ninguém. Publicar é um ato distinto: ele congela uma cópia do rascunho como uma release imutável, numerada (version = versão anterior + 1) e identificada por um checksum sha256. Releases não têm update nem delete — publicar de novo sempre cria uma versão nova; a versão anterior continua existindo exatamente como estava, para quem ainda a referencia.

Essa imutabilidade é o que permite a um dashboard "congelar" numa versão conhecida do modelo enquanto outro já está na versão mais recente — sem que uma mudança no modelo quebre painéis silenciosamente. É a mesma lógica que já vimos em outro contexto: assim como o motor de relações prefere recusar uma agregação a entregar um número inflado (aula 4), a governança de releases prefere manter versões antigas intactas a arriscar que uma edição em andamento vaze para quem já publicou um painel sobre o modelo.

Quem pode publicar

Editar o rascunho é um trabalho que vários papéis podem fazer, mas publicar uma release exige o papel de dono (owner) ou admin do workspace. Essa restrição existe porque publicar afeta, potencialmente, todo dashboard que vier a referenciar aquela versão — não é uma ação "reversível" como editar um rascunho.

Certificação: qual número é oficial

Publicar uma release do modelo é uma coisa; dizer ao leitor "este número específico já foi revisado e é confiável" é outra. Essa segunda camada é a certificação, na tela Linhagem e impacto (/linhagem):

• Você marca painéis, relatórios e conjuntos de dados (tabelas) como revisados.
• O selo de certificação aparece na lista do Workspace e no topo do painel, para quem está lendo saber que aquele número já passou por revisão humana.
• Cada certificação registra quem endossou e quando — não é um checkbox anônimo.
• Diferente de publicar o modelo (owner/admin), certificar é restrito ao dono (owner) — admin e os demais papéis veem o selo, mas não podem concedê-lo.

A tela /linhagem é área do dono: ela expõe pipelines e tabelas de todo o workspace, então um membro convidado que tentar acessá-la é levado de volta ao Workspace de BI.

Análise de impacto antes de mudar algo estrutural

A mesma tela /linhagem responde "se eu mexer nesta tabela, o que quebra?" — útil antes de qualquer mudança estrutural de dado, não só do modelo semântico. No exemplo da Comércio Aurora, o dono seleciona aurora_silver.vendas na análise de impacto e descobre que dois painéis, um relatório semanal e uma tabela derivada dependem dela — e só então decide se é seguro renomear uma coluna.

Como isso aparece no produto

• Publicar o modelo: ação dentro do editor do dashboard (/dashboards/[id]), aba do modelo — gera versão e checksum.
• Certificar: ação em /linhagem, restrita ao owner.
• Analisar impacto: também em /linhagem, disponível para owner e admin.

Erros comuns

• Confundir "salvar o rascunho" com "publicar". Salvar guarda seu trabalho em progresso; só publicar cria uma release que outros podem referenciar com confiança de que não vai mudar debaixo deles.
• Tentar certificar sem ser o dono. admin consegue ver e usar o modelo, mas o botão de certificação é exclusivo do owner — se não aparecer, confira o papel da conta.
• Mudar uma tabela sem checar o impacto primeiro. É exatamente o cenário que a análise de impacto existe para evitar: descobrir na terça-feira que o painel do cliente parou porque uma coluna mudou de nome na sexta.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /dashboards no console, editor de um painel, aba do modelo; depois /linhagem):

1. Com uma conta de papel owner/admin, abra o modelo do dashboard e confirme que está editando o rascunho.
2. Publique a release: confirme que ela ganha um número de versão e um checksum.
3. Edite o rascunho novamente (por exemplo, ajustando a descrição de uma medida) e publique de novo.
4. Confirme que a nova publicação criou version + 1, e que a versão anterior continua existindo sem alteração.
5. Abra /linhagem com uma conta owner e certifique a medida ou o painel que usa Receita.
6. Confirme que o selo de certificação aparece no topo do painel.
7. Na análise de impacto, selecione a tabela que alimenta Receita e revise a lista de painéis/relatórios afetados antes de considerar qualquer mudança estrutural.

Você terminou quando tiver duas versões publicadas do modelo (v1 e v2, ambas intactas) e um painel certificado exibindo o selo correspondente em /linhagem.

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#

• bi/modelo-semantico
• administracao/linhagem-e-impacto

Capacidades ensinadas#

C02.6 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".