📚 Banco de Dados — Notas de Aula

Módulo 1 — Projeto de Banco de Dados Relacional
Unidade 1 · Visão Geral sobre Banco de Dados e Motivação

Um banco de dados é uma coleção organizada de dados relacionados, gerenciada por um SGBD (Sistema Gerenciador de Banco de Dados). O objetivo é armazenar, recuperar e manipular dados de forma eficiente, segura e consistente.

Antes dos SGBDs, os dados ficavam em arquivos isolados — cada programa tinha seus próprios arquivos, gerando redundância, inconsistência e dificuldade de acesso compartilhado.

Problemas do sistema de arquivos
Redundância: mesmos dados em vários arquivos.
Inconsistência: atualizações parciais.
Isolamento: difícil compartilhar.
Concorrência: acessos simultâneos problemáticos.
Vantagens do SGBD
Independência dos dados.
Controle de redundância.
Compartilhamento.
Segurança e integridade.
Backup e recuperação.
Exemplo
Sistema de uma universidade: sem SGBD, o setor financeiro tem um arquivo de alunos e o setor acadêmico tem outro. O nome do aluno pode estar errado em um e certo no outro. Com SGBD, há uma única fonte de verdade.

Arquitetura de 3 Níveis (ANSI/SPARC)
NívelNomeO que descreveQuem vê
ExternoVisãoComo cada usuário vê os dadosUsuário final
ConceitualEsquema lógicoEstrutura geral do bancoDBA
InternoFísicoComo os dados são armazenadosSGBD
⚠ Importante
Independência lógica: mudar o esquema conceitual sem afetar as visões dos usuários. Independência física: mudar o armazenamento sem afetar o esquema conceitual.

Exercícios Resolvidos
Exercício 1: Qual é a principal vantagem do SGBD sobre arquivos convencionais?
→ Controle centralizado com eliminação de redundância e inconsistência.
O SGBD mantém uma única cópia consistente dos dados, com controle de acesso, integridade e recuperação automática.
Exercício 2: O que é independência de dados?
→ Capacidade de alterar a estrutura dos dados sem impactar aplicações que os utilizam.
Há duas formas: independência lógica (mudar esquema sem mudar visões) e independência física (mudar armazenamento sem mudar esquema).
Módulo 1 — Projeto de Banco de Dados Relacional
Unidade 2 · Modelo Conceitual (ER)

O Modelo Entidade-Relacionamento (ER) é uma forma de representar os dados de um sistema de forma visual e independente de implementação. É o primeiro passo no projeto de um banco de dados.

Entidade
Objeto do mundo real com existência independente. Ex: Aluno, Curso, Professor. Representa uma tabela no modelo relacional.
Atributo
Propriedade de uma entidade. Ex: Aluno tem matrícula, nome, CPF. O atributo que identifica unicamente = chave primária.
Relacionamento
Associação entre entidades. Ex: Aluno se matricula em Curso. Tem cardinalidade: 1:1, 1:N ou N:M.
Cardinalidade
1:1 — Uma pessoa tem um passaporte.
1:N — Um depto tem vários funcionários.
N:M — Alunos cursam várias disciplinas.
Exemplo — Cardinalidade 1:N
Departamento (1) ←→ (N) Funcionário. Um departamento possui vários funcionários, mas cada funcionário pertence a apenas um departamento.
Exemplo — Cardinalidade N:M
Aluno (N) ←→ (M) Disciplina. Um aluno se matricula em várias disciplinas e cada disciplina tem vários alunos. Gera uma tabela intermediária: Matrícula(aluno_id, disciplina_id, nota).

Tipos de Atributos
TipoDescriçãoExemplo
SimplesNão divisívelCPF, matrícula
CompostoDivisível em partesEndereço → rua, número, CEP
MultivaloradoMúltiplos valoresTelefones de uma pessoa
DerivadoCalculado de outroIdade (calculada da data de nascimento)
ChaveIdentifica unicamenteCPF, matrícula, CNPJ
⚠ Importante
Relacionamento N:M sempre gera uma nova tabela no modelo relacional. Ex: Aluno-Disciplina vira tabela Matrícula com chave composta (aluno_id + disciplina_id).
⚠ Importante
Entidade fraca: não tem chave própria, depende de outra entidade. Ex: Dependente depende de Funcionário — sem o funcionário, o dependente não existe.

Exercícios Resolvidos
Exercício 3: Um professor pode lecionar várias disciplinas e uma disciplina pode ter vários professores. Qual a cardinalidade?
N:M — gera tabela intermediária Leciona(prof_id, disc_id, semestre).
Ambos os lados têm "vários". Sempre que isso ocorre, é N:M e precisa de tabela extra para guardar a associação.
Exercício 4: "Data_nascimento" e "Idade" — qual é derivado?
Idade é derivada, pois é calculada a partir de Data_nascimento.
Atributos derivados não precisam ser armazenados — são calculados sob demanda. Armazenar os dois seria redundância.
Módulo 1 — Projeto de Banco de Dados Relacional
Unidade 3 · Modelo Relacional e Transformação entre Modelos

O modelo relacional representa os dados em tabelas (relações). Cada linha é uma tupla (registro) e cada coluna é um atributo. É o modelo mais usado nos SGBDs comerciais (MySQL, PostgreSQL, Oracle).

Conceito ERConceito RelacionalExemplo
EntidadeTabela (Relação)Aluno → tabela Aluno
InstânciaLinha (Tupla)Um aluno específico
AtributoColunanome, matrícula, CPF
Chave primária ERPRIMARY KEYmatrícula INT PRIMARY KEY
Relacionamento 1:NChave estrangeira (FK)depto_id REFERENCES Departamento
Relacionamento N:MTabela intermediáriaMatricula(aluno_id, disc_id)
Restrições de Integridade
Integridade de Entidade
A chave primária (PK) nunca pode ser NULL. Cada linha deve ser unicamente identificável.
Integridade Referencial
A chave estrangeira (FK) deve referenciar um valor existente na tabela pai, ou ser NULL. Ex: depto_id em Funcionário deve existir em Departamento.
Exemplo — Transformação 1:N
ER: Departamento (1) tem (N) Funcionário.
Relacional: Funcionário(func_id, nome, salario, depto_id) — a FK fica no lado N (Funcionário).
Exemplo — Transformação N:M
ER: Aluno (N) se matricula em (M) Disciplina.
Relacional: cria tabela Matricula(aluno_id, disc_id, nota, semestre) com PK composta.

Exercícios Resolvidos
Exercício 5: Em qual tabela fica a chave estrangeira em um relacionamento 1:N?
→ No lado N (o "muitos").
O lado N é quem referencia o lado 1. Ex: vários Funcionários pertencem a um Depto — a FK depto_id fica em Funcionário, não em Departamento.
Exercício 6: O que acontece se tentarmos inserir uma FK com valor que não existe na tabela pai?
→ O SGBD rejeita a operação — violação de integridade referencial.
O SGBD verifica automaticamente se o valor da FK existe na PK da tabela referenciada. Se não existir, a inserção é bloqueada.
Módulo 1 — Projeto de Banco de Dados Relacional
Unidade 4 · Qualidade do Projeto de Banco de Dados (Normalização)

A normalização é o processo de organizar as tabelas para eliminar redundâncias e dependências problemáticas. Uma tabela mal normalizada gera anomalias de inserção, atualização e exclusão.

Forma NormalRegraElimina
1FNAtributos atômicos, sem grupos repetidosAtributos multivalorados na mesma coluna
2FN1FN + sem dependência parcial da PKRedundância em chaves compostas
3FN2FN + sem dependência transitivaAtributos que dependem de não-chave
BCNFTodo determinante é superchaveAnomalias residuais da 3FN
Exemplo — Violação da 1FN
Coluna "Telefones" com valor "11999, 11888" (dois valores numa célula). Solução: criar tabela separada Telefone(pessoa_id, numero).
Exemplo — Violação da 2FN
Tabela Pedido_Item(pedido_id, produto_id, nome_produto, qtd). "nome_produto" depende só de produto_id (dependência parcial). Solução: separar em Produto(produto_id, nome_produto).
Exemplo — Violação da 3FN
Tabela Funcionário(func_id, depto_id, nome_depto). nome_depto depende de depto_id (não da PK). Solução: criar tabela Departamento(depto_id, nome_depto).
⚠ Anomalias de Atualização
Sem normalização: se o nome de um departamento muda, é preciso atualizar em todas as linhas de funcionários — se alguma falhar, o banco fica inconsistente.
⚠ Regra Prática
Na maioria dos projetos, atingir a 3FN é suficiente. BCNF é usada em casos específicos com dependências funcionais complexas.

Exercícios Resolvidos
Exercício 7: A tabela está na 1FN se...
→ Todos os atributos são atômicos (indivisíveis) e não há grupos repetidos.
1FN é a base. Sem ela, não se pode aplicar as formas normais seguintes. Cada célula deve ter exatamente um valor.
Exercício 8: Qual a diferença entre dependência parcial e transitiva?
Parcial: atributo depende de parte da PK composta. Transitiva: atributo depende de outro não-chave.
2FN elimina parcial. 3FN elimina transitiva. São conceitos diferentes e exigem soluções diferentes (separação de tabelas).
Módulo 2 — Definição e Manipulação de Dados Relacionais
Unidade 1 · SQL — Linguagem de Definição de Dados (DDL)

A DDL (Data Definition Language) define a estrutura do banco: cria, altera e remove tabelas e outros objetos. Os principais comandos são CREATE, ALTER e DROP.

-- Criar tabela CREATE TABLE Aluno ( matricula INT PRIMARY KEY, nome VARCHAR(100) NOT NULL, cpf CHAR(11) UNIQUE, nascimento DATE, depto_id INT REFERENCES Departamento(depto_id) );
-- Alterar tabela: adicionar coluna ALTER TABLE Aluno ADD COLUMN email VARCHAR(100); -- Alterar tabela: remover coluna ALTER TABLE Aluno DROP COLUMN email; -- Remover tabela DROP TABLE Aluno;
ConstraintDescriçãoExemplo
PRIMARY KEYIdentifica unicamente cada linha. Não NULL.matricula INT PRIMARY KEY
FOREIGN KEYReferencia PK de outra tabelaREFERENCES Depto(depto_id)
UNIQUEValor único, pode ser NULLcpf CHAR(11) UNIQUE
NOT NULLNão permite valores nulosnome VARCHAR(100) NOT NULL
CHECKValida condição booleanaCHECK (salario > 0)
DEFAULTValor padrão se não informadoativo BOOLEAN DEFAULT TRUE
⚠ Importante
DROP TABLE remove a tabela e todos os dados permanentemente. TRUNCATE remove só os dados. DELETE remove registros com condição. São operações diferentes!

Exercícios Resolvidos
Exercício 9: Qual a diferença entre PRIMARY KEY e UNIQUE?
→ PK: único + não NULL + identifica a linha. UNIQUE: único, mas pode ser NULL.
Uma tabela só tem uma PK (pode ser composta), mas pode ter vários UNIQUE. Ex: CPF é UNIQUE mas email também pode ser UNIQUE — a matrícula seria a PK.
Exercício 10: O que acontece ao usar DROP TABLE em uma tabela referenciada por FK?
→ O SGBD bloqueia a operação por violação de integridade referencial.
Deve-se primeiro remover a tabela que contém a FK, ou usar DROP TABLE ... CASCADE (apaga tudo em cascata — use com cuidado!).
Módulo 2 — Definição e Manipulação de Dados Relacionais
Unidade 2 · SQL — Linguagem de Manipulação de Dados (DML)

A DML (Data Manipulation Language) manipula os dados dentro das tabelas. Comandos principais: SELECT, INSERT, UPDATE, DELETE.

-- INSERT INSERT INTO Aluno (matricula, nome, cpf) VALUES (1, 'Ana', '12345678901'); -- UPDATE UPDATE Aluno SET nome = 'Ana Silva' WHERE matricula = 1; -- DELETE DELETE FROM Aluno WHERE matricula = 1; -- SELECT básico SELECT nome, cpf FROM Aluno WHERE depto_id = 3 ORDER BY nome;
SELECT — Cláusulas Principais
CláusulaFunçãoExemplo
WHEREFiltra linhasWHERE salario > 3000
GROUP BYAgrupa para funções de agregaçãoGROUP BY depto_id
HAVINGFiltra grupos (após GROUP BY)HAVING COUNT(*) > 5
ORDER BYOrdena resultadoORDER BY nome ASC
LIMITLimita quantidade de linhasLIMIT 10
DISTINCTRemove duplicatasSELECT DISTINCT depto_id
JOINs
-- INNER JOIN: só linhas que têm correspondência nos dois lados SELECT a.nome, d.nome_depto FROM Aluno a INNER JOIN Departamento d ON a.depto_id = d.depto_id; -- LEFT JOIN: todas as linhas da esquerda, NULL onde não há correspondência SELECT a.nome, d.nome_depto FROM Aluno a LEFT JOIN Departamento d ON a.depto_id = d.depto_id;
JOINResultado
INNER JOINSó linhas com correspondência nos dois lados
LEFT JOINTodos da esquerda + correspondentes da direita (NULL se não houver)
RIGHT JOINTodos da direita + correspondentes da esquerda (NULL se não houver)
FULL JOINTodos de ambos os lados (NULL onde não há correspondência)
Funções de Agregação
SELECT depto_id, COUNT(*) AS total_func, AVG(salario) AS media_sal, MAX(salario) AS maior_sal, MIN(salario) AS menor_sal, SUM(salario) AS folha FROM Funcionario GROUP BY depto_id HAVING COUNT(*) > 3;
⚠ WHERE vs HAVING
WHERE filtra linhas individuais (antes do agrupamento). HAVING filtra grupos (depois do GROUP BY). Não se usa HAVING sem GROUP BY.

Exercícios Resolvidos
Exercício 11: Liste os departamentos com mais de 5 funcionários e sua média salarial.
GROUP BY + HAVING COUNT(*) > 5 + AVG(salario)
SELECT depto_id, AVG(salario) FROM Funcionario GROUP BY depto_id HAVING COUNT(*) > 5;
Exercício 12: Qual JOIN retorna todos os alunos mesmo que não estejam matriculados em nenhuma disciplina?
LEFT JOIN — Aluno LEFT JOIN Matricula.
LEFT JOIN mantém todos do lado esquerdo (Aluno). Para alunos sem matrícula, as colunas de Matricula ficarão NULL.
Módulo 3 — Bancos de Dados Relacionais (Avançado)
Unidade 1 · Indexação e Segurança em Banco de Dados

Um índice é uma estrutura auxiliar que acelera as buscas. Funciona como o índice de um livro: em vez de ler todas as páginas, o SGBD vai direto ao ponto. O custo é espaço em disco e mais tempo nas inserções/atualizações.

Sem índice
Busca por nome: o SGBD lê todas as linhas (full table scan). O(n) — lento para tabelas grandes.
Com índice (B-tree)
Busca por nome: o SGBD percorre a árvore B e vai direto ao registro. O(log n) — muito mais rápido.
-- Criar índice CREATE INDEX idx_aluno_nome ON Aluno(nome); -- Índice único CREATE UNIQUE INDEX idx_aluno_cpf ON Aluno(cpf); -- Índice composto CREATE INDEX idx_func_depto_sal ON Funcionario(depto_id, salario); -- Remover índice DROP INDEX idx_aluno_nome;
⚠ Quando criar índices
Crie índice em colunas usadas frequentemente em WHERE, JOIN, ORDER BY. Evite em colunas com poucos valores distintos (ex: sexo M/F) — o ganho é mínimo e o custo de manutenção é alto.

Segurança — Controle de Acesso

O SGBD controla quem pode fazer o quê usando GRANT (conceder privilégios) e REVOKE (revogar privilégios).

-- Conceder privilégio de SELECT na tabela Aluno ao usuário 'joao' GRANT SELECT ON Aluno TO joao; -- Conceder múltiplos privilégios GRANT SELECT, INSERT, UPDATE ON Aluno TO maria; -- Revogar privilégio REVOKE INSERT ON Aluno FROM joao; -- Criar visão para restringir acesso a colunas sensíveis CREATE VIEW v_aluno_publico AS SELECT matricula, nome FROM Aluno; GRANT SELECT ON v_aluno_publico TO publico;
Privilégio SQLO que permite
SELECTLer dados
INSERTInserir novos registros
UPDATEModificar registros existentes
DELETERemover registros
ALL PRIVILEGESTodos os privilégios acima

Exercícios Resolvidos
Exercício 13: Por que índices podem piorar a performance em operações de escrita?
→ A cada INSERT/UPDATE/DELETE, o SGBD precisa atualizar o índice, gerando overhead.
O ganho em leitura pode ser anulado pelo custo de manutenção em tabelas com muitas escritas. É um trade-off: leitura rápida vs escrita mais lenta.
Exercício 14: Como restringir um usuário para ver apenas algumas colunas de uma tabela?
→ Criar uma VIEW com as colunas permitidas e conceder SELECT apenas na VIEW.
O usuário nunca acessa a tabela diretamente — só enxerga a visão filtrada. É a forma padrão de controlar acesso a colunas.
Módulo 3 — Bancos de Dados Relacionais (Avançado)
Unidade 2 · Processamento de Transações e Controle de Concorrência

Uma transação é uma sequência de operações tratada como uma unidade indivisível. Ou tudo acontece, ou nada acontece. Ex: transferência bancária — débito + crédito devem ocorrer juntos.

Propriedades ACID
PropriedadeSignificadoExemplo
AtomicidadeTudo ou nada — sem operações parciaisTransferência: débito E crédito ocorrem juntos
ConsistênciaO banco vai de um estado válido para outroSaldo nunca fica negativo se há restrição
IsolamentoTransações paralelas não interferem entre siDois saques simultâneos não "se veem"
DurabilidadeDados confirmados persistem mesmo após falhaApós COMMIT, dados ficam em disco
-- Exemplo de transação BEGIN; UPDATE Conta SET saldo = saldo - 500 WHERE id = 1; -- débito UPDATE Conta SET saldo = saldo + 500 WHERE id = 2; -- crédito COMMIT; -- confirma tudo -- Se der erro, desfaz: ROLLBACK;
⚠ COMMIT vs ROLLBACK
COMMIT: confirma a transação permanentemente (durável). ROLLBACK: desfaz todas as operações da transação — banco volta ao estado anterior ao BEGIN.

Controle de Concorrência — Problemas
ProblemaO que ocorreSolução
Leitura sujaLê dado de transação não confirmadaIsolamento READ COMMITTED
Leitura não repetívelLê o mesmo dado 2x e os valores diferemIsolamento REPEATABLE READ
Leitura fantasmaNova linha aparece entre duas leiturasIsolamento SERIALIZABLE
Atualização perdidaDuas transações sobrescrevem a mesma linhaBloqueio (lock)
Exemplo — Leitura suja
T1 debita R$100 de uma conta (mas não fez COMMIT). T2 lê o saldo (já descontado). T1 faz ROLLBACK. Agora T2 tem um valor que nunca existiu — isso é leitura suja.
⚠ Níveis de Isolamento (do menos para o mais restrito)
READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE. Mais isolamento = mais seguro, mas menor performance (mais bloqueios).

Exercícios Resolvidos
Exercício 15: Por que a atomicidade é essencial em transferências bancárias?
→ Sem atomicidade, o débito pode ocorrer mas o crédito falhar, sumindo dinheiro do sistema.
A transação garante que ou ambas as operações ocorrem (COMMIT) ou nenhuma (ROLLBACK). Nunca um estado intermediário visível.
Exercício 16: Qual nível de isolamento previne leitura fantasma?
SERIALIZABLE — o mais restritivo.
SERIALIZABLE garante que o resultado de transações paralelas é igual ao de execução em série. Elimina todos os problemas, mas com maior custo de performance.
Módulo 4 — Bancos de Dados NoSQL
Unidade 1 · Introdução ao NoSQL

NoSQL ("Not Only SQL") são SGBDs que não seguem o modelo relacional tradicional. Surgiram para lidar com grandes volumes de dados, alta disponibilidade e escalabilidade horizontal — demandas que SGBDs relacionais têm dificuldade em atender.

Banco Relacional (SQL)
Esquema fixo (schema-on-write).
Transações ACID.
Escala vertical (hardware maior).
Dados estruturados.
Ex: MySQL, PostgreSQL, Oracle.
Banco NoSQL
Esquema flexível (schema-on-read).
Consistência eventual (BASE).
Escala horizontal (mais máquinas).
Dados semi ou não estruturados.
Ex: MongoDB, Redis, Cassandra.
Teorema CAP

Um sistema distribuído não pode garantir simultaneamente as três propriedades: Consistência (C), Disponibilidade (A) e Tolerância a partições (P). Deve-se escolher 2.

Combinação CAPSacrificaExemplos
CPDisponibilidadeMongoDB, HBase
APConsistênciaCassandra, CouchDB
CATolerância a partiçõesSGBDs relacionais tradicionais
Tipos de Bancos NoSQL
TipoEstruturaUso idealExemplos
Chave-ValorDicionário simplesCache, sessõesRedis, DynamoDB
DocumentosJSON/BSON aninhadoCatálogos, perfisMongoDB, CouchDB
ColunarFamílias de colunasAnalytics, IoTCassandra, HBase
GrafosNós e arestasRedes sociais, rotasNeo4j, ArangoDB
⚠ BASE vs ACID
NoSQL segue BASE: Basically Available, Soft state, Eventually consistent. A consistência é eventual — todos os nós convergem para o mesmo valor, mas pode haver um atraso.

Exercícios Resolvidos
Exercício 17: Por que redes sociais (ex: Facebook) usam NoSQL?
→ Volume massivo de dados não estruturados, necessidade de escala horizontal e alta disponibilidade.
Bilhões de usuários geram posts, curtidas e comentários com estruturas variadas. NoSQL escala adicionando servidores (horizontal) sem reformular o esquema.
Exercício 18: O que é consistência eventual?
→ Os dados ficam temporariamente inconsistentes entre nós, mas convergem para o mesmo valor após algum tempo.
Ex: você posta algo no Instagram e por segundos alguns usuários não veem. Depois de propagação, todos veem. A consistência veio, mas com atraso.
Módulo 4 — Bancos de Dados NoSQL
Unidade 2 · NoSQL Orientado a Documentos e Outros SGBDs

O MongoDB é o banco de documentos mais popular. Armazena dados em formato BSON (Binary JSON) em coleções. Não exige esquema fixo — cada documento pode ter campos diferentes.

// Inserir documento db.alunos.insertOne({ nome: "Ana Silva", matricula: 12345, notas: [8.5, 9.0, 7.5], endereco: { cidade: "Campo Grande", uf: "MS" } }); // Buscar db.alunos.find({ nome: "Ana Silva" }); // Atualizar db.alunos.updateOne( { matricula: 12345 }, { $set: { nome: "Ana Costa" } } ); // Remover db.alunos.deleteOne({ matricula: 12345 });
Comparativo — SQL vs MongoDB
SQL (Relacional)MongoDB (Documentos)
Banco de dadosBanco de dados
TabelaColeção (Collection)
Linha (Tupla)Documento (Document)
ColunaCampo (Field)
JOIN entre tabelas$lookup ou dados embutidos
Schema fixoSchema flexível
Redis — Banco Chave-Valor

O Redis armazena pares chave-valor na memória RAM — extremamente rápido. Ideal para cache, sessões, filas e contadores em tempo real.

SET usuario:1:nome "Ana Silva" # armazena GET usuario:1:nome # retorna "Ana Silva" SETEX sessao:abc123 3600 "dados" # expira em 1h (cache de sessão) INCR visitas:pagina:home # contador atômico
Cassandra — Banco Colunar

O Cassandra é otimizado para escrita massiva e dados distribuídos geograficamente. Usa famílias de colunas e tem linguagem própria (CQL — Cassandra Query Language).

⚠ Quando usar cada NoSQL
Redis: cache, sessão, tempo real.
MongoDB: catálogos, CMS, perfis de usuário, dados variáveis.
Cassandra: logs, IoT, séries temporais, alta escrita.
Neo4j: redes sociais, recomendações, rotas.

Exercícios Resolvidos
Exercício 19: Por que o MongoDB não precisa de ALTER TABLE ao adicionar um campo novo?
→ Documentos são independentes — cada um pode ter campos diferentes.
Em SQL, todos os registros compartilham o mesmo esquema. No MongoDB, um novo campo é adicionado apenas nos documentos que precisam — os demais continuam sem ele.
Exercício 20: Qual banco usar para armazenar o carrinho de compras de um e-commerce com alta concorrência?
Redis — rápido, em memória, suporta expiração automática e operações atômicas.
Carrinhos são temporários, lidos/escritos com alta frequência. Redis garante acesso em microssegundos e pode expirar automaticamente carrinhos abandonados.
🗒 Cola de Prova — Resumo Geral de Banco de Dados
Comparativo de Modelos
ModeloFaseFocoFerramenta
Conceitual (ER)AnáliseO que guardar — entidades e relacionamentosDiagrama ER
Lógico (Relacional)ProjetoComo organizar — tabelas, PKs, FKsEsquema de tabelas
FísicoImplementaçãoComo armazenar — índices, partiçõesSQL DDL no SGBD
Formas Normais
Forma NormalRegra centralO que elimina
1FNAtributos atômicosGrupos repetidos, listas em colunas
2FNSem dependência parcial da PKRedundância em PKs compostas
3FNSem dependência transitivaAtributos que dependem de não-chave
SQL — Ordem de Execução
SELECT -- 6. seleciona colunas FROM -- 1. identifica tabelas JOIN -- 2. combina tabelas WHERE -- 3. filtra linhas GROUP BY -- 4. agrupa HAVING -- 5. filtra grupos ORDER BY -- 7. ordena LIMIT -- 8. limita
Propriedades ACID × BASE
ACID (SQL)
Atomicidade — tudo ou nada
Consistência — estado sempre válido
Isolamento — transações independentes
Durabilidade — persistência após commit
BASE (NoSQL)
Basically Available — sempre responde
Soft state — estado pode mudar
Eventually consistent — convergência
⭐ Regras de Ouro para a Prova
Regra
FK fica sempre no lado N do relacionamento 1:N
Regra
Relacionamento N:M sempre gera uma tabela intermediária
Regra
WHERE filtra linhas. HAVING filtra grupos. Não confunda!
Regra
INNER JOIN só retorna linhas com correspondência. LEFT JOIN retorna todos da esquerda
Regra
COMMIT confirma. ROLLBACK desfaz. Sem COMMIT, nada é persistido
Regra
Índice acelera leitura mas custa em escrita. Crie só onde há ganho real
Regra
NoSQL = escala horizontal + esquema flexível. SQL = ACID + integridade referencial
Regra
Teorema CAP: nunca há C + A + P juntos — sempre sacrifica um