Banco de Dados I

1. O que é um banco de dados?

Um banco de dados é uma coleção organizada de informações relacionadas, estruturadas de forma que possam ser facilmente acessadas, gerenciadas e atualizadas. A palavra-chave aqui é organização: um arquivo de texto com mil linhas de dados pode conter informação, mas não é um banco de dados — falta a estrutura que permite recuperar exatamente o que você precisa em milissegundos.

Pense no Instagram: cada foto que você posta precisa ser associada ao seu perfil, ter uma lista de curtidas, comentários, tags e metadados como data e localização. Quando alguém abre o feed, o aplicativo busca em frações de segundo as publicações mais recentes de centenas de pessoas que você segue, classifica por relevância e exibe com imagens em alta resolução. Isso só é possível porque todos esses dados estão armazenados em bancos de dados cuidadosamente projetados. O mesmo raciocínio vale para um banco financeiro que precisa garantir que uma transferência debite de uma conta e credite em outra de forma atômica — sem que nenhuma das duas operações fique pela metade — ou para um e-commerce que precisa checar em tempo real se um produto está disponível em estoque antes de confirmar um pedido.

Antes dos bancos de dados, as aplicações armazenavam dados em arquivos no sistema de arquivos do sistema operacional. Esse modelo causava problemas sérios: redundância (os mesmos dados duplicados em múltiplos arquivos), inconsistência (versões diferentes do mesmo dado), dificuldade de acesso concorrente (dois programas tentando escrever no mesmo arquivo ao mesmo tempo) e ausência de segurança granular. Os bancos de dados foram criados exatamente para resolver esses problemas, fornecendo uma camada de abstração entre os dados e as aplicações que os consomem.

Bancos de dados no cotidiano

Vale listar concretamente os tipos de dados que sistemas conhecidos armazenam em bancos de dados para que a abstração fique palpável:

Evolução do armazenamento de dados

Para entender por que precisamos de bancos de dados, é instrutivo olhar para a evolução das formas de armazenar informação em sistemas computacionais. Cada salto resolveu uma limitação concreta da geração anterior — e cada solução trouxe trade-offs próprios. Compreender esse histórico ajuda a escolher a ferramenta certa para o problema atual e a evitar a tentação de "improvisar com arquivos" quando o caso pede um SGBD de verdade.

2. SGBD — Sistema Gerenciador de Banco de Dados

É fundamental distinguir duas coisas que frequentemente se confundem: o banco de dados (os dados em si, os arquivos físicos em disco) e o SGBD — Sistema Gerenciador de Banco de Dados. O SGBD é o software que gerencia o banco: ele recebe comandos, verifica permissões, garante a integridade dos dados, controla o acesso concorrente de múltiplos usuários ou aplicações, gerencia memória e cache, faz backups e recuperação em caso de falha. O banco de dados em si são os arquivos físicos no disco — sem o SGBD, você não tem como interagir com eles de forma segura e eficiente.

Um SGBD cumpre quatro funções essenciais: definição de dados (permite criar e alterar a estrutura das tabelas via DDL), manipulação de dados (permite inserir, atualizar, deletar e consultar via DML e DQL), controle de dados (gerencia permissões de acesso via DCL) e controle de transações (garante as propriedades ACID via TCL). Essas quatro funções correspondem exatamente às cinco sublinguagens do SQL, que estudaremos mais adiante neste material.

O mercado oferece vários SGBDs, cada um com características distintas. PostgreSQL é o mais robusto e completo entre os open-source, com suporte a tipos avançados (JSON nativo, arrays, geometria), extensões e conformidade rigorosa com o padrão SQL — será nossa ferramenta principal neste módulo. MySQL (e seu fork MariaDB) é amplamente usado em aplicações web de médio porte. SQLite é uma biblioteca embarcada, sem servidor separado, ideal para apps mobile e desktop. MongoDB é um banco de dados NoSQL orientado a documentos JSON, útil quando o esquema é altamente variável. A escolha do SGBD é um RNF da categoria Restrições de Design e deve ser justificada, não aleatória.

Como o SGBD garante integridade

Uma das responsabilidades mais importantes do SGBD é garantir que os dados permaneçam íntegros — consistentes com as regras do negócio. Isso é feito por meio de constraints (restrições) definidas no esquema, que o SGBD verifica a cada operação de escrita. Se uma constraint for violada, a operação é rejeitada com um erro antes de qualquer dado ser persistido. Esse mecanismo evita que a responsabilidade de validação fique 100% na camada da aplicação — que pode ter bugs ou ser bypassada diretamente via SQL por alguém com acesso ao banco.

Pipeline interno: o que acontece quando você executa uma query

Quando sua aplicação envia SELECT * FROM usuarios WHERE id = 1; ao banco, o SGBD não interpreta o texto literalmente — ele passa a query por uma sequência de estágios bem definidos. Compreender esse pipeline torna explicável por que algumas queries são rápidas e outras não, e o que tuning de banco realmente significa.

Ao escrever (INSERT, UPDATE, DELETE), o SGBD primeiro grava a operação no WAL — Write-Ahead Log e só depois aplica a mudança nas páginas de dados. Esse log sequencial é o que garante a Durabilidade do ACID: se a máquina cair logo após o COMMIT, ao reiniciar o SGBD relê o WAL e reaplica as operações que ainda não tinham chegado às páginas em disco. Backups incrementais e replicação física também usam o WAL como fonte da verdade — por isso ele é central tanto para confiabilidade quanto para alta disponibilidade.

3. Modelo Entidade-Relacionamento (ER)

Antes de escrever uma linha de SQL, precisamos modelar o problema. O Modelo Entidade-Relacionamento (ER), proposto por Peter Chen em 1976, é a linguagem gráfica padrão para representar a estrutura de informação de um sistema. Ele é independente de tecnologia: um diagrama ER pode ser implementado em PostgreSQL, MySQL, Oracle ou qualquer outro banco relacional. O modelo ER nos força a pensar sobre o que armazenar antes de pensar como.

Um diagrama ER tem três elementos fundamentais. Entidades são os "substantivos" do sistema — as coisas sobre as quais precisamos armazenar informação. Exemplos: Cliente, Produto, Pedido, Funcionário. Cada entidade tem atributos — as propriedades que descrevem cada instância dessa entidade. Um Cliente pode ter nome, email e telefone. Um Produto pode ter nome, preço e estoque. Um atributo especial é a chave primária (PK) — um atributo (ou conjunto de atributos) cujo valor identifica unicamente cada instância da entidade. Finalmente, relacionamentos são as associações entre entidades — os "verbos" do sistema. Um Cliente realiza Pedidos. Um Pedido contém Produtos.

A cardinalidade especifica quantas instâncias de uma entidade podem se relacionar com instâncias de outra. Os três tipos fundamentais são: 1:1 (um para um) — cada pessoa tem exatamente um CPF; 1:N (um para muitos) — um cliente pode ter vários pedidos, mas cada pedido pertence a um único cliente; e N:M (muitos para muitos) — um pedido pode conter vários produtos, e um produto pode aparecer em vários pedidos. Relacionamentos N:M exigem uma tabela intermediária (tabela associativa ou junction table) para serem implementados no modelo relacional.

Diagrama ER — Loja Universitária

Veja um diagrama simplificado para o sistema de loja universitária iniciado na Aula 1:

Notação de Chen — símbolos gráficos formais

A notação proposta por Peter Chen no artigo original de 1976 estabelece uma gramática visual simples e ainda hoje a referência didática para diagramas ER. Cada elemento do modelo tem uma forma geométrica específica, e linhas conectam essas formas com rótulos de cardinalidade. Conhecer a notação canônica torna você capaz de ler qualquer diagrama ER em livros, papers acadêmicos e documentação corporativa — independentemente da ferramenta usada para desenhá-lo.

Modelagem em 3 etapas: Conceitual, Lógico, Físico

Modelar um banco de dados não é uma atividade única — é um processo de refinamento progressivo do O QUE existe no domínio até o COMO implementar em um SGBD específico. A literatura clássica organiza esse processo em três níveis sucessivos, cada um com um artefato próprio e uma audiência distinta.

Por que modelar antes de criar tabelas?

Modelar em ER antes de escrever DDL tem dois benefícios principais. Primeiro, permite identificar problemas de design — entidades esquecidas, relacionamentos ambíguos, atributos mal posicionados — antes que qualquer código seja escrito. Corrigir um diagrama leva minutos; corrigir um banco de dados em produção com dados reais pode levar horas e exigir migrações complexas. Segundo, o diagrama ER é uma linguagem comum entre técnicos e não técnicos: um gerente de produto consegue entender e validar um diagrama ER mesmo sem saber SQL.

4. Modelo Relacional — Tabelas, PK e FK

O modelo relacional, proposto por Edgar F. Codd em 1970, é o modelo de dados mais amplamente usado no mundo. Toda informação é organizada em tabelas (também chamadas de relações, em homenagem ao modelo matemático de álgebra relacional). Cada tabela tem um nome único no banco, um conjunto fixo de colunas (atributos) com tipos de dados definidos, e um conjunto de linhas (tuplas), onde cada linha representa uma instância da entidade.

A chave primária (Primary Key, PK) é uma coluna (ou conjunto de colunas) que identifica unicamente cada linha da tabela. Toda tabela deve ter uma PK. O SGBD cria automaticamente um índice na PK, tornando buscas por esse campo extremamente rápidas. Em PostgreSQL, o tipo SERIAL (ou BIGSERIAL para tabelas maiores) é a forma mais comum de criar PKs numéricas auto-incrementais. Para sistemas que precisam de IDs globalmente únicos sem coordenação central, usa-se UUID.

A chave estrangeira (Foreign Key, FK) é uma coluna que referencia a PK de outra tabela, estabelecendo o relacionamento entre elas no nível físico. Quando você define uma FK no SGBD, ele passa a verificar automaticamente a integridade referencial: você não pode inserir uma linha com cliente_id = 99 em pedidos se não existir um cliente com id = 99 na tabela clientes. Também não pode deletar um cliente que ainda tem pedidos associados — a menos que configure um comportamento de cascata (ON DELETE CASCADE).

Da ER às tabelas — regras formais de tradução

A passagem do modelo conceitual (ER) para o modelo lógico (relacional) segue um conjunto compacto de regras mecânicas. Aplicá-las disciplinadamente evita os dois erros mais comuns de iniciantes: (1) esquecer a tabela associativa em N:M e (2) colocar a FK do lado errado em 1:N. Memorize essas quatro regras — elas resolvem 95% dos casos práticos.

-- Entidade USUARIO → tabela usuarios
CREATE TABLE usuarios (
  id     SERIAL       PRIMARY KEY,
  nome   VARCHAR(100) NOT NULL,
  email  VARCHAR(200) UNIQUE NOT NULL
);

-- Entidade PRODUTO → tabela produtos
CREATE TABLE produtos (
  id     SERIAL          PRIMARY KEY,
  nome   VARCHAR(100)    NOT NULL,
  preco  NUMERIC(10,2)    NOT NULL
);

-- Relacionamento 1:N "USUARIO faz PEDIDO" → FK no lado N (pedidos)
CREATE TABLE pedidos (
  id          SERIAL    PRIMARY KEY,
  data        TIMESTAMP DEFAULT NOW(),
  usuario_id  INTEGER   NOT NULL REFERENCES usuarios(id)
);

-- Relacionamento N:M "PEDIDO contém PRODUTO" → tabela associativa
-- PK composta = (pedido_id, produto_id) — ambas FKs
CREATE TABLE pedido_produto (
  pedido_id   INTEGER NOT NULL REFERENCES pedidos(id),
  produto_id  INTEGER NOT NULL REFERENCES produtos(id),
  quantidade  INTEGER NOT NULL CHECK (quantidade > 0),
  PRIMARY KEY (pedido_id, produto_id)
);

Normalização — organizando para evitar redundância

A normalização é um processo de organizar as tabelas de um banco relacional para eliminar redundância e dependências anômalas. Cada forma normal estabelece um conjunto de regras que a tabela deve obedecer. As três primeiras são as mais importantes na prática:

5. SQL — As 5 Sublinguagens

SQL (Structured Query Language) não é uma linguagem monolítica — ela é composta por cinco sublinguagens, cada uma com um propósito distinto. Essa organização existe porque diferentes papéis interagem com o banco de maneiras diferentes: um DBA gerencia estrutura e permissões; um desenvolvedor escreve DML e DQL; um sistema de monitoramento opera transações via TCL. Entender as sublinguagens é entender a separação de responsabilidades no SQL.

Cada sublinguagem opera em um nível diferente de abstração. DDL opera no nível do esquema — a estrutura que contém os dados. DML e DQL operam no nível dos dados em si — as linhas dentro das tabelas. DCL opera no nível das permissões — quem pode fazer o quê. TCL opera no nível das transações — garantindo que grupos de operações sejam executados de forma atômica. Um profissional de banco de dados competente domina todas as cinco sublinguagens e sabe quando usar cada uma.

É importante notar que alguns comandos DDL (como TRUNCATE) e os comandos DCL têm efeito imediato e implícito de COMMIT em muitos SGBDs — ou seja, não podem ser revertidos com ROLLBACK. Já os comandos DML fazem parte de transações e podem ser revertidos até o COMMIT ser executado. Essa diferença tem implicações práticas importantes: você pode corrigir um UPDATE errado com ROLLBACK, mas não pode desfazer um DROP TABLE da mesma forma.

6. DDL — Criando e Alterando Estruturas

Os comandos DDL definem o esquema do banco de dados — a estrutura que contém os dados. O mais fundamental é o CREATE TABLE, que cria uma nova tabela com suas colunas, tipos e constraints. Em PostgreSQL, cada coluna precisa de um tipo de dado que define o que pode ser armazenado nela: VARCHAR(n) para texto com limite, TEXT para texto sem limite, INTEGER e BIGINT para números inteiros, NUMERIC(p,s) para decimais precisos (use para dinheiro, nunca FLOAT), BOOLEAN para verdadeiro/falso, TIMESTAMP para datas e horas, e UUID para identificadores únicos.

O comando ALTER TABLE modifica a estrutura de uma tabela existente — adiciona ou remove colunas, altera tipos, adiciona ou remove constraints. Em produção, operações de ALTER em tabelas grandes podem travar a tabela por longos períodos (lock), por isso existem estratégias como adicionar a nova coluna como nullable primeiro, popular os dados em background e depois adicionar a constraint NOT NULL. Compreender o impacto de um ALTER é parte essencial do trabalho de um desenvolvedor de backend.

O comando DROP TABLE elimina uma tabela e todos os seus dados permanentemente. Em PostgreSQL, se a tabela tiver FKs referenciando ela de outras tabelas, você precisará usar DROP TABLE nome CASCADE (que também deleta as FKs das tabelas dependentes) ou primeiro remover as FKs manualmente. TRUNCATE é diferente: remove todas as linhas da tabela mas mantém a estrutura — e é muito mais rápido que DELETE sem WHERE porque não gera registros de undo linha a linha.

-- Cria a tabela de usuários com tipos e constraints
CREATE TABLE usuarios (
  id         SERIAL       PRIMARY KEY,
  nome       VARCHAR(100) NOT NULL,
  email      VARCHAR(200) UNIQUE NOT NULL,
  ativo      BOOLEAN      DEFAULT TRUE,
  criado_em  TIMESTAMP    DEFAULT NOW()
);

-- Cria a tabela de pedidos referenciando usuarios
CREATE TABLE pedidos (
  id          SERIAL      PRIMARY KEY,
  cliente_id  INTEGER     NOT NULL REFERENCES usuarios(id),
  status      VARCHAR(20) NOT NULL DEFAULT 'pendente',
  criado_em   TIMESTAMP   DEFAULT NOW()
);

-- Adiciona coluna a tabela existente
ALTER TABLE usuarios ADD COLUMN telefone VARCHAR(20);

-- Remove tabela (irreversível!)
DROP TABLE IF EXISTS pedidos;

7. Constraints — Garantindo a Integridade dos Dados

As constraints (restrições) são regras que o SGBD aplica automaticamente a cada operação de escrita para garantir que os dados permaneçam válidos. Elas são a primeira linha de defesa contra dados inválidos — anteriores à validação na camada de aplicação. Se o SGBD rejeitar uma operação por violação de constraint, isso é um comportamento correto: é preferível um erro explícito a dados silenciosamente incorretos no banco.

As constraints mais comuns em PostgreSQL são: NOT NULL — a coluna não pode ter valor nulo; UNIQUE — nenhuma duplicata é permitida na coluna (ou combinação de colunas); DEFAULT — valor padrão caso nenhum seja fornecido na inserção; CHECK — expressão booleana que deve ser verdadeira para a linha ser aceita; PRIMARY KEY — combinação de NOT NULL e UNIQUE, define a PK da tabela; FOREIGN KEY — referência à PK de outra tabela, garante integridade referencial. Constraints podem ser definidas inline (junto à coluna) ou como constraints de tabela (ao final do CREATE TABLE), o que permite constraints sobre múltiplas colunas ao mesmo tempo.

Um detalhe importante: NULL é diferente de zero ou string vazia — NULL significa ausência de valor. Dois NULLs não são iguais entre si (NULL diferente de NULL em SQL). Isso tem implicações em consultas com WHERE coluna = NULL (que nunca retorna resultados — use WHERE coluna IS NULL) e no comportamento de constraints UNIQUE (em muitos SGBDs, múltiplos NULLs são permitidos mesmo com UNIQUE, porque NULL é considerado diferente de NULL). PostgreSQL segue esse comportamento padrão do SQL ANSI.

CREATE TABLE produtos (
  id          SERIAL          PRIMARY KEY,
  nome        VARCHAR(150)     NOT NULL,
  sku         VARCHAR(50)      UNIQUE NOT NULL,
  preco       NUMERIC(10,2)    NOT NULL CHECK (preco > 0),
  estoque     INTEGER          NOT NULL DEFAULT 0
                                 CHECK (estoque >= 0),
  categoria   VARCHAR(50)      CHECK (categoria IN (
                                   'eletronico',
                                   'vestuario',
                                   'alimento'
                                 )),
  ativo       BOOLEAN          NOT NULL DEFAULT TRUE
);

-- Constraint de tabela: PK composta (tabela associativa N:M)
CREATE TABLE item_pedido (
  pedido_id   INTEGER NOT NULL REFERENCES pedidos(id) ON DELETE CASCADE,
  produto_id  INTEGER NOT NULL REFERENCES produtos(id),
  quantidade  INTEGER NOT NULL CHECK (quantidade > 0),
  preco_unit  NUMERIC(10,2) NOT NULL,
  PRIMARY KEY (pedido_id, produto_id)
);

8. DML — Manipulando Dados

Com a estrutura criada pelo DDL, passamos a manipular os dados com os comandos DML: INSERT, UPDATE e DELETE. Ao contrário dos comandos DDL, os comandos DML fazem parte de transações e podem ser revertidos com ROLLBACK se algo der errado. Isso é especialmente importante em operações que modificam múltiplas tabelas relacionadas, como uma transferência bancária ou um checkout de e-commerce.

O comando INSERT adiciona novas linhas a uma tabela. A forma básica insere uma linha por vez; a forma multi-linha insere várias linhas num único comando, o que é muito mais eficiente porque reduz o número de round-trips ao banco. PostgreSQL oferece a cláusula RETURNING, que retorna os valores das colunas inseridas — incluindo o id gerado pelo SERIAL — sem precisar de uma segunda consulta. Isso elimina a necessidade de um SELECT MAX(id) (que seria incorreto em ambiente concorrente) ou uma segunda busca após o INSERT.

Os comandos UPDATE e DELETE são poderosos e, portanto, perigosos sem a cláusula WHERE. Um UPDATE usuarios SET ativo = FALSE sem WHERE desativa todos os usuários. Um DELETE FROM pedidos sem WHERE apaga todos os pedidos permanentemente. Em PostgreSQL, você pode configurar a sessão para exigir WHERE em operações destrutivas, e muitas ferramentas como DBeaver e psql avisam antes de executar tais comandos. A regra prática: antes de executar qualquer UPDATE ou DELETE, primeiro rode um SELECT com o mesmo WHERE para verificar quantas e quais linhas serão afetadas.

-- INSERT básico (uma linha)
INSERT INTO usuarios (nome, email)
VALUES ('Ana Silva', 'ana@email.com');

-- INSERT múltiplo (mais eficiente)
INSERT INTO produtos (nome, sku, preco)
VALUES
  ('Camiseta Inteli', 'CAM-001', 59.90),
  ('Caderno A4',      'CAD-001', 24.90),
  ('Caneca Preta',    'CAN-001', 39.90);

-- INSERT com RETURNING (retorna o id gerado)
INSERT INTO pedidos (cliente_id, status)
VALUES (1, 'pendente')
RETURNING id, criado_em;

-- UPDATE com WHERE (sempre use WHERE!)
UPDATE usuarios
SET nome = 'Ana Costa', ativo = TRUE
WHERE id = 1;

-- DELETE com WHERE (sempre use WHERE!)
DELETE FROM usuarios
WHERE id = 1;

9. DQL — Consultando Dados

O comando SELECT é, de longe, o mais utilizado em um banco de dados — aplicações leem dados muito mais frequentemente do que escrevem. O SELECT tem uma sintaxe rica e um motor de execução sofisticado que permite desde buscas simples até análises complexas com múltiplas agregações, filtros e ordenações. Dominar o SELECT é essencial para qualquer desenvolvedor backend.

A estrutura básica de um SELECT é: SELECT colunas FROM tabela WHERE condição ORDER BY coluna LIMIT n. O WHERE filtra linhas com base em condições booleanas — você pode combinar condições com AND, OR e NOT, usar operadores de comparação (=, <, >, <>), BETWEEN para intervalos, IN para listas de valores, LIKE para padrões de texto e IS NULL / IS NOT NULL para valores ausentes. O ORDER BY ordena o resultado por uma ou mais colunas em ordem ascendente (ASC, padrão) ou descendente (DESC). O LIMIT restringe o número de linhas retornadas — crucial para paginação e para evitar retornar milhões de linhas acidentalmente em tabelas grandes.

As funções de agregação calculam um único valor a partir de múltiplas linhas: COUNT(*) conta o total de linhas, COUNT(coluna) conta linhas onde a coluna não é NULL, SUM soma valores numéricos, AVG calcula a média aritmética, MIN e MAX retornam o menor e o maior valor. Funções de agregação normalmente são usadas junto com GROUP BY, que agrupa as linhas por uma ou mais colunas antes de aplicar a função. O HAVING filtra grupos (assim como WHERE filtra linhas individuais — HAVING só pode ser usado com GROUP BY).

-- SELECT básico com WHERE, ORDER BY e LIMIT
SELECT nome, email
FROM usuarios
WHERE ativo = TRUE
  AND criado_em > '2024-01-01'
ORDER BY nome ASC
LIMIT 10;

-- DISTINCT: remove duplicatas no resultado
SELECT DISTINCT status
FROM pedidos;

-- Funções de agregação
SELECT
  COUNT(*) AS total_pedidos,
  SUM(preco_unit * quantidade) AS receita_total,
  AVG(preco_unit) AS ticket_medio,
  MIN(criado_em) AS primeiro_pedido,
  MAX(criado_em) AS ultimo_pedido
FROM pedidos
WHERE status = 'confirmado';

-- GROUP BY com HAVING: agrupa e filtra grupos
SELECT status, COUNT(*) AS qtd
FROM pedidos
GROUP BY status
HAVING COUNT(*) > 5
ORDER BY qtd DESC;

10. DCL e TCL — Controle de Acesso e Transações

Os comandos DCL controlam quem pode fazer o quê no banco de dados. GRANT concede privilégios a usuários ou roles; REVOKE remove privilégios. Os privilégios podem ser granulares: SELECT, INSERT, UPDATE, DELETE, REFERENCES (para criar FKs). O princípio do menor privilégio diz que cada usuário ou aplicação deve ter apenas os privilégios mínimos necessários para sua função. Uma API que só lê dados deve ter apenas SELECT; uma API que escreve deve ter SELECT, INSERT, UPDATE, DELETE nas tabelas relevantes — mas nunca DROP TABLE ou acesso ao schema de sistema.

Os comandos TCL controlam transações. Uma transação é um grupo de operações que deve ser executado de forma atômica: ou todas têm sucesso, ou nenhuma é persistida. BEGIN inicia a transação; COMMIT persiste todas as mudanças; ROLLBACK desfaz tudo desde o BEGIN. O exemplo clássico é a transferência bancária: você precisa debitar de uma conta E creditar em outra — se o crédito falhar após o débito ter sido realizado, o dinheiro simplesmente desapareceria. A transação garante que isso não aconteça.

As transações em bancos relacionais seguem as propriedades ACID: Atomicidade — a transação é indivisível (tudo ou nada); Consistência — a transação leva o banco de um estado válido a outro estado válido, respeitando todas as constraints; Isolamento — transações concorrentes não interferem entre si (o nível de isolamento pode ser configurado); Durabilidade — após o COMMIT, os dados são persistidos mesmo em caso de falha de hardware (o SGBD escreve em um WAL — Write-Ahead Log — antes de qualquer outra coisa).

-- DCL: conceder e revogar privilégios
GRANT SELECT ON usuarios TO leitor;
GRANT SELECT, INSERT, UPDATE, DELETE ON pedidos TO api_app;
REVOKE DELETE ON usuarios FROM api_app;

-- TCL: transferência bancária atômica
BEGIN;

UPDATE contas
SET saldo = saldo - 100.00
WHERE id = 1 AND saldo >= 100.00;

UPDATE contas
SET saldo = saldo + 100.00
WHERE id = 2;

-- Se tudo correu bem, persiste as mudanças:
COMMIT;

-- Se algo deu errado, desfaz tudo:
-- ROLLBACK;

11. Comparativo entre SGBDs Relacionais

Embora todos os SGBDs relacionais sigam o padrão SQL ANSI, cada um implementa extensões e dialetos próprios. Quando você se acostuma com um SGBD e migra para outro, os primeiros tropeços são quase sempre nos detalhes de DDL: como declarar uma chave auto-incremental, como tipar texto Unicode, como armazenar JSON. Esta seção lado a lado existe para deixar claro que o conceito (PK auto-incremental, texto, booleano, data) é universal, mas a sintaxe muda. Reconhecer essas diferenças torna você capaz de ler código de qualquer projeto sem entrar em pânico.

-- ═══ PostgreSQL 16 ═══
CREATE TABLE usuarios (
  id         SERIAL       PRIMARY KEY,
  nome       VARCHAR(100) NOT NULL,
  email      VARCHAR(200) UNIQUE NOT NULL,
  ativo      BOOLEAN      DEFAULT TRUE,
  metadata   JSONB,
  criado_em  TIMESTAMP    DEFAULT NOW()
);

-- ═══ MySQL 8 / MariaDB ═══
CREATE TABLE usuarios (
  id         INT           AUTO_INCREMENT PRIMARY KEY,
  nome       VARCHAR(100)  NOT NULL,
  email      VARCHAR(200)  NOT NULL UNIQUE,
  ativo      TINYINT(1)    DEFAULT 1,
  metadata   JSON,
  criado_em  DATETIME      DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- ═══ SQLite 3 ═══
CREATE TABLE usuarios (
  id         INTEGER       PRIMARY KEY AUTOINCREMENT,
  nome       TEXT          NOT NULL,
  email      TEXT          NOT NULL UNIQUE,
  ativo      INTEGER       DEFAULT 1,
  metadata   TEXT,                       -- JSON via JSON1
  criado_em  TEXT          DEFAULT CURRENT_TIMESTAMP
);

-- ═══ SQL Server 2022 (T-SQL) ═══
CREATE TABLE usuarios (
  id         INT            IDENTITY(1,1) PRIMARY KEY,
  nome       NVARCHAR(100) NOT NULL,
  email      NVARCHAR(200) NOT NULL UNIQUE,
  ativo      BIT            DEFAULT 1,
  metadata   NVARCHAR(MAX),
  criado_em  DATETIME2      DEFAULT GETDATE()
);

-- ═══ Oracle 23ai ═══
CREATE TABLE usuarios (
  id         NUMBER         GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  nome       VARCHAR2(100) NOT NULL,
  email      VARCHAR2(200) NOT NULL UNIQUE,
  ativo      NUMBER(1)      DEFAULT 1,
  metadata   CLOB           CHECK (metadata IS JSON),
  criado_em  TIMESTAMP      DEFAULT SYSTIMESTAMP
);

12. RM-ODP — Viewpoint Information

O RM-ODP (Reference Model for Open Distributed Processing, ISO/IEC 10746) estrutura a descrição de sistemas distribuídos em cinco viewpoints (visões). Cada visão captura os interesses de um grupo específico de stakeholders, usando uma linguagem e nível de abstração adequados a esses interesses. As cinco visões são: Enterprise (propósito e regras de negócio), Information (estrutura e fluxo de dados), Computational (decomposição funcional em componentes), Engineering (distribuição e comunicação) e Technology (escolhas concretas de tecnologia).

Esta aula foca no Viewpoint Information — a visão de informação. Esse viewpoint descreve como a informação é estruturada, como muda ao longo do tempo e quais invariantes (regras permanentes) ela deve obedecer. No contexto de banco de dados, o viewpoint de informação se traduz diretamente no modelo ER e no esquema relacional: as entidades são os objetos de informação, os atributos são suas propriedades, os relacionamentos são as associações entre eles, e as constraints são os invariantes que o sistema deve preservar em toda operação.

Quando você escreve um diagrama ER, você está produzindo a visão de informação do sistema. Quando você define as constraints na DDL (NOT NULL, UNIQUE, CHECK, FOREIGN KEY), você está codificando os invariantes de informação diretamente no SGBD. Isso é poderoso: as regras de negócio relacionadas à estrutura de dados ficam centralizadas no banco, não espalhadas pela lógica da aplicação onde podem ser esquecidas ou inconsistentes entre diferentes endpoints da API.

13. RF, RN e RNF aplicados a Banco de Dados

Toda funcionalidade que precisa persistir dados possui Requisitos Funcionais (RF) que dependem do banco de dados. Identificar essa dependência é o primeiro passo para modelar corretamente. Um RF como "o usuário deve poder visualizar seu histórico de pedidos" implica que os pedidos precisam ser armazenados com referência ao usuário, com data, status e itens — e que a consulta deve ser eficiente o suficiente para retornar em tempo aceitável mesmo com milhares de pedidos por usuário. Esse RF, ao ser implementado, exige decisões de modelagem (quais tabelas, quais colunas), de DDL (tipos e constraints) e de DQL (qual SELECT e quais índices).

As Regras de Negócio (RN) que envolvem dados frequentemente se traduzem em constraints no banco. "Um produto não pode ter estoque negativo" vira CHECK (estoque >= 0). "Um email de usuário deve ser único no sistema" vira UNIQUE NOT NULL. "Um pedido só pode ter status 'confirmado', 'pendente' ou 'cancelado'" vira um CHECK (status IN (...)). Quando a RN é simples o suficiente para ser expressa como constraint SQL, prefira o banco à aplicação — o banco a aplicará em todo acesso, de qualquer origem, incluindo scripts de manutenção e migrações.

Os Requisitos Não Funcionais (RNF) mais diretamente impactados pelo banco de dados são os de Confiabilidade, Desempenho, Segurança e Suportabilidade. A escolha de usar transações ACID (TCL) é uma decisão de RNF de Confiabilidade. A criação de índices para acelerar consultas frequentes é um RNF de Desempenho. O uso de roles com menor privilégio (DCL) é um RNF de Segurança. A estruturação das migrações de banco com ferramentas como Flyway ou Knex é um RNF de Suportabilidade que garante que o esquema possa evoluir de forma controlada e rastreável.

Os 8 eixos de RNF relevantes para Banco de Dados

14. Prática Hands-on — Crie sua primeira tabela no Supabase

Toda a teoria deste material só vira competência real quando você executa SQL contra um banco de dados de verdade. Esta seção propõe uma prática curta (~10 min) usando o Supabase — uma plataforma cloud que oferece PostgreSQL gerenciado com SQL Editor embutido no navegador. Você vai modelar uma entidade pequena do projeto e ver, no Table Editor, a tabela aparecer com os tipos e constraints que escreveu.

Passo a passo

1. Acesse supabase.com e faça login (GitHub, Google ou e-mail).
2. Crie um projeto novo ou abra o projeto da sua squad. Anote a senha do banco de dados — Supabase só mostra uma vez.
3. Abra o SQL Editor no menu lateral (ícone </>).
4. Identifique uma entidade pequena do problema que sua dupla está modelando — algo como cliente, agendamento, tarefa ou produto. Não precisa modelar o domínio inteiro.
5. Modele 3 a 5 colunas: uma PK, dois ou três campos descritivos e ao menos uma constraint útil (UNIQUE, NOT NULL ou CHECK).
6. Escreva o CREATE TABLE em PostgreSQL no editor.
7. Execute com Ctrl+Enter (ou clique em Run). Você deve ver "Success. No rows returned." se tudo deu certo.
8. Confirme em Table Editor (ícone de tabela no menu lateral) que a tabela apareceu com as colunas e tipos corretos.
9. Bônus: insira uma linha com INSERT INTO ... e rode SELECT * FROM ... para ver o registro aparecer.

-- Exemplo: tabela de clientes para uma loja universitária
CREATE TABLE clientes (
  id         SERIAL       PRIMARY KEY,
  nome       VARCHAR(120) NOT NULL,
  email      VARCHAR(200) UNIQUE NOT NULL,
  curso      VARCHAR(50)  CHECK (curso IN ('CC', 'EC', 'SI', 'ES', 'AT')),
  criado_em  TIMESTAMP    DEFAULT NOW()
);

-- Bônus: insere uma linha e consulta o resultado
INSERT INTO clientes (nome, email, curso)
VALUES ('Ana Lima', 'ana@inteli.edu.br', 'SI')
RETURNING id, nome, criado_em;

SELECT * FROM clientes;

Critério de sucesso

• ✅ A tabela aparece no Table Editor com as colunas e tipos esperados.
• ✅ A constraint UNIQUE bloqueia uma segunda inserção com o mesmo email (teste e veja o erro do PostgreSQL).
• ✅ A constraint CHECK rejeita um valor de curso fora da lista permitida.
• ✅ Você consegue explicar para sua dupla, em uma frase, por que cada constraint foi escolhida.

15. Checklist de Estudo

Clique nos itens à medida que você dominar cada conceito:

• ✓
  Consigo explicar a diferença entre banco de dados e SGBD, e citar exemplos de cada categoria.
• ✓
  Consigo desenhar um diagrama ER com entidades, atributos, relacionamentos e cardinalidades.
• ✓
  Consigo identificar quando um relacionamento é 1:1, 1:N ou N:M e o que cada um implica em termos de tabelas.
• ✓
  Consigo explicar o papel da PK e da FK e o que é integridade referencial.
• ✓
  Consigo descrever as 3 primeiras formas normais com exemplos de violação e de solução para cada uma.
• ✓
  Consigo nomear as 5 sublinguagens SQL e citar ao menos um comando de cada.
• ✓
  Consigo escrever um CREATE TABLE com tipos corretos e ao menos 4 tipos de constraint diferentes.
• ✓
  Consigo escrever INSERT (simples e múltiplo com RETURNING), UPDATE e DELETE com WHERE corretos.
• ✓
  Consigo escrever um SELECT com WHERE, ORDER BY, LIMIT e pelo menos uma função de agregação com GROUP BY.
• ✓
  Consigo explicar as 4 propriedades ACID e dar um exemplo concreto de por que cada uma é necessária.
• ✓
  Consigo escrever um bloco BEGIN/COMMIT/ROLLBACK para uma operação atômica envolvendo duas tabelas.
• ✓
  Consigo relacionar o Viewpoint Information do RM-ODP com o diagrama ER e as constraints SQL.
• ✓
  Consigo mapear RFs do sistema para entidades de banco e RNs para constraints SQL.
• ✓
  Consigo redigir RNFs de Confiabilidade, Desempenho e Segurança específicos para banco de dados, com métricas mensuráveis.
• ✓
  Consigo aplicar as 4 regras de tradução ER → tabelas (entidade → tabela; 1:1 → FK única; 1:N → FK no lado N; N:M → tabela associativa com PK composta).
• ✓
  Consigo desenhar um diagrama ER usando a notação de Chen (retângulo, losango, oval) e identificar quando o losango precisa do retângulo tracejado em volta para sinalizar N:M com atributos.
• ✓
  Consigo reconhecer pelo menos 3 diferenças sintáticas entre PostgreSQL, MySQL, SQLite, SQL Server e Oracle (PK auto-incremental, booleano, JSON).
• ✓
  Criei uma tabela no Supabase com PK, ao menos uma constraint útil, e validei o resultado no Table Editor.

Referências

• PostgreSQL Documentation — documentação oficial completa do PostgreSQL
• PostgreSQL — CREATE TABLE — referência completa de sintaxe DDL e constraints
• PostgreSQL — Transaction Isolation — níveis de isolamento e propriedades ACID
• ISO/IEC 10746 — RM-ODP — especificação do Reference Model for Open Distributed Processing
• ISO/IEC 25010 — SQuaRE Quality Model — modelo de qualidade com os eixos de RNF
• E.F. Codd — A Relational Model of Data for Large Shared Data Banks (1970) — artigo original do modelo relacional
• Peter Chen — The Entity-Relationship Model (1976) — artigo original do modelo ER
• Ramakrishnan & Gehrke — Database Management Systems, 3ª ed.