AD × DBA: a diferença definitiva

Antes de qualquer conteúdo técnico, é preciso entender com clareza o que separa os dois papéis do Capítulo. Essa distinção aparece, direta ou indiretamente, em praticamente qualquer pergunta da entrevista.

1.Administrador de Dados (AD)

O Administrador de Dados trabalha principalmente com o significado do dado e sua aderência ao negócio. As responsabilidades típicas envolvem:

• o significado do dado e as regras de negócio associadas a ele;
• o modelo conceitual e o modelo lógico;
• os relacionamentos entre entidades e sua padronização;
• a qualidade, os metadados e a classificação da informação;
• o compartilhamento, o reuso e a privacidade dos dados;
• o ciclo de vida da informação e a arquitetura de dados;
• a documentação e a governança.

2.Administrador de Banco de Dados (DBA)

O Administrador de Banco de Dados trabalha principalmente com a implementação física e a operação do dado dentro do SGBD. As responsabilidades típicas envolvem:

• a criação e a alteração de objetos físicos (tabelas, tipos, índices);
• chaves primárias, estrangeiras, constraints e índices;
• o storage, o particionamento e as estatísticas;
• os planos de execução e a concorrência entre transações;
• o desempenho, a disponibilidade e a manutenção do ambiente;
• a recuperação e a operação do SGBD.

3.Comparação direta

4.Por que os dois papéis são interdependentes

Um modelo de dados bem definido pelo AD só entrega valor real se puder ser implementado com integridade e desempenho — responsabilidade do DBA. Da mesma forma, uma implementação fisicamente eficiente não corrige um modelo que não representa corretamente a regra de negócio. Um erro comum é tratar os dois papéis como isolados: na prática, uma decisão de modelagem lógica (por exemplo, a granularidade de uma entidade) sempre produz consequências físicas (mais tabelas, mais junções, mais índices necessários), e uma decisão física (por exemplo, desnormalizar uma tabela para reduzir junções) sempre produz consequências lógicas (risco de inconsistência entre os dados redundantes).

5.Resumo relâmpago

• AD cuida do significado, da estrutura lógica e da governança do dado.
• DBA cuida da implementação física, da operação e do desempenho.
• A pergunta central do AD é sobre definição, organização e proteção.
• A pergunta central do DBA é sobre implementação, acesso e manutenção.
• Os dois papéis são interdependentes: decisões de um sempre têm consequências no outro.

Modelagem de dados: conceitual, lógico e físico

Modelagem de dados é a representação organizada dos elementos que importam para o negócio, feita em três níveis de detalhamento crescente. Compreender exatamente o que pertence a cada nível é uma das perguntas mais recorrentes sobre o assunto.

1.Entidade, atributo e relacionamento

Uma entidade representa algo do mundo real ou do negócio sobre o qual se deseja guardar informação — uma pessoa, um objeto, um evento ou um conceito, como Cliente, Conta ou Transação. Um atributo é uma característica dessa entidade, como o nome ou a data de nascimento de um cliente. Um relacionamento é a associação entre duas ou mais entidades, como a associação entre Cliente e Conta.

As entidades podem ser classificadas de acordo com sua dependência de outras entidades:

2.Os três níveis de modelo

Os três níveis não são etapas alternativas: são camadas progressivas de detalhamento, cada uma construída sobre a anterior.

2.1 Modelo conceitual

O modelo conceitual mostra as entidades, os relacionamentos entre elas e as regras principais do negócio, em uma visão de alto nível, sem se preocupar com tipos de dados, índices ou qualquer característica do SGBD que vai armazenar as informações. Serve para validar o entendimento do negócio antes de qualquer detalhe técnico.

2.2 Modelo lógico

O modelo lógico acrescenta atributos, identificadores, chaves, cardinalidades, opcionalidades e o resultado da normalização, incluindo eventuais entidades associativas criadas para resolver relacionamentos muitos-para-muitos. Ainda não há compromisso com um SGBD específico.

CLIENTE
- id_cliente
- cpf
- nome
- data_nascimento

CONTA
- id_conta
- numero_conta
- tipo_conta

CLIENTE_CONTA
- id_cliente
- id_conta
- tipo_titularidade
- data_inicio
- data_fim

A entidade CLIENTE_CONTA resolve o relacionamento muitos-para-muitos entre clientes e contas: sem ela, não haveria como registrar que uma conta tem mais de um titular nem que um cliente possui mais de uma conta.

2.3 Modelo físico

O modelo físico converte o modelo lógico em objetos que podem de fato ser implementados em um SGBD: tabelas, colunas, tipos, tamanhos, nulidade, constraints, índices, particionamento e qualquer característica própria da plataforma escolhida.

CREATE TABLE cliente (
    id_cliente BIGINT NOT NULL,
    cpf CHAR(11) NOT NULL,
    nome VARCHAR(150) NOT NULL,
    data_nascimento DATE,
    CONSTRAINT pk_cliente PRIMARY KEY (id_cliente),
    CONSTRAINT uk_cliente_cpf UNIQUE (cpf)
);

3.Resumo relâmpago

• Entidade representa algo do negócio; atributo é uma característica; relacionamento associa entidades.
• Entidades podem ser fortes, fracas ou associativas.
• Modelo conceitual: visão de negócio, sem tipos nem SGBD.
• Modelo lógico: atributos, chaves, cardinalidades e normalização, ainda sem compromisso com um SGBD.
• Modelo físico: tabelas, tipos, constraints, índices — já dependente do SGBD escolhido.
• Uma entidade associativa resolve relacionamentos muitos-para-muitos.

Cardinalidade, opcionalidade e chaves

Cardinalidade, opcionalidade e os diferentes tipos de chave formam o vocabulário mais usado para descrever um modelo lógico. Confundir esses conceitos é um dos erros mais comuns de quem está começando.

1.Cardinalidade

Cardinalidade responde à pergunta "quantos": quantas ocorrências de uma entidade podem se relacionar com quantas ocorrências de outra entidade.

2.Opcionalidade

Opcionalidade responde a uma pergunta diferente: se a participação de uma entidade no relacionamento é obrigatória ou opcional. Cardinalidade e opcionalidade são independentes uma da outra e por isso costumam ser representadas juntas, por exemplo como "1:N obrigatório" ou "1:N opcional".

3.Chaves

3.1 Chave primária (PK)

Identifica de forma única cada ocorrência de uma entidade. Precisa ter três propriedades: unicidade (não pode haver duas ocorrências com o mesmo valor), não nulidade (todo registro precisa ter um valor) e estabilidade (o valor não deve mudar ao longo do tempo).

3.2 Chave estrangeira (FK)

Referencia a chave primária de outra tabela e é o mecanismo que ajuda a preservar a integridade referencial: impede, por exemplo, que uma transação seja registrada apontando para uma conta que não existe.

3.3 Chave candidata

É qualquer atributo, ou conjunto mínimo de atributos, capaz de identificar unicamente uma ocorrência da entidade. Uma entidade pode ter mais de uma chave candidata; apenas uma delas é escolhida como chave primária, e as demais costumam virar restrições de unicidade (UNIQUE).

3.4 Chave natural × chave substituta

3.5 Entidade associativa

Como visto no tema de modelagem, uma entidade associativa resolve um relacionamento muitos-para-muitos, e sua chave primária costuma ser composta pelas chaves estrangeiras das duas entidades que ela associa — como o par (id_cliente, id_conta) em CLIENTE_CONTA.

4.Resumo relâmpago

• Cardinalidade responde "quantos": 1:1, 1:N ou N:N.
• Opcionalidade responde "obrigatório ou não", de forma independente da cardinalidade.
• PK identifica unicamente; precisa ser única, não nula e estável.
• FK referencia outra tabela e preserva integridade referencial.
• Chave candidata é qualquer atributo capaz de identificar unicamente a ocorrência.
• Chave natural tem significado no negócio; chave substituta é criada só para identificação.

Normalização

Normalização é o processo de organizar os dados de uma estrutura com base em suas dependências, com o objetivo de reduzir redundância indevida e evitar anomalias de manutenção. É, provavelmente, o assunto mais cobrado em qualquer avaliação sobre modelagem de dados.

1.O problema que a normalização resolve

Considerar uma tabela única para representar um pedido:

PEDIDO
id_pedido
data_pedido
cpf_cliente
nome_cliente
telefone_cliente
id_produto
nome_produto
preco_produto
quantidade

Essa estrutura gera diversos problemas: o nome e o telefone do cliente ficam repetidos em cada pedido que ele faz; o nome e o preço do produto ficam repetidos em cada pedido que o contém; alterar o telefone de um cliente exige atualizar várias linhas; não é possível cadastrar um produto novo antes que exista um pedido para ele; e apagar o único pedido de um produto apaga também a única informação existente sobre esse produto. Esses são exatamente os três tipos de anomalia que a normalização busca eliminar: anomalia de inserção, de alteração e de exclusão.

2.Dependência funcional

Um atributo B tem dependência funcional em relação a um atributo A quando, para cada valor de A, existe exatamente um valor correspondente de B. Na tabela acima, nome_produto depende funcionalmente de id_produto: cada produto tem um único nome. Essa noção de dependência é a base de todas as formas normais.

3.Primeira Forma Normal — 1FN

Exige que todos os valores sejam atômicos (não divisíveis) e que não existam grupos repetitivos de colunas.

4.Segunda Forma Normal — 2FN

Exige estar na 1FN e que todo atributo não-chave dependa da chave completa, e não apenas de parte de uma chave composta. Esse problema só existe quando a chave primária é composta por mais de um atributo.

5.Terceira Forma Normal — 3FN

Exige estar na 2FN e não ter dependência transitiva: um atributo não-chave não pode depender de outro atributo não-chave.

6.Resumo relâmpago

• Normalização organiza dados com base em dependências, reduzindo redundância e anomalias.
• Anomalias podem ser de inserção, alteração ou exclusão.
• 1FN: valores atômicos, sem grupos repetitivos.
• 2FN: 1FN + nenhum atributo depende só de parte de uma chave composta.
• 3FN: 2FN + nenhuma dependência transitiva entre atributos não-chave.
• A normalização deve, no mínimo, chegar até a 3FN; qualquer desnormalização posterior precisa de justificativa.

DAMA-DMBOK e governança de dados

O DMBOK é uma referência de conhecimento em gestão de dados, mantida pela DAMA International. Não é uma lei, uma ferramenta ou uma metodologia rígida — a própria DAMA orienta que o framework seja adaptado ao contexto de cada organização.

1.O que é o DMBOK

DMBOK significa Data Management Body of Knowledge (corpo de conhecimento em gestão de dados). Ele organiza a disciplina de gestão de dados em áreas de conhecimento, oferecendo uma linguagem comum entre profissionais e organizações diferentes. A edição consolidada e mais amplamente adotada é a segunda edição do DMBOK.

2.As onze áreas de conhecimento

3.Governança de dados

Governança é a área que define quem decide o quê sobre os dados: quem é o responsável por definir uma regra de qualidade, quem aprova uma mudança de modelo, quem responde por um vazamento de dados pessoais. Sem uma governança clara, as demais áreas do DMBOK perdem eficácia, porque não há autoridade definida para fazer cumprir padrões de qualidade, segurança ou arquitetura.

4.Dados mestres e dados de referência

Dados mestres são as entidades centrais e compartilhadas de uma organização — como Cliente, Produto ou Fornecedor — que são usadas por múltiplos sistemas e processos. Dados de referência são conjuntos de valores padronizados usados para classificar outros dados, como uma tabela de códigos de estados ou de tipos de conta. A diferença central é que dados mestres representam entidades de negócio com identidade própria, enquanto dados de referência são, em geral, listas de domínio relativamente estáveis.

5.Resumo relâmpago

• DMBOK é um corpo de conhecimento da DAMA, não uma norma obrigatória.
• Organiza a gestão de dados em onze áreas de conhecimento.
• Governança define autoridade e responsabilidade sobre os dados.
• Dados mestres são entidades centrais compartilhadas; dados de referência são domínios padronizados.
• Deve ser adaptado ao contexto de cada organização, não aplicado de forma rígida.

Qualidade de dados

Qualidade de dados é a área que mede, controla e melhora a confiabilidade das informações. É avaliada por meio de dimensões específicas, e não por uma noção genérica de "dado certo ou errado".

1.As dimensões de qualidade

2.Tratando um problema de qualidade

Diante de um problema de qualidade — por exemplo, o mesmo cliente cadastrado três vezes, com endereços divergentes, CPF inválido em um dos registros e telefone desatualizado — a condução recomendada segue uma sequência lógica:

3.Resumo relâmpago

• Qualidade é avaliada por dimensões: completude, validade, unicidade, consistência, acurácia, atualidade, integridade e tempestividade.
• Integridade é uma dimensão de qualidade, não sinônimo dela.
• Tratar um problema de qualidade exige identificar a causa, não só corrigir o sintoma.
• Responsabilidade sobre a correção da causa é uma questão de governança.

Segurança, privacidade e LGPD

Segurança e privacidade são frequentemente tratadas como sinônimos, mas respondem a perguntas diferentes. Um ambiente pode ser tecnicamente seguro e, ainda assim, realizar um tratamento de dados pessoais inadequado.

1.Segurança

Segurança busca impedir acesso não autorizado, alteração indevida, vazamento, destruição, indisponibilidade e uso incompatível com as permissões concedidas. Seus princípios básicos incluem:

• Confidencialidade: apenas quem tem permissão pode acessar o dado.
• Integridade: o dado não é alterado de forma indevida.
• Disponibilidade: o dado está acessível quando necessário.
• Menor privilégio: cada usuário ou sistema recebe apenas o acesso mínimo necessário.
• Segregação de responsabilidades: nenhuma pessoa concentra sozinha o controle total de uma operação crítica.
• Autenticação e autorização: confirmar quem é o usuário e o que ele pode fazer.
• Rastreabilidade: é possível reconstituir quem fez o quê e quando.

2.Privacidade

Privacidade trata do uso legítimo e adequado de dados pessoais ao longo de todo o seu ciclo de vida. As perguntas centrais são diferentes das de segurança:

• Por que o dado pessoal está sendo tratado — existe uma finalidade legítima?
• Quais dados são realmente necessários para essa finalidade?
• Quem pode receber ou acessar esse dado?
• Por quanto tempo ele deve ser mantido?
• O uso é compatível com a finalidade para a qual o dado foi originalmente coletado?

3.LGPD e conceitos relacionados

A Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) disciplina o tratamento de dados pessoais nos meios físicos e digitais no Brasil, estabelecendo conceitos, princípios, responsabilidades e direitos relacionados a esse tratamento.

• Dado pessoal: informação relacionada a pessoa natural identificada ou identificável.
• Dado sensível: categoria especial de dado pessoal (como origem racial, saúde ou dados biométricos), sujeita a tratamento mais restritivo.
• Anonimização: processo que remove a possibilidade de associar o dado a um titular, de forma irreversível.
• Pseudonimização: processo que substitui identificadores diretos por identificadores artificiais, mas mantém a possibilidade de reversão sob controle específico.
• Privacy by Design: princípio de incorporar a privacidade desde a concepção do sistema ou processo, e não como um ajuste posterior.

4.Resumo relâmpago

• Segurança protege contra acesso, alteração, indisponibilidade e vazamento indevidos.
• Privacidade trata da legitimidade, necessidade e finalidade do uso de dados pessoais.
• A LGPD disciplina o tratamento de dados pessoais no Brasil.
• Anonimização é irreversível; pseudonimização é reversível sob controle.
• Privacy by Design significa incorporar privacidade desde a concepção, não depois.

Compartilhamento e reuso de dados

Compartilhar um dado corporativo não é uma simples cópia de arquivo. É uma decisão que envolve finalidade, qualidade, propriedade e rastreabilidade.

2.Perguntas antes de compartilhar um dado

Antes de disponibilizar um dado para outra área, sistema ou ambiente, um conjunto de perguntas deve ser respondido:

• Qual é a finalidade específica desse compartilhamento?
• Quem é o gestor ou responsável por esse dado?
• O consumidor realmente precisa de todos os campos, ou apenas de um subconjunto?
• Existem dados pessoais ou sigilosos envolvidos?
• O dado possui qualidade suficiente para o uso pretendido?
• Qual é a fonte oficial desse dado?
• Qual é a frequência de atualização esperada?
• Existe uma definição comum e padronizada para esse dado?
• Haverá cópia desnecessária de informação já existente em outro lugar?
• Existe uma política de retenção definida?
• Como o acesso será revogado quando não for mais necessário?
• Haverá rastreabilidade de quem acessou e como usou o dado?

3.Resumo relâmpago

• Compartilhamento exige finalidade clara, gestor definido e avaliação de necessidade real dos dados.
• Reuso deve privilegiar fonte oficial e definição padronizada, evitando cópias desnecessárias.
• Toda decisão de compartilhamento deve considerar retenção, revogação de acesso e rastreabilidade.

Ciclo de vida da informação

Todo dado corporativo passa por um conjunto de fases, desde sua criação até seu eventual descarte. Entender essas fases evita a suposição ingênua de que "guardar tudo para sempre" é a opção mais segura.

1.As fases do ciclo de vida

Em todas as fases devem existir responsabilidade definida, segurança, metadados associados, controle de qualidade, rastreabilidade, regras de acesso, prazos definidos e evidências de conformidade.

2.Por que não guardar tudo para sempre

Manter um dado indefinidamente sem necessidade real gera pelo menos quatro problemas concretos: aumenta o custo de armazenamento e de manutenção; aumenta a superfície de exposição em caso de incidente de segurança; dificulta a governança, porque quanto mais dado existe, mais difícil é saber exatamente o que existe e onde; e pode até violar princípios de proteção de dados pessoais, que orientam a retenção pelo tempo estritamente necessário à finalidade.

3.Resumo relâmpago

• O ciclo de vida vai da criação/captura até o expurgo/descarte, passando por classificação, validação, armazenamento, uso, integração, manutenção, retenção e arquivamento.
• Toda fase precisa de responsabilidade, segurança, metadados, qualidade e rastreabilidade.
• Retenção ilimitada aumenta custo, exposição e risco — o prazo deve ter justificativa.
• O descarte também precisa ser controlado e demonstrável, não apenas a guarda.

Arquitetura de dados

Arquitetura de dados é a visão estruturada de como os dados são produzidos, circulam, são integrados, armazenados, classificados, consumidos, governados e evoluem ao longo do tempo dentro de uma organização.

1.Elementos que compõem a arquitetura

• Sistemas transacionais: onde os dados de negócio são originalmente criados e alterados.
• Integrações: mecanismos que movem dados entre sistemas, como APIs e mensageria.
• Fontes oficiais: o sistema ou processo reconhecido como origem autorizada de um dado.
• ETL/ELT: processos de extração, transformação e carga de dados entre ambientes.
• Repositórios analíticos: ambientes organizados para consulta e análise, separados do ambiente transacional.
• Dados mestres e de referência: como descrito na área de DMBOK, entidades centrais e domínios padronizados.
• Catálogo e metadados: inventário do que existe, com contexto e significado.
• Linhagem: registro do caminho percorrido por um dado, desde sua origem até seu uso final.
• Camadas de consumo: as diferentes formas como o dado chega até quem precisa dele.

2.Arquitetura operacional × arquitetura analítica

3.Resumo relâmpago

• Arquitetura de dados é a visão estruturada de produção, circulação, integração, armazenamento e consumo dos dados.
• Envolve sistemas transacionais, integrações, fontes oficiais, ETL/ELT, repositórios analíticos, catálogo, metadados e linhagem.
• Arquitetura operacional sustenta o dia a dia do negócio; arquitetura analítica sustenta análise e decisão.
• Separar o ambiente analítico do transacional evita competição por recursos e degradação de desempenho.

Do modelo lógico ao físico: tipos de dados

Converter um modelo lógico em objetos físicos exige uma série de decisões técnicas: nome de tabelas e colunas, tipos, tamanhos, precisão, nulidade, chaves, índices, particionamento e características próprias do SGBD escolhido.

1.O que precisa ser decidido

• Nome da tabela e das colunas, seguindo um padrão de nomenclatura;
• Tipo de dado de cada coluna;
• Tamanho, precisão e escala, quando aplicável;
• Se a coluna aceita valor nulo;
• Chave primária e chaves únicas;
• Chaves estrangeiras;
• Regras de domínio (o conjunto de valores válidos);
• Índices necessários;
• Particionamento, se aplicável;
• Estratégia de histórico e volumetria esperada;
• Frequência de leitura e de escrita esperada.

2.Exemplos de decisão de tipo

situacao CHAR(1),
CONSTRAINT ck_conta_situacao CHECK (situacao IN ('A', 'I'))

Uma alternativa à segunda abordagem é criar uma chave estrangeira para uma tabela de domínio (por exemplo, TIPO_SITUACAO), em vez de um CHECK fixo. A escolha entre as duas depende da estabilidade do valor, da necessidade de descrição textual associada e da governança sobre esse domínio: valores muito estáveis e simples favorecem o CHECK; domínios que crescem, mudam ou precisam de descrição mais rica favorecem a tabela de domínio.

3.Resumo relâmpago

• Converter modelo lógico em físico envolve nome, tipo, tamanho, nulidade, chaves, domínio, índices e particionamento.
• CPF costuma ser CHAR de tamanho fixo, não numérico.
• Valores monetários exigem tipo decimal com precisão exata, não ponto flutuante.
• Domínios simples e estáveis podem usar CHECK; domínios que mudam ou crescem favorecem tabela de domínio com chave estrangeira.
• Nenhum modelo inicial deve ser apresentado como "pronto para produção" sem validação adicional.

Constraints

Constraints são regras aplicadas diretamente pelo banco de dados para garantir que os dados armazenados respeitem restrições de integridade, independentemente da aplicação que os insere.

1.Principais tipos de constraint

2.Constraint não é sinônimo de índice

3.Resumo relâmpago

• Constraints são regras de integridade aplicadas pelo próprio banco de dados.
• Os tipos principais são NOT NULL, PRIMARY KEY, UNIQUE, FOREIGN KEY e CHECK.
• Constraint é regra de integridade; índice é estrutura de acesso — não são sinônimos.
• Um SGBD pode criar um índice de apoio para sustentar uma PK ou UK, sem que isso una os dois conceitos.

Índices

Índice é uma estrutura que ajuda o SGBD a localizar registros sem necessariamente precisar ler a tabela inteira. Não é, porém, uma melhoria automática e gratuita: todo índice tem custo.

1.O custo de um índice

Criar um índice não traz apenas benefícios. Ele ocupa espaço em disco, aumenta o trabalho necessário em cada INSERT, UPDATE e DELETE (pois o índice também precisa ser atualizado), exige manutenção periódica, pode nunca chegar a ser utilizado pelo otimizador de consultas, e pode até confundir uma análise superficial de desempenho.

2.O que investigar antes de criar um índice

Antes de decidir por um índice, é necessário investigar: as consultas reais executadas sobre a tabela, os filtros usados, os joins envolvidos, a necessidade de ordenação, a cardinalidade e a seletividade das colunas candidatas, o volume de dados, a frequência de leitura em comparação com a de escrita, os índices já existentes, o plano de execução das consultas e as estatísticas disponíveis sobre a tabela.

3.Índice composto

Um índice pode ser criado sobre mais de uma coluna — um índice composto. A ordem das colunas dentro desse índice importa: o índice é mais eficiente para consultas que filtram primeiro pela coluna que aparece em primeiro lugar na definição do índice.

CREATE INDEX ix_transacao_conta_data
    ON transacao (id_conta, data_hora);

Esse índice tende a ser adequado para uma consulta como:

SELECT *
FROM transacao
WHERE id_conta = ?
  AND data_hora BETWEEN ? AND ?;

porque a consulta filtra primeiro por id_conta (a primeira coluna do índice) e depois por um intervalo de data_hora (a segunda coluna).

4.Resumo relâmpago

• Índice acelera buscas, mas tem custo de espaço e de manutenção em escritas.
• Antes de criar, é preciso analisar consultas reais, seletividade, volume e plano de execução.
• Alta seletividade favorece índice; baixa seletividade normalmente não.
• Em índice composto, a ordem das colunas importa e deve seguir o padrão de acesso das consultas.

Análise de performance

Performance não se resume à afirmação genérica de que "uma consulta está lenta". É uma investigação estruturada, feita por camadas, que só termina em uma decisão depois de reunir evidências.

1.Perguntas de investigação

Diante de uma consulta lenta, a investigação percorre perguntas como: qual operação está lenta e qual era o tempo esperado; houve alguma mudança recente no sistema, no volume de dados ou nas estatísticas; qual é a frequência de execução dessa consulta; o plano de execução mudou; as estatísticas da tabela estão atualizadas; está ocorrendo uma leitura completa (full scan) desnecessária; o índice existente é adequado para essa consulta; o join está estruturado corretamente; existe alguma função ou conversão de tipo aplicada sobre a coluna filtrada, o que pode impedir o uso de um índice; a estimativa de cardinalidade feita pelo otimizador está correta; existe contenção ou bloqueio (lock) envolvido; há limitação de memória, de entrada e saída (I/O) ou de espaço temporário; e, por fim, se o problema está de fato no banco de dados, ou na aplicação, na rede ou em uma integração externa.

2.A ordem profissional de análise

A sequência recomendada segue esta ordem:

3.Resumo relâmpago

• Performance é investigada por camadas: SQL, volume, plano, estatísticas, índices, joins, locks, recursos.
• A ordem correta é: evidência, hipótese, teste, medição, decisão, documentação.
• Nunca propor solução (como "criar um índice") antes de reunir evidências.
• O problema pode estar no banco, na aplicação, na rede ou em uma integração — não presumir a causa.

Desnormalização

Desnormalização é a introdução intencional e controlada de redundância, ou de estruturas derivadas, em um modelo já normalizado — quase sempre motivada por uma necessidade real de desempenho.

1.Quando considerar desnormalização

• Existe um problema de desempenho comprovado, não apenas suposto;
• A consulta afetada é crítica para o negócio;
• O custo dos joins envolvidos é relevante e mensurável;
• Há grande diferença entre o volume de leitura e o de escrita, favorecendo a leitura;
• Existe uma necessidade analítica específica que justifica a estrutura derivada.

2.Antes de desnormalizar

3.Resumo relâmpago

• Desnormalização é redundância controlada, motivada por necessidade de desempenho comprovada.
• Deve ser precedida de medição, confirmação do gargalo e avaliação de alternativas.
• Exige mecanismo definido de atualização, para não gerar dados divergentes.
• Nunca deve ser a primeira opção diante de um problema de performance ainda não medido.

Particionamento

Particionamento é a divisão lógica e física de uma tabela em partes menores e mais administráveis, mantendo a tabela como uma única entidade do ponto de vista de quem a consulta.

1.Tipos comuns de particionamento

2.Benefícios possíveis

Particionar uma tabela pode trazer: partition pruning (o otimizador consulta apenas as partições relevantes, ignorando as demais); manutenção realizada por partes, sem afetar a tabela inteira; cargas e exclusões feitas em blocos, de forma mais eficiente; melhor organização de grandes volumes de dados; separação natural entre dados recentes e dados históricos; e possibilidade de usar estratégias de armazenamento diferenciadas por partição.

3.Perguntas antes de particionar

• A maioria das consultas relevantes filtra pela coluna candidata a chave de particionamento?
• Existem consultas frequentes apenas por identificador, sem informar essa coluna?
• Qual é o crescimento esperado por período?
• Como funciona a retenção dos dados mais antigos?
• Podem existir dados que chegam atrasados, fora da janela de tempo esperada?
• Qual será o número de partições e como isso é mantido ao longo do tempo?
• Os índices serão locais (por partição) ou globais (sobre a tabela inteira)?
• Como ocorrerão as cargas, a manutenção e o expurgo de partições antigas?

4.Resumo relâmpago

• Particionamento divide uma tabela em partes administráveis: range, list ou hash.
• Pode trazer pruning, manutenção facilitada, cargas em blocos e separação de histórico.
• Não substitui modelagem nem indexação — depende do padrão real de consultas.
• A escolha da chave de particionamento deve ser compatível com o que a maioria das consultas filtra.

Storage e organização física

Storage e organização física tratam de como os dados efetivamente ocupam espaço em disco e memória. O nível de profundidade esperado aqui é conceitual, não a configuração detalhada de um SGBD específico.

1.Conceitos essenciais

2.Resumo relâmpago

• Storage trata de como os dados ocupam espaço em disco e memória.
• Conceitos-chave: página/bloco, tablespace, buffer pool, área temporária, log de transações.
• A decisão física considera volumetria, crescimento, padrão de acesso e características do SGBD.
• O nível de profundidade esperado é conceitual, não configuração detalhada de plataforma específica.

Transações e ACID

Uma transação é um conjunto de operações tratadas como uma única unidade de trabalho. O acrônimo ACID descreve as quatro propriedades que uma transação confiável deve garantir.

1.As quatro propriedades

2.Atomicidade em detalhe

3.Resumo relâmpago

• ACID: Atomicidade, Consistência, Isolamento e Durabilidade.
• Atomicidade: tudo ou nada.
• Consistência: sempre de um estado válido para outro estado válido.
• Isolamento: transações concorrentes não interferem indevidamente entre si.
• Durabilidade: resultado confirmado persiste mesmo após falhas previstas.

Concorrência, isolamento e deadlock

Quando várias transações são executadas ao mesmo tempo sobre os mesmos dados, surgem fenômenos específicos que o nível de isolamento escolhido busca controlar.

1.Os fenômenos de concorrência

2.Locks e MVCC

Um lock (bloqueio) é um mecanismo que impede que outra transação acesse ou altere um recurso enquanto ele está sendo usado, garantindo isolamento. Uma abordagem alternativa, usada por diversos SGBDs modernos, é o MVCC (controle de concorrência multiversão): em vez de bloquear leitores, o SGBD mantém versões diferentes de um mesmo dado, permitindo que uma transação leia uma versão consistente sem ser bloqueada por escritas concorrentes.

3.Deadlock

Um deadlock (impasse) ocorre quando duas ou mais transações ficam esperando indefinidamente por recursos bloqueados umas pelas outras, formando um ciclo de espera sem saída.

Prevenções e mitigações comuns incluem: acessar os recursos sempre na mesma ordem em todas as transações; manter transações curtas; usar índices adequados para reduzir o escopo de bloqueio; reduzir a quantidade de recursos bloqueados simultaneamente; implementar tratamento de repetição (retry) para transações que forem escolhidas como vítimas; monitorar a ocorrência de deadlocks; e evitar interação humana (como uma tela aguardando confirmação do usuário) durante uma transação aberta.

4.Resumo relâmpago

• Dirty read: lê dado não confirmado. Non-repeatable read: mesmo registro muda entre duas leituras. Phantom read: o conjunto de registros muda entre duas consultas. Lost update: uma atualização sobrescreve outra sem considerar a mudança intermediária.
• O comportamento exato de isolamento varia entre SGBDs — não presumir uniformidade.
• Lock bloqueia acesso concorrente; MVCC usa versões para evitar bloqueio de leitores.
• Deadlock é uma espera circular entre transações, prevenida principalmente por ordem consistente de acesso e transações curtas.

Cliente, conta e transação

Este é o caso mais completo do material, reunindo modelo lógico, decisões físicas e DDL. É o tipo de exercício com maior probabilidade de aparecer em uma avaliação técnica ou produção temática.

1.Enunciado provável

2.Ângulo AD — o modelo

O primeiro passo é identificar as entidades (Cliente, Conta, Transação) e reconhecer que a relação entre Cliente e Conta é muitos-para-muitos, o que exige uma entidade associativa.

CLIENTE
- ID_CLIENTE PK
- CPF UK
- NOME
- DATA_NASCIMENTO
- DATA_CADASTRO

CONTA
- ID_CONTA PK
- NUMERO_CONTA UK
- TIPO_CONTA
- DATA_ABERTURA
- SITUACAO

CLIENTE_CONTA
- ID_CLIENTE PK/FK
- ID_CONTA PK/FK
- TIPO_TITULARIDADE
- DATA_INICIO
- DATA_FIM

TRANSACAO
- ID_TRANSACAO PK
- ID_CONTA FK
- DATA_HORA
- TIPO_TRANSACAO
- VALOR
- SITUACAO

Pontos que merecem explicação explícita ao apresentar esse modelo:

• CLIENTE_CONTA resolve a relação N:N entre cliente e conta;
• o CPF pode ser único (restrição UNIQUE), mas não precisa necessariamente ser a chave primária física;
• uma chave substituta, como ID_CLIENTE, reduz o acoplamento ao significado externo do CPF;
• a chave estrangeira em TRANSACAO protege a integridade referencial em relação a CONTA;
• dados pessoais (nome, CPF, data de nascimento) precisam de classificação de sensibilidade e controle de acesso adequado.

3.Ângulo DBA — a implementação

CREATE TABLE CLIENTE (
    ID_CLIENTE BIGINT NOT NULL,
    CPF CHAR(11) NOT NULL,
    NOME VARCHAR(150) NOT NULL,
    DATA_NASCIMENTO DATE,
    DATA_CADASTRO TIMESTAMP NOT NULL,
    CONSTRAINT PK_CLIENTE PRIMARY KEY (ID_CLIENTE),
    CONSTRAINT UK_CLIENTE_CPF UNIQUE (CPF)
);

CREATE TABLE CONTA (
    ID_CONTA BIGINT NOT NULL,
    NUMERO_CONTA VARCHAR(20) NOT NULL,
    TIPO_CONTA VARCHAR(20) NOT NULL,
    DATA_ABERTURA DATE NOT NULL,
    SITUACAO CHAR(1) NOT NULL,
    CONSTRAINT PK_CONTA PRIMARY KEY (ID_CONTA),
    CONSTRAINT UK_CONTA_NUMERO UNIQUE (NUMERO_CONTA),
    CONSTRAINT CK_CONTA_SITUACAO CHECK (SITUACAO IN ('A', 'I'))
);

CREATE TABLE CLIENTE_CONTA (
    ID_CLIENTE BIGINT NOT NULL,
    ID_CONTA BIGINT NOT NULL,
    TIPO_TITULARIDADE VARCHAR(20) NOT NULL,
    DATA_INICIO DATE NOT NULL,
    DATA_FIM DATE,
    CONSTRAINT PK_CLIENTE_CONTA
        PRIMARY KEY (ID_CLIENTE, ID_CONTA),
    CONSTRAINT FK_CC_CLIENTE
        FOREIGN KEY (ID_CLIENTE) REFERENCES CLIENTE(ID_CLIENTE),
    CONSTRAINT FK_CC_CONTA
        FOREIGN KEY (ID_CONTA) REFERENCES CONTA(ID_CONTA)
);

CREATE TABLE TRANSACAO (
    ID_TRANSACAO BIGINT NOT NULL,
    ID_CONTA BIGINT NOT NULL,
    DATA_HORA TIMESTAMP NOT NULL,
    TIPO_TRANSACAO VARCHAR(30) NOT NULL,
    VALOR DECIMAL(15,2) NOT NULL,
    SITUACAO CHAR(1) NOT NULL,
    CONSTRAINT PK_TRANSACAO PRIMARY KEY (ID_TRANSACAO),
    CONSTRAINT FK_TRANSACAO_CONTA
        FOREIGN KEY (ID_CONTA) REFERENCES CONTA(ID_CONTA)
);

CREATE INDEX IX_TRANSACAO_CONTA_DATA
    ON TRANSACAO (ID_CONTA, DATA_HORA);

Pontos que merecem explicação explícita sobre a implementação:

• o índice em (ID_CONTA, DATA_HORA) atende bem a uma consulta de extrato por conta em um intervalo de datas;
• a tabela TRANSACAO é candidata a particionamento conforme o volume, o crescimento, a regra de negócio e o SGBD utilizado;
• a retenção dos dados deve ser definida pelo gestor da informação, segundo regras e normativos, não como decisão técnica isolada;
• dados históricos podem ser separados do ambiente transacional quando deixarem de ser necessários no dia a dia operacional;
• qualquer desnormalização futura exigiria justificativa comprovada;
• qualquer alteração nesse modelo, depois de implantado, exige análise de impacto, validação, versionamento e teste.

Essa resposta demonstra maturidade: reconhece o valor do modelo apresentado sem superestimar sua prontidão para um ambiente real de produção.

Clientes duplicados

Um cenário de qualidade de dados que aparece com frequência em instituições com muitos canais de atendimento: o mesmo cliente termina cadastrado mais de uma vez.

1.Enunciado provável

2.Ângulo AD — governança e qualidade

• Definir o conceito corporativo de "cliente" de forma clara e única;
• identificar a fonte oficial dessa informação;
• estabelecer regras de matching (correspondência) para identificar registros que provavelmente representam a mesma pessoa;
• definir a responsabilidade pela governança desse dado (data stewardship);
• criar um golden record — o registro consolidado considerado a versão correta e oficial;
• estabelecer indicadores de qualidade para acompanhar a taxa de duplicidade ao longo do tempo;
• documentar os critérios usados para decidir qual informação "sobrevive" quando dois registros são consolidados.

3.Ângulo DBA — implementação

• Definir quais restrições de unicidade são viáveis, considerando que uma constraint simples não resolve diferenças semânticas (como "João da Silva" e "João Silva");
• criar estruturas adequadas para manter o histórico da consolidação (o que foi mesclado com o quê, e quando);
• indexar os campos usados na busca por possíveis duplicidades, para viabilizar o processo de identificação em bases grandes;
• evitar bloqueios excessivos durante tratamentos em massa de dados;
• acompanhar o custo de performance das atualizações necessárias para a consolidação.

Consulta lenta

O caso clássico de diagnóstico de performance, útil para demonstrar método de investigação em vez de solução imediata sem embasamento.

1.Enunciado provável

2.Perguntas a fazer, em ordem

• Qual é o SQL exato executado?
• Qual é o volume de dados envolvido (total da tabela e total retornado)?
• Quais filtros são aplicados?
• Qual é o intervalo típico de datas consultado?
• Qual é o plano de execução atual?
• As estatísticas da tabela estão atualizadas?
• Existe algum índice sobre as colunas filtradas?
• A ordem das colunas no índice existente atende a essa consulta?
• Existe alguma função ou conversão de tipo aplicada sobre a coluna filtrada?
• Há indícios de bloqueio (lock) concorrente no momento da consulta?
• A tabela está particionada de forma compatível com esse padrão de consulta?

Compartilhamento com ambiente analítico

Um cenário que combina compartilhamento de dados, privacidade e arquitetura — três temas frequentemente cobrados de forma isolada, mas que aqui aparecem juntos.

1.Enunciado provável

2.Ângulo AD — finalidade, privacidade e governança

• Confirmar a finalidade específica do compartilhamento;
• identificar o conjunto mínimo de dados necessário para essa finalidade (não necessariamente todos os campos existentes);
• classificar a informação quanto à sensibilidade;
• verificar a base legal e a legitimidade do uso, sob a ótica da LGPD;
• definir se é necessário mascaramento ou pseudonimização de dados pessoais para essa finalidade específica;
• documentar a fonte oficial e a periodicidade de atualização dos dados compartilhados;
• registrar a linhagem, permitindo rastrear a origem do dado dentro do ambiente analítico;
• controlar o acesso ao dado compartilhado;
• definir a política de retenção específica para essa cópia analítica.

3.Ângulo DBA — impacto operacional

• Evitar que a extração de dados impacte o desempenho do ambiente transacional de origem;
• escolher um mecanismo de extração adequado (por exemplo, um processo de ETL agendado em horário de menor movimento, em vez de uma consulta direta e recorrente sobre o ambiente de produção);
• controlar o volume e a frequência da carga de dados;
• proteger as credenciais utilizadas no processo de integração;
• monitorar o volume de dados movimentado;
• garantir o nível de consistência necessário entre a origem e o ambiente analítico (por exemplo, se pequenos atrasos na atualização são aceitáveis);
• manter os ambientes transacional e analítico fisicamente separados.

Seu posicionamento e o que a banca precisa perceber

Esta parte do material é pessoal: fala diretamente com você, sobre como se apresentar. A estratégia central não é competir em "tempo de casa" com quem já atua no Capítulo — é ocupar um espaço diferente.

1.A estratégia central

Quem já trabalha no Capítulo provavelmente tem vantagem em ferramentas, rotinas e conhecimento tácito. Tentar imitar essa vivência tecnicamente carrega o risco de soar artificial. Sua estratégia é ocupar outro espaço: o de quem demonstra fundamentos sólidos, preparo deliberado, visão do processo completo, respeito às normas, capacidade de organizar problemas e velocidade de aprendizagem.

O diferencial é a combinação de: clareza de propósito, respeito aos processos, fundamento técnico, raciocínio estruturado, capacidade de aprender, comunicação objetiva e evidências reais de comportamento — não apenas discurso.

2.Seu posicionamento entre AD e DBA

A recomendação é posicionar-se inicialmente com preferência por Administrador de Dados, mantendo abertura e base para DBA. Isso combina com organização de contexto, análise, documentação, visão de processo, comunicação e a experiência que você já tem de formalização de demandas, ambientes, integrações e articulação técnica.

3.As cinco convicções que a banca precisa sair com

4.O que funciona e o que prejudica

5.Sua frase de identidade

Use estas frases ao longo da entrevista, sem repeti-las literalmente muitas vezes:

6.A mensagem que precisa ficar na cabeça da banca

Não existe forma honesta de garantir aprovação entre os primeiros colocados. Mas esse posicionamento reduz a desvantagem natural de quem tem menos tempo de casa: você não concorre como "quem sabe mais ferramentas hoje", concorre como quem apresenta a melhor combinação de propósito, fundamento, processo, maturidade e potencial de entrega.

Abertura, frases de identidade e como falar da CAIXA

Aqui está o roteiro de abertura de aproximadamente 90 segundos, o método C-A-I-X-A para estruturar qualquer resposta comportamental, e as três histórias reais já prontas para uso.

1.Roteiro de entrada — cerca de 90 segundos

Essa abertura comunica, em sequência: identidade, conexão com a experiência real, conhecimento do Capítulo, preferência declarada, humildade, prontidão e compromisso institucional.

2.O método C-A-I-X-A

Além do modelo tradicional STAR (Situação, Tarefa, Ação, Resultado), este material recomenda uma adaptação mais fácil de lembrar, usando o próprio nome da instituição:

Para uma banca com tempo limitado, a proporção recomendada é: contexto em duas frases, sua responsabilidade em uma frase, ações em três ou quatro frases, resultado e aprendizado em duas frases, e conexão com a vaga em uma frase.

3.Suas três histórias reais, prontas para uso

História 1 — Formalização de demandas técnicas

Em uma reunião de entendimento e alinhamento de prioridades, você ficou responsável por estruturar textos detalhados de tarefas de backlog relacionadas a ambientes não produtivos, atualização de versões/hotfix e recursos de máquina. Competências que essa história demonstra: organização, documentação, comunicação entre áreas, respeito ao processo, rastreabilidade, entendimento de ambientes não produtivos e capacidade de transformar conversa em demanda estruturada.

História 2 — Aprender dialogando com especialistas

Em uma discussão técnica, houve conversa sobre obtenção de identificadores por meio de joins, tabelas de controle, tempos de execução, ETL e problemas de performance envolvendo acesso entre instâncias. Você participou buscando compreender os limites técnicos, conectar especialistas e organizar o entendimento entre o lado técnico e o de negócio. Competências demonstradas: curiosidade técnica, humildade, escuta, integração entre pessoas, busca de causa, aprendizado ativo e capacidade de reconhecer limites.

História 3 — Padronização de requisitos

Em uma reunião de refinamento de backlog e processos, foram discutidos requisitos e critérios de aceitação para histórias de integração de dados, diferença entre serviço e funcionalidade, DDL, massa de dados, documentação, ambientes e esteiras. Competências demonstradas: visão de processo, critérios de aceitação, integração de dados, documentação, preocupação com consistência e trabalho multidisciplinar.

Perguntas prováveis e respostas-relâmpago

Um conjunto de perguntas comportamentais com respostas estratégicas prontas, seguido das respostas técnicas rápidas que precisam sair em 30 a 45 segundos cada.

1.Perguntas comportamentais e estratégicas

"Por que você quer trabalhar no Capítulo?"

"Por que escolher você e não alguém que já trabalha com isso?"

"Você não tem experiência específica. Por que está pronto?"

"AD ou DBA?"

"O que você faz quando não sabe?"

"Norma atrapalha a agilidade?"

"Qual seu ponto de desenvolvimento?"

"Conte um erro ou dificuldade"

2.Respostas-relâmpago técnicas

Cada uma destas precisa sair em cerca de 30 a 45 segundos, sem hesitação — o conteúdo completo de cada assunto já foi trabalhado nos temas técnicos deste material.

Presença, protocolo L-I-D-A-R e perguntas difíceis

Como se apresentar em voz, corpo e linguagem, e um protocolo estruturado para nunca travar diante de uma pergunta técnica difícil.

1.Presença: voz, corpo e linguagem

Linguagem que ajuda

• "Minha compreensão é…"
• "Eu separaria o problema em…"
• "Antes de decidir, eu validaria…"
• "A decisão depende de…"
• "O risco principal é…"
• "A norma orienta…"
• "Eu buscaria evidência no plano de execução…"
• "Eu documentaria a justificativa…"
• "No nível júnior, eu conduziria a análise e validaria com o especialista responsável."

Linguagem a evitar

• "Isso é fácil."
• "É só criar um índice."
• "Sempre se faz assim."
• "A norma manda."
• "Eu manjo."
• "Não sei nada disso."
• "Nunca trabalhei com isso."
• "Acho que seria mais ou menos…"

2.Protocolo L-I-D-A-R para perguntas difíceis

Produção temática, fechamento e erros que eliminam credibilidade

Um modelo pronto para uma eventual produção temática escrita, o fechamento recomendado da entrevista, e a lista de frases que nunca deveriam ser ditas.

1.Sobre a produção temática

2.Modelo universal de produção temática

Um título curto, técnico e orientado a valor — por exemplo, "Dados confiáveis como base para eficiência, segurança e transformação digital na CAIXA" — seguido de sete partes:

3.Fechamento da entrevista

4.Erros que eliminam credibilidade

Frases que nunca deveriam ser ditas durante a entrevista, porque substituem critério por certeza artificial:

Plano intensivo de 15 dias

Um plano dia a dia para quem tem pouco tempo até a entrevista. Cada dia é dividido em três blocos: aprender, aplicar e falar sem consulta — porque a entrevista exige recuperação ativa, não apenas leitura passiva.

Plano de 4 semanas, material mínimo e autoavaliação

Para quem tem mais tempo disponível até a entrevista, um plano mais espaçado, com rotina diária sugerida, seguido do material mínimo que deveria existir ao final da preparação e de um sistema simples de autoavaliação por tema.

1.Rotina diária sugerida

Total aproximado: duas horas e meia por dia.

2.Semana 1 — fundamentos relacionais

Estudar: banco e SGBD, tabelas, linhas e colunas, entidade, atributo e relacionamento, cardinalidade, PK/FK/UK, modelo conceitual/lógico/físico, normalização, SQL básico, DDL.

Entregas: três modelos, cinco normalizações, dois DDLs, quinze consultas SQL, explicação oral de quinze conceitos.

3.Semana 2 — Administração de Dados

Estudar: DMBOK, governança, qualidade, metadados, linhagem, arquitetura, compartilhamento, reuso, segurança, privacidade, ciclo de vida, dados mestres e de referência.

Entregas: mapa das onze áreas do DMBOK, o caso de clientes duplicados, o caso de compartilhamento analítico, um catálogo de vinte atributos, trinta itens de revisão, uma apresentação de cinco minutos sobre AD.

4.Semana 3 — fundamentos de DBA

Estudar: do lógico ao físico, tipos, constraints, índices, planos de execução, estatísticas, performance, particionamento, storage, ACID, isolamento, locks, deadlocks, desnormalização.

Entregas: três DDLs, análise de dez consultas, proposta de cinco índices, cinco cenários de concorrência, duas estratégias de particionamento, análise de um problema de performance.

5.Semana 4 — entrevista e casos

Preparar: seis histórias em C-A-I-X-A, trinta respostas técnicas, os quatro casos de estudo completos, três produções temáticas, cinco entrevistas simuladas, gravação da abertura e do fechamento, revisão dos normativos internos e revisão dos erros técnicos mais comuns.

6.Material mínimo ao final da preparação

• 1 apresentação de 90 segundos
• 1 fechamento de 30 segundos
• 6 histórias comportamentais em C-A-I-X-A
• 30 respostas técnicas curtas
• 5 modelos relacionais
• 5 exercícios de normalização
• 3 DDLs completas
• 10 análises de índices
• 5 cenários de concorrência
• 1 mapa do DMBOK
• 1 resumo da TE073confirmar internamente
• 1 resumo da TE074confirmar internamente
• 2 produções temáticas
• 3 simulações de entrevista gravadas
• 1 página final de revisão

7.Sistema de autoavaliação

Para cada tema estudado, é possível atribuir uma nota de 0 a 2 em cinco critérios, totalizando até 10 pontos por tema. Um tema só deveria ser considerado dominado ao atingir pelo menos 8 pontos.

Uma forma prática de usar esse sistema: para cada tema técnico deste material, tentar explicá-lo em voz alta, sem consultar a tela, em até 45 segundos, incluindo uma definição, um exemplo, um risco e uma conexão com a CAIXA — e então avaliar honestamente a própria resposta com os cinco critérios acima.

8.Estrutura recomendada para qualquer resposta técnica

Essa estrutura impede respostas decoradas e superficiais, porque força a passagem por definição, motivo, critério, risco, exemplo prático e validação — exatamente os elementos que uma banca técnica busca em uma resposta madura.

Cobertura do edital

Esta tabela cruza cada item do escopo divulgado para o processo seletivo com o tema deste material que o ensina, para confirmar, de relance, que nada do que pode ser cobrado ficou de fora.

1.Administrador de Dados

2.Administrador de Banco de Dados

3.Conteúdo além do escopo mínimo

Além de cobrir integralmente os itens listados no edital, este material inclui três frentes que não são exigidas explicitamente no escopo, mas que aumentam a chance de uma boa avaliação na entrevista: