Módulo 11 · Engenharia de Software · Aula 16

Integração com a
Interface Analítica

Camada semântica com definição única, contrato de consumo versionado, segurança testável por linha e desempenho medido, sobre a gold construída nas aulas anteriores.

Camada semântica Contrato Segurança por linha Latência p95

Computação 2 · Prof. Afonso Brandão · 23/09/2026

GoldFato e dimensões publicados
origem
SemânticaMétrica definida uma única vez
definição
ContratoSchema, versão e compatibilidade
interface
ConsumoPainel, API e exportação
decisão

Continuidade · o fecho do pipeline

O dado extraído, transformado e monitorado precisa chegar a quem o consome

Esta aula fecha o percurso construído desde a Aula 10. O que se decide aqui determina se todo o investimento anterior sustenta alguma decisão.

Aula 10Armazenamento
Aula 12Coleta e extração
Aula 13Transformação e carga
Aula 15Métricas e telemetria
Aula 16Interface analítica
O critério de sucesso da camada de consumo é a decisão que ela sustenta, verificada pelo uso efetivo das consultas publicadas. A quantidade de gráficos disponíveis não mede esse sucesso.

Roteiro · 120 minutos · uma hora de exposição, uma hora de prática

A primeira hora estabelece o critério, e a segunda publica a camada de consumo

A segunda hora é atividade em grupo: definir a métrica uma única vez, publicar o contrato, aplicar segurança por linha e medir a latência.

1ª hora · Bloco 01
20 min

Decisão e semântica

Quem consome e decide, e a métrica definida uma única vez.

1ª hora · Bloco 02
22 min

Serviço e contrato

Como o dado é servido, e o que a interface promete a quem consome.

1ª hora · Bloco 03
18 min

Segurança e desempenho

Acesso por linha testável, pré-agregação e latência medida.

2ª hora · Atividade
60 min

Card de trabalho

Camada semântica, contrato, segurança por linha e medição de p95.

Objetivo: projetar a camada de consumo com métrica de definição única, contrato versionado e segurança verificável, e provar as escolhas medindo latência e testando o acesso.

Bloco 1 · Quem consome e decide

A camada de consumo se projeta a partir da decisão que ela sustenta

Cinco atributos definem a interface antes de qualquer escolha de ferramenta.

1

Pergunta que o consumidor faz, escrita na linguagem dele.

2

Usuário que a faz, com o nível de autonomia técnica que possui.

3

Frequência com que a pergunta é feita, e em que momento do dia.

4

Ação que decorre da resposta, e o que muda conforme o valor obtido.

5

Tolerância de atraso aceita, que determina a frequência da carga.

Teste da decisão

Qual resposta faria o consumidor agir de outro modo?

O indicador cujo valor não altera nenhuma ação é informação sem consequência. Ele ocupa espaço no painel, consome carga para ser mantido e concorre pela atenção com o que importa.

Aplicação: para cada gráfico proposto pelo parceiro, escreva a ação que muda conforme o valor. O gráfico sem essa frase é candidato à remoção.

Projetar o painel a partir do dado disponível, e não da decisão a ser tomada. O resultado é um acervo de gráficos que ninguém consulta e que precisa ser mantido indefinidamente.

Bloco 1 · O problema

Três equipes calculam a mesma receita e chegam a três números

Nenhuma delas cometeu erro técnico. Cada uma adotou uma decisão razoável e não declarada.

Equipe comercial R$ 13,2 mi

Soma o preço dos itens de pedidos entregues, sem incluir frete, porque o frete não compõe a comissão de vendas.

Equipe financeira R$ 15,7 mi

Soma preço e frete dos pedidos entregues, enviados e faturados, incluindo os ainda não entregues, porque a receita é reconhecida no faturamento.

Equipe de dados R$ 13,5 mi

Soma o preço dos itens de todo pedido não cancelado nem indisponível, inclusive os ainda em processamento, porque considera receita tudo o que não foi desfeito.

Diagnóstico: a divergência decorre da ausência de uma definição única, sem defeito no pipeline. Enquanto cada relatório calcula a métrica no próprio SQL, a reunião discute qual número está certo em vez de discutir a decisão.
Resolver a divergência escolhendo um dos números na reunião. Sem a definição registrada em um único lugar, os três voltam a aparecer no mês seguinte.

Bloco 1 · Camada semântica

A métrica é definida uma única vez e consumida por todos os relatórios

A camada semântica é o lugar onde a regra de negócio deixa de ser SQL repetido e passa a ser artefato versionado.

-- a definição única, versionada e revisável CREATE OR REPLACE VIEW semantica.receita_entregue AS SELECT mes, regiao, categoria, sum(valor_total) AS receita, count(*) AS itens FROM gold.fato_item_venda -- recorte de status: a gold contém apenas itens entregues GROUP BY 1, 2, 3; -- metadado que acompanha a definição -- owner: financeiro | inclui frete: sim -- status: entregue | fuso: America/Sao_Paulo

Nome único e sem sinônimo concorrente em outro relatório.

Fórmula declarada, com o recorte de status explícito.

Granularidade mínima em que a métrica é válida.

Fuso aplicado, retomando a decisão da Aula 13.

Responsável que aprova mudanças na definição.

Versão, para que a série antiga continue interpretável.

Consequência prática: a mudança de definição passa a ser uma alteração revisável, com data de vigência registrada. A série histórica indica quando o critério mudou, em vez de apresentar um degrau inexplicado.

Bloco 2 · Serviço

Quatro formas de servir, escolhidas por latência, volume e autonomia

A mesma camada semântica pode ser exposta das quatro formas, e a escolha decorre de quem consome e com que frequência.

Consulta direta

latência variável

O painel consulta a gold a cada abertura. Sempre atual, e sujeito ao custo de varredura a cada acesso.

Poucos usuários com alta autonomia e perguntas exploratórias.

Tabela agregada

latência baixa e previsível

O resultado é pré-calculado na carga. Rápido e barato por acesso, ao custo de atualidade limitada à frequência da carga.

Muitos usuários com o mesmo conjunto de perguntas conhecidas.

API

latência controlada por contrato

Outro sistema consome o dado por interface versionada, com limite de requisições e paginação declarados.

Integração entre sistemas.

Exportação

latência do arquivo

Arquivo entregue em prefixo acordado. Simples e auditável, e cria cópia fora do controle de acesso do warehouse.

Entrega a terceiros e a processos externos.
Servir tudo por consulta direta sobre o fato no grão mais fino. O painel de trinta usuários passa a varrer o acervo inteiro a cada abertura, e o custo cresce com a adoção do próprio painel.

Bloco 2 · Contrato

O contrato declara o que a interface promete e o que pode mudar sem aviso

Sem contrato, toda alteração na camada de consumo é uma alteração potencialmente destrutiva para quem consome.

CláusulaO que declaraAlteração que exige nova versão
SchemaColunas, tipos e obrigatoriedade de cada campo publicadoRemover coluna, renomear ou estreitar o tipo
SemânticaO significado da métrica e o recorte aplicadoAlterar a fórmula ou o filtro de status
AtualidadeO atraso máximo entre o fato e sua disponibilidadeReduzir a frequência da carga
DisponibilidadeJanela de atendimento e limite de requisiçõesIntroduzir limite mais restritivo
CompatibilidadePor quanto tempo a versão anterior continua servidaEncerrar a versão antes do prazo declarado
O acréscimo de coluna é compatível; a remoção e a renomeação exigem nova versão. A regra é a mesma da evolução de schema do Avro, discutida na Aula 10.
O contrato precisa declarar também o prazo de convivência entre versões, porque é ele que permite ao consumidor planejar a migração.

Bloco 3 · Segurança

O controle de acesso por linha se verifica por teste executável

A política de acesso constitui controle somente depois de executada contra perfis reais e verificada por teste.

PerfilNorteSudesteNacional
Gerente Nortenão vênão vê
Gerente Sudestenão vênão vê
Diretoria
Cada célula é um teste: nove asserções executáveis, das quais quatro verificam ausência de acesso. As asserções de negação são as que mais faltam nas suítes de acesso e as únicas que revelam vazamento.

Identidade do usuário propagada até o motor, sem substituição por credencial de serviço.

Filtro por linha aplicado uma única vez, na camada semântica.

Mascaramento de coluna sensível conforme a classificação das Aulas 8 e 9.

Auditoria de quem consultou o quê, com retenção declarada.

Ambientes segregados, sem dado de produção em desenvolvimento.

Teste de negação executado a cada publicação, como os testes da Aula 13.

Aplicar o filtro de acesso dentro de cada painel. O painel seguinte é criado sem o filtro, e o dado restrito passa a ser servido sem que nenhuma política tenha sido alterada.

Bloco 3 · Desempenho

A latência percebida se mede em percentil

A média dilui as consultas lentas. O percentil 95 indica o tempo abaixo do qual ficam 95% das consultas, e portanto a espera que se repete em uma de cada vinte.

Pré-agregação

Cálculo na carga para leituras repetidas

A agregação na carga transfere o custo do momento da consulta para o da gravação. Retoma a decisão de layout da Aula 10, agora do ponto de vista do consumidor.

Poda e limite

A consulta lê apenas as partições necessárias

O filtro do painel precisa corresponder à coluna de partição da gold. Sem correspondência, cada abertura varre o acervo inteiro, e o pruning da Aula 10 não ocorre.

Observabilidade de consumo

Medir a consulta como se mede a carga

Latência p95, bytes varridos, taxa de erro e consultas por usuário. É a telemetria da Aula 15 aplicada à ponta em que o consumidor está.

Indicador de consumo: a proporção de consultas que ultrapassa o limite acordado com o consumidor. É o objetivo de nível de serviço da Aula 15, formulado agora sobre a leitura em vez da carga.
Otimizar apenas a latência média. O abandono da ferramenta decorre da experiência com as consultas mais lentas, que a média e a mediana ocultam.

Segunda hora · Card de trabalho em sala

Três perguntas sobre a camada que o grupo publica

Em grupo, sobre a silver e a gold das aulas anteriores: definir uma vez, proteger por linha e medir a leitura.

1

As três equipes chegam ao mesmo número?

Reproduza as três definições divergentes e depois unifique-as na camada semântica, com o critério declarado.

2

O gerente do Norte enxerga o Sudeste?

Implemente o filtro por linha e execute as nove asserções, incluindo as quatro que verificam negação.

3

Quanto a pré-agregação reduz a latência?

Meça o p95 da mesma pergunta servida por consulta direta e por tabela agregada.

10minGold e divergência
15minCamada semântica
10minContrato publicado
15minSegurança por linha
10minLatência medida

Segunda hora · Preparação · início dos 10 minutos da divergência

A gold é regenerada com região e data de compra

A gold da Aula 13 não tem região, e a da Aula 10 não tem data de compra; a camada semântica precisa das duas.

-- medir antes: a contagem da gold vigente SELECT count(*) AS itens_antes FROM gold.fato_item_venda; -- a regra da Aula 13 com a dimensão de geografia da Aula 10 CREATE OR REPLACE TABLE gold.fato_item_venda AS SELECT i.order_id, i.order_item_id, coalesce(d.product_id, 'DESCONHECIDO') AS product_id, coalesce(d.categoria, 'nao_informada') AS categoria, g.regiao, g.uf, p.comprado_em, date_trunc('month', p.comprado_em) AS mes, i.price, i.freight_value, i.price + i.freight_value AS valor_total FROM silver.item i JOIN silver.pedido p USING (order_id) JOIN gold.dim_geografia g ON g.customer_id = p.customer_id LEFT JOIN gold.dim_produto d USING (product_id) WHERE p.order_status = 'delivered'; -- medir depois: mesma contagem e nenhuma linha sem região SELECT count(*) AS itens_depois, count(*) FILTER (WHERE regiao IS NULL) AS sem_regiao FROM gold.fato_item_venda;
Consequência: a gold segue restrita a itens entregues e dispensa filtro de status; as três definições divergentes leem a silver, que preserva todos os status.

Segunda hora · Divergência · 10 minutos

As três definições produzem três números sobre o mesmo fato

Execute as três consultas sobre a silver e registre os valores antes de unificar. A diferença entre elas é o argumento a favor da camada semântica.

-- A. comercial: preço dos itens de pedidos entregues, sem frete SELECT round(sum(i.price), 2) AS receita_comercial FROM silver.item i JOIN silver.pedido p USING (order_id) WHERE p.order_status = 'delivered'; -- B. financeiro: preço e frete de tudo que foi faturado SELECT round(sum(i.price + i.freight_value), 2) AS receita_financeira FROM silver.item i JOIN silver.pedido p USING (order_id) WHERE p.order_status IN ('delivered', 'shipped', 'invoiced'); -- C. dados: preço de todo pedido não cancelado nem indisponível, sem frete SELECT round(sum(i.price), 2) AS receita_dados FROM silver.item i JOIN silver.pedido p USING (order_id) WHERE p.order_status NOT IN ('canceled', 'unavailable');
Registre os três valores. Na base estática da Olist, eles ficam próximos de R$ 13,2 mi, 15,7 mi e 13,5 mi; os cancelamentos simulados no CDC da Aula 12 alteram os três, sem eliminar a divergência, que decorre das definições. A tarefa seguinte consiste em declarar qual pergunta cada um responde e qual deles a organização adota como definição oficial, com o responsável designado.

Segunda hora · Semântica · 15 minutos

A definição adotada passa a existir em um único lugar

A vista publicada substitui o SQL repetido, e o metadado registra quem responde pela definição.

-- a definição oficial, com o recorte declarado CREATE SCHEMA IF NOT EXISTS semantica; CREATE OR REPLACE VIEW semantica.receita_entregue AS SELECT date_trunc('month', comprado_em) AS mes, regiao, categoria, sum(price + freight_value) AS receita, count(*) AS itens FROM gold.fato_item_venda -- já restrita a itens entregues GROUP BY 1, 2, 3; -- o metadado da métrica, versionado junto do código CREATE OR REPLACE TABLE semantica.dicionario AS SELECT 'receita_entregue' AS metrica, 'v1' AS versao, 'soma de preço e frete de itens entregues' AS formula, 'financeiro' AS responsavel, 'America/Sao_Paulo' AS fuso, DATE '2026-09-23' AS vigente_desde;
Conferência: as três consultas do slide anterior, reescritas sobre a vista, devem devolver o mesmo número. A divergência restante indica que alguma delas responde a outra pergunta, e essa pergunta precisa de métrica própria.

Segunda hora · Contrato · 10 minutos

O contrato é publicado como arquivo versionado junto do dado

Cada grupo escreve o contrato da sua camada de consumo, com as cinco cláusulas do bloco anterior.

# contrato-receita-entregue.yaml dataset: semantica.receita_entregue versao: v1 vigente_desde: "2026-09-23" schema: - {nome: mes, tipo: date, obrigatorio: true} - {nome: regiao, tipo: varchar, obrigatorio: true} - {nome: categoria, tipo: varchar, obrigatorio: false} - {nome: receita, tipo: decimal, obrigatorio: true} - {nome: itens, tipo: bigint, obrigatorio: true} semantica: soma de preço e frete de itens entregues atualidade: "até 3 horas após a carga diária" disponibilidade: "24x7, até 60 consultas por minuto" compatibilidade: "v1 servida por 90 dias após v2" responsavel: financeiro

O contrato declara também o que muda sem nova versão.

A atualidade declarada corresponde ao indicador medido na Aula 15.

O prazo de convivência entre versões permite ao consumidor planejar a migração.

O responsável nomeado é quem aprova mudança de semântica, papel distinto de quem opera a carga.

O contrato é versionado no mesmo repositório do SQL que o implementa.

Publicar o contrato em documento separado do código. As duas versões divergem na primeira alteração, e o consumidor passa a confiar no documento desatualizado.

Segunda hora · Segurança · 15 minutos

O filtro por linha reside na camada semântica e é testado por asserção

Nove asserções, das quais quatro verificam que o acesso é negado; as de negação são as que mais frequentemente faltam.

-- perfis e a região que cada um enxerga CREATE OR REPLACE TABLE semantica.perfil_regiao AS SELECT * FROM (VALUES ('gerente_norte', 'Norte'), ('gerente_sudeste', 'Sudeste'), ('diretoria', '*')) t(perfil, regiao); -- a vista aplica o filtro a partir do perfil corrente CREATE OR REPLACE VIEW semantica.receita_por_perfil AS SELECT r.* FROM semantica.receita_entregue r JOIN semantica.perfil_regiao p ON (p.regiao = r.regiao OR p.regiao = '*') WHERE p.perfil = getvariable('perfil_atual'); -- asserção de NEGAÇÃO: vazamento precisa ser 0 SET VARIABLE perfil_atual = 'gerente_norte'; SELECT count(*) AS vazamento FROM semantica.receita_por_perfil WHERE regiao = 'Sudeste';
Critério de aceite: as quatro asserções de negação devolvem zero, e as cinco de permissão devolvem linhas. A variável de sessão simula a identidade; em produção, o perfil deriva do usuário autenticado. A suíte roda a cada publicação, como os testes da Aula 13.

Segunda hora · Desempenho · 10 minutos

A mesma pergunta servida de duas formas, com a latência medida

A comparação encerra o laboratório e converte a decisão de arquitetura em número.

-- forma 1: consulta direta sobre o fato SELECT regiao, sum(price + freight_value) FROM gold.fato_item_venda GROUP BY 1; -- forma 2: tabela pré-agregada na carga CREATE SCHEMA IF NOT EXISTS consumo; CREATE OR REPLACE TABLE consumo.receita_mes_regiao AS SELECT * FROM semantica.receita_entregue; SELECT regiao, sum(receita) FROM consumo.receita_mes_regiao GROUP BY 1; -- medição: repita 20 vezes e tome o percentil 95 -- .timer on (no shell do DuckDB)
O que registrar

Latência p95 e bytes varridos nas duas formas

A pré-agregação reduz ambos, e o custo aparece como atualidade limitada à frequência da carga. Os três números juntos sustentam a decisão.

Verificação obrigatória

Os dois caminhos devolvem o mesmo valor

A pré-agregação que altera o resultado constitui defeito, pela mesma regra aplicada ao layout na Aula 10.

Registre também quantas vezes por dia a pergunta é feita. A economia por consulta multiplicada pela frequência quantifica o benefício para o parceiro.

Segunda hora · Conferência

Os valores de referência para conferir a camada de consumo

O que se confere em cada etapa, sobre a gold construída nas aulas anteriores.

EtapaO que verificarReferência
Gold regeneradaContagem antes e depois e linhas sem regiãoMesma contagem de itens e nenhuma linha sem região
DivergênciaAs três consultas sobre a silverTrês valores distintos, próximos de R$ 13,2, 15,7 e 13,5 mi na base estática, com a maior diferença entre a financeira e a comercial
Camada semânticaAs três reescritas sobre a vistaUm único valor, idêntico nas três
ContratoCláusulas declaradas no arquivoSchema, semântica, atualidade, disponibilidade e compatibilidade
SegurançaAs nove asserções da matrizQuatro negações devolvendo zero e cinco permissões devolvendo linhas
Desempenhop95 nas duas formas de servirRedução expressiva na pré-agregada, com o mesmo resultado
EquivalênciaValor devolvido pelos dois caminhosIdêntico; qualquer diferença caracteriza defeito
A magnitude da redução de latência depende da máquina de cada grupo. A conferência considera a relação entre as duas formas e a igualdade dos resultados.

Segunda hora · Uso de IA · em paralelo

A IA escreve a vista, e o grupo responde pela definição adotada

A escolha entre as três definições de receita é decisão de negócio, e o assistente não dispõe do contexto necessário para tomá-la.

Prompt 1 · Divergência

Explicitar as definições possíveis

"A partir deste schema do fato, liste as definições plausíveis de receita e diga, para cada uma, qual pergunta de negócio ela responde e qual recorte de status aplica."

Prompt 2 · Publicação

Escrever a vista e o contrato

"Escreva a vista da métrica adotada e o contrato correspondente, declarando schema, semântica, atualidade e política de compatibilidade entre versões."

Prompt 3 · Crítica

Procurar o vazamento

"Aponte, nesta implementação de acesso por linha, por qual caminho um perfil restrito ainda conseguiria observar dado de outra região, inclusive por agregação."

Execute também as asserções de negação, além das de permissão que o assistente costuma propor.

Confirme que a vista sugerida aplica o mesmo recorte declarado no contrato.

Registre o prompt junto do SQL, uma vez que ele integra o registro da decisão.

Ponte com a Aula 1 · Spec-Driven Development

Do tema à especificação executável

A decisão de consumo entra no projeto como requisito, decisão registrada e critério verificável.

RF-009

Requisito funcional

Publicar a receita entregue por mês, região e categoria, com definição única e acesso restrito à região do usuário.

RNF-009

Requisito não funcional

Latência p95 de consulta inferior a 2 s; atualidade declarada de até 3 h; versão anterior servida por 90 dias após a publicação da seguinte.

ADR-CON-01

Decisão de arquitetura

Tabela pré-agregada servindo o painel, em vez de consulta direta ao fato. Contexto: trinta usuários abrindo o mesmo painel diariamente. Consequência: atualidade limitada à frequência da carga.

Cenário de aceite

Critério verificável

Dado um usuário com perfil restrito ao Norte, quando ele consulta a receita por região, então nenhuma linha de outra região é devolvida e o total apresentado corresponde apenas ao Norte.

A definição da métrica é o artefato que atravessa todo o pipeline: ela restringe a modelagem da Aula 4, a transformação da Aula 13 e a interface publicada aqui.

Entrega do card de trabalho

A camada semântica, o contrato, a segurança testada e a latência medida

O que o grupo entrega ao final da segunda hora, e o que será conferido.

Artefato

Pacote de integração publicado

A vista da métrica com o dicionário versionado, o arquivo de contrato, a suíte de nove asserções de acesso, a medição de latência nas duas formas de servir e a justificativa escrita da definição adotada.

1

As três definições divergentes foram reproduzidas, com os valores registrados.

2

A métrica adotada existe em um único lugar, com responsável e vigência declarados.

3

O contrato declara schema, semântica, atualidade, disponibilidade e compatibilidade.

4

As quatro asserções de negação devolvem zero e as cinco de permissão devolvem linhas.

5

A latência p95 está medida nas duas formas, com os bytes varridos registrados.

6

Os dois caminhos devolvem o mesmo valor, e a equivalência está verificada.

Aula 16 · Síntese

A camada de consumo determina qual número a organização considera oficial, e o contrato determina quanto aviso o consumidor recebe quando ele muda.

dbt — Semantic models Data Mesh Architecture DuckDB — CREATE VIEW
Pergunta final: no painel do parceiro, quantas definições distintas da mesma métrica coexistem hoje?

Sobre este encontro

Integração do Datawarehouse com a Interface Analítica · 23/09/2026 · Prof. Afonso

Objetivo de aprendizagem

Projetar a camada de consumo analítico a partir da decisão que ela sustenta, definir a métrica uma única vez em camada semântica versionada, publicar contrato de consumo com política de compatibilidade, aplicar controle de acesso por linha verificável por asserção e medir a latência percebida nas formas de servir disponíveis.

Estratégia do encontro

Primeira hora de exposição dialogada em três blocos, cada um encerrado por checklist de aplicação e erro comum. Segunda hora de atividade em grupo: sobre a gold construída nas aulas anteriores, os estudantes reproduzem três definições divergentes da mesma receita, unificam-nas em camada semântica com responsável e vigência declarados, publicam o contrato de consumo, implementam acesso por linha com nove asserções — cinco delas de negação — e medem a latência p95 da mesma pergunta servida por consulta direta e por tabela pré-agregada.

Estrutura do encontro

  1. 1ª hora · Bloco 1 (20 min) — Quem consome e decide, o teste da decisão associada a cada indicador, a divergência de definição entre equipes e a camada semântica como definição única.
  2. 1ª hora · Bloco 2 (22 min) — Serviço e contrato: consulta direta, tabela agregada, API e exportação; cláusulas do contrato de consumo e o que exige nova versão.
  3. 1ª hora · Bloco 3 (18 min) — Segurança e desempenho: acesso por linha testável por asserção, mascaramento e auditoria; pré-agregação, poda e latência medida em percentil.
  4. 2ª hora · Card de trabalho (60 min) — Em grupo: divergência reproduzida (10 min), camada semântica publicada (15 min), contrato declarado (10 min), segurança por linha com nove asserções (15 min), latência medida nas duas formas e conclusão escrita (10 min).