Banco de Dados e Engenharia de Dados

Classificação clássica do SQL: DDL (Data Definition) — CREATE, ALTER, DROP, TRUNCATE; DML (Data Manipulation) — INSERT, UPDATE, DELETE, MERGE; DQL (Data Query) — SELECT; DCL (Data Control) — GRANT, REVOKE; TCL (Transaction Control) — COMMIT, ROLLBACK, SAVEPOINT.

• a) "Apenas dois subgrupos" — falso. Restrição artificial. São pelo menos 5 subgrupos.
• c) "CREATE e DROP na DML" — falso. São DDL. Categorias diferentes.
• d) "SELECT é DML" — armadilha clássica! Muitas bancas (inclusive a FCC) classificam SELECT como DQL, embora autores divirjam. Esteja atento ao contexto da questão.
• e) "ROLLBACK é DDL" — falso. ROLLBACK é TCL (Transaction Control).

1FN: valores atômicos (sem campos multivalorados). 2FN: 1FN + eliminação de dependências parciais (atributo não-chave deve depender da chave INTEIRA, em chaves compostas). 3FN: 2FN + eliminação de dependências transitivas. BCNF: 3FN reforçada — toda dependência funcional deve ter superchave à esquerda.

• a) Inverte definições: dependência transitiva é da 3FN, não 1FN. 1FN trata de atomicidade.
• c) Confunde 3FN com 1FN. 1FN trata de atomicidade; 3FN trata de dependências transitivas.
• d) "BCNF menos restritiva que 3FN" — falso. BCNF é MAIS restritiva (toda relação BCNF está em 3FN, mas a recíproca não é verdade).
• e) "Sempre atendidas em qualquer banco" — frontalmente falso. Bancos reais com frequência denormalizam por desempenho ou pragmatismo.

ACID: Atomicidade (transação tudo-ou-nada), Consistência (banco vai de estado válido para estado válido), Isolamento (transações concorrentes não interferem entre si), Durabilidade (dados persistem após COMMIT, mesmo com falha do sistema).

• a) Acrônimo inventado com palavras plausíveis. Pega quem decora só a sigla.
• c) Confunde ACID com tríade CIA (Confidencialidade, Integridade, Disponibilidade) de segurança. São conceitos de áreas distintas.
• d) Substitui letras corretas (Consistência, Isolamento) por plausíveis erradas. Comum em FCC.
• e) Invenção total — não há ACID que comece com Análise.

Chave primária (PK): identifica unicamente cada tupla; não admite NULL nem duplicação (regra de integridade de entidade). Chave estrangeira (FK): referencia uma PK (ou UK) de outra tabela (ou mesma), garantindo integridade referencial — não pode apontar para registro inexistente.

• a) "Sinônimos" — falso. PK e FK têm funções distintas e complementares.
• c) "PK pode ter null" — frontalmente falso. PK NUNCA admite NULL (violaria a regra de integridade de entidade). FK pode admitir NULL em alguns casos.
• d) "Mesmo nome obrigatório" — falso. É boa prática, mas não obrigatório. O importante é o tipo de dado e o relacionamento.
• e) "Pelo menos 3 FK" — invenção. Número arbitrário; tabela pode ter 0, 1, várias FK conforme o modelo.

INNER JOIN: só linhas com correspondência em ambas. LEFT JOIN: todas da esquerda + correspondentes da direita (NULL onde não houver match). RIGHT JOIN: o inverso. FULL OUTER JOIN: todas de ambas (NULL onde não houver match). CROSS JOIN: produto cartesiano (todas as combinações possíveis).

• a) Descreve FULL OUTER JOIN, não INNER. INNER traz só linhas com correspondência.
• c) "Sempre o mesmo resultado" — falso. LEFT e RIGHT são espelhos: A LEFT JOIN B ≡ B RIGHT JOIN A. Mas A LEFT JOIN B ≠ A RIGHT JOIN B se houver linhas órfãs.
• d) Descreve INNER JOIN, não FULL OUTER. FULL OUTER traz todas as linhas de ambas, mesmo sem correspondência.
• e) "CROSS JOIN onde PK = PK" — totalmente errado. CROSS JOIN é produto cartesiano, sem condição de junção.

Índices (geralmente B-Tree ou Hash) aceleram leituras a custo de: (1) espaço em disco, (2) desempenho de escrita (cada INSERT/UPDATE/DELETE exige atualização dos índices). Criação estratégica: indexar colunas usadas em WHERE, JOIN, ORDER BY frequentes — evitar excesso.

• a) "Sempre melhora" — falso. Índices em excesso degradam escrita e desperdiçam espaço. Indexação é trade-off.
• c) "Obrigatórios em todas as colunas" — frontalmente falso. SGBDs criam automaticamente apenas para PK; demais são opcionais.
• d) "Não ocupam espaço" — falso. Índices são estruturas físicas em disco (árvores B+, hash, bitmap).
• e) "Índice de PK criado manualmente" — falso. O índice da chave primária é criado automaticamente pelo SGBD quando se define a PK.

Quatro categorias clássicas de NoSQL: chave-valor (Redis, DynamoDB — cache, sessões); documento (MongoDB, CouchDB — JSON/BSON, esquema flexível); colunar (Cassandra, HBase — analítica em larga escala); grafo (Neo4j, ArangoDB — relacionamentos complexos, redes sociais, fraude).

• a) "Todos com mesmo modelo" — frontalmente falso. Justamente o oposto: NoSQL é família heterogênea.
• c) "Substituíram completamente os relacionais" — falso. Coexistem; cada um para seu uso. Relacionais ainda dominam transações ACID.
• d) "Apenas MongoDB é NoSQL" — falso. NoSQL é categoria ampla com dezenas de produtos.
• e) "NoSQL = sem linguagem de consulta" — falso. NoSQL significa "Not Only SQL". Vários têm linguagens próprias (Cypher para Neo4j, MQL para MongoDB).

Teorema CAP (Eric Brewer, 2000): em sistemas distribuídos, na presença de partição de rede (P inevitável), o sistema escolhe entre Consistência (todos os nós veem dado mais recente) ou Availability (cada nó responde, mesmo com dado eventualmente stale). Bancos AP: Cassandra, DynamoDB. Bancos CP: MongoDB (padrão), HBase.

• a) "Todas as três simultaneamente" — frontalmente contra o teorema. A escolha é o coração do CAP.
• c) "Apenas Consistência fundamental" — simplificação errada. As três são importantes; o teorema é sobre o trade-off.
• d) "Apenas sistemas centralizados" — falso. CAP é especificamente sobre distribuídos.
• e) Acrônimo inventado. CAP = Consistency, Availability, Partition tolerance.

Data Warehouse (DW): dados estruturados (tabelas), modelagem dimensional (estrela, floco), schema-on-write (estrutura definida na ingestão), otimizado para consultas analíticas — ex.: Snowflake, Redshift, BigQuery. Data Lake: dados brutos em qualquer formato (CSV, JSON, Parquet, imagens, logs), schema-on-read (estrutura aplicada na consulta), maior flexibilidade — ex.: AWS S3, ADLS, GCS. Híbrido: Lakehouse (Databricks).

• a) "Sinônimos" — falso. Arquiteturas conceitualmente distintas.
• c) "Data Lake é versão descontinuada" — frontalmente falso. Data Lake é arquitetura MAIS recente que Data Warehouse.
• d) "Apenas dados estruturados em Data Lake" — falso. Justamente o oposto: Data Lake é flexível, aceita todos os tipos.
• e) "DW gratuito, DL pago" — invenção. Custo depende do fornecedor e do volume, não da arquitetura conceitual.

ETL (clássico): extrai, transforma em servidor intermediário (Informatica, Talend), carrega no DW. Bom para volumes médios e transformações complexas. ELT (moderno): extrai, carrega bruto no destino, transforma com SQL no próprio DW/Lake (dbt, Snowflake, BigQuery). Aproveita poder computacional dos engines modernos. Predominante em Data Engineering atual.

• a) "Sinônimos" — falso. A ordem dos passos é o cerne da diferença.
• c) Inversão histórica: ELT é MAIS recente que ETL, não mais antigo. Surgiu com Big Data e cloud warehouses.
• d) Restrição inventada. Ambas se aplicam a qualquer destino.
• e) Confunde os dois: em ELT, transformação ocorre DEPOIS do carregamento. Essa é a inversão.

Particionamento: divide uma tabela grande em pedaços (partições) — pode ser horizontal (por linhas, ex: por data) ou vertical (por colunas). Tipicamente no mesmo servidor. Sharding: forma específica de particionamento horizontal distribuído em múltiplos servidores para escalar — cada shard é independente.

• a) "Sinônimos" — falso. Sharding é caso particular (horizontal + distribuído) de particionamento.
• c) "Sharding obsoleto" — falso. Sharding é técnica fundamental em sistemas web em escala (MongoDB, Cassandra, Elasticsearch).
• d) Inversão: particionamento pode ser num servidor único; sharding por definição exige múltiplos.
• e) "Sharding vertical por chaves alfabéticas" — invenção. Sharding é por hash, range ou diretório, mas é HORIZONTAL.

Síncrona: COMMIT só após réplicas confirmarem (consistência forte, latência maior, RPO = 0). Assíncrona: COMMIT imediato, propagação posterior (alta performance, RPO > 0). Trade-off clássico de sistemas distribuídos — relacionado ao CAP.

• a) Inverte completamente: síncrona prioriza CONSISTÊNCIA, não disponibilidade. Padrão FCC clássico.
• c) "Replicação assíncrona = backup" — falso. Backup é cópia pontual; replicação é fluxo contínuo. Coisas distintas.
• d) "Só NoSQL" — falso. Replicação é fundamental em qualquer SGBD relacional moderno (PostgreSQL, MySQL, SQL Server, Oracle).
• e) "Síncrona menor latência" — falso. Justamente o oposto: aguardar réplicas adiciona latência.

MVCC: cada transação vê um snapshot dos dados no momento de seu início; múltiplas versões coexistem internamente. Leitores não esperam escritores; escritores não esperam leitores. Maior concorrência sem locks de leitura. Usado por PostgreSQL, Oracle, SQL Server (READ_COMMITTED_SNAPSHOT), MongoDB.

• a) Descreve o modelo de bloqueio tradicional (2PL pessimista), exato oposto do MVCC.
• c) "Exclusivo de NoSQL" — falso. MVCC é técnica utilizada em vários relacionais clássicos.
• d) "Elimina ACID" — falso. MVCC é mecanismo PARA implementar isolamento ACID; não substitui.
• e) "Nunca causa deadlock" — falso. Deadlocks ainda podem ocorrer em transações com múltiplas escritas.

OLTP: transações curtas (ms), alto throughput, modelo normalizado, ACID, sistemas operacionais (NF-e, cadastro de contribuintes). OLAP: queries complexas (s/min), modelo dimensional (fato + dimensões), agregações, BI/relatórios (arrecadação por região/período). Tipicamente ETL/ELT move dados de OLTP para OLAP.

• a) "Sinônimos" — falso. Workloads radicalmente diferentes.
• c) "OLTP em desuso" — falso. OLTP é base de qualquer sistema transacional do mundo.
• d) Restrições inventadas. Tanto OLTP quanto OLAP podem ser implementados em relacionais ou NoSQL.
• e) Inversão: OLTP é majoritariamente escrita (transações); OLAP é majoritariamente leitura (análise). E ambos suportam os dois tipos de operação.

Full: tudo, simples mas pesado. Incremental: só o que mudou desde o último backup (qualquer tipo); rápido, pouco espaço, mas restauração exige full + todos os incrementais em sequência. Diferencial: só o que mudou desde o último full; restauração precisa apenas de full + último diferencial. Estratégia comum: full semanal + diferencial diário.

• a) "Sinônimos" — falso. Estratégias com trade-offs distintos.
• c) Inversão: backup incremental ocupa MENOS espaço, não mais. Pega quem decora errado.
• d) Inverte os papéis: diferencial precisa apenas do último diferencial + full. Quem precisa de "todos em sequência" é o INCREMENTAL.
• e) "Full todo dia, sem exceção" — falso. Estratégia comum é full semanal + incrementais ou diferenciais nos demais dias. Full diário é custoso e geralmente desnecessário.

Apache Kafka: plataforma distribuída de streaming, baseada em log de eventos imutável dividido em tópicos e partições. Produtores publicam, múltiplos consumidores leem em ritmo próprio (offset). Retenção configurável (não há "consumir e descartar" como em fila tradicional). Garantias: at-most-once, at-least-once, exactly-once (com configuração apropriada).

• a) "Banco relacional" — falso. Kafka é plataforma de mensageria/streaming, não SGBD.
• c) "Substitui relacionais" — falso. Coexistem; Kafka serve streaming entre sistemas, não armazenamento transacional primário.
• d) "Equivalente a fila tradicional" — falso. Em fila (RabbitMQ tradicional), mensagem é consumida e descartada; em Kafka, é mantida no log, permitindo replay e múltiplos consumidores independentes.
• e) "Proprietário da AWS" — falso. Kafka é projeto Apache (open-source), mantido pela Apache Software Foundation. AWS oferece o MSK, mas não é dona.

Esquema estrela: 1 tabela fato central (métricas: valor, quantidade) + N tabelas dimensão denormalizadas (tempo, produto, cliente, geografia). Trade-off: redundância controlada em troca de menos JOINs e melhor desempenho analítico. Floco-de-neve: dimensões normalizadas (mais JOINs, menos redundância).

• a) "Totalmente normalizado" — falso. Esquema estrela é deliberadamente desnormalizado para performance analítica.
• c) "Exclusivo NoSQL" — falso. Esquema estrela nasceu em bancos relacionais para DW.
• d) "Sinônimo de floco-de-neve" — falso. Floco normaliza as dimensões; estrela não. São variantes.
• e) "Exatamente 5 dimensões" — invenção. Pode ter qualquer número (1, 2, 10, 20 dimensões), conforme o negócio.

Trigger: código que dispara automaticamente antes ou depois de evento DML (INSERT, UPDATE, DELETE) ou DDL — usado para auditoria, validação, sincronização. Stored Procedure: bloco de código nomeado armazenado no banco, executado sob demanda via CALL/EXEC, com parâmetros de entrada/saída.

• a) "Idênticos" — falso. Triggers são automáticos (em evento); procedures são manuais (sob demanda).
• c) "Procedures depreciadas" — falso. Continuam amplamente usadas em sistemas legados e novos.
• d) "Triggers só em SELECT" — frontalmente falso. Inverte completamente: triggers tipicamente são em INSERT/UPDATE/DELETE (DML), não em SELECT.
• e) "Procedures sem parâmetros" — falso. Parâmetros de entrada e saída são recurso fundamental de procedures.

Redis: banco em memória (RAM) com persistência opcional (RDB snapshots, AOF append-only file). Estruturas: strings, listas, sets, sorted sets, hashes, streams, geospatial, HyperLogLog. Usos típicos: cache (acelerar consultas a banco principal), sessões de aplicação, filas leves, rate limiting, pub/sub. Latência sub-milissegundo.

• a) "Relacional ACID" — falso. Redis é NoSQL chave-valor; transações têm semântica diferente.
• c) "Persistência síncrona obrigatória" — falso. A vantagem do Redis é justamente operar em memória; persistência é opcional/configurável.
• d) "Substitui completamente relacionais" — falso. Coexistem; Redis é tipicamente camada de cache acima de banco principal.
• e) "Descontinuado" — falso. Redis está em desenvolvimento ativo, com nova versão recente (Redis 7.x).

CDC (Change Data Capture): captura incremental de mudanças em sistemas-fonte, geralmente lendo o log de transações (WAL/binlog) sem impactar performance. Eventos são propagados em tempo real para destinos (Kafka, Data Lakes, sistemas réplica). Ferramentas: Debezium (Kafka Connect, open-source), AWS DMS, Oracle GoldenGate. Essencial para arquiteturas modernas event-driven e Data Lakes em tempo real.

• a) Descreve o modelo tradicional de "full reload" ou "snapshot diário" — exato oposto do CDC.
• c) "Exclusivo NoSQL" — falso. CDC é majoritariamente usado para capturar mudanças de bancos RELACIONAIS para Data Lakes/Streams.
• d) "Antiga e em desuso" — falso. CDC é técnica em ascensão em Data Engineering moderno.
• e) "Só on-premises" — falso. CDC funciona perfeitamente em nuvem (AWS DMS, Azure Data Factory, GCP Datastream).