Material de Estudo - Concursos

TECNOLOGIA DA INFORMAÇÃO | BLOCO 02: Conceitos de BDs e SGBDs

1. TI - Banco de Dados - Transações (Locks, ACID, etc.)

Conceito	O que você precisa saber	Como a banca cobra
ACID	Atomicidade, Consistência, Isolamento, Durabilidade (cada uma com “função” diferente)	Troca de definições (ex.: “consistência = tudo ou nada”)
Controle de concorrência	Evita anomalias (ex.: atualização perdida) usando mecanismos como bloqueios (locks)	“Concorrência” NÃO é “garantida por índices/views”
2PL (two-phase locking)	Protocolo de bloqueios em duas fases; o 2PL estrito mantém locks até o fim	“2PL impede deadlock” (pegadinha: NÃO)
Recuperação	Log/commit/checkpoint (não é “ignorar tudo após o último checkpoint” de forma absoluta)	Confusão entre o que é refeito (redo) e desfeito (undo)
2PC (two-phase commit)	Commit distribuído; tem custo/overhead e pode ser ruim em alta latência/falhas	“Recomendado como 1ª opção em alta latência” (pegadinha)

(ACID e responsabilidades típicas: concorrência ↔ isolamento; recuperação ↔ atomicidade/durabilidade).

⚠️ Fique esperto! Aqui o bicho pega!

NÃO confunda atomicidade (tudo-ou-nada / rollback) com consistência (respeito às regras/restrições): a banca troca “garantir processamento completo” por “consistência”, mas isso descreve atomicidade.
Isolamento NÃO significa “execução sempre em sequência, sem sobreposição temporal”: ele exige efeito equivalente a uma execução serial (serializabilidade), mas pode haver concorrência controlada.
Durabilidade NÃO é “manter dados em memória principal até encerrar”: é persistência após commit, mesmo com falhas.
“Acesso concorrente garantido por índices e visões” é clássico para derrubar: concorrência é função de controle de concorrência (locks/MVCC etc.), não de estruturas de consulta.
2PL básico NÃO “impede completamente deadlocks”: deadlock pode ocorrer (ex.: ciclos de espera por locks), exigindo detecção/prevenção.
No 2PL estrito, o ponto-chave é: locks (principalmente exclusivos) ficam retidos até o final da transação; a banca inverte “liberar antes do commit” para confundir.
Em recuperação, a banca pode afirmar que “aplica APENAS registros de transações commitadas e ignora tudo após checkpoint” como regra rígida: cuidado com generalizações sobre log/checkpoint (depende da estratégia de redo/undo).
2PC NÃO é “primeira opção” em ambiente com alta latência/alto número de falhas: o protocolo tende a amplificar espera/bloqueios e custo de coordenação em cenários adversos.
Atualização perdida: ocorre quando duas transações gravam o mesmo dado e a segunda sobrescreve a primeira; a correção é controle de concorrência (não “índice”, não “view”).
Pegadinha de terminologia: “integridade/consistência” aparece como justificativa para qualquer coisa; na prova, amarre sempre à propriedade correta (A/C/I/D).

🎓 Pareto CEBRASPE

ACID cai como associação direta:
Atomicidade ↔ rollback/tudo-ou-nada; NÃO “apenas completar instrução” por “consistência”.
Consistência ↔ restrições/regras (integridade).
Isolamento ↔ transações “parecem” executar isoladas; NÃO “sem sobreposição temporal”.
Durabilidade ↔ persistência pós-commit (logs/recuperação).
Controle de concorrência: objetivo é NÃO comprometer integridade ao executar simultaneamente; “índices/views garantem concorrência” costuma ser ERRADO.
2PL: memorize o núcleo que a banca repete: “duas fases” + “estrito mantém locks até o final” + “deadlock pode existir”.
2PC: use como gatilho mental “distribuído” + “coordenação em duas fases” + “pode ser ruim em alta latência/falhas (custo/espera)”.
Recuperação: log + commit + checkpoint aparecem em itens de “C/E”; desconfie de frases absolutas com APENAS, SEMPRE, NUNCA.
“Serializabilidade” é a palavra-chave por trás do isolamento (resultado como se fosse em sequência), sem exigir execução literal sequencial.
Quando a banca mistura “integridade” com “concorrência”, a resposta quase sempre está em: integridade ↔ regras; concorrência ↔ mecanismo de sincronização.
Anomalias de concorrência (ex.: atualização perdida) são tratadas por controle de concorrência; a banca troca causa/solução para confundir.
Em itens sobre “propriedades”, procure a definição operacional: “o que garante” + “em que momento” (antes/depois do commit).

✍️ Exemplo na prática

[CEBRASPE – 2025 – TJ TRF6 (Suporte Técnico) – TRF 6] – https://www.tecconcursos.com.br/questoes/3259954

Ponto-chave: ACID = quatro propriedades; “processamento completo para evitar perda” descreve atomicidade, não “consistência”. Pegadinha: a banca troca o nome da propriedade, mantendo a definição (ou vice-versa).

[CEBRASPE – 2025 – Tec TI – BANRISUL] – https://www.tecconcursos.com.br/questoes/3455769

Ponto-chave: concorrência é garantida por controle de concorrência (ex.: locks/2PL), NÃO por índices/views. Pegadinha: usar termos “de BD” (índice/view) para justificar característica “de transação” (concorrência).

[CEBRASPE – 2025 – GAAPC (Analista de Informática/BD) – PC DF] – https://www.tecconcursos.com.br/questoes/3238275

Ponto-chave: 2PL estrito mantém bloqueios até o fim (serializabilidade), e deadlock PODE ocorrer. Pegadinha: afirmar que 2PL “impede completamente deadlocks” ou inverter o momento de liberação dos locks.

2. TI - Banco de Dados - Conceitos e Fases de Projeto e Modelagem de Dados

Conceito	O que você precisa saber	Como a banca cobra
Modelo conceitual	“Quais dados” (entidades, atributos, relacionamentos); visão macro (ex.: MER/DER)	NÃO depende de SGBD/hardware
Modelo lógico	Estruturas de BD no nível do tipo/classe do SGBD (ex.: relacional)	Depende do tipo de SGBD
Modelo físico	Armazenamento, índices, detalhes de implementação	Depende do SGBD específico

Atenção: “CONCEITUAL” existe em dois lugares diferentes: MODELO conceitual (hierarquia de modelos) ≠ NÍVEL conceitual (arquitetura ANSI/SPARC).

⚠️ Fique esperto! Aqui o bicho pega!

MER/DER é do modelo conceitual (representa entidades/relacionamentos), então é ERRADO dizer que “detalha armazenamento interno” ou que é “derivado do modelo lógico”.
Modelo lógico descreve tabelas/relacionamentos/restrições sem falar do “como armazenar em disco”; a banca tenta empurrar “disco/armazenamento” para o lógico.
Modelo físico NÃO é “visão abstrata identificando entidades e relacionamentos”: isso é “cara” do conceitual.
Arquitetura ANSI/SPARC:
Nível externo = visão do usuário (parte do BD, múltiplas visões).
Nível conceitual = BD inteiro (visão comunitária).
Nível interno = armazenamento físico.
Independência de dados:
Independência lógica: alterar esquema conceitual sem afetar esquemas externos/programas.
Independência física: alterar esquema interno sem afetar o conceitual/external.
Pegadinha recorrente: dizer que a modelagem lógica “refina entidades/atributos da conceitual, mas NÃO define atributos” — contradiz a ideia de detalhamento/refinamento.
“Atributo derivado”: pode existir no modelo sem estar armazenado fisicamente (calculado em tempo de execução); a banca confunde “estar no modelo” com “estar gravado”.
“Abstração no nível de visualização” (externo) é para simplificar a interação do usuário; a banca troca isso por “armazenamento”.
Confusão padrão: “modelo relacional” é modelo lógico; na arquitetura 3 esquemas ele pode representar esquema externo (parte) ou conceitual (inteiro), conforme o uso.
Em questões de “fase do projeto”: conceitual → lógico → físico (nessa ordem), evitando trocar “físico” para antes.

🎓 Pareto CEBRASPE

Trinca que mais aparece: conceitual (MER/DER) → lógico (relacional/tabelas) → físico (armazenamento/índices); a banca cobra invertendo “o que cada um descreve”.
Modelo conceitual = “o que pode aparecer no BD”; NÃO “como o SGBD armazena”.
Dependência:
Conceitual INDEPENDE de SGBD;
Lógico depende do tipo de SGBD;
Físico depende do SGBD específico.
ANSI/SPARC: externo (usuários) / conceitual (comunidade, BD inteiro) / interno (físico).
Independência lógica vs física é cobrada em itens espelhados: “mudar X sem afetar Y”.
“Visão comunitária” é o conceito por trás do nível conceitual (BD inteiro), não “visão de usuário individual”.
A banca força a palavra “conceitual”: cheque se ela está falando de modelo (hierarquia) ou de nível (arquitetura).
Atributo derivado: “estar no modelo” NÃO implica “estar armazenado”.
Questões de certo/errado: procure termos absolutos (“SEMPRE”, “NUNCA”, “APENAS”) na descrição das fases/modelos.

✍️ Exemplo na prática

[CEBRASPE – 2025 – Pesq (EMBRAPA) – EMBRAPA] – https://www.tecconcursos.com.br/questoes/3408658

Ponto-chave: no lógico, entidades/atributos da conceitual são refinados e viram estruturas (tabelas/classes) com detalhamento; “refina, mas não define atributos” tende a distorcer a fase. Pegadinha: negar o próprio sentido de “refinar/detalhar” na modelagem lógica.

[CEBRASPE – 2025 – PCF (Área 3) – PF] – https://www.tecconcursos.com.br/questoes/3548067

Ponto-chave: modelo lógico organiza dados em tabelas/relacionamentos/restrições, sem depender do armazenamento físico em disco. Pegadinha: empurrar “detalhes de disco” (físico) para o lógico.

[CEBRASPE – 2025 – GAAPC (Analista de Informática/BD) – PC DF] – https://www.tecconcursos.com.br/questoes/3238251

Ponto-chave: nível conceitual (ANSI/SPARC) = percepção da comunidade/BD inteiro; externo = visões dos usuários; interno = físico. Pegadinha: trocar “conceitual” por “externo” ou “interno” usando palavras como “comunidade” e “usuários individuais”.

3. TI - Banco de Dados - Definições e Propriedades do SGBD

Conceito	O que você precisa saber	Como a banca cobra
BD (banco de dados)	Coleção coerente de dados com significado; representa “minimundo” e tem finalidade	BD ≠ software
SGBD	Conjunto de programas para criar e manter BD (definir, construir, manipular, compartilhar, proteger, manter)	SGBD ≠ BD
SBD	SBD = BD + SGBD	A banca cobra a soma

Conceitos preliminares e características (autodescrição/catálogo, múltiplas visões, concorrência etc.).

⚠️ Fique esperto! Aqui o bicho pega!

“SGBD permite criar e manter BD” é o núcleo; se a alternativa reduzir SGBD a “armazenamento em disco”, está INCOMPLETA (falta definição/manipulação/compartilhamento/proteção/manutenção).
“Natureza de autodescrição” = BD traz descrição de estrutura/restrições (catálogo/metadados); a banca troca por “descrição fica nos programas” (inversão).
“Suporte a múltiplas visões” é característica do ambiente multiusuário; a banca tenta confundir com “múltiplas cópias físicas” (NÃO é isso).
“Compartilhamento e processamento de transação multiusuário” implica necessidade de controle de concorrência; a banca tenta “explicar” concorrência com índice/view (erro clássico).
“Definição” (DDL/estrutura/restrições) ≠ “manipulação” (consulta/atualização/relatórios); a banca mistura verbos para confundir a função.
Proteção inclui controle contra acesso não autorizado/malicioso; se a alternativa disser que “segurança não é papel do SGBD”, é ERRADA.
Otimização: “plano de execução” NÃO é “criar índice automaticamente”, mas mostrar a sequência de operações que o SGBD fará.
Índice é técnica para acesso rápido sem varrer a tabela inteira; a banca troca “normalização” ou “materialização de visões” como se fosse “índice”.
Metadados: são “dados sobre dados” (descritor) e aparecem como fundamento do catálogo; a banca às vezes usa definição ampla para confundir com “dados operacionais”.
Pegadinha de siglas: se aparecer ETL (extract, transform and load), trate como processo de integração/carga, NÃO como “componente obrigatório” do SGBD por si só (depende do contexto).

🎓 Pareto CEBRASPE

Definições curtas que resolvem 80%:
BD = dados coerentes com significado, “minimundo”, finalidade.
SGBD = programas para criar/manter (definir/construir/manipular/compartilhar/proteger/manter).
SBD = BD + SGBD.
Características campeãs: autodescrição (catálogo/metadados), abstração, independência dados-programas, múltiplas visões, concorrência (controle de concorrência).
Questões de desempenho:
Índices = acesso rápido a registros específicos;
Plano de execução = “sequência de operações” (não “otimização mágica”).
Quando aparecer “concorrência”, pense em transações e controle de concorrência; “índice/view” como garantia costuma ser armadilha.
“Catálogo” é o repositório de descrição (estrutura/restrições); ele separa “estrutura dos dados” dos “programas”.
“Proteção” e “segurança” aparecem como responsabilidades do SGBD (acesso não autorizado/malicioso).
Em itens objetivos (múltipla escolha), procure o verbo: “mostrar/explicar” (plano) vs “criar/implementar” (índice, particionamento etc.).
Se a alternativa for ampla e listar várias funções (definição, manipulação, compartilhamento), tende a estar mais alinhada ao conceito de SGBD.
NÃO confunda “abstração” (oculta detalhes) com “armazenamento” (detalhes físicos).

✍️ Exemplo na prática

[CEBRASPE – 2025 – AFRE RJ – SEFAZ RJ] – https://www.tecconcursos.com.br/questoes/3400209

Ponto-chave: execution plan descreve a sequência de operações que o SGBD executará para responder à consulta. Pegadinha: dizer que o plano “cria índices”, “reescreve automaticamente” ou “particiona” como regra.

[CEBRASPE – 2025 – AFRE RJ – SEFAZ RJ] – https://www.tecconcursos.com.br/questoes/3400205

Ponto-chave: índice permite localizar registros sem examinar toda a tabela (evita varredura completa). Pegadinha: trocar “índice” por “normalização”, “particionamento” ou “materialização de visões”.

[CEBRASPE – 2025 – Pesq (EMBRAPA) – EMBRAPA] – https://www.tecconcursos.com.br/questoes/3408382

Ponto-chave: itens sobre SGBD costumam cobrar “funções/propriedades” (definir, manter, proteger, otimizar). Pegadinha: reduzir SGBD a um único aspecto (ex.: “armazenar”) e ignorar catálogo/metadados/concorrência.

4. TI - Banco de Dados - Visão (View)

Conceito	O que você precisa saber	Como a banca cobra
View (visão)	Tabela virtual derivada de consulta (pré-definida/armazenada)	Em regra, NÃO atualizável
View materializada	Visão armazenada fisicamente (o SGBD mantém/atualiza conforme alterações)	Em regra, atualizável
Finalidade	Expor apenas dados necessários (segurança/abstração/complexidade)	NÃO implica duplicar dados em disco

(Definição e distinção: view virtual vs materializada).

⚠️ Fique esperto! Aqui o bicho pega!

View é “estrutura disponibilizada pelo SGBD”, mas NÃO é “para armazenar tabelas”: ela representa consulta/forma alternativa de visualização.
“View armazena fisicamente os dados duplicando tudo” é pegadinha clássica: isso só faria sentido para view materializada, não para view comum.
View comum: executa a consulta quando referenciada (tabela virtual); “melhorar desempenho por cache físico” é NÃO regra geral.
View materializada: o conteúdo pode estar armazenado, então a afirmação “consulta só ocorre quando o usuário consulta a view” pode estar errada dependendo do enfoque (refresh/materialização).
“Em regra, visões são não atualizáveis”: a banca gosta de dizer “plena liberdade para inserir/excluir/alterar” (geralmente ERRADO).
View pode ser derivada de outras views; a banca pode proibir isso para confundir.
View pode usar mais de uma tabela; afirmar “somente uma tabela” é armadilha.
View pode ser usada como mecanismo de segurança (restringir colunas/linhas), mas isso NÃO substitui política de permissões (é complemento).
“SGBD mantém views atualizadas quando tabelas-base mudam” aparece muito; cuidado para não estender isso para “cópia física” em view comum.
Quando aparecer “atualização manual por rotina específica”, desconfie: manutenção de view/materializada é comportamento gerenciado pelo SGBD conforme o mecanismo de materialização/refresh.

🎓 Pareto CEBRASPE

Frase-mãe: view = tabela virtual derivada de consulta; materialized view = armazenada.
Atualização: view comum tende a ser NÃO atualizável; materializada tende a ser mais atualizável (conforme SGBD).
Segurança: view é usada para “mostrar o que pode” (subconjunto), escondendo colunas/linhas sensíveis.
Pegadinha “desempenho”: view não acelera por “duplicar dados”; se houver ganho, costuma ser por simplificação/uso recorrente (ou materialização).
“SGBD mantém atualizadas” = foco em consistência de apresentação; NÃO conclua “há cópia física” em view comum.
Pode basear-se em várias tabelas e até em outras views.
Itens de C/E: procure “SEMPRE armazena”, “NUNCA atualiza”, “APENAS uma tabela” — geralmente são os gatilhos de erro.
“Armazenar tabelas” (literal) quase sempre está fora do conceito de view.
Materialized view: palavra-chave = materialização (existência física/armazenada) + refresh/atualização controlada pelo SGBD.

✍️ Exemplo na prática

[CEBRASPE – 2025 – Aud – FUB] – https://www.tecconcursos.com.br/questoes/3495857

Ponto-chave: view é derivada de consulta/tabela virtual; “armazenar tabelas” não descreve sua finalidade. Pegadinha: redefinir view como “estrutura de armazenamento” (confundir com tabela física).

[CEBRASPE – 2025 – APC – FUNPRESP-EXE] – https://www.tecconcursos.com.br/questoes/3291974

Ponto-chave: materialized view envolve armazenamento/materialização; a atualização não é “simplesmente executar consulta na hora”. Pegadinha: tratar materialized view como view comum (sempre virtual e sempre executada a cada consulta).

[CEBRASPE – 2025 – AFT – SEFAZ SE] – https://www.tecconcursos.com.br/questoes/3639425

Ponto-chave: view pode restringir acesso a colunas (segurança) e não altera estrutura física das tabelas-base. Pegadinha: afirmar que view “duplica dados em disco” ou “redefine armazenamento físico”.

5. TI - Banco de Dados - Triggers

Conceito	O que você precisa saber	Como a banca cobra
Evento	DML (INSERT/UPDATE/DELETE) dispara automaticamente	Trigger NÃO é “procedimento manual”
Modelo	Evento–Condição–Ação (ECA)	Ação ocorre quando condição é satisfeita
Granularidade	Por linha (row-level) vs por comando (statement-level)	Confusão “FOR EACH ROW” vs “uma vez por comando”

Definição típica: procedimentos pré-programados, chamados automaticamente em eventos de escrita na tabela (podem ser combinados com procedimentos armazenados).

⚠️ Fique esperto! Aqui o bicho pega!

Trigger é execução automática por evento; stored procedure/procedimento pode existir sem ser automático (a banca troca “procedimento” por “trigger” para confundir).
Triggers são baseados no modelo ECA: evento no BD dispara ação quando condição ocorre; se a alternativa “esquecer” condição/ação, pode estar incompleta.
“Procedimento utilizado automática e implicitamente SEMPRE que ocorrer INSERT/UPDATE/DELETE” descreve trigger, não “procedimento” genérico (pegadinha de rótulo).
Momento: BEFORE vs AFTER (a banca pode inverter “antes/depois” do efeito no dado); não aceite frase que diga “BEFORE UPDATE executa depois de atualizar valores”.
Pseudorregistros OLD/NEW (quando existem) fazem sentido em trigger por linha: OLD = valores antigos; NEW = novos valores; em trigger por comando isso NÃO se aplica da mesma forma.
Trigger pode ser associada a tabela ou view (em alguns SGBDs há INSTEAD OF para view); a banca pode dizer “somente em tabela”.
Execução por comando (statement-level): existe a ideia de “uma ação para o comando inteiro”; a banca pode inventar sintaxe (“for each table”) para confundir com o padrão “FOR EACH ROW”.
Trigger NÃO é ferramenta “apenas de desempenho”: o uso típico é regra de negócio, auditoria, integridade, automação reativa a eventos.
Cuidado com TRUNCATE: nem todo SGBD trata TRUNCATE como DELETE; afirmar “acessa OLD e recupera linhas apagadas” costuma ser armadilha.
Se aparecer “cancelar operação lançando erro”, isso é possível como comportamento de validação, mas a banca costuma errar o tipo de evento/timing (BEFORE/AFTER).

🎓 Pareto CEBRASPE

Definição que resolve: trigger = procedimento armazenado acionado automaticamente por evento de modificação (INSERT/UPDATE/DELETE).
Modelo ECA (evento-condição-ação) aparece direto em itens de C/E.
Diferencie: trigger (automática) vs procedure (pode ser chamada explicitamente).
Duas “chaves” de cobrança: quando dispara (BEFORE/AFTER) e quantas vezes dispara (por linha vs por comando).
OLD/NEW: use como âncora de “antes/depois” em nível de linha; a banca tenta usar isso para afirmar coisas absurdas em AFTER TRUNCATE, por exemplo.
“Uma única ação para o comando inteiro” é statement-level; “para cada linha afetada” é row-level (tipicamente “FOR EACH ROW”).
Trigger pode ser usada para proteção/auditoria/integridade (automatizar ação reativa), e não apenas “executar SQL”.
Itens longos com várias alternativas: geralmente só 1 respeita timing + granularidade + conceito de OLD/NEW ao mesmo tempo.
Se a alternativa afirmar que trigger “só existe com stored procedure”, é excesso: view/trigger NÃO exige procedure associada.

✍️ Exemplo na prática

[CEBRASPE – 2025 – ERM (ANM) – ANM] – https://www.tecconcursos.com.br/questoes/3324082

Ponto-chave: BEFORE/AFTER + OLD/NEW + momento real da alteração; o item pede coerência do “antes/depois” com o efeito no dado. Pegadinha: inverter timing (dizer que BEFORE ocorre depois) e inventar acesso a OLD/NEW onde não cabe.

[CEBRASPE – 2024 – Ana CT I – CNPq] – https://www.tecconcursos.com.br/questoes/2777423

Ponto-chave: triggers seguem modelo ECA: evento dispara ação quando condição ocorre. Pegadinha: reduzir trigger a “procedimento manual” ou esquecer o papel da condição.

[CEBRASPE – 2024 – APO – MPO] – https://www.tecconcursos.com.br/questoes/2877405

Ponto-chave: o que é “automático por evento” caracteriza trigger, não “procedimento” genérico. Pegadinha: trocar o rótulo (procedure) e manter a definição de trigger para induzir erro.

Checklist de Prova (revisão relâmpago)

BD: representa “minimundo”, é coleção coerente com significado e finalidade; SGBD: programas para criar/manter BD; SBD = BD + SGBD.
Características cobradas do SGBD/BD: autodescrição (catálogo/metadados), abstração, independência dados-programas, múltiplas visões, concorrência (controle de concorrência), proteção e manutenção.
Modelos (hierarquia): conceitual (MER/DER, “quais dados”, independente de SGBD) → lógico (estruturas do tipo de SGBD, ex.: relacional) → físico (armazenamento/índices, dependente do SGBD específico).
Arquitetura ANSI/SPARC (3 esquemas): externo (visões/usuários), conceitual (BD inteiro/visão comunitária), interno (armazenamento físico).
NÃO CONFUNDA: MODELO conceitual (hierarquia de modelos) ≠ NÍVEL conceitual (arquitetura 3 esquemas).
Independência de dados: lógica = alterar esquema conceitual sem afetar externos/programas; física = alterar interno sem afetar conceitual/externos.
ACID: atomicidade (tudo-ou-nada/rollback), consistência (regras/restrições), isolamento (efeito como execução serial), durabilidade (persistência pós-commit).
Pegadinhas ACID: “consistência garante processamento completo” (na verdade é atomicidade); “isolamento = execução SEMPRE em sequência” (não necessariamente).
Concorrência: NÃO é “garantida por índices/views”; é por mecanismos de controle de concorrência (locks/2PL etc.).
2PL estrito: mantém locks até o fim/commit (serializabilidade); 2PL NÃO elimina deadlock como regra.
2PC: commit distribuído com custo/espera; frase “1ª opção em alta latência/alto número de falhas” tende a ser armadilha.
View: tabela virtual derivada de consulta; em regra não atualizável; view materializada é armazenada fisicamente e, em regra, mais atualizável; view pode apoiar segurança (restringir colunas/linhas).
Pegadinhas de view: “duplica dados em disco” (não é regra), “só pode usar uma tabela”, “não pode derivar de outra view” (tudo costuma estar errado).
Trigger: procedimento acionado automaticamente por evento (INSERT/UPDATE/DELETE); modelo ECA; diferenciar BEFORE/AFTER e por linha vs por comando; cuidado com uso indevido de OLD/NEW e com sintaxes inventadas (“for each table”).

TECNOLOGIA DA INFORMAÇÃO | BLOCO 02: Conceitos de BDs e SGBDs

1. TI - Banco de Dados - Transações (Locks, ACID, etc.)

2. TI - Banco de Dados - Conceitos e Fases de Projeto e Modelagem de Dados

3. TI - Banco de Dados - Definições e Propriedades do SGBD

4. TI - Banco de Dados - Visão (View)

5. TI - Banco de Dados - Triggers

Checklist de Prova (revisão relâmpago)

Módulo VI - Análises Estratégicas

Módulo V - Direcionamento por Estágios

Módulo IV - Organização e Planejamento

Módulo III - Metodologia de Estudos

Módulo II - Ferramentas de Estudo para Concursos

Módulo I - Introdução ao Manual