🎙️ Sou o Camilo, teu professor de TI. Chegamos no bloco onde a FCC PARA de perguntar e manda você FAZER. Aqui não tem decoreba de definição que salve — aqui você lê o SQL, escolhe o NoSQL certo e desempata um RANK na mão. Pega firme: este é o OURO da série, e é onde eu mais agrego o que nenhum cursinho te deu.
⚡ É o assunto MAIS cobrado do bloco de BD na FCC 2026. Só em SEFAZ-MT 2026 caíram 8 questões de SQL escrito + 3 de Oracle + 2 de modelagem. Em SP caiu SQL (id 3708) + NoSQL chave-valor (id 3709); em GO caiu NoSQL grafo (id 2746). BD/SQL caiu firme nas 3 provas-espelho (MT/GO/SP) que calibram o CE.
📜 O edital do CE LISTA os subtemas de SQL um a um (item #9): "Agregação, Agrupamento, Junção, Ordenação, Restrições e Operações Lógicas" + item #8 "Relacionais / Não Relacionais (NoSQL)". A banca tá te dando o gabarito do que estudar.
👻 O OURO ÓRFÃO que decidiu MT e NINGUÉM deu na reta final: funções de janela (RANK × DENSE_RANK × ROW_NUMBER, SUM OVER PARTITION BY) + CTE (WITH) + subquery correlacionada + GROUP BY/HAVING. O Renato (prof do CE) parou na porta do SQL — prometeu uma "Aula 4" de DQL que não saiu. Aqui é onde EU entro: a gente treina SQL na mão, com ICMS de verdade.
🎯 Ataca direto o gap eliminatório. Foi a Fluência (35%) que te tirou no PA. Este bloco é prático, nacional e recicladíssimo — ponto que você ganha treinando, não decorando.
🧭 Tradução do Camilo: o concorrente decora "o que é PK" e deixa o
SUM() OVER (PARTITION BY)em branco. Você vai fazer o contrário — treinar o código e pegar os 4-5 pontos que ele larga. É o pulo do gato desta aula.
Gabriel Santana — 1º lugar SEFAZ-GO 2026 (banca FCC). (GO é espelho direto do CE — mesma banca, edital reciclado.)
🔗 Fonte: live LS Concursos c/ Prof. Lucas Eduardo · DEPOIMENTOS_APROVADOS.md (depoimento #1)
🎯 A tática dele pra TI: teoria uma passada só, o resto é questão. "Eu só aprendia mesmo com as questões." — e SQL é o caso EXTREMO disso: não existe decorar SQL, existe resolver SQL. Por isso esta aula é toda construída em cima de questão real comentada na mão.
💎 Pra colar na parede: "SQL você não estuda, você TREINA" — assim como você não decora a pista de obstáculos do CEFAN, você corre ela até o corpo saber sozinho. Cada questão de janela/CTE que você fizer na mão vira ponto automático na prova.
| Aula | Tema | 💰 Onde está o ponto |
|---|---|---|
| 00 | Fundamentos (tipos de dado, DIKW, ciclo de vida) | 🛡️ blindagem barata |
| 01 | CRISP-DM (as 6 fases na ordem) | 🥉 alto |
| 02 | Arquitetura & Eng. de Dados (DW/Mart/Lake/Lakehouse, ETL×ELT, OLAP, Big Data, DAG) | 🥈 ouro |
| 03 ⬅️ (esta) | Banco de Dados & SQL (relacional, normalização, NoSQL, SQL na mão) | 🥇 OURO |
| 04 | Machine Learning & IA (sup × não-sup, clusterização, over/underfit, Lasso/Ridge) | 👑 O OURO MÁXIMO (7 de 11 em SP) |
| 05 | Governança & Ética de Dados (qualidade, viés, IA generativa) | 🟡 médio |
| 06 | Segurança / LGPD / Sigilo Fiscal (CID, LGPD, CTN 198 + IN SEFAZ-CE 92/21) | 🟡 médio |
| 07 | Python / Pandas / NumPy (Pandas, leitura de código) | 👻 órfão eliminatório (hedge) |
🔑 Leitura do mapa: Aula 02 te deu onde o dado mora (Lake/DW); esta Aula 03 te dá como você fala com ele (SQL) e qual banco escolher (relacional × NoSQL). Logo depois vem o OURO MÁXIMO (ML, Aula 04). BD e ML são os dois pés da prova nova.
Estes são os profs que a gente "ouviu" pra montar a munição. São INSUMO — a palavra final é minha. Faro = quão bem cada um previu o que a FCC 2026 cobrou em MT/GO/SP (provas que JÁ aconteceram).
| Prof | Faro | Confie nele para... |
|---|---|---|
| Felipe Mathias (TI Descompl.) | 10/10 | normalização (chama de OURO), DQL/leitura de código, NoSQL × relacional, CAP/BASE — a fonte-mãe do bloco |
| Emannuelle Gouveia (Estratégia) | 8/10 | NoSQL por tipo/produto, PK/FK/integridade, JOIN, Oracle/SGA, DROP×TRUNCATE — cirúrgica em "tipo ↔ exemplo" |
| Renato da Costa (prof oficial do CE) | 6/10 | relacional (MER/3 níveis/PK-FK) — ⚠️ ver alerta |
⚠️ HONESTIDADE OBRIGATÓRIA: o Renato é o prof oficial de Fluência do CE, mas no SQL ele parou na porta: deu relacional (PK/FK/normalização básica/ACID) e jogou SQL/DQL + NoSQL pra uma "Aula 4" que prometeu e ainda não saiu (degravação 21/06). 🧭 Tradução do Camilo: o Felício não tem aula CE-específica fechada de SQL escrito. Logo, o drill desta aula é a fonte real dele — funções de janela, CTE, GROUP BY/HAVING na mão. É aqui que eu tapo o buraco que o curso do CE deixou.
🎯 A FCC NÃO cobra BD relacional decorado — cobra SQL ESCRITO e NoSQL POR CASO DE USO. Quem apostou pesado em álgebra relacional, MER e ACID teórico levou balde de água fria. A banca virou cientista de dados: te dá um cenário fazendário e pede a ferramenta certa.
🪤 No SQL, a FCC fica trocando a SINTAXE pra eliminar (Emannuelle: "ela fica só trocando a sintaxe, se você sabe a sintaxe corta várias letras"). As alternativas são quase iguais — muda uma cláusula, um PARTITION BY, um ON pra WHERE. Você acha o erro de sintaxe/lógica e risca.
⚡ A dica de prova nº 1 (Mathias): "SQL é linguagem, você precisa CONVERSAR com o código." Não decore a definição — leia o que cada comando FAZ e simule mentalmente a saída.
🔗 Conexão (não-ilha): todo cenário é fiscal — ICMS por município, NF-e × pagamento, ranking de crédito tributário. Você já conhece esse mundo da Legislação Tributária. O SQL é só a ferramenta que filtra a nota fria que você já sabe caçar.
🔑 Bordão da aula: na FCC, banco de dados não se decora — se RESOLVE na mão.
Bloco 1 — Modelo relacional 🟡 (entidade/atributo/relação=tabela · 3 níveis conceitual/lógico/físico).
Bloco 2 — PK / FK / Integridade 🟠 (PK = NOT NULL + UNIQUE · as 4 integridades · FK = integridade referencial).
Bloco 3 — Normalização 1FN/2FN/3FN 🔴 (atômico/Parcial/Transitiva · o atributo derivado que quebra a 3FN — o ouro do Mathias).
Bloco 4 — NoSQL por caso de uso 🔴 (chave-valor/documento/colunar/grafo · CAP · BASE × ACID — a decoreba tipo↔produto↔cenário).
Bloco 5 — SQL / DQL na mão 🔴🔴 (SELECT/WHERE/JOIN/GROUP BY/HAVING/ORDER BY + o OURO ÓRFÃO: funções de janela, CTE, subquery correlacionada).
Bloco 6 — Oracle / trigger / SGA / DDL 🟡 (instância=SGA+processos · trigger :OLD/:NEW · DROP × TRUNCATE × DELETE).
▶️ Próximo (Bloco 1): a base de tudo — como o mundo real (contribuinte, NF-e, pagamento) vira tabela, e os 3 níveis de abstração que a FCC adora. Rápido, porque o ouro mora nos blocos 3, 4 e 5. Bora.
🎯 O que travar neste bloco (só isso):
Entidade = objeto do mundo real → vira tabela · Atributo = característica → vira coluna · Relação = TABELA (não confunda com "relacionamento").
3 níveis de abstração: conceitual (MER, leigo entende) → lógico (depende do SGBD) → físico (como o SGBD acessa).
🪤 A pegadinha-rei já mora aqui: PK NÃO aceita NULL (lá embaixo, bloco 2).
🟡 PROBABILIDADE PRO CE: MÉDIA. Caiu só em MT (id 3004) e em 2026 a FCC virou cientista de dados — modelagem encolheu. Mas é base estável e está no edital (#8 "Relacionais"). Estuda rápido, não martela.
O Guilherme (seu amigo auditor) foi escalado pra ajudar o arquiteto de dados da SEFAZ a desenhar o banco do sistema de Arrecadação. Na mesa dele, o mundo real vira tabela:
| No mundo real... | Vira no banco... | Nome técnico |
|---|---|---|
| O Contribuinte (a DABOA Comércio) | uma tabela | Entidade |
| O CNPJ, a razão social, o regime | as colunas da tabela | Atributos |
| O fato de "a DABOA tem 3 estabelecimentos" | uma ligação entre tabelas | Relacionamento (vira FK) |
| "Cada estabelecimento é único" | a coluna que identifica | Chave Primária (PK) |
| "Todo pagamento aponta pra um contribuinte válido" | a coluna que conecta | Chave Estrangeira (FK) |
A sacada: o Guilherme não inventa nada — ele traduz o mundo fiscal pra tabelas. Entidade→tabela, atributo→coluna, e as chaves amarram tudo com integridade.
🧊 OS 3 NÍVEIS DE ABSTRAÇÃO — caixa-mãe (decore esta tabela)
| Nível | Sinônimo | O que é | Quem entende |
|---|---|---|---|
| Conceitual | externo / visão | MER / DER (diagrama entidade-relacionamento), independe de SGBD | leigo entende (alta abstração) |
| Lógico | intermediário | modelo relacional (tabelas), já depende do SGBD escolhido (software) | técnico (abstração média) |
| Físico | interno | como o SGBD ACESSA os dados no disco (índices, blocos) | DBA (baixa abstração, máximo detalhe) |
🔑 A regra de ouro: abstração é inversamente proporcional ao detalhamento. Mais abstrato = menos detalhe (conceitual). Mais detalhe = menos abstrato (físico). 🔑 Macete da Emannuelle: "MER → conceitual. Modelo relacional → lógico." Associação direta de palavra-chave — mata a questão sem ler o enunciado-enrolation inteiro. ⚠️ Pegadinha do Mathias: o nível físico NÃO é o dado em si — é como o SGBD acessa o dado. O dado fica "lá embaixo".
🎙️ O PLACAR DOS PROFESSORES — Modelo relacional
Leitura do Camilo: consenso total aqui — Mathias e Emannuelle cravaram a id 3004 e ninguém errou o conceito. A diferença é só profundidade.
| Prof | Veredito | O que disse (literal do dossiê) |
|---|---|---|
| Felipe Mathias | 🎯 CRAVOU (id 3004) | "Entidade = objeto do mundo real → vira tabela; Atributo = característica → vira coluna; DER ↔ modelo conceitual" |
| Emannuelle Gouveia | 🎯 CRAVOU (id 3004) | "tabela e relação são sinônimo" · "esta tabela [conceitual/lógico/físico] você vai PRINTAR e levar, a FCC ama encher o saco com isso" |
| Renato da Costa (CE) | 🎯 conceito | "o edital de vocês força o lógico e o físico, pula o conceitual" — vocabulário por contexto |
O arquiteto de dados de uma Secretaria da Fazenda está projetando o novo banco de dados para o sistema de Arrecadação. O modelo precisa garantir que nenhum Pagamento seja registrado sem estar vinculado a um Contribuinte válido e que cada Estabelecimento seja identificado de forma exclusiva. Para assegurar a integridade e a consistência do ecossistema fiscal, o analista deve
🪤 AS PEGADINHAS DO BLOCO 1 (a FCC repete)
PK aceita NULL? → NUNCA. Nem "cadastro provisório", nem "exceção". (letra A da questão)
Integridade referencial é garantida pelo código da aplicação? → NÃO, é do banco (constraint FK). "Confiar no código" = falso. (letra C)
"Relação" = "relacionamento"? → NÃO. Relação = TABELA. Relacionamento é a ligação (vira FK). A FCC adora essa troca de termo.
MER é do nível lógico? → NÃO, MER = conceitual. Modelo relacional = lógico.
🔗 CONEXÃO — não é ilha
Liga com a Aula 02 (arquitetura): o modelo relacional é o que vive no DW (schema-on-write, esquema antes de gravar) — o oposto do Data Lake (schema-on-read). O DW é "tabela arrumada".
Liga com Legislação Tributária: a tabela CONTRIBUINTE é o cadastro que você cruza com a NF-e pra pegar nota fria (o caso DIKW da Aula 00). O banco relacional é onde o ciclo do crédito tributário mora estruturado.
🧊 GUARDE NO BOLSO (Bloco 1)
Entidade→tabela · Atributo→coluna · Relação=tabela · Relacionamento→FK.
3 níveis: conceitual (MER, leigo) → lógico (SGBD, modelo relacional) → físico (acesso no disco).
🪤 PK não aceita NULL · integridade referencial é do BANCO (constraint), não do código.
➡️ Próximo (Bloco 2): as chaves que amarram tudo — PK, FK e as 4 integridades. É o conceito que entra em TODA questão de modelagem.
🎯 O que travar neste bloco (só isso):
PK = NOT NULL + UNIQUE (já embute as duas — não precisa declarar separado).
As 4 integridades: chave/unicidade · domínio · entidade · referencial.
FK = aponta pra PK de outra tabela = garante integridade referencial.
🟠 PROBABILIDADE PRO CE: MÉDIA-ALTA. Não cai sozinho com frequência, mas entra como núcleo de TODA questão de modelagem/normalização (foi o coração das ids 3004 e 3005 do MT). Alto valor transversal.
A Emannuelle tem um macete que cola na cabeça: pensa na FK como um passaporte em Portugal. 🛂
O Felício está em Portugal com passaporte brasileiro. O passaporte diz: "esse cara NÃO nasceu aqui — ele pertence a outro país (outra tabela)."
Na tabela PAGAMENTO, a coluna contribuinte_id é uma FK: ela não "nasceu" ali, ela aponta pra PK da tabela CONTRIBUINTE. É o passaporte que diz de onde o dado veio.
🔑 Integridade referencial = você só registra um pagamento pra um contribuinte que EXISTE. O passaporte tem que ser válido — não dá pra apontar pra um contribuinte fantasma.
🧊 PK / FK — caixa-mãe (decore)
| Conceito | Definição | Regra de ouro |
|---|---|---|
| Chave Primária (PK) | identifica cada linha de forma única | NOT NULL + UNIQUE (já embute as duas) |
| Chave candidata | atributo que poderia ser PK | NOT NULL + UNIQUE também |
| Chave Estrangeira (FK) | aponta pra PK de outra tabela | garante integridade referencial |
🔑 Emannuelle (cravou): "a PRIMARY KEY automaticamente já é NOT NULL e UNIQUE." Se a questão disser "PK precisa declarar NOT NULL à parte" → falso, já vem embutido.
🧊 AS 4 INTEGRIDADES (decore os 4 nomes — a FCC pede por nome)
| Integridade | O que garante | Exemplo fiscal |
|---|---|---|
| Chave / unicidade | a PK é única (sem repetir) | dois contribuintes não têm o mesmo CNPJ |
| Domínio | o valor é do tipo/faixa permitido do campo | alíquota só aceita número, não texto |
| Entidade | a PK não é nula | todo contribuinte TEM um CNPJ |
| Referencial | a FK aponta pra um valor que EXISTE na origem | só registra pagamento de contribuinte cadastrado |
🧠 Mnemônico: CDER — Chave, Domínio, Entidade, Referencial. (As duas que a FCC mais cobra: entidade = PK não nula · referencial = FK válida.)
🎙️ O PLACAR DOS PROFESSORES — PK/FK/Integridade
Leitura do Camilo: Emannuelle é cirúrgica aqui (faro 8/10) e Mathias confirma. Não há divergência — é decoreba de alto ROI.
| Prof | Veredito | O que disse (literal do dossiê) |
|---|---|---|
| Emannuelle Gouveia | 🎯 CRAVOU | "PRIMARY KEY automaticamente já é NOT NULL e UNIQUE" · restrições: "unicidade, domínio, entidade (PK não nula), referencial (FK = valor da origem)" · macete do passaporte |
| Felipe Mathias | 🎯 CRAVOU | "Chave candidata = NOT NULL + UNIQUE; FK referencia a PK da outra tabela — REFERENCES tabela[PK]" |
(Esse conceito caiu embutido nas ids 3004 e 3005 do MT — a integridade referencial é o coração das duas respostas. A questão dedicada você resolve no Bloco 1 acima.)
🪤 AS PEGADINHAS DO BLOCO 2
"PK precisa declarar NOT NULL + UNIQUE separadamente" → falso, já vem embutido.
"FK identifica a linha na própria tabela" → falso, isso é a PK. FK aponta pra fora. (foi a letra E da id 3004)
"Integridade de entidade = FK válida" → falso: entidade = PK não nula; referencial = FK válida. Não troque.
⚠️ Especificidade CE (Renato avisou): o edital CE pede entidade fraca (depende de outra, PK = PK da forte + id próprio, ex.: dependente) × entidade associativa (mapeia relacionamento N:N). A banca confunde os dois.
🔗 CONEXÃO — não é ilha
A FK é o que segura o ciclo do crédito tributário no banco: o LANCAMENTO aponta (FK) pro CONTRIBUINTE e pro TRIBUTO. Sem integridade referencial, você teria lançamento de imposto pra contribuinte que não existe — a fraude que o Guilherme caça. O banco bem modelado já barra a inconsistência na fonte.
🧊 GUARDE NO BOLSO (Bloco 2)
PK = NOT NULL + UNIQUE (embutido).
4 integridades — CDER: Chave/unicidade · Domínio · Entidade (PK não nula) · Referencial (FK válida).
FK = passaporte: "não nasceu aqui, aponta pra outra tabela" = integridade referencial.
➡️ Próximo (Bloco 3): o OURO do Mathias — normalização 1FN/2FN/3FN. Aqui mora o atributo derivado que quebra a 3FN, o padrão FCC que caiu cravado no MT.
🎯 O que travar neste bloco (o ouro do Mathias):
Mnemônico: 1FN = Atômico · 2FN = Parcial · 3FN = Transitiva.
PK de 1 coluna → 2FN automática (só viola 2FN com PK COMPOSTA).
Atributo DERIVADO/calculado (ex.: valor = alíquota × base) → quebra a 3FN (a clássica FCC).
É cumulativa: pra estar na 3FN, tem que estar na 2FN e na 1FN.
🔴 PROBABILIDADE PRO CE: ALTA. Caiu no MT (id 3005), o Mathias chama de OURO ("a maioria das bancas cobra até a 3FN ou BCNF; FCC adora") e é 100% nacional/transferível. Único freio: GO/SP não cobraram → mantém em alta, não máxima.
A SEFAZ tinha uma tabela gigante e redundante — tudo num lugar só:
LANCAMENTO_FISCAL (CPF, Nome, Endereço, Código_Tributo, Descrição_Tributo, Alíquota, Nº_Lançamento, Data, Valor_Devido)
O problema (a "dor" da redundância): o nome do contribuinte se repete em CADA lançamento dele. Se a DABOA muda de endereço, você tem que atualizar mil linhas — e se esquecer uma, o banco fica inconsistente (anomalia de atualização).
A cura = normalizar (decompor em tabelas):
CONTRIBUINTE (CPF → Nome, Endereço) — dados que dependem só do CPF.
TRIBUTO (Código_Tributo → Descrição, Alíquota) — dados que dependem só do código.
LANCAMENTO (Nº, Data, Valor + FKs pro contribuinte e pro tributo) — só o evento, sem repetir cadastro.
🔑 Mathias: "Redundância = mesmo dado em mais de um local." Normalizar = jogar o repetido pra outra tabela e referenciar por FK. Ganho duplo: menos espaço + mais integridade (muda 1 linha só).
🧊 AS 3 FORMAS NORMAIS — caixa-mãe (decore)
| Forma | Regra | Mnemônico | Como viola |
|---|---|---|---|
| 1FN | sem atributos compostos/multivalorados — tudo atômico (1 valor por célula) | Atômico | telefone "999, 888" na mesma célula |
| 2FN | 1FN + sem dependência parcial (não-chave depende da PK inteira) | Parcial | só viola com PK COMPOSTA |
| 3FN | 2FN + sem dependência transitiva (não-chave → não-chave) | Transitiva | município → UF; ou atributo derivado |
🔑 As 3 verdades que matam a questão FCC (Mathias):
PK de 1 coluna → 2FN AUTOMÁTICA. Não dá pra depender "parcialmente" de uma chave única. Só viola 2FN com PK composta.
Dependência transitiva = não-chave depende de outro não-chave (ex.: município → UF, sendo município não-chave) → tira da 3FN.
Atributo DERIVADO/calculado (ex.: valor_total = alíquota × base) quebra a 3FN, porque depende de outros campos não-chave. Padrão FCC do honorário.
BIZU DO MATHIAS — o teto da FCC: a FCC PARA na 3FN (com a pegadinha do derivado/transitiva). BCNF + axiomas de Armstrong = mania da FGV. Não gaste sono com BCNF/4FN/5FN pro CE — só reconheça a definição literal. Foca 1FN→3FN.
🎙️ O PLACAR DOS PROFESSORES — Normalização
Leitura do Camilo: Mathias é a fonte-mãe ABSOLUTA aqui (faro 10/10) — destilado completíssimo, cravou o raciocínio exato da id 3005. Os outros furaram ou não cobriram.
| Prof | Veredito | O que disse (literal do dossiê) |
|---|---|---|
| Felipe Mathias | 🎯 CRAVOU (id 3005) | "2FN só viola com PK COMPOSTA" · "atributo DERIVADO/calculado = quebra 3FN — padrão FCC do honorário" · "a maioria das bancas cobra até a 3FN ou BCNF; FCC adora" |
| Ramon Souza | ❌ furou | "ele NÃO falou de normalização" — era a 2ª de BD do MT e ele não cobriu |
| Emannuelle Gouveia | ⚪ não cobriu a fundo | citou armazenado × derivado, mas sem dissecar as formas normais |
Uma Secretaria da Fazenda Estadual mantém um sistema corporativo de controle de lançamentos tributários. O modelo inicial utiliza: LANÇAMENTO_FISCAL (CPF_Contribuinte, Nome_Contribuinte, Endereço, Código_Tributo, Descrição_Tributo, Alíquota, Número_Lançamento, Data_Lançamento, Valor_Devido). Auditorias internas identificaram redundâncias, anomalias de atualização e inconsistências históricas, especialmente quando há alteração de alíquotas e atualização cadastral de contribuintes. Diante disso, a equipe de TI decidiu reestruturar o modelo aplicando normalização até a Terceira Forma Normal (3FN), sob a perspectiva estritamente estrutural, desconsiderando requisitos de histórico temporal ou versionamento de dados e respeitando dependências funcionais clássicas e integridade referencial. Considerando a aplicação prática das formas normais nesse contexto, a técnica que representa corretamente um modelo em 3FN é:
🪤 AS PEGADINHAS DO BLOCO 3 (as que a FCC ADORA)
PK de 1 coluna pode violar a 2FN? → NÃO. PK única → 2FN automática. (a CESPE-FUB cobrou isso literal — "parece que viu minha aula", Mathias)
Atributo derivado/calculado (valor = alíquota × base) fere a 3FN? → SIM. É a clássica do honorário. Campo calculado de não-chaves = transitiva.
"Manter dado duplicado com consistência controlada pela aplicação" está na 3FN? → NÃO, duplicar = desnormalizar.
Transitividade NUNCA pode existir na 3FN? → quase — ⚠️ fineza do Mathias: pode se o atributo também for definido por uma chave candidata (ex.: RG→nome quando RG é candidata e CPF/PK também→nome). O proibido é depender SÓ de não-chave.
🚨 NÃO confunda normalização de BD (1-3FN, decompor tabela) com normalização de ML (min-max/z-score, escala numérica — Aula 04). A FCC adora cruzar.
🔗 CONEXÃO — não é ilha
Liga com a Aula 02: normalizar é o oposto de desnormalizar. O DW usa modelo dimensional DESNORMALIZADO (esquema estrela) de propósito, pra "reduzir junções" e acelerar consulta analítica. Por isso a letra E da questão tenta te enganar com "DW operacional" — em DW desnormalizar é OK, mas a questão pedia 3FN (mundo OLTP/transacional). Contexto define.
Liga com Legislação Tributária: a tabela TRIBUTO (código → alíquota) separada é o que permite mudar a alíquota do ICMS numa linha só quando a lei muda — sem reescrever o histórico de lançamentos.
🧊 GUARDE NO BOLSO (Bloco 3)
Mnemônico: 1FN=Atômico · 2FN=Parcial · 3FN=Transitiva. Cumulativas.
PK de 1 coluna → 2FN automática (só viola com PK composta).
Atributo derivado/calculado → quebra a 3FN (a clássica FCC do honorário).
FCC para na 3FN. BCNF/Armstrong = FGV. Não confunda com normalização de ML.
➡️ Próximo (Bloco 4): o NoSQL — a decoreba mais rentável do bloco. Tipo ↔ produto ↔ caso de uso fazendário. Caiu no GO (grafo) e no SP (chave-valor).
🎯 O que travar neste bloco (a decoreba que dá ponto):
4 tipos ↔ produto ↔ caso de uso fazendário (a FCC dá o cenário, você escolhe a técnica).
NoSQL = "Not Only SQL" (não "não SQL"!) — suporta os 3 tipos de dado (relembra Aula 00).
Relacional = ACID × NoSQL = BASE · Teorema CAP (só 2 de 3).
🔴 PROBABILIDADE PRO CE: ALTA (a mais sólida do bloco). É o ÚNICO assunto com 3 sinais cravados + caiu nas DUAS espelhos diretas (GO grafo + SP chave-valor) + está nominado no edital (#8 "Não Relacionais (NoSQL)") + Mathias fez discursiva CE inteira sobre isso. Ataca de cabeça.
O Guilherme tem 4 missões diferentes na fiscalização, e cada uma pede um banco NoSQL diferente:
| Missão do Guilherme | Banco certo | Produto | Por quê |
|---|---|---|---|
| 🕸️ Investigar fraude: empresas ↔ sócios ↔ NF-e, achar caminhos e vizinhança | GRAFO | Neo4j | relacionamentos complexos = nós + arestas |
| ⚡ Cache de indicadores consolidados lidos toda hora, baixa latência | CHAVE-VALOR | Redis | acesso rápido por chave única |
| 📊 Agregações massivas de bilhões de NF-e (analítico) | COLUNAR | Cassandra / HBase | varredura por coluna pra métricas |
| 📄 Integrar cadastro federal flexível (cada registro tem campos diferentes), JSON | DOCUMENTO | MongoDB / CouchDB | hierárquico/flexível |
A sacada: a FCC descreve a missão (o cenário fazendário) e te pede qual NoSQL. Você não decora "o que é grafo" — você reconhece "caça caminhos entre entidades → GRAFO". É o padrão recorrente.
🧊 OS 4 TIPOS DE NoSQL — caixa-mãe (a decoreba-rei: decore as 3 colunas juntas)
| Tipo | Produto (decore!) | Caso de uso / gatilho na questão |
|---|---|---|
| Chave-valor | Redis, DynamoDB, Voldemort | cache · baixa latência · leituras repetitivas por chave · indicadores consolidados |
| Documento | MongoDB (BSON), CouchDB | hierárquico · flexível · JSON/XML · "muita flexibilidade" · perfis/catálogos |
| Colunar | Cassandra, HBase, BigTable | agregações massivas · analítico · scans por coluna · grande volume |
| Grafo | Neo4j, AllegroGraph | nós + arestas · relacionamentos complexos · caminhos/vizinhança · fraude/rede social |
🔑 Macete do Mathias: questão que fala "muita flexibilidade" → DOCUMENTO. Questão que fala "caminhos/relacionamentos/vizinhança" → GRAFO.
🧊 ACID × BASE × CAP — a tríade que a FCC compara (Mathias + Emannuelle)
🔵 Relacional = ACID (transação forte, consistência imediata):
🟢 NoSQL = BASE (distribuído, abre mão da consistência forte):
⚖️ Teorema CAP (de Brewer) — só 2 de 3:
Consistency · Availability · Partition tolerance.
🔑 Em sistema distribuído nunca atende os 3 ao mesmo tempo. NoSQL tipicamente favorece A + P → sacrifica C (por isso é "eventualmente consistente").
💡 Por que abrir mão da consistência forte? Protocolos distribuídos (2PC/3PC) são lentos → contrariam a velocidade que o NoSQL busca (Mathias).
🧠 Bizu: relacional escolhe C (consistência forte = ACID); NoSQL escolhe A+P (disponível e particionável = BASE).
🎙️ O PLACAR DOS PROFESSORES — NoSQL
Leitura do Camilo: TRIPLO sinal pro CE. Emannuelle é cirúrgica no "tipo ↔ produto", Mathias fez a discursiva CE inteira sobre NoSQL × relacional (CAP/BASE), e caiu nas DUAS espelhos. Confia de olhos fechados.
| Prof | Veredito | O que disse (literal do dossiê) |
|---|---|---|
| Emannuelle Gouveia | 🎯 CRAVOU (id 2746 grafo + id 3709 chave-valor) | "Vem muita questão: marque o exemplo de banco orientado a X. Cai de forma bem direta" · "NoSQL não é 'não SQL', é Not Only SQL" · 4 tipos+produtos |
| Felipe Mathias | 🎯 CRAVOU (discursiva CE) | "4 paradigmas: documentos/colunar/chave-valor/grafos" · CAP (2 de 3, favorece A+P) · BASE × ACID · correlação tabela↔coleção, linha↔documento, PK↔_id |
| Manuela (Simulado TI CE) | 🎯 aposta pro CE | "grafos = múltiplos relacionamentos · sharding/escala horizontal · consistência eventual" |
Considerando uma investigação de fraude fiscal em que a Receita Estadual precisa modelar relações entre empresas, sócios, operações, notas fiscais e intermediários, com consultas profundas de vizinhança e caminhos entre entidades, o tipo de banco NoSQL que atende ao cenário descrito é
Um sistema estadual de arrecadação consolida diariamente indicadores tributários provenientes de múltiplas fontes e, para acelerar leituras repetitivas desses indicadores já consolidados, a equipe de Dados está avaliando armazená-los em um banco NoSQL do tipo chave-valor. Considerando as características desse modelo de dados, a justificativa que melhor fundamenta essa escolha é:
🪤 AS PEGADINHAS DO BLOCO 4
NoSQL = "não SQL"? → NÃO. É "Not Only SQL" (não SOMENTE SQL). E suporta os 3 tipos de dado (Aula 00).
"Grafo serve pra documentos" / "chave-valor pra múltiplos relacionamentos" → trocou os tipos. Grafo = relacionamentos; documento = flexível.
CAP atende os 3 (C+A+P) ao mesmo tempo? → NÃO, só 2. NoSQL escolhe A+P (sacrifica C).
A alternativa "mais completa/bonita" é a certa? → CUIDADO — quando se pede a justificativa de UM tipo, a certa é a característica ESSENCIAL, não a genérica de distribuído (foi a casca de banana da id 3709, letra B).
Mapa de correlação (Mathias, decore): tabela↔coleção · linha/registro↔documento · coluna↔campo · PK↔_id · FK↔referência/embedded.
🔗 CONEXÃO — não é ilha
Liga com a Aula 00 (tipos de dado): NoSQL é onde os 3 tipos convivem (estruturado/semi/não-estruturado) — por isso a NF-e em XML (semi) e o auto de infração em PDF (não-estruturado) vão pro Data Lake/NoSQL, não pra tabela relacional rígida.
Liga com a Aula 02 (arquitetura): o NoSQL é o motor do Big Data (escalabilidade horizontal via sharding) — a FCC associa muito NoSQL ↔ Big Data.
Caso fiscal-rei: o grafo é a arma anti-fraude — mapeia o esquema de notas frias entre laranjas (sócios↔empresas↔NF-e), exatamente o que o Guilherme caça.
🧊 GUARDE NO BOLSO (Bloco 4)
4 tipos ↔ produto ↔ caso: chave-valor (Redis, cache/baixa latência) · documento (MongoDB, flexível/JSON) · colunar (Cassandra, analítico) · grafo (Neo4j, fraude/caminhos).
NoSQL = Not Only SQL. Relacional = ACID (escolhe C) · NoSQL = BASE (escolhe A+P) · CAP = só 2 de 3.
🪤 "caminhos/vizinhança" → GRAFO · "flexibilidade" → DOCUMENTO · "baixa latência por chave" → CHAVE-VALOR.
➡️ Próximo (Bloco 5): o OURO ÓRFÃO MÁXIMO — SQL escrito na mão. Funções de janela (RANK/DENSE_RANK), CTE, GROUP BY/HAVING, JOIN. Ninguém deu, decidiu o MT. Aqui você vira fera. Pega FIRME.
🎯 O que travar neste bloco (a aposta nº1 do bloco INTEIRO):
DQL básico: SELECT · WHERE (AND/OR/IN/BETWEEN) · ORDER BY · GROUP BY · HAVING (filtra GRUPO, ≠ WHERE) · agregação (COUNT/SUM/AVG).
JOIN: condição no ON × WHERE muda tudo no LEFT JOIN.
👻 O OURO ÓRFÃO: funções de janela (RANK × DENSE_RANK × ROW_NUMBER · SUM() OVER PARTITION BY) · CTE (WITH) · subquery correlacionada.
🔴🔴 PROBABILIDADE PRO CE: A MAIS ALTA DO BLOCO. Caiu 8× no MT + 1 no SP, todos os profs cravam, e o edital CE lista os subtemas um a um (#9: agregação, agrupamento, junção, ordenação, restrições, operações lógicas). Treinar na mão — NÃO decorar definição.
🎙️ O RECADO DURO DO CAMILO (leia antes de tudo):
Este bloco é o coração da prova de BD e é onde o curso do CE te abandonou — o Renato prometeu uma "Aula 4" de SQL que nunca saiu. As funções de janela e a CTE decidiram o MT e NENHUM cursinho deu de bandeja. Então combina comigo: você NÃO vai decorar o que é RANK. Você vai simular a saída na mão, linha por linha, até o OVER (PARTITION BY) virar reflexo. É como a pista de obstáculos — você corre até o corpo saber. Cada questão aqui é ponto de graça que o concorrente larga em branco.
A FCC pega quem não sabe em que ordem o banco executa as cláusulas. Decore esta escada — ela explica por que HAVING ≠ WHERE e por que o ON ≠ WHERE:
🧊 ORDEM DE EXECUÇÃO (não é a ordem que você escreve!)
| # | Cláusula | O que faz |
|---|---|---|
| 1 | FROM / JOIN | monta as tabelas (e o ON filtra a junção) |
| 2 | WHERE | filtra LINHAS (antes de agrupar) |
| 3 | GROUP BY | agrupa as linhas |
| 4 | HAVING | filtra GRUPOS (depois de agregar) |
| 5 | SELECT | escolhe colunas (e calcula funções de janela) |
| 6 | ORDER BY | ordena o resultado final |
🔑 A regra de ouro: WHERE filtra LINHA (antes do GROUP BY); HAVING filtra GRUPO (depois). Por isso você não pode usar SUM() no WHERE — o SUM só existe depois do agrupamento (use HAVING).
🎬 Caso: o Guilherme quer o total de ICMS por município, mas só os municípios cujo total passa do limite legal.
SELECT municipio, SUM(valor_icms) AS total
FROM arrecadacao
GROUP BY municipio -- agrupa por município
HAVING SUM(valor_icms) > 1000000; -- filtra GRUPOS (total > limite)O
GROUP BYjunta as linhas por município; oSUMagrega; o HAVING corta os grupos abaixo do limite. WHERE não serviria — o total só existe depois de agrupar.
Em uma consulta para totalizar ICMS por município e retornar apenas municípios cujo total agregado ultrapasse um limite legal, considerando a ordem de avaliação das cláusulas SQL, a cláusula usada para filtrar resultados agregados após o agrupamento é
🎬 Caso: o Guilherme quer TODAS as NF-e autorizadas, mesmo as sem pagamento, mas só considerando pagamentos com situação
'CONFIRMADO'.Aqui mora uma das pegadinhas mais finas da FCC. No LEFT JOIN: - condição no ON → filtra durante a junção, preserva todas as linhas da esquerda (NF-e sem pagamento ficam, com NULL). - condição no WHERE → filtra depois, e ELIMINA as NF-e sem pagamento (porque NULL não passa no
situacao = 'CONFIRMADO').
Um data warehouse relaciona NF-e (tabela T_NFE) a registros de pagamento (tabela T_PAGAMENTO, referenciada no SQL pelo alias p), com a necessidade de listar todas as NF-e autorizadas mesmo quando não exista pagamento associado e considere apenas pagamentos cuja coluna situacao esteja com valor 'CONFIRMADO'. Nesse caso, a forma de impor a condição sobre p.situacao sem eliminar NF-e sem pagamento é
Aqui é onde você ganha do concorrente. Função de janela = faz um cálculo POR GRUPO mas MANTÉM cada linha (diferente do GROUP BY, que colapsa em 1 linha por grupo). A marca é o OVER (...).
🧊 RANK × DENSE_RANK × ROW_NUMBER — caixa-mãe (decore a diferença no empate)
Imagine ranquear contribuintes por crédito tributário. Dois empatam em 1º:
| Contribuinte | Crédito | ROW_NUMBER | RANK | DENSE_RANK |
|---|---|---|---|---|
| DABOA | 100 | 1 | 1 | 1 |
| BETA | 100 | 2 | 1 | 1 |
| GAMA | 90 | 3 | 3 (pula o 2) | 2 (sem lacuna) |
| DELTA | 80 | 4 | 4 | 3 |
🔑 A diferença que a FCC cobra:
ROW_NUMBER() = numera 1,2,3,4 sempre (nunca empata, ignora empate).
RANK() = empate recebe a mesma posição, mas PULA a seguinte (1,1,3) — deixa lacuna.
DENSE_RANK() = empate recebe a mesma posição e NÃO pula (1,1,2) — sem lacuna.
Um relatório de fiscalização foi elaborado para classificar contribuintes por valor total de crédito tributário, exigindo que empates recebam a mesma posição e que a numeração não apresente lacunas após empates. A função analítica Oracle que atende corretamente ao requisito é
Agora o SUM() OVER (PARTITION BY) — somar por grupo mantendo a linha:
🧊 SUM() OVER (PARTITION BY ...) — a "soma que não colapsa"
O PARTITION BY divide em grupos (como o GROUP BY), mas o OVER faz a soma aparecer em cada linha do grupo, sem perder o detalhe.
SELECT contribuinte_id, exercicio, mes, valor_icms,
SUM(valor_icms) OVER (PARTITION BY contribuinte_id, exercicio) AS total_anual
FROM arrecadacao_icms;
Resultado: cada linha mensal aparece (granularidade preservada) E ao lado vem o total anual do contribuinte naquele exercício. GROUP BY não faria isso (colapsaria os meses).
Em uma data warehouse em que ARRECADACAO_ICMS registra valores mensais por contribuinte e exercício, e sendo necessário exibir cada mês mantendo a granularidade, mas também o total anual por contribuinte em cada linha, a abordagem mais adequada é utilizar SUM(valor_icms)
🧊 CTE — Common Table Expression (WITH)
Cria um resultado intermediário nomeado (uma "tabela temporária" da consulta), pra reusar e deixar legível. Perfeito quando você calcula um agregado e precisa compará-lo com outra agregação.
WITH total_por_municipio AS (
SELECT municipio, SUM(valor) AS total FROM arrecadacao GROUP BY municipio
)
SELECT municipio, total FROM total_por_municipio
WHERE total > (SELECT AVG(total) FROM total_por_municipio); -- reusa a CTE
Deseja-se obter a apuração do total de ICMS por município e, a partir desse resultado intermediário, retornar apenas municípios cujo total esteja acima da média estadual, usando SQL Oracle com legibilidade e reúso do resultado agregado. Para isso, a estrutura adequada deve usar
Agora a subquery correlacionada — a subconsulta que roda uma vez por linha da consulta externa, referenciando ela:
Em uma SEFAZ, a tabela PAGAMENTO_ICMS possui valores pagos por contribuinte e exercício, e a necessidade de retornar apenas contribuintes cujo pagamento em um exercício seja maior que a média do próprio exercício, calculada dinamicamente. Nesse caso, a construção SQL que atende corretamente ao que se deseja é
Em um processo anual de consolidação de arrecadação, totais de ICMS por município devem ser inseridos em uma tabela histórica a partir da tabela operacional, garantindo consistência do agregado no momento da inserção. A abordagem SQL no Oracle que melhor atende ao requisito é INSERT
Uma equipe de fiscalização deseja gerar um relatório priorizando contribuintes cujo volume de NF-e emitidas seja atípico. A tabela nfe contém, entre outras, as colunas contribuinte_id e qtd_emitidas. Deseja-se listar os contribuintes cuja quantidade emitida no mês seja maior que 5000 ou menor que 10, ordenando a saída do maior para o menor valor de qtd_emitidas. O comando SQL que atende ao requisito é: SELECT contribuinte_id,
🪤 AS PEGADINHAS DO BLOCO 5 (as que decidem a prova)
HAVING × WHERE: HAVING filtra grupo (depois do GROUP BY); WHERE filtra linha (antes). Não pode SUM() no WHERE.
LEFT JOIN — condição no ON × WHERE: no ON preserva a esquerda; no WHERE vira INNER e elimina os NULL.
RANK × DENSE_RANK: RANK pula (lacuna); DENSE_RANK é denso (sem lacuna). "Sem lacuna" = DENSE_RANK.
GROUP BY × função de janela: GROUP BY colapsa (1 linha/grupo); OVER (PARTITION BY) mantém as linhas com o total ao lado.
Função de janela (OVER) NÃO vai no WHERE — só no SELECT/ORDER BY (roda depois do WHERE).
> X AND < Y com X>Y = conjunto vazio (sempre distrator). Extremos = OR.
OVER() vazio = total geral · OVER(ORDER BY) = acumulado · OVER(PARTITION BY) = total do grupo.
🔗 CONEXÃO — não é ilha
Liga com a Aula 02 (OLAP): o SUM() OVER (PARTITION BY) é a versão SQL do drill-down/roll-up — você vê o detalhe (mês) E o agregado (ano) na mesma tela.
Liga com a Aula 07 (Python/Pandas): o GROUP BY do SQL é o df.groupby() do Pandas; o pd.Grouper(freq='M') que caiu no MT (Aula 00) é o mesmo "agrupar por chave" do SQL. Mesma lógica, ferramenta diferente.
Caso fiscal-rei: o DENSE_RANK monta o ranking de maiores devedores de ICMS (a "lista de prioridade" da malha fiscal), e o SUM OVER mostra quanto cada contribuinte deve no ano sem perder o detalhe mensal — exatamente o relatório que prioriza quem o Guilherme fiscaliza primeiro.
🧊 GUARDE NO BOLSO (Bloco 5 — o mais importante da aula)
Ordem de execução: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.
WHERE filtra linha · HAVING filtra grupo.
LEFT JOIN: condição no ON preserva a esquerda; no WHERE vira INNER.
RANK pula (lacuna) · DENSE_RANK denso (sem lacuna) · ROW_NUMBER sempre 1,2,3.
SUM() OVER (PARTITION BY) = total do grupo MANTENDO a linha (≠ GROUP BY que colapsa).
CTE (WITH) = resultado intermediário reutilizável/legível · subquery correlacionada = média "do próprio grupo, por linha" · janela não vai no WHERE.
➡️ Próximo (Bloco 6): Oracle — instância/SGA, trigger :OLD/:NEW e o trio DROP × TRUNCATE × DELETE. Pega LEVE, é blindagem que pode encolher no CE.
🎯 O que travar neste bloco (só o que a prova cobrou):
Instância = SGA (memória) + processos de segundo plano (não é tablespace nem datafile).
Trigger DML nível LINHA usa :OLD e :NEW (auditoria automática sem mexer na aplicação).
DROP remove estrutura+dados · TRUNCATE só dados (mantém estrutura) · DELETE linha a linha.
🟡 PROBABILIDADE PRO CE: MÉDIA (tende a ENCOLHER). Caiu 3× no MT, mas só no MT — e o edital CE pesa DQL e ciência de dados, não administração de SGBD/DBA. O Renato (prof do CE) não dá Oracle. Pega leve: decora o que caiu, não afunda em flashback/RMAN.
A SEFAZ exige que toda alteração de lançamento fiscal gere um log automático com o valor antigo e o novo — sem depender de o programador lembrar de chamar a rotina. Solução: um trigger que dispara sozinho no banco a cada INSERT/UPDATE, capturando :OLD (valor anterior) e :NEW (valor novo). É o "olho que nunca pisca" da auditoria.
🧊 ORACLE — caixa-mãe (decore só isto)
| Conceito | Definição | Pegadinha |
|---|---|---|
| Instância Oracle | SGA (memória compartilhada) + processos de segundo plano que executam SQL | NÃO é tablespace, datafile nem dicionário |
| SGA | área de memória: Buffer Cache, Redo Log Buffer, Shared Pool, Large Pool, Stream Pool | é memória, não disco |
| Trigger DML de linha | dispara automático em INSERT/UPDATE/DELETE; usa :OLD / :NEW | ≠ procedure (chamada manual), ≠ job (agendado) |
| DROP | remove a tabela + os dados + a estrutura | DDL |
| TRUNCATE | remove só os dados (mantém a estrutura/tabela) | DDL, não dá pra "voltar" fácil |
| DELETE | remove linha a linha (com WHERE), pode dar rollback | DML |
🎙️ O PLACAR DOS PROFESSORES — Oracle
Leitura do Camilo: Emannuelle é a dona do Oracle (faro 8/10) e cravou SGA + DROP. O trigger :OLD/:NEW é um órfão fino (ninguém destacou como aposta, mas caiu). ⚠️ A aula dela tem MUITO DBA pesado (flashback, RMAN, isolamento) que caiu menos — não afunde nisso pro CE.
| Prof | Veredito | O que disse (literal do dossiê) |
|---|---|---|
| Emannuelle Gouveia | 🎯 CRAVOU (id 2976 SGA + id 2982 DROP) | "SGA — Buffer Cache, Redo Log Buffer, Shared/Large/Stream Pool" · "DROP apaga a estrutura e o conteúdo; TRUNCATE apaga só os dados, mantém a estrutura" · "essa aula tem chances reais, não tem apelação" |
| Felipe Mathias | 🎯 CRAVOU (id 2982) | DDL/DROP no guia de SQL |
| trigger :OLD/:NEW (id 2983) | ⚠️ órfão fino | nenhum dossiê isolou trigger de linha como aposta destacada — mas caiu |
Uma Secretaria da Fazenda usa um sistema de arrecadação estadual em Oracle Database por onde múltiplos usuários executam consultas simultâneas como necessidade de processamento consistente de SQL. Nesse cenário e levando em conta a arquitetura básica do Sistema Gerenciador de banco de Dados, o componente que processa instruções SQL por meio de memória compartilhada e processos é
Em um sistema estadual, toda inserção ou alteração de lançamentos fiscais deve gerar auditoria automática com valores anteriores e novos, sem intervenção da aplicação. Respeitando os modelos de estrutura DML do Oracle, a solução técnica mais adequada consiste na criação de
Considere a descontinuidade de um módulo tributário após mudança normativa e a necessidade de remover definitivamente uma tabela de arrecadação e seus dados do esquema Oracle, respeitando regras de DDL. Nesse caso, a ação mais adequada é
🪤 AS PEGADINHAS DO BLOCO 6
Instância = tablespace/datafile? → NÃO. Instância = memória (SGA) + processos. Tablespace/datafile = disco (só armazena).
Trigger de instrução acessa :OLD/:NEW por linha? → NÃO, só o de linha acessa. Auditoria de valor antigo/novo = trigger de linha.
TRUNCATE remove a estrutura? → NÃO, só os dados (mantém a tabela). Quem remove a estrutura é o DROP.
DELETE apaga a estrutura/metadados? → NÃO, só linhas. Tabela continua existindo.
🔗 CONEXÃO — não é ilha
Liga com o Bloco 2 (DML/DDL): DROP/TRUNCATE são DDL (mudam estrutura); DELETE é DML (muda dados); GRANT é DCL; SELECT é DQL. Saber a sublinguagem de cada comando é decoreba de ponto fácil.
Liga com o sigilo fiscal (Aula 06): o trigger de auditoria é a base técnica da rastreabilidade que a IN SEFAZ-CE 92/21 e o CTN 198 exigem — todo acesso/alteração de dado de contribuinte deixa rastro automático.
🧊 GUARDE NO BOLSO (Bloco 6)
Instância = SGA (memória) + processos (processa SQL); disco só armazena.
Trigger de LINHA + :OLD/:NEW = auditoria automática (valor antigo/novo, sem mexer na aplicação).
DROP mata tabela (estrutura+dados) · TRUNCATE esvazia (só dados) · DELETE remove linhas.
Sublinguagens: DDL (create/drop/truncate) · DML (insert/update/delete) · DQL (select) · DCL (grant/revoke) · DTL (commit/rollback).
Para tudo e respira, Felício. 🫁 Esta foi a aula mais prática da série até agora — e a mais rentável. Você saiu do "o que é uma tabela" e chegou no SUM() OVER (PARTITION BY contribuinte_id, exercicio). Isso é o que decide a prova de BD na FCC nova. Guarda o que importa no bolso e pega a ordem de ataque.
A tabela-mãe da Aula 03 (cola no espelho):
Bloco Núcleo (1 frase) 🔑 Bordão 1️⃣ Relacional entidade→tabela, atributo→coluna, relação=tabela "MER=conceitual; PK não nula" 2️⃣ PK/FK PK identifica dentro, FK aponta pra fora "PK = NOT NULL + UNIQUE · CDER" 3️⃣ Normalização decompor pra tirar redundância "1FN=Atômico, 2FN=Parcial, 3FN=Transitiva · derivado quebra 3FN" 4️⃣ NoSQL banco certo pra cada missão "grafo=fraude/caminhos · NoSQL=Not Only SQL · ACID×BASE×CAP" 5️⃣ SQL na mão filtra, agrupa, ranqueia "WHERE linha/HAVING grupo · DENSE_RANK sem lacuna · OVER mantém linha" 6️⃣ Oracle DBA leve "instância=SGA+processos · trigger :OLD/:NEW · DROP×TRUNCATE×DELETE"
Você não precisa gabaritar BD — precisa passar do corte. A ordem é por ROI:
1️⃣ TREINA SQL escrito na mão 🔴🔴 — é o que MAIS cai (8× no MT) e o que NINGUÉM te deu.
Foco: funções de janela (RANK/DENSE_RANK/ROW_NUMBER · SUM OVER PARTITION BY), CTE (WITH), GROUP BY/HAVING, JOIN ON×WHERE. Edital CE lista isso item por item.
Ação: refaz as 9 questões deste bloco até a saída sair na sua cabeça antes de olhar o gabarito. SQL é treino, não leitura.
2️⃣ DECORA NoSQL por caso de uso 🔴 — caiu nas 2 espelhos diretas (GO+SP), 3 sinais cravados.
3️⃣ TRAVA normalização 🔴 — Mathias chama de OURO; a clássica do derivado.
4️⃣ BLINDAGEM: relacional + PK/FK + Oracle 🟡 — base estável, mas cai pouco/encolhe no CE.
🧭 Bordão do plano: o SQL na mão vale por 5 questões; trate como a pista de obstáculos — corre até virar reflexo.
Honestidade temporal: o CE ainda NÃO aconteceu (prova 01-02/08/2026) — tudo aqui é aposta 🔮, calibrada pelo que JÁ CAIU ⚡ em MT/GO/SP 2026.
Tema Quem confiar Veredito real Pro CE SQL escrito (janela/CTE/HAVING/JOIN) Mathias + drill Camilo ⚡ JÁ CAIU 8× (MT) + 1 (SP) 🔴🔴 MÁXIMA NoSQL por tipo Emannuelle + Mathias ⚡ JÁ CAIU (GO grafo + SP chave-valor) 🔴 ALTA Normalização 1-3FN Mathias (OURO) ⚡ JÁ CAIU (MT) 🔴 ALTA PK/FK/relacional Emannuelle/Mathias ⚡ JÁ CAIU (MT, embutido) 🟡 MÉDIA Oracle/trigger/SGA Emannuelle ⚡ JÁ CAIU (MT 3×) 🟡 MÉDIA (encolhe)
O professor de TI aqui é o Camilo. O Mathias e a Emannuelle têm faro de ouro — eu peso o que eles mostraram. Mas a palavra final é nossa, calibrada pela prova real: o Mathias cravou normalização e DQL (e caiu); a Emannuelle cravou NoSQL e SGA (e caiu); e o buraco que NINGUÉM tapou — funções de janela e CTE — é onde EU entro com você no drill. Você não decora cursinho — você resolve SQL.
🔑 Bordão-mestre da Aula 03: banco de dados na FCC não se decora — se RESOLVE na mão. Quem treina o
OVER (PARTITION BY)pega o ponto que o concorrente larga em branco.
🧭 PRÓXIMA PARADA — Aula 04: Machine Learning & IA (o OURO MÁXIMO).
Se BD/SQL é ouro, ML é a mina inteira: 7 das 11 questões de Fluência da SEFAZ-SP 2026 foram de Machine Learning. Na Aula 04 a gente ataca supervisionado × não-supervisionado, clusterização (K-means), over/underfitting, treino/validação/teste e o par órfão Lasso × Ridge que só o Mathias deu. É o bloco que decide a vaga. Pega firme lá em cima. 🪜
🔵 Bate o olho e resolve as que você já sabe · 🔴 Corrige com calma as que travar. Todas FCC, conferidas no banco. As de SQL escrito são o alvo (funções de janela, CTE, HAVING, JOIN — o ouro órfão que decide); NoSQL e Oracle vêm em seguida. Resolve o SQL NA MÃO, simulando a saída — é treino, não leitura.
Última atualização: 22/06/2026 12:08 — Camilo