Qualidade e governação de dados

🌐 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)

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

Guia de estudo do capítulo 5 do curso Data Architect. Leia primeiro os seis módulos; esta página ajuda-o a verificar o que ficou.

Sobre este guia de estudo. Foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Nunca se baseia em perguntas reais do exame e não afirma saber o que sai na prova. Se já fez o exame, por favor não me envie as perguntas: o contrato de certificação proíbe partilhá-las, e decorar respostas é, de qualquer forma, a maneira errada de se tornar arquiteto.

Este capítulo carrega a secção de Governação de Dados do exame (10%) e partes de Modelação de Dados (metadados) e de Gestão de Dados Salesforce (consistência). É também onde a lei de privacidade encontra o modelo de dados. Isto é arquitetura, não aconselhamento jurídico: o Jurídico decide o que se aplica, e o arquiteto torna-o aplicável. Os números da plataforma mudam, por isso confira os atuais antes de contar com eles.

Para o exame

Marque à medida que avança. Cada item tem um link para onde é ensinado.

GOV-2: projetar um programa de governação

• Sei que o proprietário do registo (um mecanismo da plataforma para o acesso) não é o proprietário dos dados (responsável pelos dados como ativo do negócio), e que cada campo pode registar um Data Owner. (O proprietário do registo não é o proprietário dos dados)
• Consigo distinguir o proprietário dos dados (define a política), o data steward (mantém tudo a funcionar) e o custodiante (opera o sistema). (Proprietário, data steward, custodiante)
• Conhecimento para o exame: conheço as três formas de conduzir um programa de governação, centralizada, federada (descentralizada) e híbrida, e o que cada uma significa para quem define a política e onde ficam as definições partilhadas. (Como o programa funciona)
• Consigo usar uma RACI para responder onde são os dados criados, editados e referenciados. (Faça a matriz RACI merecer o seu lugar)
• Consigo nomear um ponto de aplicação para uma política de governação (permissões, validação, campos só da integração, histórico de campos), não só formação. (A governação tem de se tornar mecânica)
• Sei que os sinais de qualidade que vale medir são aqueles sobre os quais alguém vai agir. (Meça aquilo sobre o que alguém vai agir)

SDM-2 e MDM-4: manter os dados maus lá fora

• Consigo decidir se a criação de contas deve ser aberta ou trancada, e conheço o caminho do tipo de registo provisório para contas que são mestres num ERP. (Aberta ou trancada?, O caminho do meio)
• Consigo proteger atributos governados (um ID do ERP, uma denominação social) e ainda deixar editáveis os campos próprios do Salesforce: um golden record híbrido. E sei que um campo só de leitura numa página do Dynamic Forms não é aplicação; a segurança em nível de campo ou uma regra de validação é. (Proteja o registo governado, Um tipo de registo para cada fluxo)
• Sei que os fluxos bidirecionais são os mais difíceis: se o ERP é o mestre de um campo, o Salesforce está a pedir para o alterar, e uma colisão precisa de uma regra (o ERP prevalece, rejeitar se mudou, ou uma pessoa resolve). (Proteja o registo governado)
• Sei que campos obrigatórios podem criar dados falsos (N/A, 999999), e conheço as alternativas. (Não deixe campos obrigatórios criarem dados falsos)
• Consigo decidir o que acontece aos dados de entrada que chumbam nas verificações: aceitar, rejeitar ou pôr em quarentena, e quem é dono da exceção. (Cada fronteira de dados precisa de uma decisão de qualidade)
• Sei que dados de referência também precisam de metadados: definições, um dono, uma origem e mapeamentos entre sistemas. (Dados de referência também precisam de metadados)

DM-3: metadados de negócio e técnicos

• Conhecimento para o exame: sei distinguir metadados de negócio (significado, definições, proprietário, regras, sensibilidade) de metadados técnicos (objetos, campos, tipos, nomes de API, esquemas, mapeamentos, linhagem). (Dois tipos de metadados)
• Sei a diferença entre um dicionário de negócio (o que significa), a linhagem (de onde veio) e a classificação (como tem de ser tratado). (Conheça os seus dados)
• Conheço os campos de classificação do Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, em campos padrão e personalizados. (A classificação responde a outra pergunta)
• Sei que devo classificar os campos sensíveis, não todos os campos, e que classificação sem aplicação é decoração. (Classificação sem aplicação é decoração)

GOV-1: dados pessoais e sensíveis

• Reconheço as principais leis (RGPD, CCPA/CPRA, PIPEDA, LGPD, a Privacy Act da Austrália, HIPAA, PCI DSS, SOX, COPPA), sei que o RGPD pode abranger organizações fora da UE, e sei o que as leis têm em comum: direitos, transferências, notificação de violações de dados e responsabilidade. (As regulações que deve reconhecer, As leis não param na fronteira)
• Sei a diferença entre encriptação, mascaramento, pseudonimização e anonimização, e que os dados pseudonimizados continuam a ser dados pessoais. (Anonimizado, pseudonimizado, encriptado, mascarado)
• Sei que recolher menos é um controlo de privacidade, e que a retenção é projetada desde o início. (Recolher menos é uma decisão de arquitetura, A retenção faz parte do modelo)
• Conheço o modelo de dados de consentimento: consentimento global no Indivíduo, consentimento por tipo de ponto de contacto, consentimento por ponto de contacto, e finalidade de uso dos dados. (Use o modelo que a Salesforce já construiu)
• Sei que os pedidos têm prazos (RGPD: um mês, prorrogável por mais dois), por isso o mapa de cópias tem de existir antes. (O relógio está a contar)
• Sei que o direito a ser esquecido significa encontrar cada cópia (histórico, arquivos, análise, logs, ficheiros, texto livre), e que as políticas do Privacy Center são executadas por objeto a partir de um registo de cliente. (Agora a pessoa diz: esqueçam-me, O Privacy Center é uma ferramenta, não a arquitetura inteira)
• Conheço os trade-offs do Shield Platform Encryption: os campos probabilísticos não podem ser filtrados, agrupados nem ordenados em SOQL; a encriptação determinística permite filtrar; os campos encriptados não podem orientar a partilha baseada em critérios. (A encriptação é um controlo, não conformidade)
• Sei que não devo copiar os dados sensíveis da produção para as sandboxes, e que o Data Mask está a ser substituído pelo Data Mask & Seed. (Não copie o risco da produção para a sandbox)
• Conheço o histórico de campos (até 20 campos por objeto; 18 meses, 24 só pela API; em texto longo, regista só a edição) versus o Field Audit Trail (até 200 campos, guardado até o eliminar). (O histórico também são dados)
• Conheço a retenção dos logs do Event Monitoring (1 dia sem o extra para alguns eventos, 30 dias por defeito com ele, até 365 alargados), e que é preciso exportar os eventos para um SIEM antes de precisar deles: os logs pagos não podem ser recuperados de antes do início do contrato. (Auditar e monitorizar não são o mesmo)

Além do exame

O exame é o chão, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.

• Uma política sem ponto de aplicação é, em boa parte, um desejo.
• Os donos definem a política; os arquitetos aplicam-na. Não invente a política, e não se faça de advogado.
• A governação nunca termina. Vai e vem; projete o retorno.
• Não conte com o bom comportamento. Construa o controlo: pessoas, integrações e agentes, todos erram.
• Governe o suficiente, não tudo.
• Evite primeiro os erros caros. Um duplicado com dois anos de histórico é um problema grande.
• Distinga o que as pessoas leem daquilo com base em que as máquinas decidem.
• Documente amplamente; classifique de forma deliberada.
• O dado sensível mais barato de governar é aquele que nunca copiou.
• O consentimento é um dado, e a permissão para usar dados tem de poder ser representada como dado.
• Controle primeiro para onde vão os dados pessoais, porque a eliminação é rara e difícil.
• A conformidade não é um produto.
• Capturar → Classificar → Proteger → Usar → Reter → Eliminar → Auditar.
• Capture as evidências antes de alguém as pedir.

Palavras a conhecer

Termo	Numa linha
Governação de dados	As políticas para os dados, e a arquitetura que as torna verdadeiras
Proprietário dos dados	A pessoa ou função responsável por um tipo de dado
Data steward	A pessoa que mantém os dados saudáveis no dia a dia
Custodiante	A equipa que opera os sistemas que guardam os dados
RACI	Responsável, Aprovador (Accountable), Consultado, Informado
Registo provisório	Um registo criado antes de o sistema com autoridade o aceitar
Dicionário de negócio	Definições acordadas dos termos importantes do negócio
Linhagem	De onde veio um valor e o que lhe aconteceu pelo caminho
Classificação de dados	Rotular os dados por sensibilidade e categoria de conformidade para que recebam os controlos certos
Taxonomia	O conjunto de rótulos que uma organização usa para classificar dados
Dados pessoais	Informação que identifica uma pessoa, ou que pode ser associada a uma
Pseudonimização	Substituir identificadores enquanto ainda existe um caminho de volta; continuam a ser dados pessoais
Anonimização	Remover a capacidade razoável de identificar a pessoa
Modelo de dados de consentimento	Os objetos da Salesforce para o consentimento por pessoa, canal, ponto de contacto e finalidade
Direito a ser esquecido	O direito de uma pessoa, onde a lei o concede, a ver os seus dados pessoais apagados
Golden record híbrido	Um registo com os campos do sistema mestre e os campos próprios do Salesforce, cada um com uma única origem
Metadados de negócio / técnicos	O que os dados significam e quem é dono deles / como são construídos e se movem
Field Audit Trail	Histórico de campos mais longo: até 200 campos por objeto, guardado até ser eliminado
Event Monitoring	Logs de inícios de sessão, exportações, chamadas de API e visualizações, guardados durante tempo limitado
SIEM	Um repositório de segurança onde os logs de eventos são guardados e analisados

Teste-se

Cenários curtos ao estilo do curso. Decida a sua resposta antes de abrir.

1. A política diz que só as Finanças podem alterar a denominação social de um cliente. A equipa planeia tratar disso na formação. O que falta?

Um ponto de aplicação. A formação não é um controlo: use acesso ao nível do campo, um campo que só a integração grava, uma regra de validação ou um processo controlado. Os donos definem a política; o arquiteto torna-a mecanicamente verdadeira. Releia A governação tem de se tornar mecânica.

2. Os clientes são mestres no ERP. Os comerciais precisam de começar a vender a novos prospects de imediato. Como permitir isso sem dois sistemas a criar o registo mestre?

Deixe os comerciais criarem a conta como um tipo de registo provisório, e depois converta-a por um processo controlado: as Finanças aprovam, ou a integração submete-a ao ERP, que faz a correspondência ou cria o cliente e devolve o ID com autoridade. Releia O caminho do meio.

3. Um novo campo obrigatório enche-se de «N/A» e «999999». O que aconteceu, e o que faria em vez disso?

Os utilizadores foram obrigados a responder antes de saberem. Exija-o mais adiante no processo, deixe outro sistema fornecê-lo, use um estado provisório, ou permita um Desconhecido explícito quando essa for uma resposta real. Releia Não deixe campos obrigatórios criarem dados falsos.

4. A equipa trocou os nomes por tokens e diz que os dados estão anonimizados, por isso o pedido de eliminação está resolvido. Está?

Não, se os tokens podem voltar a ser associados à pessoa: isso é pseudonimização, e os dados continuam a ser pessoais. Diga exatamente o que o sistema faz, onde fica o mapeamento, e deixe o Jurídico decidir se isso cumpre o requisito. Releia Anonimizado, pseudonimizado, encriptado, mascarado.

5. Um Destinatário aceita mensagens sobre a entrega, mas não marketing. Como deve o modelo guardar isto?

Com o modelo de dados de consentimento, não com uma caixa de verificação: a pessoa, o canal (SMS), o número específico e a finalidade de uso dos dados (notificações de entrega, não marketing). E decida que sistema tem autoridade sobre o consentimento, para que uma retirada chegue a cada sistema que age com base nele. Releia Use o modelo que a Salesforce já construiu.

6. A conformidade precisa de filtrar relatórios por um campo encriptado de número da Segurança Social. O campo usa o esquema de encriptação por defeito. Qual é o problema?

A encriptação probabilística não permite filtrar em cláusulas WHERE de SOQL nem em filtros de gestão de dados. A encriptação determinística permite filtrar, com um pequeno custo em força. A encriptação é uma decisão de design com trade-offs, não uma caixa de verificação no fim. Releia A encriptação é um controlo, não conformidade.

7. Seis meses depois de um incidente, alguém pergunta quem exportou um conjunto de registos. Ninguém configurou o armazenamento do Event Monitoring. O que pode dizer?

Provavelmente nada: os logs de eventos são guardados durante tempo limitado (no máximo um ano, mesmo alargado), por isso o que for mais antigo desapareceu, a menos que tenha sido exportado. Configure o Event Monitoring e envie os eventos para um SIEM antes de precisar deles. Releia Auditar e monitorizar não são o mesmo.

8. Um vendedor pede ao Salesforce para alterar a denominação social de um cliente, que tem o ERP como mestre. Nos mesmos minutos, alguém a altera no ERP. O que deve dizer o design?

Que o Salesforce estava a pedir, não a alterar: o ERP é o mestre do campo. Decida de antemão a regra para colisões (o ERP prevalece, rejeitar se o valor mudou, ou uma pessoa resolve) e se os campos relacionados viajam juntos. Releia Proteja o registo governado.

9. Chega um pedido de apagamento de uma pessoa. A equipa planeia começar a mapear onde estão os dados dela. Qual é o problema?

O relógio já está a contar: ao abrigo do RGPD, um mês, prorrogável por mais dois para pedidos complexos. O mapa de cópias tem de existir antes de o pedido chegar. Releia O relógio está a contar.

Para saber mais

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25): a lista oficial de objetivos e os seus pesos. Confira sempre a versão atual antes de marcar o exame.
• A secção Para saber mais de cada módulo lista a documentação da Salesforce e as leis por trás dos seus factos, com a data de consulta.