Dicionário, linhagem e classificação
Também em 28 idiomas
English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 3 de 6 do capítulo Qualidade e governança de dados, capítulo 5 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Mantendo dados ruins do lado de fora · Próximo: Leis de privacidade moldam o design
A pergunta que este módulo responde: Como registrar o que os dados significam, de onde vieram e quão sensíveis são?
Você herdou uma org. A Conta tem 900 campos, entre eles Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c e Account_Status__c. Qual deles diz se alguém é de fato cliente? Você abre as descrições. Três estão em branco. Uma diz “Customer Type”. Obrigado. Uma diz que veio do ERP; outra foi criada seis anos atrás por alguém que já saiu há muito tempo. Agora imagine que você não é o arquiteto, mas uma integração, uma equipe de relatórios ou um agente. A organização tem dados de sobra. Isso não significa que ela sabe o que os dados significam.
É aí que os metadados viram arquitetura, por meio de três perguntas relacionadas, mas não iguais:
- Dicionário: o que estes dados significam?
- Linhagem: de onde eles vieram?
- Classificação: como precisam ser tratados?
Dois tipos de metadados
Seção intitulada “Dois tipos de metadados ”Os metadados vêm em dois tipos, e você precisa dos dois. Metadados de negócio são o que os dados significam para o negócio: a definição, o proprietário, as regras de uso, o quanto são sensíveis. Metadados técnicos são como os dados são construídos e se movem: o objeto e o campo, o tipo e o tamanho, o nome de API, o esquema, o mapeamento de um sistema para outro, a linhagem da origem ao destino. O nome de API e o tipo de um campo dizem a um desenvolvedor como usá-lo; a definição e o proprietário dizem a todos os outros se devem usá-lo. Quando eles discordam, ou um deles está faltando, é aí que integrações e relatórios dão errado.
Conhecimento para o exame. Saiba distinguir metadados de negócio (significado, definições, proprietário, regras, sensibilidade: o dicionário de negócio e a classificação) de metadados técnicos (objetos, campos, tipos, nomes de API, esquemas, mapeamentos e linhagem).
Comece pelo significado
Seção intitulada “Comece pelo significado ”O capítulo 3 definiu a regra: todo campo ganha uma descrição. Não “Customer Status” para um campo chamado Customer Status, mas algo como “O relacionamento comercial atual do parceiro com a Steve Trucking. Definido pelo ERP depois da ativação. Não usar para qualificação de prospects.” Agora sei o que significa, de onde vem e para que não usar. Esse é o começo de um dicionário de negócio: definições comuns para os dados que importam. O que é um cliente? Um cliente ativo? O que Entregue significa? O que conta como pontual? Parecem óbvios até você colocar cinco departamentos numa sala: o Financeiro tem uma definição, Vendas outra, Operações uma terceira, o data warehouse uma quarta, e alguém construiu um dashboard sobre uma quinta. O problema não é que ninguém fale a mesma língua. É que a empresa não chegou a um acordo sobre o significado.
Um dicionário pode viver numa planilha ou numa ferramenta de documentação, mas suas definições importantes precisam ficar perto de onde as pessoas usam os dados. Na plataforma, isso são descrições de campos, texto de ajuda e os metadados de classificação. Na análise importa ainda mais: “receita” não pode significar uma coisa no dashboard executivo e outra na consulta de um analista. É para isso que serve uma camada semântica, e os modelos semânticos do Data 360 guardam definições governadas, como métricas, dimensões e relacionamentos, acima dos dados físicos (Create a Semantic Model in Data 360 (opens in a new tab), em inglês). A tecnologia muda; o requisito não: dados importantes precisam de um significado acordado.
E comece pelo significado, não pela tecnologia. Um dicionário que começa com objeto, campo, tipo e nome de API documenta a implementação. Um que começa com termos de negócio documenta a empresa:
| Termo de negócio | Significado | Onde é representado |
|---|---|---|
| Parceiro varejista | Um varejista para o qual a Steve Trucking entrega, sob contrato | Conta no Salesforce; cliente no ERP financeiro |
| Entrega | Uma entrega para um Destinatário, num endereço, num dia | RouteDesk hoje; uma ordem de serviço quando as entregas passarem para o Salesforce |
| Destinatário | A pessoa que recebe uma entrega | Dados do Destinatário na entrega |
| Entregue | Concluída segundo a definição operacional acordada | Status da entrega |
| Entrega pontual | Concluída dentro da janela de entrega acordada | Métrica derivada |
Um significado, muitas representações técnicas.
Depois pergunte de onde veio
Seção intitulada “Depois pergunte de onde veio ”Depois que sei o que um valor significa, quero saber de onde ele veio. Isso é linhagem. A razão social de um parceiro no Salesforce: um vendedor a digitou, o ERP a enviou, uma integração a transformou, o Data 360 a unificou, foi calculada, a IA a gerou? Isso afeta o quanto confio nela e o que posso fazer com ela. Lembre-se dos registros provisórios do módulo 2: duas contas podem dizer “Keystone”, uma criada ontem por um vendedor, a outra vinda do ERP com um identificador com autoridade. Mesmo texto, linhagem diferente, tratamento diferente.
Linhagem não é só o diagrama de mil tabelas de um engenheiro de dados. Para dados importantes, quero responder a perguntas práticas: onde começou, qual sistema tem autoridade, o que o transformou, quais sistemas receberam cópias, o que o alterou por último, e consigo rastrear um valor derivado até suas fontes? O panorama do capítulo 4 diz que os sistemas estão conectados. A linhagem diz o que aconteceu com os dados no caminho.
Parte da linhagem vem de graça: o ID do ERP na conta, Criado por e Última modificação por, logs de integração, documentos de mapeamento. O Data 360 acrescenta aos seus objetos de dados campos de linhagem que registram a fonte de dados e o objeto de origem de cada registro (Data Lineage Fields (opens in a new tab), em inglês). Mas não presuma que a linhagem aparece porque os sistemas estão integrados. Às vezes a linhagem mais útil é um campo: Sistema de origem = Keystone. E, se a origem importa para a governança, torne-a mecanicamente confiável, preenchida pela integração, não digitada por uma pessoa.
Dados derivados precisam de linhagem mais do que tudo. Digamos que a Steve Trucking calcule um risco de atraso na entrega a partir da posição do caminhão, da janela de entrega e do histórico da rota, e o despacho o use para priorizar. De onde veio o “alto”? Acrescente um agente dizendo a um Destinatário “sua entrega está atrasada”, e você precisa saber o que embasou isso, e quão recente era. Quanto mais você se afasta de valores armazenados rumo a valores calculados, unificados, previstos e gerados, mais a linhagem importa.
A classificação responde a outra pergunta
Seção intitulada “A classificação responde a outra pergunta ”Agora: como ele deve ser tratado? Nome do Destinatário, endereço de entrega, telefone, observações da entrega, status da entrega, número do caminhão, centro de distribuição, Parceiro varejista, foto: não são igualmente sensíveis. “Saiu para entrega” não é um número de telefone, e o código de um CD não é a foto do interior da casa de alguém. O Salesforce permite registrar isso em cada campo, padrão ou personalizado: Data Owner, Field Usage, Data Sensitivity Level e Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), em inglês). O capítulo 3 os chamou de campos de taxonomia, e explicou por que eles importam: marque um campo como PII ou GDPR e os processos conseguem encontrá-lo, das ferramentas de mascaramento à camada de confiança de IA do Salesforce (trust layer), que pode impedir que valores marcados cheguem a um modelo de linguagem de grande porte (LLM). Um alerta do capítulo 3: o Salesforce agora desativa esse mascaramento para LLM nos agentes, porque ele pode remover o contexto de que um agente precisa (Classifique o que importa: os campos de taxonomia). Então a classificação ainda precisa conduzir os outros controles.
Minha posição aqui é deliberada: classifique os campos sensíveis, não todos os campos. Não quero três meses gastos classificando milhares de campos para alguém relatar “100% classificado” e ninguém usar. O telefone do Destinatário: sim. O endereço residencial: sim. Observações de entrega que podem conter códigos de portão e “cachorro no quintal”: sim. Fotos que podem mostrar pessoas ou uma casa: com certeza. Um rótulo interno de exibição? Não é onde a energia de governança deve ir. Isso não torna aceitáveis os campos sem documentação. São dois trabalhos diferentes: a documentação é ampla; a classificação é deliberada. É isso que mantém a classificação significativa.
Uma taxonomia que as pessoas consigam usar
Seção intitulada “Uma taxonomia que as pessoas consigam usar ”A classificação precisa de um vocabulário, uma taxonomia. Os padrões da Salesforce vão de Public, Internal, Confidential, Restricted a MissionCritical; sua organização pode querer seus próprios rótulos. Não os estou prescrevendo. Mantenha-os compreensíveis: se há 47 categorias e ninguém fora da equipe de privacidade sabe distinguir a 31 da 32, não está ajudando. Uma boa taxonomia liga um rótulo a um comportamento. Se um campo é dado pessoal sensível, quem pode vê-lo, ele pode ir para um sandbox, sair da região, aparecer na análise, por quanto tempo é guardado, um agente pode usá-lo? Agora a classificação está trabalhando.
Classificação sem aplicação é decoração
Seção intitulada “Classificação sem aplicação é decoração ”Marque o telefone do Destinatário como sensível e não mude mais nada, e você escreveu documentação. Útil, mas a governança vai além: a classificação deve guiar permissões, mascaramento, criptografia, retenção, consentimento, movimentação de dados, uso em sandbox, auditoria e acesso da IA. Parte disso é decisão de design do arquiteto; algumas plataformas agora aplicam etiquetas e classificações diretamente em políticas, como faz a governança do Data 360 (Data Governance in Data 360 (opens in a new tab), em inglês). E marcar um campo como Restricted não impede ninguém de lê-lo. A classificação diz como um campo deve ser tratado; a segurança faz isso acontecer. A sequência é: identificar os dados, entendê-los, classificar o que importa, e então aplicar os controles que a classificação pede.
Três perguntas sobre os seus dados, e a terceira precisa conduzir alguma coisa.
Dados de referência também precisam de metadados
Seção intitulada “Dados de referência também precisam de metadados ”Códigos de país, status de entrega, códigos de CD, identificadores de parceiros, motivos de cancelamento: parecem simples até dois sistemas discordarem. Um diz CANCELLED, outro CANCELED, um terceiro CNCL, um quarto 9. Dados de referência precisam de definições, de um dono, de uma origem, de um ciclo de vida quando os valores mudam, e de mapeamentos quando os sistemas os representam de formas diferentes. Valores pequenos podem guiar processos muito grandes. O capítulo 6 vai além.
Os três juntos
Seção intitulada “Os três juntos ”Pegue o telefone do Destinatário. Dicionário: o número usado para falar com a pessoa que recebe uma entrega específica. Linhagem: vem do manifesto do Parceiro varejista. Classificação: dado pessoal. Agora as perguntas de arquitetura são possíveis: a equipe pode vê-lo, e por quanto tempo (o briefing diz só nas suas próprias paradas, só no dia); ele pode ir para um sandbox; o Snowflake precisa dele; um agente pode usá-lo; o que acontece quando a entrega termina?
Agora pegue o status da entrega. Dicionário: o estado operacional atual da entrega. Linhagem: definido pelo processo de entrega da Steve Trucking e devolvido a cada parceiro pela integração dele. Classificação: operacional, não sensível. Dados diferentes, tratamento diferente. Esse é o ponto.
Não trato os metadados como documentação produzida depois que a arquitetura de verdade está pronta. Se não consigo dizer o que um campo significa, não entendo o modelo de dados. Se não sei de onde veio um valor, não entendo as integrações. Se não sei se ele é sensível, não entendo a segurança. Os metadados descrevem a arquitetura, e às vezes a guiam.
Além do exame: o que a IA muda. A classificação está virando o interruptor do que um agente pode recuperar ou repetir, e a linhagem precisa chegar até a resposta ou a ação do agente. Se um agente diz a um Destinatário que a entrega está atrasada, a arquitetura deve conseguir dizer o que embasou isso, de onde veio, e se o agente tinha permissão para usá-lo. “Em algum lugar do Salesforce” não é linhagem, e “dados de cliente” não é uma classificação.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Quais termos de negócio precisam de definições governadas, para que sistemas e equipes não deem significados diferentes a uma mesma palavra.
- Como os valores importantes mantêm linhagem suficiente para mostrar sua origem, sua autoridade e suas transformações.
- Quais campos carregam significado de sensibilidade ou de conformidade e, por isso, recebem classificação explícita.
- Que taxonomia a organização usa, e se as pessoas conseguem aplicá-la de forma consistente.
- Como a classificação guia controles reais em vez de ficar parada sem uso.
Antes de governar dados, saiba o que você tem: o que significam, de onde vieram, como precisam ser tratados. Documente amplamente, classifique de forma deliberada, mantenha a linhagem onde ela importa. Senão você não governa os dados. Só os tem.
Para saber mais
Seção intitulada “Para saber mais ”- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (em inglês), consultado em 2026-10-14.
- Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) e Create a Semantic Model in Data 360 (opens in a new tab) (em inglês), consultados em 2026-10-14.