Banco de Dados

1. Introdução — o mundo moderno funciona sobre dados

Neste exato momento, enquanto você lê este material, bancos estão processando transferências PIX, hospitais estão acessando exames de pacientes, aplicativos estão calculando rotas, redes sociais estão armazenando mensagens, lojas virtuais estão registrando pedidos e escolas estão controlando frequência e notas.

Tudo isso depende de algo fundamental: informações organizadas. Hoje estamos tão acostumados com sistemas digitais que parece natural encontrar qualquer informação em segundos. Mas durante grande parte da história humana isso era extremamente difícil.

E quanto mais a sociedade crescia, mais informações eram produzidas, mais registros precisavam ser controlados e mais complexa se tornava a administração dos dados. Os bancos de dados surgiram justamente para resolver esse problema.

2. O problema da organização das informações

Imagine uma escola antes da informática. Tudo precisava ser controlado manualmente: matrículas, boletins, frequência, histórico escolar, biblioteca, pagamentos e documentos dos alunos.

As informações eram armazenadas em livros, fichários, pastas, armários e arquivos físicos. Em uma instituição com centenas, milhares ou dezenas de milhares de alunos, administrar tudo isso manualmente se tornava extremamente difícil.

Repetição de informações

O nome de um mesmo aluno precisava aparecer na matrícula, no boletim, na biblioteca, no financeiro e no histórico escolar. Isso gerava redundância, isto é, repetição desnecessária de dados. E redundância aumenta erros, inconsistências, retrabalho e dificuldade de manutenção.

Analogia importante

Imagine uma biblioteca gigantesca sem categorias, códigos, índices ou prateleiras organizadas. Mesmo existindo milhares de livros importantes, encontrar uma informação se torna extremamente difícil. Os bancos de dados nasceram exatamente para evitar esse tipo de caos informacional.

3. O crescimento da sociedade e o aumento dos dados

Durante muito tempo, a quantidade de informações produzidas era relativamente pequena. Mas isso começou a mudar com crescimento populacional, industrialização, expansão das empresas, crescimento dos governos, avanço das telecomunicações e aumento das operações bancárias.

A sociedade começou a gerar dados em escala cada vez maior. Controlar manualmente todas as movimentações bancárias de um país, todos os exames de um hospital, todas as mensagens de uma rede social ou todas as vendas de um grande e-commerce seria praticamente impossível.

4. A chegada dos computadores

Conforme as empresas e instituições cresceram, os computadores começaram a ganhar importância. A ideia parecia revolucionária: armazenar informações digitalmente. Agora os dados poderiam ocupar menos espaço físico, ser copiados, pesquisados e processados mais rapidamente.

Na época, parecia que os computadores resolveriam todos os problemas administrativos. Mas existia um ponto importante: os primeiros sistemas ainda não possuíam bancos de dados modernos.

5. Os primeiros sistemas computacionais

Nos primeiros sistemas computacionais, cada programa armazenava suas informações em arquivos próprios.

Sistema financeiro  → financeiro.dat
Sistema acadêmico   → alunos.dat
Biblioteca          → livros.dat
Recursos humanos    → funcionarios.dat

6. Sistemas baseados em arquivos

Esse modelo ficou conhecido como sistema baseado em arquivos. Nele, cada programa possuía seus próprios dados, cada sistema controlava seus próprios arquivos e não existia gerenciamento centralizado das informações.

Sistema Financeiro
        │
        └── financeiro.dat

Sistema Acadêmico
        │
        └── alunos.dat

Biblioteca
        │
        └── livros.dat

Os sistemas funcionavam praticamente isolados.

7. O grande problema dos arquivos isolados

7.1 Redundância de dados

A mesma informação precisava ser armazenada várias vezes. Se o telefone de um cliente fosse atualizado em apenas um sistema, um setor teria o telefone novo e outro ainda teria o antigo.

7.2 Inconsistência de dados

Esse é um dos problemas mais perigosos dos sistemas antigos.

Financeiro: Rua das Flores, 100
Biblioteca: Rua das Flores, 180

Agora existem dois endereços diferentes para a mesma pessoa. Qual deles é verdadeiro?

7.3 Isolamento de informações

O sistema financeiro não compartilhava informações naturalmente com biblioteca, secretaria, recursos humanos ou estoque. Gerar relatórios integrados era extremamente difícil.

“Mostrar todos os alunos inadimplentes
que ainda possuem livros emprestados.”

7.4 Dependência entre programa e arquivo

Os programas conheciam exatamente o formato dos arquivos. Se a empresa desejasse adicionar um campo como email, o formato do arquivo mudava e frequentemente o programa precisava ser alterado também.

7.5 Segurança limitada

Cada programa implementava segurança da sua própria maneira. Não existia gerenciamento centralizado, controle integrado de usuários nem política unificada de acesso.

8. A necessidade de um novo modelo

Os dados existiam, mas estavam espalhados, repetidos, inconsistentes, isolados e difíceis de integrar. A sociedade precisava de algo capaz de centralizar, organizar, relacionar e proteger informações.

9. O surgimento dos SGBDs

Esses sistemas especializados ficaram conhecidos como SGBD — Sistema Gerenciador de Banco de Dados, ou DBMS — Database Management System. O SGBD representou uma mudança gigantesca: antes cada programa controlava seus próprios arquivos; agora os dados passaram a ser administrados por um sistema especializado.

O SGBD passou a armazenar dados, organizar informações, controlar acessos, evitar inconsistências, permitir consultas, proteger integridade, gerenciar concorrência e recuperar falhas.

10. A grande revolução: o modelo relacional

Mesmo com os SGBDs, ainda existia uma pergunta importante: qual a melhor maneira de organizar os dados? Diversos modelos surgiram, como o hierárquico, em rede e relacional.

10.1 Modelo hierárquico

No modelo hierárquico, os dados eram organizados como uma árvore: um elemento pai e vários elementos filhos.

Empresa
 ├── Departamento Financeiro
 │      ├── Funcionário A
 │      └── Funcionário B
 └── Departamento TI
        └── Funcionário C

Ele funcionava bem para estruturas rígidas, mas tinha dificuldade para representar relações complexas e conexões flexíveis.

10.2 Modelo em rede

O modelo em rede permitia relações mais complexas entre registros. Trouxe mais flexibilidade, mas também aumentou a complexidade de implementação e manutenção.

10.3 Modelo relacional

Na década de 1970, Edgar Frank Codd propôs uma ideia revolucionária: organizar os dados em tabelas relacionadas. Essa proposta mudou a história da computação.

11. O poder dos relacionamentos

A verdadeira força do modelo relacional não está apenas nas tabelas. Está nos relacionamentos entre elas.

TURMAS
 id_turma (PK)
       ▲
       │
ALUNOS
 id_turma (FK)

Quando um aplicativo mostra cliente, pedido, produto e pagamento, ele está relacionando várias tabelas ao mesmo tempo.

12. O surgimento do SQL

Com o crescimento dos bancos relacionais surgiu a necessidade de uma linguagem padronizada. Essa linguagem ficou conhecida como SQL — Structured Query Language.

SELECT nome
FROM alunos
WHERE id_turma = 10;

Esse comando busca os nomes dos alunos da turma 1A. O SQL é uma linguagem declarativa: normalmente dizemos o que queremos, e o SGBD decide como executar.

13. O modelo relacional mudou o mundo

O modelo relacional trouxe simplicidade, organização, integridade, flexibilidade e padronização. Isso permitiu a criação de bancos, redes sociais, hospitais, ERPs, e-commerce, sistemas acadêmicos e aplicativos.

14. A explosão dos dados e o mundo moderno

Depois que os bancos relacionais se consolidaram, o mundo mudou novamente. A sociedade passou a produzir dados em escala gigantesca por causa de computadores pessoais, internet, smartphones, redes sociais, serviços digitais, comércio eletrônico, sensores, streaming e GPS.

15. A internet mudou as regras do jogo

Antes da internet, muitos sistemas funcionavam localmente. Mas a internet trouxe milhões de usuários simultâneos. Agora os bancos de dados precisavam responder rapidamente, funcionar 24 horas, suportar milhares de acessos, manter integridade e processar operações em tempo real.

16. O crescimento dos bancos relacionais

Os bancos relacionais continuaram evoluindo. SGBDs como Oracle, PostgreSQL, MySQL e SQL Server passaram a oferecer transações, recuperação de falhas, gerenciamento multiusuário, segurança avançada, controle de permissões e otimização de consultas.

17. Big Data — novos problemas de escala

Com internet, smartphones, sensores e serviços digitais, algumas organizações passaram a lidar com volumes, velocidades e variedades de dados muito maiores. O termo Big Data aparece nesse contexto para descrever desafios que não se resumem apenas a “ter muitos dados”.

18. NoSQL — outros modelos para outros problemas

Também surgiram bancos não relacionais, frequentemente agrupados sob o nome NoSQL — Not Only SQL. Eles não substituem automaticamente bancos relacionais: oferecem modelos diferentes para necessidades específicas.

Documento MongoDB   Chave-valor Redis   Grafos Neo4j   Colunas amplas (wide-column) Cassandra

19. Cloud Computing — bancos como serviço

A computação em nuvem também mudou a forma de operar bancos: em vez de manter toda a infraestrutura localmente, organizações podem usar serviços gerenciados, com recursos de disponibilidade, backup, monitoramento e escala fornecidos pela plataforma.

20. Dados e Inteligência Artificial

Sistemas de Inteligência Artificial também dependem de dados organizados, acessíveis e confiáveis. Isso aproxima bancos de dados de temas como análise, busca, recomendação e aplicações com IA.

21. O mundo atual funciona sobre dados

Hoje praticamente toda área depende de bancos de dados: educação, medicina, bancos, logística, indústria, agronegócio, comércio, segurança, redes sociais e aplicativos.

Sistemas manuais
        ↓
Arquivos digitais
        ↓
SGBDs
        ↓
Modelo Relacional
        ↓
SQL
        ↓
Internet
        ↓
Big Data
        ↓
NoSQL
        ↓
Cloud Computing
        ↓
Inteligência Artificial

22. Resumo inteligente do capítulo

Neste capítulo aprendemos por que os bancos de dados surgiram, os problemas dos sistemas manuais, as limitações dos sistemas baseados em arquivos, como nasceram os SGBDs, como o modelo relacional revolucionou a computação, como surgiu o SQL e como os bancos evoluíram para Big Data, NoSQL, cloud e IA.

Mais importante: aprendemos que banco de dados não é apenas tecnologia. Banco de dados é organização inteligente da informação em escala global.

23. Checagem antes de avançar

1. Qual problema central dos arquivos isolados levou à necessidade dos SGBDs?
2. O que o modelo relacional mudou na organização dos dados?
3. Qual é a diferença entre banco de dados, SGBD e SQL?
4. Por que o surgimento de novas tecnologias não tornou o modelo relacional inútil?

24. Fechamento do capítulo

Neste capítulo você não aprendeu apenas “história”. Você começou a entender por que bancos de dados existem, quais problemas eles resolvem e por que se tornaram uma das tecnologias mais importantes da computação moderna.

Agora estamos prontos para estudar tabelas, registros, colunas/atributos, valores, chaves, integridade e estrutura relacional: os fundamentos internos dos bancos de dados modernos.

BLOCO 1 — Dados e Informação

Antes de entender tabelas, comandos SQL ou sistemas gerenciadores, é preciso compreender algo mais básico: os dados.

Muitas pessoas começam Banco de Dados pensando diretamente em tabelas e comandos. Mas tudo nasce de algo mais simples: valores que precisam ser organizados para ganhar sentido.

O que é um dado?

Um dado é um valor bruto. Sozinho, normalmente possui pouco significado, porque ainda não está organizado dentro de um contexto.

João
15
Notebook
3500
2026
Aprovado

Esses valores existem, mas ainda não sabemos exatamente o que representam. O número 15 pode ser idade, quantidade, nota, código, número de parcelas ou estoque.

O que é informação?

Informação é o dado organizado com significado. Quando um dado recebe contexto, relação e finalidade, ele passa a comunicar algo útil.

O cliente João comprou um notebook por R$ 3500 em 2026.

Agora os dados possuem sentido. Existe um cliente, um produto, um valor e um período.

Analogia importante

Imagine peças soltas de um quebra-cabeça. Cada peça existe, mas sozinha não mostra a imagem completa. Quando as peças são organizadas corretamente, surge uma imagem compreensível. Com dados acontece a mesma coisa.

O problema do dado desorganizado

Ter muitos dados não significa ter informação útil. Um hospital, uma escola, uma loja ou um banco podem possuir milhares de registros e, ainda assim, não conseguir usá-los bem se estiverem desorganizados.

Dados podem existir em muitos formatos

O mundo moderno é movido por dados. Mas o valor real aparece quando esses dados são organizados, protegidos, consultados e relacionados.

BLOCO 2 — Estrutura Fundamental dos Bancos

Depois de entender dados e informação, precisamos entender como os bancos relacionais organizam essas informações.

Nos bancos relacionais, a estrutura central é a tabela.

A tabela é o coração do modelo relacional

Uma tabela é uma estrutura organizada em linhas e colunas, usada para armazenar dados de um mesmo tipo de elemento.

Essa tabela representa alunos. Cada linha representa um aluno específico. Cada coluna representa uma característica dos alunos.

Tabela, linha, coluna e valor

TABELA: alunos

┌────┬────────┬───────┐
│ id │ nome   │ turma │
├────┼────────┼───────┤
│ 1  │ João   │ 1A    │
│ 2  │ Maria  │ 1B    │
└────┴────────┴───────┘

Atributo e domínio

Em modelagem, uma coluna também pode ser chamada de atributo. O domínio define quais valores são aceitáveis para aquele atributo ou coluna.

A estrutura do banco não é apenas visual. Ela define como os dados serão armazenados, interpretados, validados e consultados.

BLOCO 3 — Chaves e Relacionamentos

Organizar dados em tabelas é essencial, mas não é suficiente. Em sistemas reais, as tabelas precisam se conectar.

É aqui que entram as chaves.

O que é uma chave?

Uma chave é um campo usado para identificação ou relacionamento. Ela ajuda o banco a localizar registros, evitar duplicidade e conectar informações.

Chave Primária

A chave primária identifica cada registro de forma única.

A coluna/atributo id_aluno identifica cada aluno individualmente. Ela não pode repetir e não deve ficar vazia.

Chave Estrangeira

A chave estrangeira cria relacionamento entre tabelas.

TURMAS
 id_turma (PK)
       ▲
       │
ALUNOS
 id_turma (FK)

A coluna/atributo id_turma aparece na tabela alunos para indicar a qual turma cada aluno pertence.

Relacionamentos representam o mundo real

O pensamento relacional muda a forma de enxergar sistemas. O aluno começa a perceber que aplicativos, sites e sistemas são formados por informações conectadas.

BLOCO 4 — Tipos de Dados

Nem todo dado é igual. Idade não é texto, data não é telefone, preço não é nome e verdadeiro/falso não é CPF.

O tipo de dado define que tipo de informação uma coluna aceita.

Texto

Usado para nomes, e-mails, cidades, endereços, descrições e telefones.

VARCHAR(100) significa texto variável de até 100 caracteres.

Números

Datas

Datas são usadas para nascimento, cadastro, pagamento, entrega, login, vencimento e histórico.

NULL

NULL não significa zero nem texto vazio. NULL significa ausência de informação.

Escolher tipos corretamente melhora validação, desempenho, armazenamento e consistência.

BLOCO 5 — Integridade dos Dados

Integridade significa manter os dados corretos, válidos, coerentes e confiáveis.

Um banco de dados profissional não deve apenas guardar dados. Ele também deve proteger os dados contra erros.

Integridade de entidade

Garante que cada registro possa ser identificado corretamente. A chave primária não deve repetir e não deve ser nula.

Integridade referencial

Garante que os relacionamentos entre tabelas sejam válidos.

Integridade de domínio

Garante que os valores aceitos façam sentido para o atributo.

Restrições comuns

BLOCO 6 — Como os Bancos Funcionam nos Sistemas Reais

O usuário enxerga telas, botões, formulários, listas e relatórios. Mas por trás dessas telas, o sistema está lendo e gravando dados em tabelas.

Usuário
   ↓
Tela
   ↓
Aplicação
   ↓
API / Servidor
   ↓
Banco de Dados
   ↓
Resposta

Exemplo: cadastro

O usuário vê um formulário com nome, e-mail e senha. A aplicação valida os dados e, antes de gravar a senha, transforma-a usando um mecanismo seguro de hash de senha.

-- Representação didática: a aplicação gera o hash antes do INSERT
INSERT INTO usuarios
(nome, email, senha_hash)
VALUES
('João', 'joao@email.com', '<hash_gerado_pela_aplicacao>');

Exemplo: login

Quando alguém faz login, a aplicação localiza o usuário e verifica a senha informada de forma segura comparando-a com o hash armazenado. Não se deve buscar uma senha em texto puro no banco.

Exemplo: loja virtual

Quando alguém compra online, o sistema precisa localizar cliente, verificar estoque, registrar pedido, registrar pagamento e atualizar produtos.

clientes
↓
pedidos
↓
itens_pedido
↓
produtos
↓
pagamentos

Os bancos também ajudam empresas a gerar relatórios, dashboards, estatísticas, análises e decisões.

BLOCO 7 — Problemas Clássicos de Iniciantes

Os maiores problemas em banco de dados geralmente não começam no SQL, mas na estrutura.

Exemplo ruim

Exemplo melhor

Banco de Dados exige pensamento estrutural. Não é apenas código. É organização lógica da informação.

BLOCO 8 — Resumo Estrutural dos Fundamentos

Banco de Dados não funciona como conceitos isolados. Tudo trabalha junto.

Dados
↓
Informação
↓
Estrutura
↓
Tabelas
↓
Colunas / atributos
↓
Tipos
↓
Chaves
↓
Relacionamentos
↓
Integridade
↓
Sistema funcionando

Os próximos capítulos dependem desses fundamentos. Modelagem, normalização, SQL, JOIN, transações e projetos só fazem sentido quando essa base está clara.

BLOCO 9 — Como Pensar um Banco de Dados

O maior erro dos iniciantes é acreditar que criar um banco começa abrindo o MySQL e digitando comandos.

Profissionais normalmente fazem o contrário: primeiro pensam a estrutura.

Banco de Dados começa antes do computador

Antes de SQL, MySQL, tabelas ou código, vem a organização mental das informações.

Exemplo: sistema escolar

Escola
↓
Alunos
Professores
Turmas
Disciplinas
Notas
Frequência

Depois pensamos nas colunas/atributos, tipos, chaves, relacionamentos e regras de integridade.

Checagem antes de avançar

1. Explique a diferença entre dado e informação.
2. Diferencie tabela, registro, coluna/atributo e valor.
3. Qual é a função de PK e FK?
4. Por que integridade e tipos de dados importam?

FECHAMENTO DO CAPÍTULO 1

A partir deste ponto, o aluno já consegue enxergar sistemas como estruturas organizadas de informação.

Agora já é possível compreender tabelas, registros, relacionamentos, tipos, integridade e o funcionamento básico dos sistemas modernos.

Mais importante: o aluno começa a desenvolver pensamento estrutural.

Os próximos capítulos aprofundarão modelagem, representação visual, organização lógica e implementação profissional em bancos reais.

BLOCO 1 — O que é Modelagem

Um dos maiores erros de quem começa Banco de Dados é acreditar que desenvolver um banco significa abrir o MySQL, criar tabelas e começar digitando SQL.

Em sistemas profissionais, normalmente acontece o contrário: antes de existir tabela, comando, banco físico ou código, existe planejamento estrutural.

Esse planejamento recebe o nome de modelagem.

Por que modelar?

Antes de criar o banco, precisamos entender quais informações existem, quais relações existem, quais regras precisam ser respeitadas e como tudo se conecta.

A modelagem serve para:

• organizar informações;
• reduzir redundância;
• evitar inconsistências;
• facilitar manutenção;
• melhorar comunicação entre equipes;
• preparar a implementação correta do banco.

Analogia importante

Ninguém constrói uma casa, um hospital ou uma ponte levantando paredes aleatoriamente. Primeiro se analisa, planeja, desenha e organiza. Banco de Dados funciona da mesma forma.

Problema real
↓
Análise
↓
Modelagem
↓
Estrutura lógica
↓
Banco físico
↓
SQL

Pensar como usuário é diferente de pensar como analista

O usuário normalmente pensa em ações: cadastrar cliente, lançar nota, consultar pedido, emitir relatório.

O analista pensa estruturalmente:

• quais entidades existirão?
• quais atributos serão necessários?
• como essas entidades se relacionam?
• quais regras precisam ser respeitadas?
• quais dados precisam ser armazenados?

Modelagem não é apenas desenhar caixas. É raciocínio estrutural.

BLOCO 2 — Entidades

Entidade é algo importante do mundo real que precisa ser representado no sistema.

Normalmente representa pessoas, objetos, eventos, processos ou elementos relevantes para o funcionamento do sistema.

Como identificar entidades?

O analista observa o problema real e procura elementos principais, normalmente substantivos importantes do processo.

Um cliente realiza pedidos em uma loja.

Possíveis entidades:

• Cliente;
• Pedido;
• Produto;
• Pagamento.

Entidade não é tabela ainda

Na modelagem conceitual, ainda não estamos criando tabelas físicas. Estamos analisando o mundo real e representando seus elementos importantes.

Mundo real
↓
Entidades
↓
Relacionamentos
↓
Modelo conceitual
↓
Modelo lógico
↓
Banco físico

Entidade associativa: quando a relação também precisa guardar dados

Alguns relacionamentos precisam ser representados por um elemento próprio. É o caso de ItemPedido, que liga Pedido e Produto e pode guardar informações da própria relação, como quantidade e preço praticado.

Esse tipo de estrutura é especialmente importante em relacionamentos N:N. Mais adiante veremos como ela se transforma em uma tabela associativa no modelo lógico.

BLOCO 3 — Atributos

As entidades sozinhas ainda não bastam. Depois de identificar uma entidade, precisamos definir quais informações ela precisa armazenar.

Essas informações são chamadas de atributos.

Exemplo: entidade Aluno

Aluno
 ├── id_aluno
 ├── nome
 ├── telefone
 ├── email
 └── data_nascimento

Exemplo: entidade Produto

Produto
 ├── id_produto
 ├── nome
 ├── preco
 ├── estoque
 └── estoque_minimo

Tipos de atributos

Exemplo ruim

Exemplo melhor

Cada atributo deve armazenar apenas um tipo de informação.

BLOCO 4 — Relacionamentos

As entidades não vivem isoladas. No mundo real, alunos pertencem a turmas, clientes fazem pedidos, produtos pertencem a categorias e médicos realizam consultas.

Relacionamento é a associação entre entidades.

Antes de desenhar: descubra a regra de negócio

Relacionamentos e cardinalidades não devem ser escolhidos por aparência. Eles nascem das regras de negócio: frases que explicam como o sistema realmente funciona.

Antes de traçar uma linha no DER, pergunte: quem se relaciona com quem, isso é obrigatório e quantas ocorrências podem participar?

Por que relacionamentos são importantes?

Sem relacionamentos, as tabelas ficam isoladas, os dados não conversam e o sistema perde sentido.

Cliente
   ↓
Pedido
   ↓
Produto
   ↓
Pagamento

Relacionamentos reduzem redundância, melhoram organização, ajudam na integridade e representam regras reais do negócio.

Relacionamento também comunica regra

A ligação entre Cliente e Pedido não é apenas visual. Ela significa que um pedido pertence a um cliente, e que o sistema deve respeitar essa relação.

BLOCO 5 — Cardinalidade

Depois de identificar o relacionamento, precisamos responder uma pergunta essencial: quantas ocorrências de uma entidade podem se relacionar com outra?

Isso é chamado de cardinalidade.

Relacionamento 1:1

Uma ocorrência se relaciona com apenas uma outra ocorrência.

FUNCIONARIO 1 ─── 1 CRACHA

Esse exemplo só será 1:1 se a regra da organização disser que cada funcionário possui no máximo um crachá ativo e cada crachá pertence a um único funcionário.

Relacionamento 1:N

É um dos relacionamentos mais comuns.

Cliente 1 ─── N Pedido

Um cliente pode fazer vários pedidos, mas cada pedido pertence a um cliente.

Relacionamento N:N

Uma ocorrência de uma entidade pode se relacionar com várias ocorrências da outra, e vice-versa.

Aluno N ─── N Disciplina

Em bancos relacionais, normalmente resolvemos N:N criando uma tabela intermediária.

Aluno
↓
Matricula
↓
Disciplina

A tabela intermediária pode ter informações próprias

Cardinalidade depende das regras do negócio. Não deve ser inventada sem entender o funcionamento real do sistema.

Cardinalidade mínima e máxima: é obrigatório ou opcional?

Além de saber se a relação é 1:1, 1:N ou N:N, precisamos descobrir se a participação é obrigatória ou opcional.

Essa leitura evita um erro comum: saber apenas “um para muitos”, mas não saber se o relacionamento é obrigatório.

BLOCO 6 — DER (Diagrama Entidade Relacionamento)

Depois de entender entidades, atributos, relacionamentos e cardinalidade, precisamos representar tudo isso visualmente.

DER significa Diagrama Entidade Relacionamento.

O que o DER mostra?

• entidades;
• atributos;
• relacionamentos;
• cardinalidades;
• organização lógica do sistema.

Exemplo simplificado

CLIENTE 1 ─── N PEDIDO
PEDIDO  1 ─── N ITEM_PEDIDO
PRODUTO 1 ─── N ITEM_PEDIDO
CATEGORIA 1 ─── N PRODUTO

O DER não é SQL, não é MySQL e ainda não é o banco físico. Ele é uma representação visual da estrutura pensada.

Problema real
↓
Modelagem
↓
DER
↓
Banco físico
↓
SQL

Por que o DER é importante?

Ele ajuda a visualizar o sistema inteiro, comunicar a estrutura para outras pessoas, encontrar erros antes da implementação e documentar o projeto.

BLOCO 6.1 — Exemplo visual de DER: Sistema Comercial

A seguir temos um exemplo visual de DER para um sistema comercial simples. O objetivo é mostrar, de forma parecida com ferramentas de modelagem, como entidades, atributos, relacionamentos, chaves primárias e cardinalidades aparecem no desenho.

BLOCO 7 — Problemas Clássicos de Modelagem

Muitos problemas em sistemas começam na modelagem: lentidão, redundância, inconsistência, dificuldade de manutenção e retrabalho.

Exemplo de estrutura problemática

Essa estrutura mistura aluno, turma, professor, disciplina e nota em uma única tabela. Isso pode gerar redundância, inconsistência e dificuldade de manutenção.

Fluxo correto

Problema real
↓
Análise
↓
Modelagem
↓
DER
↓
Banco físico
↓
SQL

Modelagem ruim custa caro, porque corrigir a estrutura do banco depois pode afetar todo o sistema.

BLOCO 8 — Pensando Como Analista

O verdadeiro trabalho do analista é transformar problemas reais em estruturas organizadas de informação.

O sistema ainda não foi programado, não possui banco e não possui interface. Mesmo assim, o analista já começa a visualizar a estrutura.

Primeiro passo: entender o problema real

Antes de pensar em SQL, tabelas ou MySQL, o analista pensa no negócio.

Exemplo: uma escola deseja cadastrar alunos, controlar notas, registrar frequência e organizar turmas.

O analista começa perguntando:

• quais informações precisam existir?
• quais entidades aparecem?
• quais atributos são necessários?
• como as entidades se relacionam?
• quais regras precisam ser respeitadas?

O analista aprende a separar responsabilidades

Em vez de criar uma “tabela geral”, o analista separa alunos, professores, disciplinas, turmas, notas e frequência.

Aluno
↓
Turma
↓
Disciplina
↓
Nota

Modelagem é pensamento, não ferramenta

A ferramenta pode ser Draw.io, brModelo, MySQL Workbench, Oracle Data Modeler ou papel e caneta. O principal é o raciocínio estrutural.

O objetivo não é decorar diagramas. O objetivo é desenvolver pensamento analítico.

Checagem antes de avançar

1. Identifique entidades, atributos e relacionamentos em um sistema simples.
2. Escreva uma regra de negócio antes de definir uma cardinalidade.
3. Diferencie 1:1, 1:N e N:N.
4. Explique o que 0..N e 1..1 acrescentam à leitura da cardinalidade.

FECHAMENTO DO CAPÍTULO 2

A partir deste ponto, o aluno já consegue transformar problemas reais em estruturas organizadas de informação.

Agora já é possível identificar entidades, definir atributos, criar relacionamentos, compreender cardinalidades, interpretar DERs, analisar problemas de modelagem e desenvolver visão estrutural de sistemas.

Mais importante: o aluno começa a desenvolver pensamento analítico profissional.

O foco deixa de ser apenas tabelas, comandos e diagramas, e passa a ser organização lógica da informação.

Os próximos capítulos aprofundarão a transformação do modelo conceitual em estruturas relacionais mais próximas da implementação, preparando o caminho para normalização, SQL e projetos completos.

BLOCO 1 — Da Modelagem Conceitual para as Tabelas

No capítulo anterior, a modelagem conceitual nos ajudou a enxergar o sistema antes da implementação. Identificamos entidades, atributos, relacionamentos, cardinalidades e representamos tudo visualmente por meio de DER.

Agora a pergunta muda. O aluno já não pergunta apenas “quais entidades existem?”. A pergunta passa a ser: como isso vira uma estrutura relacional real?

Problema real
        ↓
Modelagem Conceitual
        ↓
Modelagem Lógica
        ↓
Modelagem Física
        ↓
SQL no SGBD

A modelagem lógica é a ponte entre o desenho conceitual e o banco físico. Ela ainda não é o SQL final, mas já começa a pensar em tabelas, colunas, registros, chaves primárias, chaves estrangeiras e relações implementáveis.

O sistema comercial como referência

Para manter coerência com o DER do capítulo anterior, usaremos o mesmo sistema comercial simples:

• PRODUTO — representa os itens vendidos ou controlados em estoque;
• CATEGORIA — agrupa produtos semelhantes;
• FORNECEDOR — representa quem fornece produtos;
• PRODUTO_FORNECEDOR — será usada quando um produto puder ter vários fornecedores.

Entidade vira tabela

Na modelagem conceitual, falávamos em entidades. Na modelagem lógica, essas entidades começam a se transformar em tabelas.

Atributo vira coluna

Os atributos da entidade passam a ser colunas da tabela.

Ocorrência vira registro

Cada ocorrência de uma entidade vira um registro, ou seja, uma linha dentro da tabela.

Cada linha representa um produto real armazenado no banco.

Relacionamento vira chave estrangeira

No DER, víamos uma linha conectando CATEGORIA e PRODUTO. Na modelagem lógica, esse relacionamento precisa aparecer dentro das tabelas.

CATEGORIA 1 ─── N PRODUTO

A forma lógica de representar isso é colocar a chave da categoria dentro da tabela produto.

Agora o relacionamento deixou de ser apenas visual. Ele virou estrutura relacional.

BLOCO 2 — PK e FK na Estrutura Relacional

Agora precisamos aprofundar dois conceitos centrais da modelagem lógica: PK e FK.

PK — Chave Primária

PK significa Primary Key, ou chave primária. Sua função é identificar cada registro de forma única dentro de uma tabela.

Mesmo que dois produtos tenham descrições parecidas, seus identificadores são diferentes. Isso permite alterar, consultar, relacionar ou excluir exatamente o registro correto.

Características de uma PK

• não deve repetir;
• não deve ser nula;
• deve identificar apenas um registro;
• deve permanecer estável sempre que possível.

FK — Chave Estrangeira

FK significa Foreign Key, ou chave estrangeira. Sua função é conectar uma tabela à outra.

A coluna id_categoria em produto aponta para id_categoria em categoria.

produto.id_categoria
        ↓
categoria.id_categoria

Integridade referencial

A chave estrangeira ajuda a garantir que um produto não aponte para uma categoria inexistente.

Se a categoria 99 não existe, o relacionamento está quebrado.

PK identifica. FK relaciona.

BLOCO 3 — Relacionamento N:N e Tabela Associativa

Nem todo relacionamento é simples. No DER original, podemos simplificar dizendo que um fornecedor possui vários produtos e que um produto pertence a um fornecedor. Porém, em um sistema comercial mais realista, isso pode ser diferente.

Um produto pode ter vários fornecedores, e um fornecedor pode fornecer vários produtos.

PRODUTO N ─── N FORNECEDOR

O problema do N:N

Bancos relacionais não implementam relacionamento muitos-para-muitos diretamente dentro de uma única coluna.

Esse modelo é ruim porque guarda vários valores em uma única coluna.

A solução: tabela associativa

Criamos uma tabela intermediária para representar o relacionamento.

PRODUTO
   ↓
PRODUTO_FORNECEDOR
   ↓
FORNECEDOR

Agora o relacionamento N:N foi transformado em dois relacionamentos 1:N.

Chave composta na tabela associativa

Na tabela produto_fornecedor, a combinação id_produto + id_fornecedor pode identificar cada relação de forma única. Quando uma chave é formada por mais de uma coluna, chamamos de chave composta.

PRIMARY KEY (id_produto, id_fornecedor)

Assim, o mesmo par produto–fornecedor não pode aparecer duplicado, embora o mesmo produto possa aparecer com fornecedores diferentes.

A relação também pode ter atributos

Às vezes, a tabela associativa não serve apenas para ligar duas tabelas. Ela também pode guardar informações próprias da relação.

O preço de custo não pertence apenas ao produto. Ele depende da combinação entre produto e fornecedor.

BLOCO 4 — Redundância e o Nascimento da Normalização

Agora que já temos tabelas, PK, FK e relacionamentos, começamos a enxergar problemas estruturais com mais clareza.

O principal deles é a redundância.

O que é redundância?

Redundância é repetição desnecessária de informações.

A categoria “Periféricos” aparece repetida. Em uma tabela pequena isso parece simples, mas em um sistema real com milhares de produtos, o problema cresce.

Problemas causados pela redundância

• desperdício de armazenamento;
• risco de inconsistência;
• dificuldade de atualização;
• retrabalho;
• relatórios incorretos.

Anomalia de atualização

Se a categoria “Periféricos” mudar para “Acessórios”, todas as linhas precisam ser atualizadas. Se uma linha ficar para trás, o banco passa a ter informações inconsistentes.

Anomalia de inserção

Se categoria e produto estiverem misturados na mesma tabela, talvez não seja possível cadastrar uma categoria nova enquanto ainda não existir produto para ela.

Anomalia de exclusão

Se o último produto de uma categoria for apagado, talvez a informação da própria categoria desapareça junto.

BLOCO 5 — Primeira Forma Normal (1FN)

A Primeira Forma Normal resolve problemas de valores múltiplos e grupos repetitivos.

Valor atômico

Valor atômico é um valor indivisível no contexto da tabela. Ou seja, uma mesma célula não deve guardar listas ou vários valores misturados.

Exemplo incorreto

A coluna fornecedores possui vários valores dentro de uma única célula. Isso viola a 1FN.

Exemplo correto

Grupos repetitivos

Outro problema comum é criar colunas repetidas.

Isso limita o crescimento. E se o pedido tiver dez produtos?

Solução

Agora o crescimento acontece em linhas, não em colunas repetidas.

BLOCO 6 — Segunda Forma Normal (2FN)

Antes da 2FN, precisamos tornar explícita uma ideia que já estamos usando: dependência funcional.

Em uma tabela associativa com chave composta, precisamos perguntar se cada atributo depende da combinação inteira da chave ou somente de uma parte dela.

A Segunda Forma Normal resolve justamente problemas de dependência parcial.

A 2FN aparece principalmente em tabelas com chave composta, como tabelas associativas.

Exemplo problemático

Se a chave da tabela é formada por id_produto + id_fornecedor, a coluna nome_fornecedor não depende da combinação inteira. Ele depende apenas de id_fornecedor.

Isso é dependência parcial.

Estrutura correta

Agora nome do fornecedor fica na tabela fornecedor, e preço de custo fica na tabela que representa a relação produto-fornecedor.

BLOCO 7 — Terceira Forma Normal (3FN)

A Terceira Forma Normal resolve problemas de dependência transitiva.

Exemplo problemático

O nome da cidade e o estado não dependem diretamente do fornecedor. Eles dependem de id_cidade.

id_fornecedor
      ↓
id_cidade
      ↓
nome_cidade / estado

Isso é dependência transitiva.

Estrutura correta

Agora a cidade fica centralizada em uma tabela própria.

Outro exemplo no sistema comercial

O nome da categoria depende de id_categoria, não diretamente de id_produto. Portanto, deve ficar na tabela categoria.

BLOCO 8 — Refinamento Lógico e Visão Profissional

Depois de aplicar modelagem lógica e normalização, o sistema comercial começa a ficar realmente organizado.

CATEGORIA 1 ─── N PRODUTO
CIDADE    1 ─── N FORNECEDOR
PRODUTO   1 ─── N PRODUTO_FORNECEDOR
FORNECEDOR 1 ─ N PRODUTO_FORNECEDOR

Modelo lógico refinado

Agora cada tabela possui responsabilidade clara. Essa é uma característica importante de uma boa modelagem lógica.

Equilíbrio profissional

Normalizar não significa criar tabelas infinitas. O objetivo é equilíbrio: reduzir redundância, manter clareza e permitir manutenção futura.

Checagem antes de avançar

1. Explique como entidade, atributo e relacionamento chegam ao modelo lógico.
2. Por que um N:N costuma exigir tabela associativa?
3. Diferencie 1FN, 2FN e 3FN pelo problema que cada uma evita.
4. Explique por que dependência funcional ajuda a decidir onde um dado deve ficar.

FECHAMENTO DO CAPÍTULO 3

Ao longo deste capítulo, o aluno deixou de enxergar o banco de dados apenas como tabelas isoladas e passou a compreender a estrutura relacional de forma muito mais profissional.

Agora já é possível:

• transformar entidades em tabelas;
• compreender PK e FK;
• implementar relacionamentos;
• resolver relacionamentos N:N;
• utilizar tabelas associativas;
• identificar redundância;
• compreender 1FN, 2FN e 3FN;
• analisar dependências;
• refinar estruturalmente um banco relacional.

Mais importante: o aluno começou a desenvolver pensamento lógico relacional.

BLOCO 1 — Modelagem Física

Até aqui trabalhamos a modelagem conceitual e a modelagem lógica. Agora entramos na modelagem física, que é a implementação concreta do banco dentro de um SGBD real.

Modelagem Conceitual
↓
Modelagem Lógica e Normalização
↓
Modelagem Física
↓
SQL no MySQL

Na modelagem física, decisões como tipos reais, chaves, restrições e estrutura das tabelas deixam de ser apenas ideia e passam a existir dentro do MySQL.

BLOCO 2 — O que é SQL?

SQL significa Structured Query Language, ou Linguagem de Consulta Estruturada. SQL não é o banco; SQL é a linguagem usada para conversar com o banco.

Usaremos SQL sempre conectado ao sistema comercial já modelado: categoria, cidade, fornecedor, produto e produto_fornecedor. O objetivo é implementar o mesmo modelo refinado no capítulo anterior, sem voltar para uma estrutura simplificada.

BLOCO 3 — O que é MySQL e o que é SGBD?

SGBD significa Sistema Gerenciador de Banco de Dados. O MySQL é um SGBD relacional. Ele executa comandos SQL, armazena dados, controla permissões, protege integridade e gerencia as tabelas fisicamente.

Aluno escreve SQL
↓
MySQL interpreta
↓
MySQL executa
↓
Banco físico é alterado

Neste tutorial, os exemplos principais serão pensados para o CLI do MySQL, aquela tela preta de terminal, para que o aluno aprenda SQL de forma direta.

BLOCO 4 — Preparando o Ambiente MySQL

Para executar os comandos deste capítulo, o computador precisa ter o MySQL Server instalado e configurado. No Windows, a instalação oficial atual pode ser feita pelo pacote MSI e pelo MySQL Configurator.

1. Instale o MySQL Server.
2. Durante a configuração, defina e guarde a senha administrativa solicitada.
3. Confirme que o serviço do MySQL está iniciado.
4. Abra o Prompt de Comando ou o terminal do MySQL.

mysql -u root -p

Depois de informar a senha, o aluno estará dentro do ambiente interativo do MySQL.

A administração completa de instalação, usuários, permissões, backup e restauração será aprofundada no Capítulo 6. Aqui fazemos apenas o necessário para conseguir praticar SQL desde já.

BLOCO 5 — CREATE DATABASE e USE

O primeiro passo físico é criar o banco de dados do sistema comercial.

CREATE DATABASE comercio;
SHOW DATABASES;
USE comercio;

CREATE DATABASE cria o banco. SHOW DATABASES lista os bancos existentes. USE seleciona o banco ativo.

Query OK, 1 row affected
Database changed

BLOCO 6 — CREATE TABLE: criando as tabelas do sistema comercial

Agora criaremos as cinco tabelas do modelo lógico refinado. A ordem importa: primeiro as tabelas que não dependem de outras; depois as que possuem chaves estrangeiras; por último, a tabela associativa.

CATEGORIA    CIDADE
    ↓          ↓
 PRODUTO   FORNECEDOR
      ↘    ↙
 PRODUTO_FORNECEDOR

CREATE TABLE categoria (
    id_categoria INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(50) NOT NULL UNIQUE
);

CREATE TABLE cidade (
    id_cidade INT PRIMARY KEY AUTO_INCREMENT,
    nome_cidade VARCHAR(80) NOT NULL,
    estado CHAR(2) NOT NULL,
    UNIQUE (nome_cidade, estado)
);

CREATE TABLE fornecedor (
    id_fornecedor INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(80) NOT NULL,
    telefone VARCHAR(20),
    id_cidade INT,

    FOREIGN KEY (id_cidade)
        REFERENCES cidade(id_cidade)
);

CREATE TABLE produto (
    id_produto INT PRIMARY KEY AUTO_INCREMENT,
    descricao VARCHAR(100) NOT NULL,
    preco DECIMAL(10,2) NOT NULL,
    qtde INT NOT NULL DEFAULT 0,
    id_categoria INT NOT NULL,
    estoque_minimo INT NOT NULL DEFAULT 0,

    CONSTRAINT chk_produto_preco CHECK (preco >= 0),
    CONSTRAINT chk_produto_qtde CHECK (qtde >= 0),
    CONSTRAINT chk_produto_estoque_minimo CHECK (estoque_minimo >= 0),

    FOREIGN KEY (id_categoria)
        REFERENCES categoria(id_categoria)
);

CREATE TABLE produto_fornecedor (
    id_produto INT NOT NULL,
    id_fornecedor INT NOT NULL,
    preco_custo DECIMAL(10,2),
    prazo_entrega INT,

    PRIMARY KEY (id_produto, id_fornecedor),

    FOREIGN KEY (id_produto)
        REFERENCES produto(id_produto),

    FOREIGN KEY (id_fornecedor)
        REFERENCES fornecedor(id_fornecedor),

    CONSTRAINT chk_preco_custo CHECK (preco_custo >= 0),
    CONSTRAINT chk_prazo_entrega CHECK (prazo_entrega >= 0)
);

Agora o SQL respeita exatamente o raciocínio do capítulo anterior: produto não possui id_fornecedor. A relação N:N fica em produto_fornecedor.

SHOW TABLES;
DESCRIBE categoria;
DESCRIBE cidade;
DESCRIBE fornecedor;
DESCRIBE produto;
DESCRIBE produto_fornecedor;

BLOCO 6.1 — ALTER TABLE: quando a estrutura precisa evoluir

CREATE TABLE cria a estrutura inicial. Mas sistemas evoluem. ALTER TABLE modifica a estrutura de uma tabela que já existe.

Para aprender sem alterar o modelo comercial, use uma tabela de laboratório:

CREATE TABLE estrutura_lab (
    id INT PRIMARY KEY
);

ALTER TABLE estrutura_lab
ADD COLUMN observacao VARCHAR(100);

DESCRIBE estrutura_lab;

ALTER TABLE estrutura_lab
DROP COLUMN observacao;

DROP TABLE estrutura_lab;

BLOCO 7 — INSERT INTO: inserindo os dados da base

Agora o banco deixa de ser apenas estrutura e começa a receber dados. Vamos preservar os dados existentes de categoria, fornecedor e produto e transformar a antiga ligação produto–fornecedor em registros da tabela associativa.

Inserindo categorias

INSERT INTO categoria (id_categoria, nome)
VALUES
(1, 'DOCE'),
(2, 'SALGADO'),
(3, 'BEBIDA'),
(4, 'LIMPEZA'),
(5, 'PERFUMARIA'),
(6, 'UTENSILIO'),
(7, 'FRUTAS'),
(8, 'VERDURA'),
(9, 'CARNE'),
(10, 'FRIOS'),
(11, 'PADARIA'),
(12, 'HIGIENE'),
(13, 'CONGELADOS'),
(14, 'MATINAIS'),
(15, 'LATICINIOS'),
(16, 'ENLATADOS'),
(17, 'TEMPEROS'),
(18, 'MASSAS'),
(19, 'BISCOITOS'),
(20, 'DOCES E SOBREMESAS'),
(21, 'PET SHOP'),
(22, 'UTILIDADES DOMESTICAS'),
(23, 'PAPELARIA'),
(24, 'DESCARTAVEIS'),
(25, 'HORTIFRUTI'),
(26, 'MERCEARIA');

Cidades

A tabela cidade já existe, mas a base atual não informa a cidade verdadeira dos fornecedores. Portanto, ela ficará vazia por enquanto. Quando houver esses dados, eles deverão ser cadastrados antes de associá-los aos fornecedores.

Inserindo fornecedores

INSERT INTO fornecedor (id_fornecedor, nome, telefone)
VALUES
(3, 'ARMAZEM DO COMERCIO', '(19) 9999-1001'),
(4, 'COCA-COLA FEMSA', '(19) 9999-1002'),
(5, 'NESTLE BRASIL', '(19) 9999-1003'),
(6, 'AMBEV DISTRIBUIDORA', '(19) 9999-1004'),
(7, 'SADIA ALIMENTOS', '(19) 9999-1005'),
(8, 'PERDIGAO DISTRIBUICAO', '(19) 9999-1006'),
(9, 'YPE PRODUTOS', '(19) 9999-1007'),
(10, 'UNILEVER BRASIL', '(19) 9999-1008'),
(11, 'PEPSICO', '(19) 9999-1009'),
(12, 'BAUDUCCO', '(19) 9999-1010'),
(13, 'CASA DO MERCADO', '(19) 9999-1011'),
(18, 'DISTRIBUIDORA CENTRAL', '(19) 9999-1012'),
(19, 'MAX ALIMENTOS', '(19) 9999-1013'),
(20, 'BOM PRECO ATACADO', '(19) 9999-1014'),
(21, 'NOVA ERA COMERCIAL', '(19) 9999-1015'),
(22, 'SUPERMIX DISTRIBUIDORA', '(19) 9999-1016'),
(23, 'REAL COMERCIO', '(19) 9999-1017'),
(24, 'ALFA DISTRIBUICAO', '(19) 9999-1018'),
(25, 'COMERCIAL BRASIL', '(19) 9999-1019'),
(26, 'ESTRELA DO LAR', '(19) 9999-1020'),
(27, 'TOP BEBIDAS', '(19) 9999-1021'),
(28, 'VALE ALIMENTOS', '(19) 9999-1022'),
(29, 'PRIME DISTRIBUIDORA', '(19) 9999-1023'),
(30, 'IDEAL COMERCIO', '(19) 9999-1024'),
(31, 'TOTAL LIMPEZA', '(19) 9999-1025');

Inserindo produtos

A tabela produto deve ser inserida depois de categoria, porque possui uma FK apontando para ela. O fornecedor não fica mais dentro de produto.

INSERT INTO produto (id_produto, descricao, preco, qtde, id_categoria, estoque_minimo)
VALUES
(12, 'BALA 7 BELO', 0, 12, 1, 5),
(13, 'PIRULITO', 1, 25, 1, 5),
(14, 'CHICLETE', 0, 8, 1, 10),
(15, 'PACOCA', 1, 6, 1, 10),
(16, 'BOMBOM', 2, 15, 1, 10),
(17, 'COXINHA', 8, 20, 2, 5),
(18, 'QUIBE', 10, 18, 2, 5),
(19, 'MISTAO', 15, 2, 2, 3),
(20, 'PASTEL', 9, 4, 2, 5),
(21, 'ENROLADINHO', 6, 7, 2, 5),
(22, 'COCA COLA LATA', 5, 120, 3, 20),
(23, 'GUARANA LATA', 4, 15, 3, 20),
(24, 'SUCO DE LARANJA', 6, 9, 3, 10),
(25, 'AGUA MINERAL', 2, 18, 3, 30),
(26, 'ENERGETICO', 9, 3, 3, 5),
(27, 'DETERGENTE', 3, 25, 4, 10),
(28, 'SABAO EM PO', 18, 5, 4, 8),
(29, 'AGUA SANITARIA', 5, 6, 4, 8),
(30, 'DESINFETANTE', 7, 4, 4, 8),
(31, 'ESPONJA', 2, 30, 4, 15),
(32, 'SHAMPOO', 15, 12, 5, 5),
(33, 'CONDICIONADOR', 17, 9, 5, 5),
(34, 'SABONETE', 3, 40, 5, 10),
(35, 'CREME DENTAL', 6, 8, 12, 10),
(36, 'DESODORANTE', 12, 2, 5, 5),
(37, 'PRATO DESCARTAVEL', 8, 35, 24, 10),
(38, 'COPO DESCARTAVEL', 6, 10, 24, 15),
(39, 'GUARDANAPO', 4, 12, 24, 20),
(40, 'PAPEL ALUMINIO', 9, 4, 22, 5),
(41, 'FILME PVC', 7, 3, 22, 5),
(42, 'MACA', 8, 20, 7, 10),
(43, 'BANANA', 6, 18, 7, 10),
(44, 'LARANJA', 5, 22, 7, 10),
(45, 'MAMAO', 9, 4, 7, 5),
(46, 'UVA', 14, 2, 7, 5),
(47, 'ALFACE', 3, 15, 8, 8),
(48, 'TOMATE', 7, 7, 8, 10),
(49, 'BATATA', 5, 9, 8, 12),
(50, 'CEBOLA', 6, 6, 8, 10),
(51, 'CENOURA', 4, 5, 8, 8),
(52, 'PICANHA', 65, 1, 9, 2),
(53, 'FRANGO', 18, 8, 9, 5),
(54, 'LINGUICA', 22, 4, 9, 5),
(55, 'CARNE MOIDA', 35, 3, 9, 5),
(56, 'BISTECA', 28, 2, 9, 3),
(57, 'PRESUNTO', 32, 6, 10, 5),
(58, 'MUSSARELA', 45, 4, 10, 5),
(59, 'MORTADELA', 16, 12, 10, 5),
(60, 'IOGURTE', 7, 5, 15, 8),
(61, 'REQUEIJAO', 12, 2, 15, 5),
(62, 'PAO FRANCES', 1, 130, 11, 20),
(63, 'SONHO', 6, 4, 11, 5),
(64, 'BOLO DE CHOCOLATE', 25, 1, 11, 2),
(65, 'ROSCA DOCE', 12, 2, 11, 2),
(66, 'PAO DE FORMA', 9, 6, 11, 5),
(67, 'PAPEL HIGIENICO', 18, 8, 12, 10),
(68, 'ABSORVENTE', 9, 3, 12, 5),
(69, 'ALGODAO', 5, 2, 12, 5),
(70, 'COTONETE', 4, 2, 12, 5),
(71, 'ESCOVA DENTAL', 7, 4, 12, 5);

Inserindo as relações produto–fornecedor

No arquivo antigo, cada produto carregava um id_fornecedor. Agora preservamos essa informação no lugar correto: a tabela produto_fornecedor.

INSERT INTO produto_fornecedor (id_produto, id_fornecedor)
VALUES
(12, 5),
(13, 5),
(14, 5),
(15, 5),
(16, 5),
(17, 13),
(18, 13),
(19, 13),
(20, 13),
(21, 13),
(22, 4),
(23, 6),
(24, 11),
(25, 27),
(26, 6),
(27, 9),
(28, 9),
(29, 9),
(30, 10),
(31, 31),
(32, 10),
(33, 10),
(34, 10),
(35, 10),
(36, 10),
(37, 25),
(38, 25),
(39, 25),
(40, 25),
(41, 25),
(42, 28),
(43, 28),
(44, 28),
(45, 28),
(46, 28),
(47, 28),
(48, 28),
(49, 28),
(50, 28),
(51, 28),
(52, 19),
(53, 7),
(54, 8),
(55, 19),
(56, 7),
(57, 7),
(58, 7),
(59, 7),
(60, 5),
(61, 5),
(62, 12),
(63, 12),
(64, 12),
(65, 12),
(66, 12),
(67, 10),
(68, 10),
(69, 10),
(70, 10),
(71, 10);

Hoje cada produto da base possui uma associação conhecida. A estrutura, porém, já aceita que no futuro o mesmo produto tenha outros fornecedores, sem alterar a tabela produto.

Os IDs começam em valores já existentes porque o banco veio de uma base usada em Access. Isso não é problema: chaves primárias não precisam ser sequenciais perfeitas; precisam ser únicas. Como usamos AUTO_INCREMENT, novos cadastros sem ID explícito poderão continuar a sequência automaticamente.

BLOCO 8 — SELECT: consultando dados

SELECT consulta dados no banco. Ele não altera, não apaga e não insere registros.

SELECT * FROM categoria;
SELECT * FROM cidade;
SELECT * FROM fornecedor;
SELECT * FROM produto;
SELECT * FROM produto_fornecedor;

Também podemos consultar apenas algumas colunas:

SELECT descricao, preco, qtde
FROM produto;

DISTINCT e LIMIT

DISTINCT elimina repetições no resultado e LIMIT restringe quantas linhas serão exibidas.

SELECT DISTINCT id_categoria
FROM produto;

SELECT descricao, preco
FROM produto
ORDER BY id_produto
LIMIT 10;

BLOCO 9 — WHERE: filtrando dados

WHERE aplica condições. Ele permite buscar apenas os registros que interessam.

SELECT *
FROM produto
WHERE id_categoria = 3;

SELECT *
FROM produto
WHERE qtde <= estoque_minimo;

SELECT descricao, preco
FROM produto
WHERE preco > 20;

Com esses dados, já é possível identificar bebidas, produtos caros e itens com estoque baixo.

Combinando condições

SELECT *
FROM produto
WHERE preco >= 5 AND preco <= 20;

SELECT *
FROM produto
WHERE id_categoria IN (3, 7, 8);

SELECT *
FROM produto
WHERE preco BETWEEN 10 AND 30;

SELECT *
FROM fornecedor
WHERE id_cidade IS NULL;

SELECT *
FROM produto
WHERE NOT id_categoria = 3;

SELECT *
FROM produto
WHERE id_categoria = 3 OR id_categoria = 15;

AND exige as duas condições; OR aceita uma ou outra; NOT nega uma condição; IN testa uma lista; BETWEEN testa um intervalo; e valores nulos são verificados com IS NULL ou IS NOT NULL, nunca com = NULL.

BLOCO 10 — ORDER BY: ordenando resultados

ORDER BY organiza o resultado da consulta.

SELECT descricao, preco
FROM produto
ORDER BY descricao;

SELECT descricao, preco
FROM produto
ORDER BY preco DESC;

SELECT descricao, qtde
FROM produto
ORDER BY qtde;

ASC é crescente. DESC é decrescente. Quando omitimos, o MySQL usa ordem crescente por padrão.

BLOCO 11 — LIKE: pesquisas textuais

LIKE permite procurar padrões em campos de texto. O símbolo % funciona como coringa.

SELECT descricao
FROM produto
WHERE descricao LIKE 'P%';

SELECT descricao
FROM produto
WHERE descricao LIKE '%COLA%';

SELECT nome
FROM fornecedor
WHERE nome LIKE '%BRASIL%';

SELECT nome
FROM categoria
WHERE nome LIKE '%DOCE%';

Esse tipo de busca aparece em sistemas reais quando o usuário digita parte do nome de um produto, fornecedor ou categoria.

BLOCO 12 — UPDATE: alterando registros

UPDATE modifica dados existentes. O uso do WHERE é essencial. Para praticar sem alterar um produto real da base, criaremos um registro temporário apenas para este teste.

INSERT INTO produto
(id_produto, descricao, preco, qtde, id_categoria, estoque_minimo)
VALUES
(1001, 'PRODUTO TEMPORARIO UPDATE', 5, 1, 3, 0);

SELECT *
FROM produto
WHERE id_produto = 1001;

UPDATE produto
SET preco = 6
WHERE id_produto = 1001;

SELECT *
FROM produto
WHERE id_produto = 1001;

-- limpeza do laboratório
DELETE FROM produto
WHERE id_produto = 1001;

BLOCO 13 — DELETE: removendo registros

DELETE remove registros. Assim como UPDATE, precisa de muito cuidado com WHERE.

Para praticar sem destruir um produto real da base, crie primeiro um registro temporário sem fornecedor associado.

INSERT INTO produto
(id_produto, descricao, preco, qtde, id_categoria, estoque_minimo)
VALUES
(1000, 'PRODUTO TEMPORARIO', 5, 1, 3, 0);

SELECT *
FROM produto
WHERE id_produto = 1000;

DELETE FROM produto
WHERE id_produto = 1000;

SELECT *
FROM produto
WHERE id_produto = 1000;

Se tentarmos apagar um produto que ainda aparece em produto_fornecedor, ou uma categoria que possui produtos vinculados, a FK pode impedir a exclusão. Isso não é erro do banco: é proteção da integridade referencial.

BLOCO 14 — FOREIGN KEY: integridade referencial real

A FOREIGN KEY é a implementação física do relacionamento entre tabelas. Ela impede referências para registros que não existem. Usaremos um produto temporário e o removeremos ao final.

-- deve funcionar: categoria 3 existe
INSERT INTO produto
(id_produto, descricao, preco, qtde, id_categoria, estoque_minimo)
VALUES
(900001, 'PRODUTO TESTE', 5, 10, 3, 5);

-- deve falhar: categoria 999 não existe
INSERT INTO produto
(id_produto, descricao, preco, qtde, id_categoria, estoque_minimo)
VALUES
(900002, 'PRODUTO INVALIDO', 5, 10, 999, 5);

-- deve funcionar: produto e fornecedor existem
INSERT INTO produto_fornecedor (id_produto, id_fornecedor)
VALUES (900001, 4);

-- deve falhar: fornecedor 999 não existe
INSERT INTO produto_fornecedor (id_produto, id_fornecedor)
VALUES (900001, 999);

-- limpeza dos testes válidos
DELETE FROM produto_fornecedor
WHERE id_produto = 900001;

DELETE FROM produto
WHERE id_produto = 900001;

Os comandos inválidos são rejeitados pelas restrições. Os dois DELETEs finais removem somente os registros de laboratório que foram aceitos, preservando a base comercio.

BLOCO 15 — JOIN: unindo tabelas relacionadas

JOIN é usado para unir dados de tabelas relacionadas. Aqui o banco relacional mostra seu verdadeiro valor.

SELECT
    produto.descricao,
    categoria.nome AS categoria
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria;

Agora o aluno não vê apenas o número da categoria; vê o nome real da categoria.

SELECT
    produto.descricao,
    categoria.nome AS categoria,
    fornecedor.nome AS fornecedor
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria
INNER JOIN produto_fornecedor
    ON produto.id_produto = produto_fornecedor.id_produto
INNER JOIN fornecedor
    ON produto_fornecedor.id_fornecedor = fornecedor.id_fornecedor
ORDER BY produto.descricao;

Perceba o caminho: produto chega ao fornecedor por meio de produto_fornecedor. Essa consulta comprova que a implementação física respeita o N:N modelado anteriormente.

BLOCO 16 — Funções de agregação

Funções de agregação resumem dados. As principais são COUNT, SUM, AVG, MIN e MAX.

SELECT COUNT(*) FROM produto;

SELECT SUM(qtde) FROM produto;

SELECT AVG(preco) FROM produto;

SELECT MIN(preco) FROM produto;

SELECT MAX(preco) FROM produto;

Com essas consultas, o banco começa a produzir indicadores: quantidade de produtos, estoque total, média de preço e maior ou menor valor.

BLOCO 17 — GROUP BY: agrupando dados

GROUP BY agrupa registros para produzir relatórios por categoria, fornecedor ou outro campo.

SELECT
    categoria.nome AS categoria,
    COUNT(*) AS total_produtos
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria
GROUP BY categoria.nome
ORDER BY total_produtos DESC;

SELECT
    categoria.nome AS categoria,
    SUM(produto.qtde) AS total_estoque,
    AVG(produto.preco) AS preco_medio
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria
GROUP BY categoria.nome
ORDER BY total_estoque DESC;

SELECT
    fornecedor.nome AS fornecedor,
    COUNT(*) AS total_produtos
FROM produto_fornecedor
INNER JOIN fornecedor
    ON produto_fornecedor.id_fornecedor = fornecedor.id_fornecedor
GROUP BY fornecedor.id_fornecedor, fornecedor.nome
ORDER BY total_produtos DESC;

HAVING: filtrando grupos

WHERE filtra linhas antes do agrupamento. HAVING filtra o resultado dos grupos depois do GROUP BY.

SELECT
    categoria.nome AS categoria,
    COUNT(*) AS total_produtos
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria
GROUP BY categoria.id_categoria, categoria.nome
HAVING COUNT(*) >= 3
ORDER BY total_produtos DESC;

BLOCO 18 — Boas Práticas e Visão Profissional

SQL profissional não é apenas escrever comandos que funcionam. É escrever comandos organizados, seguros e coerentes com a modelagem.

• use nomes claros;
• organize consultas longas em várias linhas;
• teste SELECT antes de UPDATE ou DELETE;
• use PK, FK e demais restrições para proteger integridade;
• prefira listar explicitamente as colunas em INSERTs importantes;
• mantenha coerência entre modelagem, tabelas e comandos;
• não decore SQL sem entender a estrutura.

BLOCO 19 — Fechamento do Capítulo SQL com MySQL

Neste capítulo, o banco deixou de ser apenas desenho e estrutura lógica. Ele virou implementação física real no MySQL.

Aprendemos modelagem física, SQL, MySQL, SGBD, CREATE DATABASE, CREATE TABLE, ALTER TABLE, AUTO_INCREMENT, restrições, INSERT, SELECT, DISTINCT, LIMIT, WHERE, AND, OR, NOT, IN, BETWEEN, IS NULL, ORDER BY, LIKE, UPDATE, DELETE, FOREIGN KEY, JOIN, funções de agregação, GROUP BY, HAVING e boas práticas.

Mais importante: entendemos como transformar uma modelagem relacional completa em um banco físico real utilizando SQL no MySQL.

BLOCO 1 — Por que JOIN existe?

Nos capítulos anteriores, aprendemos que um banco relacional não deve guardar tudo em uma única tabela. Categorias ficam em categoria, fornecedores em fornecedor, produtos em produto e a relação N:N entre produto e fornecedor fica em produto_fornecedor.

Essa separação reduz redundância e melhora a integridade. Mas cria uma nova necessidade: quando queremos enxergar uma informação completa, precisamos consultar várias tabelas relacionadas ao mesmo tempo.

Guardar corretamente
↓
separar os dados em tabelas relacionadas
↓
consultar quando necessário
↓
JOIN reúne as informações no resultado

BLOCO 2 — Relacionamento e JOIN não são a mesma coisa

Um relacionamento pertence à estrutura do banco. Ele nasce das regras de negócio e normalmente é representado por PKs e FKs. Um JOIN pertence à consulta: usamos SQL para percorrer esse relacionamento e mostrar informações que estão separadas.

No nosso banco comercial, o caminho principal é:

CATEGORIA 1 ─── N PRODUTO
                    ↓
                    N
           PRODUTO_FORNECEDOR
                    N
                    ↓
               FORNECEDOR
                    ↓
              CIDADE (opcional)

Antes de escrever qualquer JOIN, pergunte: qual informação eu quero e por quais relacionamentos preciso passar para chegar até ela?

BLOCO 3 — Anatomia de um JOIN

Vamos começar sem abreviações. Queremos mostrar o produto e o nome de sua categoria.

SELECT produto.descricao, categoria.nome
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria;

BLOCO 4 — INNER JOIN: somente quem possui correspondência

O INNER JOIN retorna apenas as linhas que encontram correspondência dos dois lados da junção.

PRODUTO           CATEGORIA
   22  ───────────  3 BEBIDA     ✓ aparece
   27  ───────────  4 LIMPEZA    ✓ aparece
   ?   ── sem correspondência    ✗ não aparece

SELECT
    produto.id_produto,
    produto.descricao,
    categoria.nome AS categoria
FROM produto
INNER JOIN categoria
    ON produto.id_categoria = categoria.id_categoria
ORDER BY produto.descricao;

Como id_categoria em produto é obrigatório e protegido por FOREIGN KEY, todos os produtos válidos devem encontrar uma categoria. Isso mostra como integridade e JOIN trabalham juntos.

BLOCO 5 — INNER JOIN em um relacionamento N:N

Produto e fornecedor possuem relacionamento N:N. Por isso, não existe uma FK de fornecedor dentro de produto. Para chegar de produto até fornecedor precisamos atravessar a tabela associativa.

PRODUTO
   ↓ id_produto
PRODUTO_FORNECEDOR
   ↓ id_fornecedor
FORNECEDOR

SELECT
    produto.descricao AS produto,
    fornecedor.nome AS fornecedor
FROM produto
INNER JOIN produto_fornecedor
    ON produto.id_produto = produto_fornecedor.id_produto
INNER JOIN fornecedor
    ON produto_fornecedor.id_fornecedor = fornecedor.id_fornecedor
ORDER BY produto.descricao;

BLOCO 6 — Aliases: abreviando sem perder o sentido

Depois que o caminho ficou claro, podemos usar aliases para reduzir a repetição dos nomes das tabelas. Alias é apenas um apelido válido durante aquela consulta.

SELECT
    p.descricao AS produto,
    f.nome AS fornecedor
FROM produto AS p
INNER JOIN produto_fornecedor AS pf
    ON p.id_produto = pf.id_produto
INNER JOIN fornecedor AS f
    ON pf.id_fornecedor = f.id_fornecedor
ORDER BY p.descricao;

BLOCO 7 — LEFT JOIN: preserve tudo que está à esquerda

O LEFT JOIN preserva todas as linhas da tabela que está à esquerda da junção, mesmo quando não existe correspondência do lado direito.

Na base atual existem fornecedores cadastrados que ainda não possuem produto associado. Isso nos permite observar o comportamento do LEFT JOIN sem inventar registros.

SELECT
    f.id_fornecedor,
    f.nome AS fornecedor,
    pf.id_produto
FROM fornecedor AS f
LEFT JOIN produto_fornecedor AS pf
    ON f.id_fornecedor = pf.id_fornecedor
ORDER BY f.nome;

Quando um fornecedor não possui produto relacionado, ele continua aparecendo. As colunas vindas de produto_fornecedor aparecem como NULL.

FORNECEDOR                    PRODUTO_FORNECEDOR
COCA-COLA FEMSA      ──────── produto 22
AMBEV DISTRIBUIDORA  ──────── produto 23
ARMAZEM DO COMERCIO  ──────── NULL   ← continua aparecendo

BLOCO 8 — Encontrando quem NÃO possui correspondência

LEFT JOIN fica especialmente útil quando queremos descobrir registros sem relação correspondente.

SELECT
    f.id_fornecedor,
    f.nome AS fornecedor
FROM fornecedor AS f
LEFT JOIN produto_fornecedor AS pf
    ON f.id_fornecedor = pf.id_fornecedor
WHERE pf.id_produto IS NULL
ORDER BY f.nome;

A lógica é:

preserve todos os fornecedores
↓
tente encontrar produto_fornecedor
↓
onde não encontrou, pf.id_produto ficou NULL
↓
WHERE ... IS NULL mostra somente esses casos

BLOCO 9 — RIGHT JOIN: preserve tudo que está à direita

O RIGHT JOIN faz a ideia inversa: preserva todas as linhas da tabela que aparece à direita da junção.

SELECT
    f.id_fornecedor,
    f.nome AS fornecedor,
    pf.id_produto
FROM produto_fornecedor AS pf
RIGHT JOIN fornecedor AS f
    ON pf.id_fornecedor = f.id_fornecedor
ORDER BY f.nome;

Essa consulta preserva todos os fornecedores e, portanto, produz a mesma ideia da consulta anterior escrita com LEFT JOIN e as tabelas em ordem invertida.

BLOCO 10 — ON e WHERE têm papéis diferentes

Uma regra prática ajuda muito:

• ON explica como as tabelas se relacionam;
• WHERE filtra quais linhas do resultado queremos manter.

SELECT
    p.descricao,
    c.nome AS categoria,
    p.preco
FROM produto AS p
INNER JOIN categoria AS c
    ON p.id_categoria = c.id_categoria
WHERE p.preco >= 20
ORDER BY p.preco DESC;

BLOCO 11 — Múltiplas junções: percorrendo o banco inteiro

Uma consulta pode atravessar vários relacionamentos. Vamos mostrar produto, categoria, fornecedor e, quando existir, a cidade do fornecedor.

SELECT
    p.id_produto,
    p.descricao AS produto,
    c.nome AS categoria,
    f.nome AS fornecedor,
    ci.nome_cidade,
    ci.estado
FROM produto AS p
INNER JOIN categoria AS c
    ON p.id_categoria = c.id_categoria
INNER JOIN produto_fornecedor AS pf
    ON p.id_produto = pf.id_produto
INNER JOIN fornecedor AS f
    ON pf.id_fornecedor = f.id_fornecedor
LEFT JOIN cidade AS ci
    ON f.id_cidade = ci.id_cidade
ORDER BY p.descricao, f.nome;

Observe que usamos INNER JOIN enquanto a correspondência é necessária para montar o caminho produto → categoria → fornecedor. Para cidade usamos LEFT JOIN porque id_cidade é opcional no modelo.

BLOCO 12 — JOIN com GROUP BY: incluindo também quem tem zero

Já aprendemos funções de agregação e GROUP BY. Agora podemos combiná-las com LEFT JOIN para criar relatórios mais completos.

SELECT
    f.id_fornecedor,
    f.nome AS fornecedor,
    COUNT(pf.id_produto) AS total_produtos
FROM fornecedor AS f
LEFT JOIN produto_fornecedor AS pf
    ON f.id_fornecedor = pf.id_fornecedor
GROUP BY f.id_fornecedor, f.nome
ORDER BY total_produtos DESC, f.nome;

Usamos COUNT(pf.id_produto), e não COUNT(*), porque queremos contar somente produtos realmente encontrados. Quando não existe correspondência, pf.id_produto é NULL e não entra nessa contagem.

SELECT
    f.id_fornecedor,
    f.nome AS fornecedor,
    COUNT(pf.id_produto) AS total_produtos
FROM fornecedor AS f
LEFT JOIN produto_fornecedor AS pf
    ON f.id_fornecedor = pf.id_fornecedor
GROUP BY f.id_fornecedor, f.nome
HAVING COUNT(pf.id_produto) = 0
ORDER BY f.nome;

BLOCO 13 — Erros comuns em JOIN

BLOCO 14 — Como escolher o JOIN?

1. O que eu quero descobrir?
2. Qual tabela contém o ponto de partida?
3. Qual relacionamento leva ao próximo dado?
4. Preciso somente de correspondências ou preservar ausentes?
5. Escrevo o JOIN.
6. Confiro se o resultado faz sentido.

BLOCO 15 — Laboratório final: relatório comercial completo

Agora reunimos o que aprendemos em uma consulta que percorre o modelo relacional completo.

SELECT
    p.id_produto,
    p.descricao AS produto,
    p.preco,
    p.qtde,
    c.nome AS categoria,
    f.nome AS fornecedor,
    pf.preco_custo,
    pf.prazo_entrega,
    ci.nome_cidade,
    ci.estado
FROM produto AS p
INNER JOIN categoria AS c
    ON p.id_categoria = c.id_categoria
INNER JOIN produto_fornecedor AS pf
    ON p.id_produto = pf.id_produto
INNER JOIN fornecedor AS f
    ON pf.id_fornecedor = f.id_fornecedor
LEFT JOIN cidade AS ci
    ON f.id_cidade = ci.id_cidade
ORDER BY c.nome, p.descricao, f.nome;

Leia essa consulta de cima para baixo e tente responder:

1. Qual é a tabela de partida?
2. Por que categoria usa INNER JOIN?
3. Por que precisamos passar por produto_fornecedor?
4. Por que cidade usa LEFT JOIN?
5. Se um produto passasse a ter dois fornecedores, quantas linhas ele poderia gerar nesse relatório?

BLOCO 16 — Fechamento do Capítulo

Neste capítulo, relacionamentos deixaram de ser apenas linhas de um DER e passaram a orientar consultas reais.

Aprendemos a diferença entre relacionamento e JOIN, a condição ON, INNER JOIN, LEFT JOIN, RIGHT JOIN, aliases, relações N:N por tabela associativa, múltiplas junções, ausência de correspondência com NULL e JOIN combinado com GROUP BY.

BLOCO 1 — Usar um banco e administrar um SGBD são coisas diferentes

Até aqui trabalhamos principalmente como usuários do banco: criamos tabelas, inserimos dados e escrevemos consultas. A administração começa quando passamos a cuidar do ambiente que torna tudo isso possível.

BLOCO 2 — Quem é quem no MySQL?

Quando dizemos simplesmente “MySQL”, podemos estar falando de programas diferentes. Para administrar corretamente, precisamos separá-los.

Aplicação / Workbench / cliente mysql
              ↓ conexão
        MYSQL SERVER
           (mysqld)
              ↓
   bancos, tabelas e dados

BLOCO 3 — Instalação atual do MySQL no Windows

Neste curso adotamos o MySQL 8.4 LTS como referência estável. No Windows, a documentação oficial recomenda a instalação pelo pacote MSI e a configuração pelo MySQL Configurator.

1. Baixe o MySQL Community Server para Windows no site oficial.
2. Execute o instalador MSI.
3. Ao final da instalação, execute o MySQL Configurator.
4. Configure o servidor como serviço do Windows.
5. Defina uma senha forte para a conta administrativa root.
6. Conclua a configuração e confirme que o serviço iniciou.

O diretório padrão de uma instalação MSI do MySQL 8.4 costuma ficar em C:\Program Files\MySQL\MySQL Server 8.4. Não é necessário decorar esse caminho; precisamos apenas saber que a pasta bin contém programas como mysql, mysqld e mysqldump.

BLOCO 4 — Serviço do Windows: o servidor precisa estar funcionando

Em uma instalação normal no Windows, o MySQL Server é configurado como um serviço. Assim, ele pode iniciar automaticamente com o sistema operacional.

Windows inicia
     ↓
serviço do MySQL inicia
     ↓
mysqld fica aguardando conexões
     ↓
clientes podem se conectar

Uma forma simples de verificar é abrir Serviços do Windows (services.msc) e localizar o serviço configurado para o MySQL.

BLOCO 5 — CMD ou mysql>? Saiba onde executar cada comando

Este é um dos erros mais comuns de quem começa. Existem comandos do sistema operacional e comandos enviados ao servidor MySQL.

BLOCO 6 — Primeira verificação administrativa

Com o servidor iniciado, abra o CMD e conecte:

mysql -u root -p

Depois de informar a senha e aparecer o prompt mysql>, execute:

SELECT VERSION();
SELECT CURRENT_USER();
SHOW DATABASES;

Você também pode usar:

SHOW PROCESSLIST;

Esse comando permite observar conexões/sessões que o usuário atual tem permissão para enxergar. Não precisamos administrar concorrência ainda; por enquanto basta reconhecer que o servidor pode atender vários clientes.

BLOCO 7 — root é administrador, não usuário comum da aplicação

A conta root possui grande poder administrativo. Ela é útil para tarefas que realmente exigem administração, mas não deve ser a conta normal usada por um aplicativo, site ou aluno para todas as atividades.

ROOT
  ↓ administra
cria contas + concede somente o necessário
  ↓
USUÁRIO DA APLICAÇÃO / OPERADOR / CONSULTA

BLOCO 8 — Conta MySQL = usuário + origem

No MySQL, uma conta é identificada por algo como 'usuario'@'host'. Isso significa que nome e origem da conexão fazem parte da identidade da conta.

Para nosso laboratório local, criaremos uma conta restrita a localhost:

CREATE USER 'operador_comercio'@'localhost'
IDENTIFIED BY 'Exemplo-Apenas-Troque-Agora#2026';

Uma conta recém-criada não ganha automaticamente acesso ao banco comercio. Primeiro criamos a identidade; depois concedemos privilégios.

BLOCO 9 — GRANT: concedendo apenas o necessário

Suponha que operador_comercio precise consultar e manter os dados comerciais, mas não precise criar bancos, excluir tabelas ou administrar usuários.

GRANT SELECT, INSERT, UPDATE, DELETE
ON comercio.*
TO 'operador_comercio'@'localhost';

Leia a instrução:

SELECT, INSERT, UPDATE, DELETE  → o que pode fazer
comercio.*                      → em todas as tabelas do banco comercio
'operador_comercio'@'localhost'→ quem recebe

Agora crie também uma conta somente para consultas:

CREATE USER 'consulta_comercio'@'localhost'
IDENTIFIED BY 'Exemplo-Leitura-Troque-Agora#2026';

GRANT SELECT
ON comercio.*
TO 'consulta_comercio'@'localhost';

Isso materializa uma regra simples: quem só precisa ler não deve receber UPDATE ou DELETE.

BLOCO 10 — SHOW GRANTS e REVOKE: conferir antes de confiar

Depois de conceder privilégios, confirme o resultado:

SHOW GRANTS FOR 'operador_comercio'@'localhost';
SHOW GRANTS FOR 'consulta_comercio'@'localhost';

Se um privilégio deixou de ser necessário, retire-o com REVOKE:

REVOKE DELETE
ON comercio.*
FROM 'operador_comercio'@'localhost';

BLOCO 11 — Roles: quando várias contas possuem a mesma função

Se muitas contas precisarem do mesmo conjunto de privilégios, repetir GRANT usuário por usuário aumenta o trabalho. Uma role é um conjunto nomeado de privilégios que pode ser concedido a contas.

CREATE ROLE 'leitura_comercio';

GRANT SELECT
ON comercio.*
TO 'leitura_comercio';

CREATE USER 'analista_comercio'@'localhost'
IDENTIFIED BY 'Exemplo-Role-Troque-Agora#2026';

GRANT 'leitura_comercio'
TO 'analista_comercio'@'localhost';

SET DEFAULT ROLE 'leitura_comercio'
TO 'analista_comercio'@'localhost';

BLOCO 12 — Ciclo de vida das contas

Além de criar e conceder acesso, o administrador precisa saber alterar, bloquear e remover contas.

ALTER USER 'operador_comercio'@'localhost'
IDENTIFIED BY 'NOVA_SENHA_FORTE_E_EXCLUSIVA';

ALTER USER 'operador_comercio'@'localhost' ACCOUNT LOCK;

ALTER USER 'operador_comercio'@'localhost' ACCOUNT UNLOCK;

Quando uma conta realmente deixou de existir:

DROP USER 'operador_comercio'@'localhost';

BLOCO 13 — Administração segura: quatro regras que evitam muitos problemas

1. Não use root na aplicação. Crie uma conta própria para cada finalidade.
2. Não conceda mais privilégios do que o necessário.
3. Não exponha o servidor diretamente à Internet só para “fazer conectar”. Acesso remoto envolve rede, firewall, origem da conta e proteção da conexão.
4. Não altere arquivos internos do diretório de dados manualmente. Use ferramentas e procedimentos próprios do SGBD.

BLOCO 14 — Backup: uma cópia capaz de permitir recuperação

Backup não é apenas “salvar um arquivo”. O objetivo é conseguir recuperar dados e objetos depois de erro, falha, corrupção ou perda.

Banco funcionando
      ↓
criar backup
      ↓
guardar em local adequado
      ↓
testar restauração
      ↓
ter confiança de recuperação

BLOCO 15 — Laboratório: backup lógico com mysqldump

Saia do prompt mysql> ou abra outro CMD. Para criar uma cópia lógica do banco comercio:

mysqldump -u root -p --single-transaction comercio > comercio_backup.sql

Depois de pressionar Enter, o programa pedirá a senha. O arquivo comercio_backup.sql será criado na pasta atual do CMD.

BLOCO 16 — Laboratório seguro: restaure sem destruir o banco original

Um backup que nunca foi restaurado ainda não foi realmente testado. Em vez de sobrescrever o banco original, vamos restaurar em outro banco.

1. No prompt mysql>, crie um banco vazio para o teste:

CREATE DATABASE comercio_teste_restore;

2. No CMD, carregue o arquivo nele:

mysql -u root -p comercio_teste_restore < comercio_backup.sql

3. De volta ao mysql>, valide:

USE comercio_teste_restore;
SHOW TABLES;
SELECT COUNT(*) FROM produto;
SELECT COUNT(*) FROM fornecedor;
SELECT COUNT(*) FROM produto_fornecedor;

Compare as quantidades com o banco original. Abra algumas tabelas, execute JOINs e confirme se estrutura e dados foram recuperados.

Depois do laboratório e somente se tiver certeza de que não precisa mais do banco de teste, ele pode ser removido:

DROP DATABASE comercio_teste_restore;

BLOCO 17 — Outra forma de dump: levando o próprio nome do banco

Quando usamos a opção --databases, o arquivo de dump inclui comandos para criar e selecionar o banco durante a restauração.

mysqldump -u root -p --single-transaction --databases comercio > comercio_com_database.sql

Nesse caso, a restauração pode ser feita no CMD sem informar um banco de destino:

mysql -u root -p < comercio_com_database.sql

BLOCO 18 — Workbench: interface gráfica para tarefas administrativas

O MySQL Workbench permite executar SQL e também oferece telas administrativas. Entre elas estão controle do serviço, status do servidor, usuários e privilégios, exportação e importação de dados.

BLOCO 19 — Logs, configuração e diagnóstico: saiba onde olhar

Um administrador não precisa decorar centenas de variáveis. Precisa desenvolver uma sequência de diagnóstico.

Servidor não responde
        ↓
serviço está iniciado?
        ↓
consigo conectar localmente?
        ↓
usuário/senha/origem estão corretos?
        ↓
qual mensagem de erro apareceu?
        ↓
logs e configuração ajudam a explicar

O MySQL mantém arquivos de configuração e logs do servidor. Em Windows, instalações padrão armazenam dados de configuração e informações operacionais em diretórios próprios do MySQL. Não altere arquivos no escuro. Leia a mensagem de erro, faça backup da configuração e consulte a documentação da versão utilizada antes de mudar parâmetros.

BLOCO 20 — Política mínima de backup

Em ambiente real, um backup manual feito uma única vez não basta. Uma política precisa responder:

1. O quê? Quais bancos e objetos precisam ser protegidos?
2. Quando? Qual frequência atende a quantidade de dados que a organização aceita perder?
3. Onde? Onde as cópias ficarão guardadas para não desaparecerem junto com o servidor?
4. Por quanto tempo? Quais versões históricas serão mantidas?
5. Quem? Quem é responsável por verificar o processo?
6. Como testar? Quando e onde a restauração será validada?

BLOCO 21 — Laboratório integrador de administração

Agora execute o ciclo administrativo completo usando o banco comercio:

1. confirme que o serviço MySQL está iniciado;
2. conecte como administrador;
3. confirme versão e conta atual;
4. crie uma conta somente de leitura para comercio;
5. conceda apenas SELECT;
6. confira com SHOW GRANTS;
7. entre com essa nova conta e teste um SELECT;
8. tente um UPDATE e observe que ele deve ser negado;
9. volte à conta administrativa;
10. faça um dump do banco;
11. restaure em comercio_teste_restore;
12. valide tabelas, quantidades e um JOIN;
13. remova somente o banco de teste quando finalizar.

BLOCO 22 — Fechamento do Capítulo

Neste capítulo, aprendemos a separar MySQL Server, processo mysqld, cliente mysql e Workbench; instalar e reconhecer o serviço; identificar onde cada comando deve ser executado; administrar contas e privilégios; aplicar menor privilégio; usar roles; criar backup lógico; restaurar com segurança; validar recuperação e organizar um diagnóstico básico.

O próximo passo é entender algo que acontece dentro do trabalho concorrente com os dados: como várias alterações podem formar uma unidade segura e como o banco decide confirmar ou desfazer mudanças.

BLOCO 1 — O problema: duas operações que precisam dar certo juntas

Imagine uma transferência bancária de R$ 100 entre duas contas. O sistema precisa retirar R$ 100 da conta A e acrescentar R$ 100 na conta B.

Conta A: - 100
        ↓
Conta B: + 100

Se a primeira operação for gravada e a segunda falhar, o dinheiro simplesmente desaparece. O problema não está em um UPDATE isolado: está no conjunto das operações.

BLOCO 2 — O que é uma transação?

Uma transação é uma sequência de operações que pertence ao mesmo processo de negócio. Exemplos:

• transferir dinheiro entre contas;
• registrar um pedido e seus itens;
• baixar estoque depois de uma venda;
• registrar matrícula e pagamento inicial;
• reservar uma vaga sem permitir que duas pessoas ocupem o mesmo lugar.

START TRANSACTION
      ↓
operação 1
      ↓
operação 2
      ↓
COMMIT  ou  ROLLBACK

COMMIT confirma as alterações. ROLLBACK desfaz as alterações ainda não confirmadas da transação.

BLOCO 3 — InnoDB: o mecanismo que usaremos

No MySQL, o mecanismo InnoDB oferece transações ACID, bloqueios em nível de linha e controle de concorrência. É o mecanismo padrão nas instalações atuais do MySQL.

SHOW TABLE STATUS FROM comercio;

Na coluna Engine, as tabelas do nosso laboratório devem aparecer como InnoDB.

BLOCO 4 — AUTOCOMMIT: existe uma transação mesmo quando você não percebe

Por padrão, uma nova conexão do MySQL inicia com autocommit ligado. Nesse modo, cada comando SQL bem-sucedido é tratado como uma pequena transação e confirmado automaticamente.

SELECT @@autocommit;

Resultado 1 significa autocommit ligado.

Quando várias instruções precisam formar uma única unidade, use uma transação explícita.

BLOCO 5 — Sua primeira transação explícita

Vamos experimentar sem deixar alteração permanente. Primeiro consulte um produto existente:

SELECT id_produto, descricao, qtde
FROM produto
WHERE id_produto = 22;

START TRANSACTION;

UPDATE produto
SET qtde = qtde - 1
WHERE id_produto = 22;

SELECT id_produto, descricao, qtde
FROM produto
WHERE id_produto = 22;

ROLLBACK;

SELECT id_produto, descricao, qtde
FROM produto
WHERE id_produto = 22;

Dentro da transação, sua própria sessão enxerga a alteração. Depois do ROLLBACK, a quantidade deve voltar ao valor anterior.

BLOCO 6 — COMMIT: quando a alteração passa a valer

Agora veremos o caminho oposto. Para evitar alterar a base principal do curso, criaremos uma pequena tabela de laboratório. A criação é feita antes da transação.

CREATE TABLE conta_lab (
  id_conta INT PRIMARY KEY,
  titular VARCHAR(60) NOT NULL,
  saldo DECIMAL(10,2) NOT NULL
) ENGINE=InnoDB;

INSERT INTO conta_lab VALUES
(1, 'ANA', 1000.00),
(2, 'BRUNO', 500.00);

Agora faça uma transferência de R$ 100:

START TRANSACTION;

UPDATE conta_lab
SET saldo = saldo - 100
WHERE id_conta = 1;

UPDATE conta_lab
SET saldo = saldo + 100
WHERE id_conta = 2;

SELECT * FROM conta_lab;

COMMIT;

Depois do COMMIT, a transação termina e suas alterações ficam confirmadas.

BLOCO 7 — ROLLBACK: falhou? volte o conjunto

Repita a ideia, mas imagine que algo deu errado antes de concluir:

START TRANSACTION;

UPDATE conta_lab
SET saldo = saldo - 50
WHERE id_conta = 1;

-- imagine que uma validação da aplicação falhou aqui

ROLLBACK;

SELECT * FROM conta_lab;

O saldo volta ao estado existente antes dessa transação.

BLOCO 8 — SAVEPOINT: voltar apenas até um ponto

Às vezes queremos preservar parte do trabalho realizado dentro da transação. Um SAVEPOINT funciona como um marco intermediário.

START TRANSACTION;

UPDATE conta_lab
SET saldo = saldo + 20
WHERE id_conta = 1;

SAVEPOINT depois_primeiro_ajuste;

UPDATE conta_lab
SET saldo = saldo + 30
WHERE id_conta = 2;

ROLLBACK TO SAVEPOINT depois_primeiro_ajuste;

COMMIT;

O segundo ajuste é desfeito, mas o primeiro pode ser confirmado pelo COMMIT final.

BLOCO 9 — ACID: quatro propriedades para confiar na transação

ACID não são quatro comandos SQL. São quatro propriedades usadas para pensar sobre a confiabilidade das transações.

BLOCO 10 — Atomicidade e consistência no exemplo da transferência

Na transferência, atomicidade significa não aceitar “saiu da conta A, mas não entrou na B”. Já a consistência significa que o banco deve sair de um estado válido e chegar a outro estado válido, respeitando regras como chaves, restrições e regras de negócio.

BLOCO 11 — Isolamento: agora entram dois usuários

Até aqui executamos tudo em uma única conexão. Sistemas reais possuem vários usuários e processos ao mesmo tempo.

Sessão A ─┐
          ├── Banco de Dados
Sessão B ─┘

O desafio é permitir concorrência sem deixar uma transação enxergar ou sobrescrever dados de forma inadequada.

BLOCO 12 — Três fenômenos clássicos de concorrência

Esses nomes parecem abstratos até pensarmos em duas pessoas comprando o último item, dois caixas alterando o mesmo saldo ou dois atendentes reservando a mesma vaga.

BLOCO 13 — Os quatro níveis de isolamento

O MySQL/InnoDB oferece os quatro níveis tradicionais de isolamento. Eles representam escolhas entre maior liberdade de concorrência e maior proteção entre transações.

SELECT @@transaction_isolation;

Em uma instalação padrão do MySQL 8.4, o resultado esperado é REPEATABLE-READ.

BLOCO 14 — Alterando o isolamento de uma transação

Podemos definir o nível para a próxima transação:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;

SELECT * FROM conta_lab;

COMMIT;

Não mude níveis apenas para “resolver erro”. Primeiro identifique o problema de concorrência e só depois decida qual comportamento faz sentido.

BLOCO 15 — SELECT ... FOR UPDATE: ler e reservar para alteração

Imagine que uma aplicação consulta o estoque e, alguns milissegundos depois, decide diminuí-lo. Outra transação pode alterar a mesma linha nesse intervalo.

Quando a leitura serve de base para uma alteração que virá em seguida, o InnoDB oferece a leitura bloqueante FOR UPDATE.

START TRANSACTION;

SELECT id_produto, descricao, qtde
FROM produto
WHERE id_produto = 22
FOR UPDATE;

UPDATE produto
SET qtde = qtde - 1
WHERE id_produto = 22
  AND qtde > 0;

COMMIT;

Enquanto a transação mantém o bloqueio apropriado, outra sessão que tente alterar a mesma linha pode precisar aguardar.

BLOCO 16 — Laboratório de duas sessões

Abra duas conexões. Na Sessão A:

START TRANSACTION;

SELECT id_produto, qtde
FROM produto
WHERE id_produto = 22
FOR UPDATE;

-- não dê COMMIT ainda

Na Sessão B, também abra uma transação antes de tentar alterar:

START TRANSACTION;

UPDATE produto
SET qtde = qtde - 1
WHERE id_produto = 22;

-- quando o UPDATE finalmente concluir, execute:
ROLLBACK;

A Sessão B deve ficar aguardando enquanto A mantém o bloqueio. Volte à Sessão A e execute ROLLBACK;. O UPDATE da Sessão B então pode prosseguir; em seguida, execute o ROLLBACK indicado nela para que nenhuma baixa fique gravada.

BLOCO 17 — Deadlock: quando cada transação espera pela outra

Um deadlock ocorre quando transações ficam presas em uma dependência circular de bloqueios.

Transação A bloqueia linha 1
          e espera linha 2
                 ↑
                 │
Transação B bloqueia linha 2
          e espera linha 1

O InnoDB normalmente detecta o deadlock e escolhe uma transação para desfazer, permitindo que a outra prossiga.

BLOCO 18 — Como reduzir deadlocks e esperas desnecessárias

• mantenha transações curtas;
• não espere interação humana com uma transação aberta;
• acesse registros em uma ordem consistente;
• use filtros e índices adequados;
• bloqueie somente o que realmente precisa;
• trate falhas e possibilidade de repetição na aplicação.

Para investigar o último deadlock detectado pelo InnoDB, um administrador pode consultar:

SHOW ENGINE INNODB STATUS;

BLOCO 19 — Cuidado: nem tudo obedece ao ROLLBACK como um UPDATE

Comandos de definição de estrutura, como vários CREATE, ALTER, DROP e TRUNCATE, podem causar COMMIT implícito no MySQL. Por isso, não use DDL no meio de um laboratório esperando que um ROLLBACK reverta tudo como se fossem comandos DML comuns.

Por isso criamos conta_lab antes de iniciar as transações do laboratório.

BLOCO 20 — Laboratório integrador

Faça o ciclo completo:

1. confirme que conta_lab usa InnoDB;
2. consulte saldos iniciais;
3. execute uma transferência com START TRANSACTION;
4. confira os valores antes de confirmar;
5. teste uma transferência com ROLLBACK;
6. teste outra com COMMIT;
7. use SAVEPOINT em uma operação com três etapas;
8. abra duas sessões e observe um bloqueio com FOR UPDATE;
9. consulte o nível de isolamento atual;
10. explique onde aparecem atomicidade, consistência, isolamento e durabilidade.

BLOCO 21 — Fechamento do Capítulo

Neste capítulo, aprendemos que transação é uma unidade de trabalho; vimos autocommit, START TRANSACTION, COMMIT, ROLLBACK e SAVEPOINT; relacionamos ACID a situações reais; observamos concorrência em duas sessões; conhecemos níveis de isolamento, FOR UPDATE, bloqueios, deadlocks e o cuidado com comandos que provocam commit implícito.

Agora o SQL básico e o comportamento transacional estão sólidos o suficiente para avançar para consultas e recursos que ampliam o poder da linguagem.

BLOCO 1 — SQL avançado não significa SQL incompreensível

Até aqui já usamos SELECT, filtros, JOIN, GROUP BY, HAVING e transações. SQL avançado começa quando uma pergunta deixa de caber confortavelmente em uma consulta simples.

Pergunta de negócio
        ↓
consulta simples resolve?
        ↓ não
subconsulta / CTE / janela / view / índice / rotina
        ↓
solução mais clara, reutilizável ou eficiente

BLOCO 2 — Subconsulta: um SELECT dentro de outro comando

Uma subconsulta é um SELECT usado dentro de outra instrução. Comece pensando em duas perguntas separadas.

Exemplo: quais produtos custam mais do que o preço médio de todos os produtos?

SELECT id_produto, descricao, preco
FROM produto
WHERE preco > (
    SELECT AVG(preco)
    FROM produto
)
ORDER BY preco DESC;

A consulta interna calcula um único valor: a média. A consulta externa compara cada produto com esse resultado.

BLOCO 3 — IN, EXISTS e NOT EXISTS

Subconsultas não servem apenas para retornar um único valor. Elas também podem responder se existe ou não uma correspondência.

IN com subconsulta

No Capítulo 4 usamos IN com uma lista fixa. Agora a própria lista pode vir de outro SELECT:

SELECT id_produto, descricao, id_categoria
FROM produto
WHERE id_categoria IN (
    SELECT id_categoria
    FROM categoria
    WHERE nome LIKE '%DOCE%'
)
ORDER BY descricao;

A consulta interna retorna os IDs das categorias cujo nome contém “DOCE”; a consulta externa procura produtos que pertencem a qualquer uma delas.

Fornecedores que possuem pelo menos um produto

SELECT f.id_fornecedor, f.nome
FROM fornecedor AS f
WHERE EXISTS (
    SELECT 1
    FROM produto_fornecedor AS pf
    WHERE pf.id_fornecedor = f.id_fornecedor
)
ORDER BY f.nome;

Fornecedores sem produtos associados

SELECT f.id_fornecedor, f.nome
FROM fornecedor AS f
WHERE NOT EXISTS (
    SELECT 1
    FROM produto_fornecedor AS pf
    WHERE pf.id_fornecedor = f.id_fornecedor
)
ORDER BY f.nome;

EXISTS pergunta se a subconsulta encontra pelo menos uma linha. NOT EXISTS pergunta o contrário.

BLOCO 4 — JOIN ou subconsulta?

Muitas perguntas podem ser resolvidas de mais de uma forma. Isso não significa que exista sempre uma única sintaxe correta.

BLOCO 5 — UNION e UNION ALL: empilhando resultados

JOIN coloca colunas relacionadas lado a lado. UNION combina resultados compatíveis colocando linhas de uma consulta abaixo das linhas de outra.

SELECT 'CATEGORIA' AS tipo, nome AS descricao
FROM categoria
UNION ALL
SELECT 'FORNECEDOR' AS tipo, nome AS descricao
FROM fornecedor
ORDER BY tipo, descricao;

As consultas precisam retornar quantidade compatível de colunas, em posições correspondentes e com tipos que possam ser combinados.

BLOCO 6 — CTE: dando nome a uma etapa da consulta

Uma CTE — Common Table Expression é definida com WITH. Ela permite dar um nome temporário a um resultado e usá-lo logo depois.

WITH estoque_baixo AS (
    SELECT id_produto, descricao, qtde, estoque_minimo
    FROM produto
    WHERE qtde <= estoque_minimo
)
SELECT *
FROM estoque_baixo
ORDER BY qtde, descricao;

BLOCO 7 — CTEs podem trabalhar em sequência

Quando o raciocínio possui etapas, podemos declarar mais de uma CTE.

WITH resumo_categoria AS (
    SELECT
        id_categoria,
        COUNT(*) AS total_produtos,
        AVG(preco) AS preco_medio
    FROM produto
    GROUP BY id_categoria
),
resultado AS (
    SELECT
        c.nome AS categoria,
        r.total_produtos,
        r.preco_medio
    FROM resumo_categoria AS r
    INNER JOIN categoria AS c
        ON c.id_categoria = r.id_categoria
)
SELECT *
FROM resultado
ORDER BY preco_medio DESC;

O importante é conseguir explicar o papel de cada etapa. Se uma CTE apenas deixa a consulta maior sem melhorar a leitura, ela não está ajudando.

BLOCO 8 — Funções de janela: calcular sem perder as linhas

GROUP BY agrupa várias linhas e produz uma linha por grupo. Uma função de janela calcula usando linhas relacionadas, mas mantém as linhas individuais no resultado.

SELECT
    p.descricao,
    c.nome AS categoria,
    p.preco,
    AVG(p.preco) OVER (
        PARTITION BY p.id_categoria
    ) AS media_categoria
FROM produto AS p
INNER JOIN categoria AS c
    ON c.id_categoria = p.id_categoria
ORDER BY c.nome, p.preco DESC;

PARTITION BY divide as linhas em grupos lógicos para o cálculo, sem reduzir o número de linhas exibidas.

BLOCO 9 — ROW_NUMBER e RANK: criando posições

Funções de janela também permitem criar rankings.

SELECT
    c.nome AS categoria,
    p.descricao,
    p.preco,
    ROW_NUMBER() OVER (
        PARTITION BY p.id_categoria
        ORDER BY p.preco DESC
    ) AS posicao
FROM produto AS p
INNER JOIN categoria AS c
    ON c.id_categoria = p.id_categoria
ORDER BY c.nome, posicao;

ROW_NUMBER() gera uma sequência sem empates de numeração. RANK() atribui a mesma posição a valores empatados e pode pular números depois do empate.

WITH ranking AS (
    SELECT
        p.id_categoria,
        p.descricao,
        p.preco,
        ROW_NUMBER() OVER (
            PARTITION BY p.id_categoria
            ORDER BY p.preco DESC
        ) AS posicao
    FROM produto AS p
)
SELECT
    c.nome AS categoria,
    r.descricao,
    r.preco,
    r.posicao
FROM ranking AS r
INNER JOIN categoria AS c
    ON c.id_categoria = r.id_categoria
WHERE r.posicao <= 3
ORDER BY c.nome, r.posicao;

BLOCO 10 — Acumulados com SUM OVER

Outra aplicação útil é calcular valores acumulados sem perder cada linha.

SELECT
    id_produto,
    descricao,
    preco,
    SUM(preco) OVER (
        ORDER BY id_produto
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS preco_acumulado
FROM produto
ORDER BY id_produto;

BLOCO 11 — VIEW: salvando uma consulta com nome

Uma view é uma consulta armazenada no banco e acessada como se fosse uma tabela virtual.

CREATE OR REPLACE VIEW vw_produto_categoria AS
SELECT
    p.id_produto,
    p.descricao,
    p.preco,
    p.qtde,
    c.nome AS categoria
FROM produto AS p
INNER JOIN categoria AS c
    ON c.id_categoria = p.id_categoria;

Depois:

SELECT *
FROM vw_produto_categoria
WHERE preco > 20
ORDER BY preco DESC;

BLOCO 12 — Índices: atalhos para localizar linhas

Um índice é uma estrutura mantida pelo SGBD para encontrar determinadas linhas com menos trabalho. Sem um índice útil, uma consulta pode precisar examinar muitas linhas.

Sem índice adequado
linha 1 → linha 2 → linha 3 → ...

Com índice adequado
valor procurado → caminho mais direto até as linhas

Para experimentar:

CREATE INDEX idx_produto_descricao
ON produto(descricao);

SHOW INDEX FROM produto;

Esse índice pode ajudar consultas que pesquisam pela descrição, dependendo do filtro, da quantidade de dados e das decisões do otimizador.

BLOCO 13 — EXPLAIN: pergunte ao MySQL como ele pretende executar

EXPLAIN mostra o plano escolhido pelo otimizador. Ele ajuda a investigar ordem de leitura das tabelas, índices possíveis, índice escolhido e estimativa de linhas examinadas.

EXPLAIN
SELECT id_produto, descricao, preco
FROM produto
WHERE descricao LIKE 'A%';

Algumas colunas importantes da saída tradicional:

BLOCO 14 — EXPLAIN ANALYZE: plano e execução real

No MySQL 8.4, EXPLAIN ANALYZE executa uma consulta SELECT e mostra informações reais da execução em formato de árvore.

EXPLAIN ANALYZE
SELECT id_produto, descricao, preco
FROM produto
WHERE descricao LIKE 'A%';

BLOCO 15 — TRIGGER: uma ação automática ligada a uma tabela

Um trigger é executado automaticamente quando ocorre um evento de INSERT, UPDATE ou DELETE na tabela associada. Vamos criar um laboratório de auditoria de preço.

CREATE TABLE IF NOT EXISTS auditoria_preco (
    id_auditoria INT PRIMARY KEY AUTO_INCREMENT,
    id_produto INT NOT NULL,
    preco_anterior DECIMAL(10,2) NOT NULL,
    preco_novo DECIMAL(10,2) NOT NULL,
    alterado_em TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

DROP TRIGGER IF EXISTS trg_produto_audita_preco;

DELIMITER //
CREATE TRIGGER trg_produto_audita_preco
AFTER UPDATE ON produto
FOR EACH ROW
BEGIN
    IF NEW.preco <> OLD.preco THEN
        INSERT INTO auditoria_preco
            (id_produto, preco_anterior, preco_novo)
        VALUES
            (NEW.id_produto, OLD.preco, NEW.preco);
    END IF;
END//
DELIMITER ;

OLD representa os valores anteriores da linha; NEW, os valores novos.

BLOCO 16 — PROCEDURE: uma rotina chamada com CALL

Uma stored procedure agrupa instruções SQL no servidor e pode receber parâmetros.

DROP PROCEDURE IF EXISTS sp_produtos_por_categoria;

DELIMITER //
CREATE PROCEDURE sp_produtos_por_categoria(IN p_id_categoria INT)
BEGIN
    SELECT id_produto, descricao, preco, qtde
    FROM produto
    WHERE id_categoria = p_id_categoria
    ORDER BY descricao;
END//
DELIMITER ;

Para executar:

CALL sp_produtos_por_categoria(1);

O parâmetro permite reutilizar a mesma rotina para categorias diferentes.

BLOCO 17 — FUNCTION: uma rotina que devolve um valor

Uma stored function retorna um valor e pode ser usada dentro de expressões SQL.

DROP FUNCTION IF EXISTS fn_status_estoque;

DELIMITER //
CREATE FUNCTION fn_status_estoque(
    p_qtde INT,
    p_minimo INT
)
RETURNS VARCHAR(10)
DETERMINISTIC
RETURN CASE
    WHEN p_qtde <= p_minimo THEN 'REPOR'
    ELSE 'OK'
END//
DELIMITER ;

Depois:

SELECT
    descricao,
    qtde,
    estoque_minimo,
    fn_status_estoque(qtde, estoque_minimo) AS status_estoque
FROM produto
ORDER BY descricao;

BLOCO 18 — VIEW, PROCEDURE, FUNCTION e TRIGGER: não confunda

BLOCO 19 — Laboratório integrador

Monte um pequeno painel analítico do banco comercio:

1. use uma subconsulta para identificar produtos acima da média de preço;
2. use NOT EXISTS para localizar fornecedores sem produtos;
3. use uma CTE para separar produtos com estoque baixo;
4. use ROW_NUMBER para criar ranking de preço por categoria;
5. crie uma view de produto + categoria;
6. observe uma consulta com EXPLAIN antes e depois de um índice de laboratório;
7. crie a função de status de estoque;
8. execute a procedure de produtos por categoria;
9. teste o trigger de auditoria alterando conscientemente um preço e depois restaurando o valor.

BLOCO 20 — Resumo e próxima etapa

Neste capítulo usamos subconsultas, EXISTS e NOT EXISTS, UNION, CTEs, funções de janela, views, índices, EXPLAIN, triggers, procedures e functions.

O próximo passo será reunir modelagem, regras de negócio, implementação, consultas e validação em um Projeto Integrador completo.

BLOCO 1 — O projeto: sistema de vendas de uma pequena loja

Uma pequena loja precisa substituir planilhas separadas por um sistema capaz de controlar clientes, produtos, categorias, pedidos, itens vendidos e estoque.

BLOCO 2 — Antes do DER: requisitos

Requisito descreve algo que o sistema precisa permitir ou garantir. Antes de desenhar tabelas, escreva o que o negócio precisa.

1. cadastrar clientes;
2. cadastrar categorias e produtos;
3. registrar pedidos de clientes;
4. registrar vários produtos em um pedido;
5. guardar quantidade e preço praticado em cada item vendido;
6. controlar estoque atual dos produtos;
7. consultar histórico de pedidos;
8. calcular total de cada pedido;
9. identificar produtos nunca vendidos;
10. permitir que uma aplicação acesse o banco com uma conta própria.

BLOCO 3 — Regras de negócio

Agora transformamos os requisitos em regras mais precisas.

BLOCO 4 — Cardinalidade mínima e máxima

CLIENTE   0..N ───── 1..1 PEDIDO
CATEGORIA 0..N ───── 1..1 PRODUTO
PEDIDO    1..N ───── 0..N PRODUTO
              via ITEM_PEDIDO

Em uma implementação real, um pedido pode existir temporariamente sem itens enquanto está sendo montado. A regra “pedido finalizado precisa ter pelo menos um item” normalmente exige validação da aplicação ou um processo transacional; uma simples FK não garante isso sozinha.

BLOCO 5 — DER conceitual

CLIENTE
  │ 1
  │
  │ N
PEDIDO ──────── ITEM_PEDIDO ──────── PRODUTO
                   N            N        │ N
                                         │
                                         │ 1
                                      CATEGORIA

Entidades principais: CLIENTE, PEDIDO, PRODUTO e CATEGORIA. ITEM_PEDIDO nasce do relacionamento N:N entre pedido e produto e ainda possui atributos próprios: quantidade e preço_unitario.

BLOCO 6 — Do conceitual para o modelo lógico

CLIENTE
PK id_cliente
   nome
   email
   telefone

CATEGORIA
PK id_categoria
   nome

PRODUTO
PK id_produto
   descricao
   preco
   estoque
FK id_categoria

PEDIDO
PK id_pedido
   data_pedido
   status
FK id_cliente

ITEM_PEDIDO
PK/FK id_pedido
PK/FK id_produto
      quantidade
      preco_unitario

A chave composta de ITEM_PEDIDO impede que o mesmo produto seja repetido duas vezes no mesmo pedido. Se o negócio quisesse permitir várias linhas do mesmo produto, precisaríamos rever essa regra e a chave.

BLOCO 7 — Normalização: por que não guardar tudo em uma planilha?

Imagine uma planilha assim:

Pedido, cliente e categoria ficam repetidos. Se o e-mail mudar, várias linhas precisam ser corrigidas. Se a categoria mudar de nome, o mesmo problema reaparece.

BLOCO 8 — Criando o banco e as tabelas

CREATE DATABASE loja_integrador
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;

USE loja_integrador;

CREATE TABLE cliente (
    id_cliente INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(100) NOT NULL,
    email VARCHAR(120) UNIQUE,
    telefone VARCHAR(20)
);

CREATE TABLE categoria (
    id_categoria INT PRIMARY KEY AUTO_INCREMENT,
    nome VARCHAR(60) NOT NULL UNIQUE
);

CREATE TABLE produto (
    id_produto INT PRIMARY KEY AUTO_INCREMENT,
    descricao VARCHAR(120) NOT NULL,
    preco DECIMAL(10,2) NOT NULL,
    estoque INT NOT NULL DEFAULT 0,
    id_categoria INT NOT NULL,
    CHECK (preco >= 0),
    CHECK (estoque >= 0),
    FOREIGN KEY (id_categoria)
        REFERENCES categoria(id_categoria)
);

CREATE TABLE pedido (
    id_pedido INT PRIMARY KEY AUTO_INCREMENT,
    data_pedido DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    status VARCHAR(15) NOT NULL DEFAULT 'ABERTO',
    id_cliente INT NOT NULL,
    CHECK (status IN ('ABERTO','PAGO','CANCELADO')),
    FOREIGN KEY (id_cliente)
        REFERENCES cliente(id_cliente)
);

CREATE TABLE item_pedido (
    id_pedido INT NOT NULL,
    id_produto INT NOT NULL,
    quantidade INT NOT NULL,
    preco_unitario DECIMAL(10,2) NOT NULL,
    PRIMARY KEY (id_pedido, id_produto),
    CHECK (quantidade > 0),
    CHECK (preco_unitario >= 0),
    FOREIGN KEY (id_pedido)
        REFERENCES pedido(id_pedido),
    FOREIGN KEY (id_produto)
        REFERENCES produto(id_produto)
);

BLOCO 9 — Dados iniciais para teste

INSERT INTO categoria (id_categoria, nome) VALUES
(1, 'PAPELARIA'),
(2, 'INFORMATICA'),
(3, 'ESCRITORIO');

INSERT INTO produto
(id_produto, descricao, preco, estoque, id_categoria) VALUES
(1, 'CADERNO UNIVERSITARIO', 18.90, 40, 1),
(2, 'CANETA AZUL', 3.50, 100, 1),
(3, 'MOUSE USB', 49.90, 25, 2),
(4, 'SUPORTE PARA NOTEBOOK', 89.90, 12, 2),
(5, 'PASTA ARQUIVO', 12.50, 30, 3);

INSERT INTO cliente
(id_cliente, nome, email, telefone) VALUES
(1, 'ANA SOUZA', 'ana@exemplo.com', '11999990001'),
(2, 'BRUNO LIMA', 'bruno@exemplo.com', '11999990002'),
(3, 'CARLA MENDES', 'carla@exemplo.com', '11999990003');

INSERT INTO pedido
(id_pedido, data_pedido, status, id_cliente) VALUES
(1, '2026-08-20 10:00:00', 'PAGO', 1),
(2, '2026-08-21 14:30:00', 'PAGO', 2),
(3, '2026-08-22 09:15:00', 'ABERTO', 1);

INSERT INTO item_pedido
(id_pedido, id_produto, quantidade, preco_unitario) VALUES
(1, 1, 2, 18.90),
(1, 2, 5, 3.50),
(2, 3, 1, 49.90),
(2, 5, 2, 12.50),
(3, 4, 1, 89.90);

BLOCO 10 — Primeira consulta: pedido completo

SELECT
    p.id_pedido,
    p.data_pedido,
    c.nome AS cliente,
    pr.descricao AS produto,
    i.quantidade,
    i.preco_unitario,
    i.quantidade * i.preco_unitario AS subtotal
FROM pedido AS p
INNER JOIN cliente AS c
    ON c.id_cliente = p.id_cliente
INNER JOIN item_pedido AS i
    ON i.id_pedido = p.id_pedido
INNER JOIN produto AS pr
    ON pr.id_produto = i.id_produto
ORDER BY p.id_pedido, pr.descricao;

O relatório recompõe dados que foram corretamente separados durante a normalização.

BLOCO 11 — Total de cada pedido

SELECT
    p.id_pedido,
    c.nome AS cliente,
    p.status,
    SUM(i.quantidade * i.preco_unitario) AS total_pedido
FROM pedido AS p
INNER JOIN cliente AS c
    ON c.id_cliente = p.id_cliente
INNER JOIN item_pedido AS i
    ON i.id_pedido = p.id_pedido
GROUP BY p.id_pedido, c.nome, p.status
ORDER BY p.id_pedido;

BLOCO 12 — Perguntas de negócio mais avançadas

Produtos nunca vendidos

SELECT pr.id_produto, pr.descricao
FROM produto AS pr
WHERE NOT EXISTS (
    SELECT 1
    FROM item_pedido AS i
    WHERE i.id_produto = pr.id_produto
)
ORDER BY pr.descricao;

Quanto cada cliente já comprou em pedidos pagos?

WITH compras AS (
    SELECT
        c.id_cliente,
        c.nome,
        SUM(i.quantidade * i.preco_unitario) AS total_comprado
    FROM cliente AS c
    INNER JOIN pedido AS p
        ON p.id_cliente = c.id_cliente
    INNER JOIN item_pedido AS i
        ON i.id_pedido = p.id_pedido
    WHERE p.status = 'PAGO'
    GROUP BY c.id_cliente, c.nome
)
SELECT
    nome,
    total_comprado,
    RANK() OVER (ORDER BY total_comprado DESC) AS posicao
FROM compras
ORDER BY posicao, nome;

BLOCO 13 — Registrando uma venda com transação

Criar o pedido, inserir itens e baixar estoque formam um único processo. Se uma parte falhar, não queremos metade da venda gravada.

START TRANSACTION
        ↓
verificar/bloquear estoque
        ↓
criar pedido
        ↓
inserir itens
        ↓
baixar estoque
        ↓
COMMIT ou ROLLBACK

Em uma venda de duas unidades do produto 1, uma aplicação pode iniciar assim:

START TRANSACTION;

SELECT id_produto, preco, estoque
FROM produto
WHERE id_produto = 1
FOR UPDATE;

-- A aplicação verifica se estoque >= 2.

INSERT INTO pedido (id_cliente, status)
VALUES (3, 'ABERTO');

SET @novo_pedido = LAST_INSERT_ID();

INSERT INTO item_pedido
(id_pedido, id_produto, quantidade, preco_unitario)
SELECT @novo_pedido, id_produto, 2, preco
FROM produto
WHERE id_produto = 1;

UPDATE produto
SET estoque = estoque - 2
WHERE id_produto = 1
  AND estoque >= 2;

-- Se todas as validações deram certo:
COMMIT;

BLOCO 14 — Uma VIEW para o resumo de pedidos

CREATE OR REPLACE VIEW vw_resumo_pedido AS
SELECT
    p.id_pedido,
    p.data_pedido,
    p.status,
    c.id_cliente,
    c.nome AS cliente,
    SUM(i.quantidade * i.preco_unitario) AS total_pedido
FROM pedido AS p
INNER JOIN cliente AS c
    ON c.id_cliente = p.id_cliente
INNER JOIN item_pedido AS i
    ON i.id_pedido = p.id_pedido
GROUP BY
    p.id_pedido,
    p.data_pedido,
    p.status,
    c.id_cliente,
    c.nome;

Agora relatórios podem começar por:

SELECT *
FROM vw_resumo_pedido
WHERE status = 'PAGO'
ORDER BY data_pedido DESC;

BLOCO 15 — Índice orientado por necessidade

Se relatórios consultarem pedidos frequentemente por período, faz sentido testar um índice sobre a data.

CREATE INDEX idx_pedido_data
ON pedido(data_pedido);

EXPLAIN
SELECT id_pedido, data_pedido, status
FROM pedido
WHERE data_pedido >= '2026-08-01'
  AND data_pedido < '2026-09-01';

Em nossa base pequena, o otimizador pode continuar preferindo uma leitura simples. O projeto mostra o processo correto: identificar consulta importante → medir → criar índice quando fizer sentido → medir novamente.

BLOCO 16 — O banco não deve ser exposto diretamente ao usuário

Usuário
   ↓
Aplicação / API
   ↓
Driver ou Connector
   ↓
MySQL Server
   ↓
Banco loja_integrador

A interface do sistema conversa com a aplicação. A aplicação valida regras, controla transações e usa uma conta MySQL com privilégios adequados. O usuário final não precisa conhecer a senha do banco.

BLOCO 17 — Consultas parametrizadas

Quando a aplicação recebe um valor do usuário, não deve montar SQL concatenando texto recebido.

"SELECT * FROM cliente WHERE id_cliente = " + valor_recebido

SELECT * FROM cliente WHERE id_cliente = ?

BLOCO 18 — O que testar antes de dizer que o banco está pronto?

BLOCO 19 — Entregáveis do projeto

Um projeto de banco não termina no arquivo SQL. Organize a entrega:

1. descrição do problema;
2. requisitos;
3. regras de negócio;
4. DER conceitual;
5. modelo lógico com PKs e FKs;
6. justificativa de normalização;
7. script de criação do banco;
8. dados de teste;
9. consultas e relatórios;
10. teste de transação;
11. plano básico de usuário/permissões;
12. backup e teste de restauração;
13. descrição de como uma aplicação acessará o banco.

BLOCO 20 — Revisão crítica do próprio projeto

Antes de entregar, faça perguntas que um revisor faria:

• algum dado está repetido sem necessidade?
• todas as tabelas possuem uma chave adequada?
• as FKs representam as regras de negócio?
• há atributos que pertencem a outra entidade?
• o histórico de venda é preservado?
• uma operação parcial pode deixar o banco inconsistente?
• as consultas respondem perguntas reais?
• o usuário da aplicação possui privilégios demais?
• o backup foi realmente restaurado?

BLOCO 21 — Resumo e próxima etapa

Neste projeto percorremos o ciclo completo: problema → requisitos → regras → modelagem conceitual → modelo lógico → normalização → implementação física → dados → consultas → transação → desempenho → segurança → aplicação → testes e recuperação.

O último capítulo amplia a visão: como bancos relacionais convivem com NoSQL, nuvem, APIs, Big Data e Inteligência Artificial, e como escolher tecnologia sem seguir moda.

BLOCO 1 — Moderno não significa abandonar o relacional

Depois de aprender modelagem, SQL, transações, segurança e administração, seria um erro concluir que tudo isso foi substituído. Bancos relacionais continuam sendo uma escolha excelente quando o problema exige estrutura clara, integridade, relacionamentos e transações confiáveis.

Problema real
    ↓
requisitos de dados + acesso + escala + consistência
    ↓
escolha da tecnologia
    ↓
relacional / documento / chave-valor / grafo / analytics / combinação

BLOCO 2 — NoSQL é uma família, não um único tipo de banco

O termo NoSQL reúne tecnologias com modelos diferentes do relacional tradicional. Elas não possuem todas as mesmas características.

BLOCO 3 — Banco de documentos

Em um banco de documentos, um registro pode ser representado por uma estrutura parecida com JSON. MongoDB, por exemplo, armazena documentos em BSON.

{
  "pedido": 501,
  "cliente": {
    "id": 7,
    "nome": "ANA"
  },
  "itens": [
    {"produto": "CADERNO", "qtd": 2, "preco": 18.90},
    {"produto": "CANETA", "qtd": 5, "preco": 3.50}
  ]
}

Dados usados juntos podem ser armazenados juntos. Isso pode ser muito conveniente, mas também exige cuidado com duplicidade, tamanho dos documentos, atualização e padrões de acesso.

BLOCO 4 — Chave-valor: acesso extremamente direto

No modelo chave-valor, uma chave identifica um valor.

sessao:usuario:42  → { dados da sessão }
produto:22:cache   → { resumo do produto }
tentativas:login:7 → 3

Esse formato combina bem com situações em que a aplicação já sabe exatamente qual chave precisa buscar. Sistemas como Redis vão além de valores simples e oferecem várias estruturas de dados, mas a ideia de chave continua central.

BLOCO 5 — Bancos de grafos: quando as relações são o centro do problema

Grafos representam dados como nós e relacionamentos, ambos podendo possuir propriedades.

(PESSOA: Ana) ──COMPRA──> (PRODUTO: Notebook)
      │
      └──CONHECE──> (PESSOA: Bruno)
                         │
                         └──COMPRA──> (PRODUTO: Mouse)

Quando a pergunta principal envolve percorrer muitas conexões — amigos de amigos, rotas, fraude, dependências ou recomendações — um banco de grafos pode tornar esse tipo de navegação mais natural.

BLOCO 6 — Bancos de colunas amplas

Bancos de colunas amplas foram projetados para grandes volumes distribuídos e padrões específicos de acesso. Em vez de começar por um modelo relacional cheio de JOINs, o desenho costuma considerar fortemente como os dados serão consultados.

BLOCO 7 — Esquema rígido, flexível e híbrido

Relacional não significa que tudo precise ser inflexível, e NoSQL não significa ausência de esquema. O MySQL 8.4, por exemplo, possui tipo de dados JSON.

CREATE TABLE produto_flexivel (
    id INT PRIMARY KEY,
    descricao VARCHAR(100) NOT NULL,
    atributos JSON
);

INSERT INTO produto_flexivel VALUES
(1, 'NOTEBOOK', JSON_OBJECT(
    'ram', '16 GB',
    'ssd', '512 GB',
    'cor', 'cinza'
));

BLOCO 8 — Como escolher entre relacional e outros modelos?

BLOCO 9 — Escala vertical e horizontal

Escalar horizontalmente pode envolver réplicas, particionamento e outras técnicas. Mas distribuição traz novos problemas: latência de rede, sincronização, falhas parciais e consistência.

BLOCO 10 — Réplica, particionamento e cache

BLOCO 11 — Consistência em sistemas distribuídos

No capítulo de transações, “consistência” apareceu dentro do ACID. Em sistemas distribuídos existe também a discussão de consistência entre cópias e nós.

Durante uma falha de comunicação entre partes de um sistema distribuído, pode ser necessário decidir entre recusar certas operações para preservar uma visão mais consistente ou continuar atendendo e aceitar temporariamente diferenças entre réplicas.

BLOCO 12 — Banco em nuvem: serviço gerenciado

Em vez de instalar e manter todo o servidor manualmente, podemos contratar um serviço gerenciado de banco. Plataformas de nuvem oferecem opções relacionais e NoSQL com automação de tarefas operacionais.

Aplicação
   ↓
serviço de banco gerenciado
   ├── infraestrutura
   ├── monitoramento
   ├── opções de backup
   ├── opções de alta disponibilidade
   └── atualização/operação conforme o serviço

BLOCO 13 — Disponibilidade e recuperação são decisões diferentes

Serviços de nuvem podem oferecer implantação em múltiplas zonas, réplicas, snapshots e restauração para um ponto no tempo. Cada recurso responde a um risco diferente.

Não escolha arquitetura apenas pela lista de recursos. Pergunte quanto tempo o sistema pode ficar indisponível e quanto dado o negócio aceita perder.

BLOCO 14 — API: a fronteira entre aplicação e dados

Navegador / App móvel / outro sistema
                 ↓ HTTPS
                API
                 ↓
        regras + autenticação
                 ↓
              Banco

A API pode validar entrada, autenticar usuários, aplicar regras, controlar transações e devolver apenas os dados necessários. Ela também evita expor diretamente credenciais e portas do banco aos clientes finais.

BLOCO 15 — OLTP e analytics: perguntas diferentes

Um banco criado para registrar pedidos não precisa ser a mesma plataforma usada para analisar bilhões de eventos históricos.

BLOCO 16 — Data warehouse, data lake e lakehouse

BLOCO 17 — Big Data: mais do que “muitos registros”

Big Data costuma ser explicado por dimensões como volume, velocidade e variedade. O ponto importante é que certas cargas ultrapassam o que uma arquitetura convencional consegue processar de modo adequado em custo, tempo ou complexidade.

sensores + cliques + transações + logs + arquivos
                    ↓
          ingestão e processamento
                    ↓
             armazenamento
                    ↓
          análise / modelos / BI

Antes de escolher ferramentas, defina a pergunta analítica. Coletar dados sem objetivo cria custo e risco, não inteligência.

BLOCO 18 — IA, embeddings e busca vetorial

Modelos de IA frequentemente trabalham com embeddings: representações numéricas que capturam características semânticas de textos, imagens ou outros dados. Embeddings podem ser comparados por similaridade.

documento
   ↓ modelo de embedding
vetor numérico
   ↓
armazenamento vetorial
   ↓ similaridade
conteúdo semanticamente próximo

Um sistema de busca vetorial não substitui automaticamente as tabelas transacionais. Um e-commerce pode manter pedido e pagamento no banco relacional e usar vetores para busca semântica de produtos ou documentos.

BLOCO 19 — RAG: IA consultando uma base de conhecimento

RAG — Retrieval-Augmented Generation combina recuperação de conteúdo relevante com geração por um modelo de linguagem.

Pergunta do usuário
       ↓
busca por conteúdo relevante
       ↓
trechos recuperados
       ↓ contexto
modelo de linguagem
       ↓
resposta baseada nesse contexto

O banco ou vector store participa da etapa de recuperação. O modelo de linguagem continua sendo outra parte da arquitetura. Qualidade dos documentos, atualização, permissões e avaliação das respostas continuam importantes.

BLOCO 20 — Dados para IA precisam de qualidade e governança

IA não corrige automaticamente dados ruins. Duplicidades, cadastros incorretos, documentos desatualizados e permissões mal definidas podem produzir resultados ruins ou exposição indevida de informação.

BLOCO 21 — Quatro cenários, quatro arquiteturas possíveis

Em sistemas maiores, essas escolhas podem coexistir. O pedido oficial pode estar no relacional, a sessão no cache, os eventos no analytics e os embeddings em uma camada vetorial.

BLOCO 22 — Checklist para escolher tecnologia

1. qual problema de negócio estamos resolvendo?
2. qual é a estrutura natural dos dados?
3. quais consultas e operações são mais importantes?
4. quais regras de integridade são obrigatórias?
5. quais operações precisam ser transacionais?
6. qual volume existe hoje e qual crescimento é plausível?
7. qual disponibilidade e recuperação são necessárias?
8. quais conhecimentos a equipe possui?
9. qual custo operacional e financeiro é aceitável?
10. como segurança, privacidade e governança serão tratadas?

BLOCO 23 — O que permanece válido em qualquer tecnologia

As ferramentas mudam. Os princípios que aprendemos durante o módulo continuam úteis:

BLOCO 24 — Fechamento do módulo

Começamos entendendo por que bancos de dados surgiram. Passamos por fundamentos, modelagem conceitual, modelo lógico, normalização, implementação, SQL, relacionamentos, administração, transações, recursos avançados e um projeto completo.

Agora também sabemos que o ecossistema de dados é maior que um único SGBD. A competência mais importante é conseguir entender o problema, estruturar os dados, preservar sua integridade e escolher conscientemente a tecnologia.