Dicionário de dados: o que é, como montar e exemplo preenchido

A linha de STATUS_ITEM num dicionário de dados de uma distribuidora diz apenas isto: “Situação do item no armazém.” Ao lado, o domínio lista quatro letras: A, B, R e X. Nenhuma célula explica o que cada letra quer dizer. A linha tem fonte, tipo e dono. Mesmo assim, não responde à pergunta que importa.

Minha formação passa por uma especialização em Estatística, e ali toda variável começa por uma classificação. Antes de qualquer média, a pergunta é se o dado é nominal, ordinal, discreto ou contínuo. Com STATUS_ITEM, essa pergunta fica sem resposta. Você colocaria essas quatro letras em ordem num gráfico sem saber o que cada uma quer dizer? Se as letras formam uma escala, ordenar faz sentido. Se são só rótulos, ordenar é inventar uma ordem que o armazém nunca combinou.

A gente construiu o kit da Voitto em volta de um caso só, e é ele que guia este texto. Uma distribuidora de material de construção, com sete centros de distribuição, viu a ruptura de estoque subir 40% entre janeiro e junho de 2026. Antes de medir qualquer coisa, a equipe descreveu oito campos. Quatro deles saíram marcados como ambíguos.

A seguir, você vê o que um dicionário de dados registra, como montar o seu em sete passos e por que os campos ambíguos voltam como problema na etapa seguinte. O modelo em branco está no fim do texto, pronto para baixar.

O que é dicionário de dados

Dicionário de dados é o documento que diz, campo por campo, o que cada coluna de uma base significa. Ele registra o nome exato na fonte, a definição em português, o tipo, a unidade ou o domínio aceito e quem responde pelo campo. Serve para que duas pessoas leiam o mesmo número do mesmo jeito.

No Kit de Ferramentas de Análise de Dados, o dicionário de dados é a ferramenta E05, a segunda da fase Dados. O guia resume a entrega dela assim: “O significado de cada campo crítico, a regra de negócio por trás do nome da coluna.” A palavra que pesa ali é regra. Tipo e formato qualquer sistema já mostra. A regra, quase sempre, só existe na cabeça de quem alimenta o campo.

Em linguagem técnica, o dicionário de dados é um registro de metadados, ou seja, dados sobre os dados. O corpo de conhecimento da DAMA International (DMBOK) trata metadados como uma das áreas de conhecimento da gestão de dados. Numa empresa grande, esse trabalho mora em programas de governança de dados e em ferramentas próprias de catálogo. Numa análise com prazo, cabe numa planilha de oito linhas.

A diferença de escala não muda o propósito. Quem trabalha com dados estruturados já sabe que cada coluna tem um tipo e um conjunto de valores válidos. O dicionário de dados acrescenta o que o banco não guarda: o significado combinado entre as áreas. Sem ele, o gerenciamento de dados cuida da estrutura e deixa o sentido por conta da memória de cada um.

Para que serve, na prática? Primeiro, para evitar que duas áreas tirem conclusões opostas da mesma coluna. Segundo, para que quem chega depois entenda a base sem repetir as conversas. Terceiro, para dar régua aos testes de qualidade que vêm em seguida. Um dicionário de dados bem feito também encurta reuniões. Em vez de discutir o que um número quer dizer, o grupo discute o que o número mostra. E, quando o resultado for questionado, a folha mostra de onde veio cada campo e quem respondeu por ele.

As oito colunas da E05, uma por uma

A planilha E05 tem oito colunas. Sete são preenchidas por você e a última é calculada. A tabela mostra o papel de cada uma e o que costuma dar errado quando ela fica rasa.

A figura abaixo desmonta uma linha real do caso, a de LEAD_TIME. Repare que todas as células estão cheias e, mesmo assim, a linha termina em revisar. O que segura o campo é a marca de ambíguo, e não um buraco.

Uma boa definição costuma dizer também o que o campo não é. No caso, COD_SKU avisa que não é o código do fabricante. DT_PEDIDO avisa que registra o lançamento no sistema, e não a data do contato. QTD_SALDO já vem descontado do que está separado. Cada negativa fecha uma leitura errada que alguém, em algum momento, poderia fazer.

Dono merece atenção à parte. No caso, ela traz a área e o nome de uma pessoa. A área diz a quem o campo pertence. A pessoa diz a quem perguntar quando a dúvida aparece no meio da análise. Uma área sem nome vira caixa de entrada que ninguém lê. Um nome sem área some da folha quando a pessoa muda de função. A linha precisa dos dois.

Fonte parece a coluna mais óbvia, até a base juntar sistemas. No caso, são três: o ERP, o WMS e a planilha de Compras. Cada um guarda datas e códigos do seu jeito. Saber de onde o campo sai explica por que DT_PEDIDO e DT_ENTREGA chegam em formatos diferentes.

O nome exato na fonte também importa mais do que parece. Numa consulta ao banco de dados SQL, é esse nome que vai no comando. Se o dicionário de dados traduz a coluna para “código do produto”, quem consulta perde tempo procurando uma coluna que não existe.

Como escrever uma boa definição de campo

Definição é a coluna que mais pesa no dicionário de dados, e também a que mais sai rasa. Uma definição útil costuma responder cinco perguntas curtas.

• O que o campo mede. A grandeza ou o atributo, com o nome que o negócio usa.
• Qual evento dispara o registro. Para datas e prazos, o momento exato que conta.
• Em que unidade. Dias corridos ou úteis, unidades ou caixas, valor com ou sem imposto.
• O que o campo não é. A leitura errada mais provável, dita numa frase.
• O que o vazio significa. Zero, não se aplica ou falta de registro.

Aplique as cinco perguntas à linha de LEAD_TIME no caso. A definição diz: “Dias entre pedido e entrega. Preenchido à mão, em branco quando ninguém anotou.” A unidade está na coluna ao lado. O vazio também está explicado. Falta dizer se os dias são corridos ou úteis. E falta dizer qual entrega conta.

Esse último ponto é leitura minha, e a planilha não o registra. Se a entrega de LEAD_TIME é a mesma de DT_ENTREGA, o prazo herda a dúvida da data. Parte das pessoas lança a chegada ao CD, e parte lança a data da nota. Assim, o mesmo fornecedor pode ganhar dois prazos para o mesmo tipo de pedido. Uma frase na definição fecha as duas lacunas de uma vez.

Uma definição assim cabe em duas ou três linhas. Não precisa de linguagem técnica. Precisa só que o dono leia e confirme que é isso mesmo.

Tipo de sistema e tipo de variável: a coluna que engana

A coluna Tipo da E05 aceita três respostas no caso: texto, número e data. É o tipo que o sistema usa para guardar o valor. A estatística faz outra pergunta. O Guia Prático Lean Seis Sigma Black Belt resume a resposta na página 230. Essa página fica no capítulo 22, chamado “Seleção de Métricas e Coleta de Dados”. Ali, “os dados qualitativos descrevem características subjetivas ou não numéricas, e são classificados em ordinais (que apresentam uma ordem) e nominais (dados que não podem ser ordenados)”. Os quantitativos, diz o mesmo resumo, “podem ser medidos ou contados” e se dividem em discretos e contínuos.

As duas classificações não coincidem. Um campo do tipo texto pode ser nominal, como o código de um item, ou ordinal, como uma escala de A a D. Um campo do tipo número pode ser uma contagem ou uma medida. A tabela cruza os oito campos do caso com a classe que eu atribuiria a cada um. A terceira coluna é leitura minha e não está na planilha.

STATUS_ITEM é a única linha em que a classe fica em aberto. Se as letras seguem uma escala, um gráfico ordenado conta uma história. Se forem só estados sem ordem, o mesmo gráfico conta outra. Uma frase na definição resolve. Sem ela, quem monta o gráfico escolhe sozinho.

Essa diferença muda a conta que o relatório faz. Para um campo nominal, a medida de centro que faz sentido é a moda, o valor mais frequente. Para um ordinal, a mediana já funciona, porque existe ordem. A média só vale para quantitativos. Se STATUS_ITEM for tratado como escala sem ser, um relatório pode exibir um “status médio” por CD. É um número que ninguém sabe ler, e a folha evita que ele chegue a um gráfico.

As datas pedem outro cuidado. DT_PEDIDO vem do ERP no formato AAAA-MM-DD. DT_ENTREGA vem da planilha em DD/MM/AAAA. Quem subtrair uma da outra para conferir um prazo precisa converter antes. E só descobre isso lendo a coluna de domínio.

A classe também decide a conversão na hora de preparar a base. No Power Query, um código com zeros à esquerda lido como número perde os zeros. COD_SKU é texto de 12 caracteres, e o dicionário de dados registra isso antes que alguém converta. O tratamento em si é tema do texto sobre como tratar dados no Power BI.

Campo ambíguo: quatro jeitos de um campo significar duas coisas

A coluna Ambíguo? é a mais importante da E05 e a mais fácil de preencher com pressa. No caso, quatro campos receberam sim. Cada um é ambíguo por um motivo diferente. Vale separar os motivos, porque cada um pede um combinado diferente.

• Domínio sem legenda. STATUS_ITEM aceita A, B, R e X. A definição diz que é a situação do item no armazém, mas não diz o que cada letra significa. O combinado é uma legenda, letra por letra, escrita pelo dono.
• Vazio que tem sentido. LEAD_TIME é digitado à mão e fica vazio quando ninguém anotou. Se esse vazio virar zero, o prazo médio encolhe sem motivo, e o combinado precisa dizer como a análise lida com essa falta.
• Dois eventos na mesma coluna. DT_ENTREGA deveria guardar a chegada ao CD. Parte das pessoas lança a data da nota. O combinado escolhe um dos dois eventos e avisa quem digita.
• Texto livre. FORNECEDOR é digitado sem lista, e a mesma empresa aparece escrita de três jeitos. O combinado é uma chave única, que a planilha sozinha não tem.

O rodapé da planilha diz isso numa frase: “Campo ambíguo não é campo ruim, é campo que precisa de combinado escrito”. Marcar sim abre uma tarefa para o dono do campo, e ela só fecha quando a regra vai para a definição.

Os quatro tipos aparecem longe do dicionário de dados também. O lead time vazio distorce qualquer média de prazo. A grafia múltipla de fornecedor quebra o ranking da gestão de fornecedores. E um código de status sem legenda é o tipo de coisa que a padronização de processos existe para evitar.

Um teste prático ajuda a decidir a marca. Pergunte a duas pessoas de áreas diferentes o que o campo significa, sem mostrar a definição. Se as respostas divergirem, o campo é ambíguo, mesmo que a coluna esteja bem preenchida.

No caso, dois desses combinados aparecem mais adiante no kit, no registro de tratamento da análise. A grafia do fornecedor foi unificada pelo CNPJ do cadastro do ERP, e não pelo texto digitado, em 612 registros. Os 334 vazios de LEAD_TIME receberam a mediana de prazo do próprio fornecedor. Excluir esses pedidos puniria quem preenche pior a planilha, e não quem atrasa mais. As duas decisões respondem a perguntas que o dicionário de dados já tinha deixado abertas.

O que a coluna Pronto para uso confere, e o que ela deixa passar

A última coluna da E05 é uma fórmula. Ela responde OK quando a linha tem definição, tipo e dono preenchidos e a marca de ambíguo é diferente de sim. Em qualquer outro caso, responde revisar. A lógica é uma função SE no Excel com um E dentro, nada mais sofisticado.

A instrução do cabeçalho da planilha cita só três condições: definição, tipo e dono. A fórmula tem uma quarta, a ambiguidade. É por ela que STATUS_ITEM sai revisar com todas as células cheias. Quem lê só a instrução acha que a linha está pronta.

Duas colunas ficam fora da conta: Fonte e Unidade / domínio. Uma linha sem fonte e sem domínio pode sair OK, se tiver definição, tipo e dono. No caso isso não acontece, porque todas as linhas estão completas. Numa planilha nova, vale conferir essas duas colunas à mão antes de confiar no OK.

Para contar quantas linhas estão prontas numa planilha grande, uma função CONT.SE sobre a última coluna basta. No caso, a conta dá quatro OK e quatro revisar. Esse número é o tamanho da conversa que falta antes de medir a qualidade da base.

O que o livro diz sobre o significado dos dados

O capítulo 22 começa pela escolha de métricas e pela coleta. Na página 215, ele traz uma frase que serve de justificativa para a E05 inteira: “A coleta e o armazenamento de dados precisos e relevantes são cruciais para a análise e a interpretação dessas medidas”. Preciso e relevante são as duas palavras que a planilha transforma em colunas.

O capítulo não usa o nome dicionário de dados. O que ele pede é precisão no que se guarda, relevância para a pergunta e a classificação da variável antes da análise. A tabela liga cada pedido a uma coluna da planilha. O livro não cita a E05, e a correspondência é minha.

O capítulo seguinte, a partir da página 231, trata da análise do sistema de medição (MSA). A MSA pergunta se o instrumento mede sempre igual. O dicionário de dados pergunta, antes, se todos entendem a mesma coisa pelo nome do campo. Um plano de coleta de dados bem feito precisa das duas respostas.

Onde a E05 entra na fase Dados

A fase Dados do kit segue uma ordem. Primeiro, o mapa de fontes (E04) diz onde cada campo mora. Depois, o dicionário de dados (E05) diz o que ele significa. Só então o checklist de qualidade (E06) conta quantos registros prestam, e o perfil estatístico (E07) descreve a distribuição.

A ordem tem motivo. Um teste de fora do domínio só existe se alguém escreveu o domínio. Uma inconsistência só aparece se alguém disse qual é a forma certa. O dicionário de dados é o que transforma “parece estranho” em regra que dá para contar.

No caso, a ligação entre as duas folhas é nítida. Os quatro campos marcados como ambíguos na E05 são exatamente os quatro de maior taxa de problema na E06. FORNECEDOR lidera, seguido de LEAD_TIME, DT_ENTREGA e STATUS_ITEM. Os quatro campos sem marca ficaram abaixo de 1%.

Não é prova de causa. Três dos quatro campos saem de uma planilha digitada à mão, e isso pesa tanto quanto a ambiguidade. Mas o sinal chegou antes da contagem. Quem leu a E05 com cuidado já sabia onde procurar. É o tipo de achado que a integração de dados entre ERP e planilha costuma revelar tarde, quando ninguém documentou os campos.

O mapa de fontes do caso já apontava outro sinal: o código do fornecedor no ERP não bate com o da planilha de Compras. O dicionário registra o sintoma do outro lado, a grafia livre. As duas folhas, lidas juntas, contam a mesma história antes de qualquer análise de dados começar.

O domínio escrito na E05 vira teste na E06. No caso, STATUS_ITEM teve 1.642 registros fora das quatro letras aceitas, porque o campo recebia texto livre. Sem a linha do dicionário de dados listando A, B, R e X, esses registros não teriam como ser contados. O tratamento usou uma tabela de equivalência, em que “ativo” vira A. E essa tabela só pode ser montada por quem sabe o que cada letra significa.

Como montar um dicionário de dados em sete passos

1. Parta da pergunta. Liste só os campos que a análise vai usar. Se a definição do problema fala de ruptura por CD, a folha precisa de saldo, pedido, entrega e CD, não das duzentas colunas da base.
2. Copie o nome exato. Use o nome que a coluna tem na fonte, com maiúsculas e sublinhados. O mapa de fontes já traz essa lista.
3. Escreva a definição com o dono. Uma frase sobre o que o campo mede e outra sobre o que ele não é. Se só você sabe explicar, você ainda não falou com o dono.
4. Registre tipo e classe. Anote o tipo do sistema e, na definição, a classe estatística quando ela não for óbvia. Para códigos, diga que são texto.
5. Feche o domínio. Unidade para números, formato para datas e lista com legenda para códigos. Uma validação de dados no Excel pode travar a digitação dentro desse domínio depois.
6. Marque a ambiguidade com honestidade. Use o teste das duas pessoas. Quando marcar sim, escreva o combinado na mesma linha.
7. Confira o resultado. Leia a coluna Pronto para uso e revise à mão Fonte e Unidade / domínio, que a fórmula não olha.

O passo mais demorado é o terceiro. Definir um campo com o dono pede uma conversa curta por linha, e é essa conversa que o dicionário de dados guarda. Com oito campos, são oito conversas.

Se a mesma chave aparece em duas fontes, anote isso na definição. É a informação que vai orientar um PROCV ou uma junção mais tarde. E evita cruzar colunas que só têm o nome parecido.

Depois de pronto, o dicionário de dados pede manutenção. Sistemas mudam códigos, planilhas ganham colunas e donos trocam de área. Três hábitos seguram a folha em dia. Guarde no cabeçalho quando ela foi revista pela última vez. Mantenha a versão anterior quando uma definição mudar, para saber qual regra valia em cada período. E revise a folha sempre que a fonte mudar, antes do próximo relatório. Uma folha velha engana mais do que a falta dela, porque passa uma certeza que já não vale.

Exemplo de dicionário de dados preenchido

O exemplo vem do caso ilustrativo do kit, a distribuidora da abertura. São oito campos de três fontes, descritos antes da medição de qualidade. A miniatura abre a folha inteira, e o botão logo abaixo baixa a mesma folha em PDF.

1. Distribuidora de material de construção: quatro campos prontos e quatro para revisar

O caso começa com três perguntas sobre a ruptura: por que falta produto, qual fornecedor atrasa mais e se a falta é igual em todos os centros. O obstáculo é que nenhuma chave comum liga as três fontes. O ERP Protheus registra por pedido, o WMS Vertice por SKU e dia, e a planilha do Compras por entrega. Lida contra as perguntas, a escolha dos oito campos se explica. COD_SKU e as datas são as chaves que permitem cruzar as fontes, QTD_SALDO e STATUS_ITEM servem à pergunta da falta, CD à dos centros, e LEAD_TIME, DT_ENTREGA e FORNECEDOR à do atraso. Cada fonte tem uma área dona. TI responde pelo ERP, Logística pelo WMS e Suprimentos pela planilha.

Quatro linhas fecharam em OK. COD_SKU é texto de 12 caracteres, e a definição avisa que não é o código do fabricante. DT_PEDIDO segue o formato AAAA-MM-DD. QTD_SALDO conta unidades de saldo físico. CD aceita 7 valores, um por centro de distribuição.

STATUS_ITEM é a linha curiosa. Tem fonte, tipo, dono e domínio, com as letras A, B, R e X. Fica em revisar só porque a equipe marcou a ambiguidade, e a definição não traz a legenda das letras.

As outras três linhas em revisar vêm da planilha. LEAD_TIME é preenchido à mão e fica em branco quando ninguém anota. DT_ENTREGA usa DD/MM/AAAA, e há quem lance a data da nota. FORNECEDOR é texto livre, com a mesma empresa grafada de 3 jeitos.

O saldo da folha é quatro prontos e quatro para revisar. Nenhuma das revisões depende de fórmula. Depende de uma conversa com o dono do campo e de uma frase escrita na definição. E a espera tem preço, porque justamente as linhas em revisar sustentam a pergunta do atraso. Sem a frase escrita, o ranking de fornecedores roda sobre prazos em branco, datas de nota misturadas com datas de chegada e uma mesma empresa espalhada em grafias diferentes.

O que o exemplo ensina de mais útil está nas linhas em revisar. Nenhuma delas tem célula vazia. O dicionário de dados pede ali uma escolha, e cada linha tem a sua pergunta. Qual evento DT_ENTREGA registra? O que significa a letra R? Quem escolhe a grafia oficial do fornecedor?

Repare também em quem é dono do quê. As linhas prontas vêm de TI e de Logística. Três das quatro linhas em revisar vêm da planilha de Compras, a fonte em que os valores são digitados. O dono ali é Suprimentos, e é com essa área que as três conversas precisam acontecer.

Vale notar também o que a folha não tenta fazer. Ela não conta quantos registros de LEAD_TIME estão vazios, nem quantas grafias de FORNECEDOR existem na base. Essas contagens são trabalho da E06. O dicionário de dados só aponta onde contar, e isso já basta para a etapa seguinte começar pelo lugar certo.

Dicionário de dados, glossário e catálogo: qual é qual

Os três nomes aparecem juntos em projetos de dados e confundem quem está começando. A diferença está no objeto que cada um descreve.

Na prática, um alimenta o outro. O glossário define ruptura. O dicionário de dados diz quais campos calculam a ruptura. O catálogo diz em que sistema esses campos estão. E a modelagem de dados mostra como as tabelas se ligam para o cálculo acontecer.

Em projetos de business intelligence, o dicionário costuma virar documentação do modelo publicado. Numa análise pontual, como a do caso, ele é uma planilha que acompanha o relatório. O formato muda, e a pergunta de cada linha continua a mesma.

Uma confusão frequente é chamar de dicionário a lista de colunas que o próprio sistema exporta. Essa lista traz nome, tipo e tamanho, às vezes com uma descrição curta. Falta o que dá sentido ao campo: a regra, o dono e a marca de ambiguidade. É um bom ponto de partida para o segundo passo, mas não substitui as conversas do terceiro.

Erros comuns ao montar um dicionário de dados

O guia do kit registra o erro comum desta ferramenta: “Documentar tipo e formato, mas não a regra que explica por que o campo se comporta assim.” Os outros da lista derivam dele.

• Definição que repete o nome. “Situação do item” para STATUS_ITEM descreve a coluna e não explica nada. A definição precisa da regra.
• Código sem legenda. Listar A, B, R e X no domínio sem dizer o que cada letra é deixa a ambiguidade intacta.
• Vazio lido como zero. Um campo digitado à mão fica vazio quando falta o registro. Tratar vazio como zero muda médias e prazos.
• Base inteira no lugar da pergunta. Documentar duzentas colunas atrasa a análise e dilui a atenção nos campos que decidem o resultado.
• Marca de ambíguo por pressa. Marcar não para ver a linha ficar OK esconde exatamente o campo que mais precisa de conversa.
• Dono genérico. Escrever “a empresa” ou “o sistema” na coluna Dono deixa a dúvida sem destinatário. Toda linha precisa de uma área e de uma pessoa.
• Documento parado. Quando o sistema muda um código ou um formato, o dicionário de dados envelhece sem aviso. Anote a data da última revisão.

Quando o dicionário de dados pode ser curto

Nem toda análise pede uma E05 detalhada. Se a base tem uma fonte só, poucos campos e nomes que se explicam sozinhos, três linhas com definição e domínio resolvem. Um relatório interno de uso único também aceita uma versão curta.

Algumas situações pedem o contrário. Mais de uma fonte, campo digitado à mão, código sem legenda e dado pessoal são sinais de que vale o documento completo. No último caso, a Lei Geral de Proteção de Dados exige registro das operações de tratamento, e o dicionário ajuda a saber quais campos são pessoais.

O caso da distribuidora está no meio do caminho. São oito campos, mas três fontes, e uma delas é digitada. Por isso a folha completa valeu a pena, mesmo curta.

A versão curta não dispensa as duas colunas que mais erram. Mesmo com três linhas, escreva o domínio de cada código e o que o vazio significa. São as informações que mais faltam quando alguém retoma a análise meses depois. Tipo e fonte aparecem no próprio sistema, e o significado depende de alguém ter escrito.

Modelo de dicionário de dados em branco para baixar

A E05 em branco é o modelo de dicionário de dados do kit, com a fórmula da última coluna pronta. Você preenche as sete primeiras colunas e a planilha calcula se a linha está pronta para uso.

A folha traz no cabeçalho as quatro instruções de preenchimento, as oito colunas e as linhas para os campos. A legenda no rodapé separa o que você preenche do que a planilha calcula.

Abrir e baixar a E05 em branco (planilha)

O exercício que dá o primeiro gás é digitar o caso da distribuidora na folha vazia e ver se os quatro OK aparecem nos mesmos campos. Depois, troque pelos campos da sua própria base, começando pelos que você suspeita serem ambíguos.

Se você quer praticar o percurso completo, da pergunta ao relatório, te convido a conhecer na formação em análise de dados da Voitto as fases do kit em sequência, do jeito que a gente ensina. E quem leva esse cuidado para projetos Lean Seis Sigma tem na Academia de Certificação da Voitto o caminho das certificações.