Analista Judiciário - Tecnologia da Informação - Analista de Sistemas
O analista Otto precisa criar a tabela PROCESSOS garantindo que:1. o número do processo seja único e obrigatório.2. o status só possa ser “ABERTO”, “FECHADO” ou “EM_ANDAMENTO”.3. a coluna ID seja chave primária gerada automaticamente.Para garantir a integridade dos dados, no PostgreSQL, Otto deve implementar:
Aindexes;
Btriggers;
Cschemas;
Dsequences;
Econstraints.
Revelar gabarito e comentário▾
GabaritoE — constraints.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
PostgreSQL: Constraints para integridade dos dados
Gabarito: letra E. Para garantir unicidade, obrigatoriedade, restrição de valores e chave primária automática, Otto deve usar constraints (restrições de integridade) – recurso nativo do SQL que inclui PRIMARY KEY, UNIQUE, NOT NULL e CHECK. Nenhum dos outros mecanismos (indexes, triggers, schemas, sequences) atende simultaneamente a todos os requisitos de forma declarativa e eficiente.
A banca testa o conhecimento de como implementar regras de integridade em bancos relacionais. As três condições do enunciado se traduzem diretamente em constraints:
Número do processo único e obrigatório → UNIQUE + NOT NULL (ou PRIMARY KEY, que já implica ambos).
Status com valores fixos → CHECK (ex.: CHECK (status IN ('ABERTO','FECHADO','EM_ANDAMENTO'))).
ID autoincrementado como chave primária → SERIAL + PRIMARY KEY (o SERIAL é um atalho que cria uma sequência, mas a restrição de chave primária é uma constraint).
Alternativa A — ❌ Incorreta
Indexes (índices) aceleram consultas e podem reforçar unicidade (índice UNIQUE), mas não garantem obrigatoriedade (NOT NULL) nem restringem valores (CHECK). Também não geram valores automáticos. São um complemento, não a solução principal.
Alternativa B — ❌ Incorreta
Triggers (gatilhos) permitem executar código antes/depois de operações e poderiam simular as restrições, mas a abordagem declarativa (constraints) é a forma nativa e preferida no PostgreSQL. Além disso, triggers aumentam a complexidade e o custo de manutenção. Para as exigências dadas, constraints bastam.
Alternativa C — ❌ Incorreta
Schemas (esquemas) são contêineres lógicos para agrupar objetos do banco (tabelas, views, etc.). Não impõem regras sobre dados de colunas; apenas organizam o catálogo.
Alternativa D — ❌ Incorreta
Sequences (sequências) geram números sequenciais únicos, úteis para chaves autoincrementadas. Porém, não garantem obrigatoriedade, não validam valores e não criam a restrição de chave primária. Uma coluna com SERIAL precisa de PRIMARY KEY (uma constraint) para ser efetivamente chave.
Alternativa E — ✅ Correta ⟵ GABARITO
Constraints são o recurso correto. No PostgreSQL, as constraints disponíveis incluem:
PRIMARY KEY (unicidade + não nulo + identificador único da linha)
UNIQUE (unicidade)
NOT NULL (obrigatoriedade)
CHECK (validação de valores)
FOREIGN KEY (integridade referencial)
Com elas, Otto implementa todas as condições de forma declarativa, eficiente e integrada ao mecanismo de integridade do banco.
NÃO CAIA NESSA!
O candidato pode achar que sequences (alternativa D) são a resposta porque o enunciado cita chave primária gerada automaticamente. De fato, sequences são usadas internamente pelo tipo SERIAL, mas a garantia de integridade (chave primária) vem da constraint PRIMARY KEY, não da sequência isoladamente. A presença da palavra "automática" pode desviar o foco para sequences, mas a questão pede o que garante a integridade – e isso são constraints.