Apostila Interativa — 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 turma = '1A';

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 — quando os dados explodiram

Com a internet, surgiu um novo desafio: quantidade absurda de dados. Big Data não significa apenas “muitos dados”; envolve escala, velocidade, variedade, complexidade e geração contínua de informações.

18. O surgimento do NoSQL

Alguns problemas modernos começaram a exigir mais flexibilidade, escalabilidade extrema, armazenamento distribuído e velocidade em cenários específicos. Foi nesse contexto que surgiram os bancos NoSQL, expressão geralmente entendida como Not Only SQL: “não apenas SQL”.

Tipos de bancos NoSQL

Documento MongoDB   Chave-valor Redis   Grafos Neo4j   Colunar Cassandra

19. Cloud Computing — bancos na nuvem

Outro avanço revolucionário foi a computação em nuvem. Antes, os bancos normalmente ficavam em servidores locais. Agora eles podem funcionar pela internet, com escalabilidade, acesso remoto, alta disponibilidade, backups automatizados e elasticidade.

Exemplos modernos incluem Amazon RDS, Google Cloud SQL, Azure SQL, Firebase e Supabase.

20. Bancos de dados e Inteligência Artificial

A Inteligência Artificial moderna depende profundamente de dados organizados. Sem dados, não existe IA útil.

Um sistema de recomendação da Netflix, por exemplo, analisa filmes assistidos, tempo de visualização, avaliações, preferências e histórico do usuário. Tudo isso depende de bancos de dados.

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. Exercícios diretos

1. Explique o principal problema dos sistemas baseados em arquivos.
2. O que é redundância de dados?
3. O que é inconsistência?
4. Qual foi a principal contribuição do modelo relacional?
5. Qual a função de um SGBD?
6. Explique resumidamente a diferença entre banco relacional e banco NoSQL.

24. Perguntas reflexivas

1. Por que a sociedade moderna depende tanto de bancos de dados?
2. Quais problemas poderiam acontecer se bancos não garantissem integridade?
3. Por que apenas armazenar dados não é suficiente?
4. Por que bancos relacionais continuam importantes mesmo com NoSQL?

25. Desafio final do capítulo

26. 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, campos, chaves, integridade e estrutura relacional: os fundamentos internos dos bancos de dados modernos.

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.

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, o campo não deve guardar listas ou vários valores misturados.

Exemplo incorreto

A coluna fornecedores possui vários valores dentro de um único campo. 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)

A Segunda Forma Normal resolve 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, o campo 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.

EXERCÍCIOS — CAPÍTULO 3

Exercício 3A — Transformação do DER em tabelas

1. Explique como a entidade PRODUTO se transforma em tabela.
2. Explique como os atributos descrição, preço e quantidade aparecem no modelo lógico.
3. Explique como o relacionamento CATEGORIA 1:N PRODUTO aparece nas tabelas.

Exercício 3B — PK e FK

1. Qual é a função da PK em uma tabela?
2. Qual é a função da FK?
3. Explique por que produto.id_categoria é FK.
4. O que aconteceria se um produto apontasse para uma categoria inexistente?

Exercício 3C — Tabela associativa

1. Por que PRODUTO N:N FORNECEDOR precisa de tabela associativa?
2. Quais campos poderiam existir em produto_fornecedor?
3. Por que preco_custo pode pertencer à tabela associativa?

Exercício 3D — Redundância

1. Explique o que é redundância.
2. Por que repetir o nome da categoria dentro de produto é ruim?
3. Quais problemas podem ocorrer em uma atualização?

Exercício 3E — 1FN

1. O que significa valor atômico?
2. Por que guardar “Tech, Alpha, Mega” em uma única coluna viola a 1FN?
3. Como resolver esse problema?

Exercício 3F — 2FN

1. O que é dependência parcial?
2. Por que nome_fornecedor não deve ficar em produto_fornecedor?
3. Onde o nome do fornecedor deve ficar?

Exercício 3G — 3FN

1. O que é dependência transitiva?
2. Por que nome_cidade e estado devem ficar em uma tabela cidade?
3. Dê outro exemplo de dependência transitiva.

Exercício 3H — Desafio final

Refine o sistema comercial considerando as tabelas categoria, cidade, fornecedor, produto e produto_fornecedor.

1. Liste as PKs.
2. Liste as FKs.
3. Explique os relacionamentos.
4. Indique onde a 1FN aparece.
5. Indique onde a 2FN aparece.
6. Indique onde a 3FN aparece.
7. Explique por que esse modelo está mais organizado que uma tabela única.

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.

✅ CAPÍTULO 3 — MODELAGEM LÓGICA E NORMALIZAÇÃO OFICIALMENTE FINALIZADO

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, fornecedor e produto.

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 trabalhar com MySQL normalmente usamos o MySQL Server e alguma forma de enviar comandos. Aqui o foco pedagógico será o terminal CLI.

mysql -u root -p

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

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 três tabelas principais, respeitando a ordem correta: primeiro tabelas independentes, depois a tabela que possui FKs.

A tabela categoria nasce antes de produto porque produto depende dela. A tabela fornecedor também nasce antes de produto pelo mesmo motivo.

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

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

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

    FOREIGN KEY (id_categoria)
        REFERENCES categoria(id_categoria),

    FOREIGN KEY (id_fornecedor)
        REFERENCES fornecedor(id_fornecedor)
);

Essa estrutura implementa fisicamente o DER comercial. Produto se relaciona com categoria e fornecedor por meio das chaves estrangeiras.

SHOW TABLES;
DESCRIBE categoria;
DESCRIBE fornecedor;
DESCRIBE produto;

BLOCO 7 — INSERT INTO: inserindo todos os dados reais

Agora o banco deixa de ser apenas estrutura e começa a receber dados. Usaremos todos os dados oficiais das tabelas categoria, fornecedor e produto.

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');

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 e fornecedor, porque possui FKs apontando para elas.

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

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.

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 fornecedor;
SELECT * FROM produto;

Também podemos consultar apenas algumas colunas:

SELECT descricao, preco, qtde
FROM produto;

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.

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.

SELECT *
FROM produto
WHERE id_produto = 22;

UPDATE produto
SET preco = 6
WHERE id_produto = 22;

SELECT *
FROM produto
WHERE id_produto = 22;

UPDATE produto
SET preco = preco + 1
WHERE id_categoria = 3;

BLOCO 13 — DELETE: removendo registros

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

SELECT *
FROM produto
WHERE id_produto = 26;

DELETE FROM produto
WHERE id_produto = 26;

SELECT *
FROM produto
WHERE id_produto = 26;

Ao tentar apagar uma categoria que possui produtos vinculados, a FK pode impedir a exclusão, protegendo a integridade referencial.

BLOCO 14 — FOREIGN KEY: integridade referencial real

A FOREIGN KEY é a implementação física do relacionamento entre tabelas. Ela impede que produto aponte para categoria ou fornecedor inexistente.

INSERT INTO produto
VALUES (100, 'PRODUTO TESTE', 5, 10, 3, 4, 5);

INSERT INTO produto
VALUES (101, 'PRODUTO INVALIDO', 5, 10, 999, 4, 5);

O segundo INSERT deve falhar se a categoria 999 não existir. Isso mostra que o MySQL está protegendo o relacionamento.

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 fornecedor
    ON produto.id_fornecedor = fornecedor.id_fornecedor
ORDER BY produto.descricao;

Essa consulta une produto, categoria e fornecedor em um relatório comercial real.

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
INNER JOIN fornecedor
    ON produto.id_fornecedor = fornecedor.id_fornecedor
GROUP BY fornecedor.nome
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 e FK para proteger integridade;
• mantenha coerência entre modelagem, tabelas e comandos;
• não decore SQL sem entender a estrutura.

BLOCO 19 — Fechamento Oficial 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, INSERT, SELECT, WHERE, ORDER BY, LIKE, UPDATE, DELETE, FOREIGN KEY, JOIN, funções de agregação, GROUP BY e boas práticas.

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

✅ CAPÍTULO 4 — SQL COM MYSQL OFICIALMENTE FINALIZADO