Dicionário, linhagem e classificação
Também em 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 governação de dados, capítulo 5 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Manter os dados maus lá fora · Próximo: As leis de privacidade moldam o design
A pergunta que este módulo responde: Como registar o que os dados significam, de onde vieram e quão sensíveis são?
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 facto cliente? Abre as descrições. Três estão em branco. Uma diz «Customer Type». Obrigado. Uma diz que veio do ERP; outra foi criada há seis anos por alguém que já saiu há muito tempo. Agora imagine que não é o arquiteto, mas uma integração, uma equipa de relatórios ou um agente. A organização tem dados de sobra. Isso não significa que saiba o que os dados significam.
É aí que os metadados se tornam arquitetura, através de três perguntas relacionadas, mas não iguais:
- Dicionário: o que estes dados significam?
- Linhagem: de onde vieram?
- Classificação: como têm de ser tratados?
Dois tipos de metadados
Seção intitulada “Dois tipos de metadados ”Os metadados são de dois tipos, e precisa dos dois. Os metadados de negócio são o que os dados significam para o negócio: a definição, o proprietário, as regras de utilização, o quão sensíveis são. Os metadados técnicos são a forma 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 programador como o usar; a definição e o proprietário dizem a todos os outros se o devem usar. Quando discordam, ou quando um deles falta, é aí que as integrações e os relatórios correm mal.
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: cada campo ganha uma descrição. Não «Customer Status» para um campo chamado Customer Status, mas algo como «A relação comercial atual do parceiro com a Steve Trucking. Definida 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 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 significa Entregue? O que conta como pontual? Parecem óbvios até pôr cinco departamentos numa sala: as Finanças têm uma definição, as Vendas outra, as Operações uma terceira, o data warehouse uma quarta, e alguém construiu um dashboard sobre uma quinta. O problema não é ninguém falar a mesma língua. É a empresa não ter chegado a acordo sobre o significado.
Um dicionário pode viver numa folha de cálculo ou numa ferramenta de documentação, mas as suas definições importantes têm de 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 relações, 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: os 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 retalhista | Um retalhista para o qual a Steve Trucking entrega, sob contrato | Conta no Salesforce; cliente no ERP financeiro |
| Entrega | Uma entrega para um Destinatário, numa morada, num dia | RouteDesk hoje; uma ordem de trabalho 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 | Estado 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 de saber o que um valor significa, quero saber de onde veio. Isso é linhagem. A denominação social de um parceiro no Salesforce: um comercial escreveu-a, o ERP enviou-a, uma integração transformou-a, o Data 360 unificou-a, foi calculada, a IA gerou-a? Isso afeta o quanto confio nela e o que posso fazer com ela. Lembre-se dos registos provisórios do módulo 2: duas contas podem dizer «Keystone», uma criada ontem por um comercial, a outra vinda do ERP com um identificador com autoridade. O mesmo texto, outra linhagem, outro tratamento.
A 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, que sistema tem autoridade, o que o transformou, que sistemas receberam cópias, o que o alterou por último, e consigo rastrear um valor derivado até às suas fontes? O panorama do capítulo 4 diz que os sistemas estão ligados. A linhagem diz o que aconteceu aos dados pelo 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 registam a fonte de dados e o objeto de origem de cada registo (Data Lineage Fields (opens in a new tab), em inglês). Mas não presuma que a linhagem aparece por os sistemas estarem integrados. Às vezes a linhagem mais útil é um campo: Sistema de origem = Keystone. E, se a origem importa para a governação, torne-a mecanicamente fiável, preenchida pela integração, não escrita por uma pessoa.
Os dados derivados precisam de linhagem mais do que tudo. Digamos que a Steve Trucking calcula um risco de atraso na entrega a partir da posição do camião, da janela de entrega e do histórico da rota, e a expedição usa-o para priorizar. De onde veio o «alto»? Acrescente um agente a dizer a um Destinatário «a sua entrega está atrasada», e precisa de saber o que o sustentou, e quão recente era. Quanto mais 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 deve ser tratado? Nome do Destinatário, morada de entrega, telefone, notas da entrega, estado da entrega, número do camião, centro de distribuição, Parceiro retalhista, fotografia: 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 fotografia do interior da casa de alguém. O Salesforce permite registar 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 chamou-lhes campos de taxonomia, e explicou porque é que importam: marque um campo como PII ou GDPR e os processos conseguem encontrá-lo, desde as ferramentas de mascaramento até à camada de confiança de IA do Salesforce (trust layer), que pode impedir que os valores marcados cheguem a um modelo de linguagem de grande dimensão (LLM). Um alerta do capítulo 3: o Salesforce desativa agora esse mascaramento para LLM nos agentes, porque pode remover o contexto de que um agente precisa (Classifique o que importa: os campos de taxonomia). Por isso, a classificação continua a ter de conduzir os outros controlos.
A minha posição aqui é deliberada: classifique os campos sensíveis, não todos os campos. Não quero três meses gastos a classificar milhares de campos para alguém reportar «100% classificado» e ninguém os usar. O telefone do Destinatário: sim. A morada de casa: sim. Notas de entrega que podem conter códigos de portão e «cão no quintal»: sim. Fotografias que podem mostrar pessoas ou uma casa: com certeza. Um rótulo interno de apresentação? Não é para aí que deve ir a energia de governação. 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; a sua organização pode querer os seus próprios rótulos. Não os estou a prescrever. Mantenha-os compreensíveis: se há 47 categorias e ninguém fora da equipa de privacidade sabe distinguir a 31 da 32, não está a ajudar. Uma boa taxonomia liga um rótulo a um comportamento. Se um campo é um dado pessoal sensível, quem o pode ver, pode ir para uma sandbox, sair da região, aparecer na análise, durante quanto tempo é guardado, um agente pode usá-lo? Agora a classificação está a trabalhar.
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 escreveu documentação. Útil, mas a governação vai mais longe: a classificação deve orientar permissões, mascaramento, encriptação, 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 aplicam agora etiquetas e classificações diretamente em políticas, como faz a governação 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 o ler. A classificação diz como um campo deve ser tratado; a segurança fá-lo acontecer. A sequência é: identificar os dados, entendê-los, classificar o que importa, e depois aplicar os controlos que a classificação pede.
Três perguntas sobre os seus dados, e a terceira tem de 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, estados 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. Os 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 orientar processos muito grandes. O capítulo 6 vai mais longe.
Os três juntos
Seção intitulada “Os três juntos ”Pegue no 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 retalhista. Classificação: dado pessoal. Agora as perguntas de arquitetura são possíveis: a equipa pode vê-lo, e durante quanto tempo (o briefing diz só nas suas próprias paragens, só no dia); pode ir para uma sandbox; o Snowflake precisa dele; um agente pode usá-lo; o que acontece quando a entrega termina?
Agora pegue no estado 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 sua integração. Classificação: operacional, não sensível. Dados diferentes, tratamento diferente. É esse o ponto.
Não trato os metadados como documentação produzida depois de a verdadeira arquitetura estar 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 é sensível, não entendo a segurança. Os metadados descrevem a arquitetura, e às vezes orientam-na.
Além do exame: o que a IA muda. A classificação está a tornar-se o interruptor do que um agente pode recuperar ou repetir, e a linhagem tem de chegar até à resposta ou à ação do agente. Se um agente diz a um Destinatário que a entrega está atrasada, a arquitetura deve conseguir dizer o que sustentou isso, de onde veio, e se o agente tinha permissão para o usar. «Algures no 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 ”- Que termos de negócio precisam de definições governadas, para que sistemas e equipas não deem significados diferentes a uma mesma palavra.
- Como os valores importantes mantêm linhagem suficiente para mostrar a sua origem, a sua autoridade e as suas transformações.
- Que 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 orienta controlos reais em vez de ficar parada sem uso.
Antes de governar dados, saiba o que tem: o que significam, de onde vieram, como têm de ser tratados. Documente amplamente, classifique de forma deliberada, mantenha a linhagem onde importa. Caso contrário 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.