Banco de Dados

Dois deles são consequência um do outro; comece por esse par.

Redundância descontrolada: o mesmo dado é gravado em vários arquivos, ocupando espaço e criando várias versões da verdade. Inconsistência: como nada sincroniza essas cópias, elas divergem — é consequência direta da redundância. Dependência programa-dados: o layout do arquivo está no código, então mudar o layout obriga a alterar e recompilar todos os programas. Dificuldade de acesso concorrente: sem um árbitro entre dois programas que gravam ao mesmo tempo, o arquivo corrompe.

Redundância descontrolada, inconsistência, dependência programa-dados e dificuldade de acesso concorrente.

Pergunte-se: quem avisa o outro arquivo?

O aluno comunica a mudança ao setor com que tem contato — digamos, a secretaria. O arquivo da secretaria passa a ter o telefone novo; o da biblioteca continua com o antigo, porque não existe mecanismo que propague a alteração. A biblioteca liga para cobrar um livro atrasado e não encontra o aluno. O problema é a inconsistência, causada pela redundância descontrolada: o telefone está guardado duas vezes e nada obriga as duas cópias a andarem juntas.

A biblioteca fica com o telefone desatualizado. É inconsistência, causada por redundância descontrolada.

Pense no que se faz com um log depois de escrito.

Os quatro problemas nascem da atualização de dados duplicados. Um log é append-only: cada linha é escrita uma vez e nunca alterada nem apagada. Sem atualização, não há como duas cópias divergirem — a inconsistência não tem como surgir. A redundância existe (o log repete dados que estão no banco), mas é redundância controlada e intencional, com finalidade de auditoria. A concorrência é resolvida pelo próprio sistema operacional, que garante atomicidade de escritas pequenas em modo append. E a dependência programa-dados é irrelevante porque o log não é lido por programas que dependem de seu layout, e sim por humanos e ferramentas tolerantes a formato.

Porque o log é append-only: sem atualização de dado já gravado, não há divergência entre cópias — e é justamente a atualização que gera os quatro problemas.

O que deve constar numa nota fiscal emitida em 2024 se o cliente mudou de endereço em 2025?

A cópia no pedido não é redundância descontrolada: é um dado histórico. O endereço no pedido responde a "para onde esta compra foi entregue", que é uma pergunta diferente de "onde o cliente mora hoje" — respondida pelo cadastro. Se o pedido apenas apontasse para o cadastro, atualizar o endereço do cliente reescreveria o passado, e a nota fiscal de dois anos atrás passaria a mostrar um endereço que não existia na época. Isso é redundância controlada, decidida de propósito, e o nome técnico do padrão é snapshot de dados transacionais. O colega teria razão se o campo copiado fosse usado como se fosse o dado atual — por exemplo, se a tela de cadastro do cliente lesse o endereço a partir do último pedido, ou se um relatório de mala direta usasse os endereços dos pedidos em vez do cadastro. Aí passariam a existir duas fontes disputando a mesma pergunta, que é exatamente a definição do problema.

É redundância controlada: o pedido guarda o endereço histórico da entrega, não o endereço atual do cliente. O colega só teria razão se essa cópia fosse usada para responder "onde o cliente mora hoje".

Um é conteúdo, o outro é programa.

O banco de dados é a coleção de dados inter-relacionados que representa um recorte do mundo real — é conteúdo armazenado. O SGBD é o software que gerencia essa coleção: define a estrutura, executa as consultas, controla quem acessa, arbitra o acesso simultâneo e recupera o banco depois de uma falha. Um banco pode ser migrado de um SGBD para outro; são coisas separadas.

Banco de dados é a coleção de dados; SGBD é o software que a gerencia.

Instância é o que muda quando alguém usa o sistema.

(a) Esquema — é a descrição da estrutura. (b) Instância — é o conteúdo num dado momento, e muda a cada cadastro. (c) Esquema — restrições fazem parte da descrição da estrutura, não do conteúdo.

(a) esquema; (b) instância; (c) esquema.

Índice é decisão de armazenamento.

Demonstra independência física de dados. O índice é uma estrutura de armazenamento: altera como o SGBD encontra as linhas no disco, sem alterar quais linhas existem nem quais colunas a tabela tem. Como o esquema lógico permaneceu idêntico, as consultas — escritas contra o esquema lógico — continuam válidas. Quem decide usar ou não o índice é o otimizador do SGBD, em tempo de execução; o programador nem precisa saber que ele existe.

Independência física: mudou o armazenamento, não o esquema lógico contra o qual as consultas foram escritas.

Pergunte de quem é a dependência: do SGBD ou do programa?

A independência lógica não falhou — ela foi anulada pelo programa. A promessa da independência lógica é que uma aplicação continue funcionando quando o esquema muda em partes que ela não usa. Mas SELECT * não nomeia as colunas que usa: ele pede todas e assume uma ordem posicional que o esquema não garante. O relatório, portanto, depende da estrutura física do resultado, e não do conjunto de colunas de que precisa. Com SELECT nome, cpf, cidade FROM cliente, o acréscimo de data_nascimento seria invisível para ele. A conclusão prática é que independência de dados é uma capacidade oferecida pelo SGBD, não uma garantia automática: o programa precisa escrever consultas que a aproveitem.

Não. A independência lógica existe, mas SELECT * a descarta ao depender da ordem posicional das colunas em vez de nomeá-las.

Pense no que acontece quando duas coisas ocorrem ao mesmo tempo, e no que acontece quando falta energia.

A primeira é o controle de concorrência. Reimplementá-lo exige tratar bloqueios, detectar e resolver impasses (deadlocks) e garantir níveis de isolamento entre transações — problemas que envolvem toda a combinação de operações simultâneas possíveis, e cujos erros aparecem só sob carga, de forma não determinística e quase impossível de reproduzir em teste. A segunda é a recuperação após falha. O SGBD mantém um log de transações que permite refazer o que estava confirmado e desfazer o que estava pela metade quando a energia caiu; garantir isso na aplicação significaria implementar escrita à frente do log, pontos de verificação e um protocolo de recuperação que funcione mesmo se a falha ocorrer durante a própria recuperação. Nos dois casos, o custo alto não está em escrever o caminho normal, e sim em cobrir corretamente todos os caminhos de exceção — e a consequência de errar é perda ou corrupção silenciosa de dados.

Controle de concorrência e recuperação após falha. Ambas são caras porque o difícil não é o caso normal, e sim cobrir todos os casos de exceção — cujos erros são não determinísticos e corrompem dados em silêncio.

Vá do disco para o usuário.

Interno: como os dados estão fisicamente armazenados — arquivos, blocos, índices. Conceitual: a estrutura lógica completa do banco, com entidades, atributos, relacionamentos e restrições, sem detalhes de armazenamento. Externo: as visões, cada uma expondo a um grupo de usuários apenas o recorte do conceitual que lhe interessa.

Interno (armazenamento), conceitual (estrutura lógica) e externo (visões).

Pergunte se a mudança altera o que existe ou só como se chega até ele.

(a) Nível interno: o índice é um caminho de acesso, não altera o que existe logicamente. (b) Nível conceitual: acrescentar coluna altera a estrutura lógica do banco. (c) Nível externo: a visão é um recorte para um grupo de usuários; a tabela por baixo continua com o salário.

(a) interno; (b) conceitual; (c) externo.

Como uma ferramenta de modelagem descobre quais tabelas existem no banco?

Se o catálogo é feito das mesmas estruturas que o resto do banco, então toda ferramenta que já sabe falar SQL sabe interrogá-lo, sem precisar de uma interface proprietária. É assim que ferramentas de modelagem fazem engenharia reversa de um banco existente, que geradores de código descobrem colunas e tipos, e que scripts de auditoria verificam se toda tabela tem chave primária. A alternativa — um formato binário fechado — obrigaria cada ferramenta a implementar um leitor específico por SGBD. Além disso, a uniformidade reduz o próprio SGBD: o mesmo processador de consultas serve para dados do usuário e para metadados, em vez de existirem dois mecanismos.

Porque torna os metadados acessíveis pela mesma linguagem dos dados: qualquer ferramenta que fale SQL consegue inspecionar o banco, sem interface proprietária.

Materializar é passar a guardar o resultado. O que passa a existir em dois lugares?

Uma visão comum é apenas uma consulta guardada: nada é armazenado, e a junção é refeita a cada acesso. Materializá-la significa passar a armazenar fisicamente o resultado. Em termos dos três níveis, a definição no nível externo permanece idêntica — as aplicações continuam consultando o mesmo nome, com as mesmas colunas — e a mudança acontece no nível interno, que agora guarda uma cópia pré-computada. É, portanto, um ganho obtido sem alterar nada acima, o que é exatamente a promessa da independência física. O novo problema é que o resultado passa a existir em dois lugares: nas tabelas de origem e na cópia materializada. Isso é redundância, e reintroduz o risco de inconsistência — se as tabelas base mudarem e a cópia não for atualizada, a visão devolve dado velho. A decisão a tomar passa a ser a política de atualização: sincronizar a cada alteração (correto, porém caro na escrita) ou periodicamente (barato, mas admitindo uma janela de dados desatualizados). Ou seja, troca-se tempo de consulta por consistência e custo de escrita.

A definição externa não muda; o nível interno passa a guardar o resultado pré-computado. O problema novo é a redundância: a cópia pode divergir das tabelas base, e é preciso decidir a política de atualização.

Substantivos sobre os quais se guarda informação; verbos que ligam dois deles.

Entidades: Editora, Livro, Autor. Relacionamentos: Editora publica Livro; Autor escreve Livro. As expressões "vários livros" e "um ou mais autores" indicam as cardinalidades — 1:N entre editora e livro, N:N entre autor e livro.

Entidades: Editora, Livro, Autor. Relacionamentos: publica (Editora–Livro) e escreve (Autor–Livro).

A que pergunta o modelo conceitual responde?

Porque nenhum dos dois pertence à pergunta que o modelo conceitual responde. Chave estrangeira é o mecanismo com que o modelo relacional implementa um relacionamento; num modelo conceitual o relacionamento já está representado diretamente, e antecipar a chave é misturar duas etapas. VARCHAR(80) é decisão de projeto físico, que depende do SGBD escolhido — e o modelo conceitual precisa sobreviver à troca de SGBD. Além disso, há uma razão prática: o modelo conceitual é o documento que se revisa com quem entende do negócio, e essa pessoa não tem como validar um tipo de dado, mas tem plena condição de dizer se um cliente pode ou não ter dois endereços.

Porque ambos são decisões de implementação. O conceitual descreve o domínio e precisa sobreviver à troca de SGBD e ser validável por quem entende do negócio, não de banco.

Pergunte se o endereço tem existência e identidade próprias no negócio.

Endereço como atributo está certo quando o negócio trata o endereço como uma propriedade simples do cliente, sem existência própria: cada cliente tem um endereço, ninguém precisa consultar endereços independentemente de clientes, e não há dado a guardar sobre o endereço em si. É o caso de um cadastro simples de correspondência. Endereço como entidade está certo quando ele adquire identidade própria — quando um cliente pode ter vários (cobrança, entrega, fiscal), quando dois clientes podem compartilhar o mesmo endereço, quando é preciso guardar dados sobre o endereço (coordenadas, zona de entrega, restrição de acesso) ou quando outras entidades além de cliente também se ligam a endereços. O critério não é estético: é a existência independente. Se a resposta a "faz sentido perguntar algo sobre este endereço sem falar de cliente nenhum?" for sim, é entidade.

Atributo quando o endereço é propriedade simples e única do cliente; entidade quando tem existência independente — vários por cliente, compartilhado, ou com dados próprios.

O que se perde ao pular o desenho e ir direto para a obra?

A afirmação confunde o destino com o caminho, e três consequências mostram por quê. Primeira: o modelo E-R é o artefato que se valida com o especialista do domínio, que não lê DDL. Pulando-o, o erro de entendimento do negócio só aparece quando o sistema já está escrito — e é o erro mais caro que existe, porque nenhuma correção de código o resolve. Segunda: o E-R representa relacionamentos N:N diretamente, enquanto o modelo relacional exige tabela associativa. Desenhando tabelas de saída, essa tabela associativa é inventada antes de o relacionamento ter sido compreendido, e é comum ela nascer sem os atributos que o relacionamento tinha. Terceira: decisões que no E-R são explícitas — se algo é entidade ou atributo, se um relacionamento é obrigatório — ficam implícitas no DDL, escondidas em NOT NULL e em nomes de coluna, e deixam de ser discutíveis. Dito isso, a afirmação tem um fundo legítimo: em domínios pequenos e já conhecidos, um E-R cerimonioso e cheio de notação é burocracia. A resposta madura não é abandonar a modelagem conceitual, e sim ajustar seu rigor ao tamanho do problema — um rascunho de dez minutos num quadro já colhe quase todo o benefício.

É falsa como regra: o E-R é o que se valida com o especialista do domínio, representa N:N diretamente e torna explícitas decisões que o DDL esconde. Mas o rigor da notação deve ser proporcional ao tamanho do problema.

Um deles é identificador, um é multivalorado e um é derivado.

isbn: identificador, simples, monovalorado — distingue univocamente cada livro. titulo: descritivo, simples, monovalorado. autores: descritivo, multivalorado — um livro pode ter vários. ano_publicacao: descritivo, simples, armazenado. idade_do_livro: derivado — calculado do ano de publicação em relação ao ano corrente, e por isso não deve ser armazenado.

isbn = identificador; titulo e ano_publicacao = descritivos simples; autores = multivalorado; idade_do_livro = derivado.

Procure algo cujo número recomeça do 1 dentro de cada 'pai'.

Entidade fraca é a que não tem identificador próprio e depende da existência de outra entidade — a proprietária — para ser identificada. Sua chave é a combinação de um identificador parcial com a chave da proprietária. Exemplo: Dependente de um funcionário num plano de saúde. O identificador parcial é o nome do dependente, que só é único dentro de um mesmo funcionário — existem muitos dependentes chamados "João" na empresa, mas apenas um entre os dependentes do funcionário 4021. A chave completa é, portanto, (matricula_funcionario, nome_dependente). Se o funcionário for removido, seus dependentes deixam de ter sentido e são removidos junto: a dependência é existencial, não apenas de identificação.

É a entidade sem identificador próprio, identificada por um identificador parcial mais a chave da proprietária. Ex.: Dependente, com identificador parcial nome, dentro de Funcionário.

O que acontece com o total de um pedido quando o preço do produto muda no ano seguinte?

Guardar é a decisão certa em dois casos. O primeiro é histórico: se o total for sempre recalculado a partir dos preços atuais, um pedido fechado em 2024 passa a exibir o valor de 2026 quando os preços subirem — o sistema reescreve o passado. Guardando o total (e os preços unitários praticados), o pedido registra o que de fato foi cobrado, que é um dado legal e contábil, não um cálculo. O segundo é de desempenho: um relatório que soma o faturamento de milhões de pedidos recalculando itens toda vez faz um trabalho enorme para chegar a um número que nunca mais muda. Nos dois casos a redundância deixa de ser descontrolada e passa a ser controlada — desde que a regra seja explícita: o total é congelado no fechamento do pedido e não é recalculado depois. O erro seria guardar o total e continuar permitindo edição de itens sem recalcular, aí sim criando um dado que mente em silêncio.

Quando o valor é histórico (o que foi efetivamente cobrado, imune a mudanças futuras de preço) ou quando o custo de recalcular em relatórios é proibitivo — sempre com a regra de congelamento explícita.

Pergunte se "atendimento" tem atributos e existência próprios.

A tentação é modelar um relacionamento ternário entre Médico, Paciente e Medicamento. Ele é tecnicamente possível, mas esconde um problema: a data, o diagnóstico e as observações não pertencem a nenhuma das três entidades — são propriedades do encontro. E um relacionamento ternário só admite um conjunto de atributos por combinação das três pontas, o que impede, por exemplo, que o mesmo médico atenda o mesmo paciente duas vezes prescrevendo o mesmo medicamento em datas diferentes. A alternativa melhor é promover o encontro a entidade: Atendimento, com identificador próprio, ligada a Médico (1:N) e a Paciente (1:N), e ligada a Medicamento por um relacionamento N:N que carrega dose e posologia. Isso decompõe o ternário em binários, permite repetição ao longo do tempo, dá lugar natural aos atributos do encontro e ainda torna o modelo capaz de representar um atendimento sem nenhuma prescrição — situação perfeitamente real que o ternário não conseguiria registrar, já que um relacionamento ternário exige as três pontas presentes. A regra prática que fica: quando um relacionamento tem atributos próprios e pode se repetir no tempo, ele quer ser uma entidade.

Não deve ser ternário. Atendimento deve virar entidade, ligada a Médico e Paciente por relacionamentos binários e a Medicamento por N:N — só assim cabem os atributos do encontro, a repetição no tempo e o atendimento sem prescrição.

Leia dos dois lados antes de responder.

(a) N:N — um autor escreve vários livros e um livro pode ter vários autores. (b) 1:N — um estado tem várias cidades, mas cada cidade pertence a um só estado. (c) 1:1 — uma pessoa tem um CPF e um CPF pertence a uma só pessoa.

(a) N:N; (b) 1:N; (c) 1:1.

Pense na coluna da chave estrangeira.

Participação total significa cardinalidade mínima 1: toda ocorrência da entidade obrigatoriamente participa do relacionamento. Participação parcial significa mínima 0: a ocorrência pode existir isolada. No banco, a diferença aparece na chave estrangeira: participação total vira NOT NULL, participação parcial permite NULL. Se um pedido tem participação total no relacionamento com cliente, a coluna cliente_id é NOT NULL e o SGBD passa a recusar qualquer tentativa de gravar pedido sem dono — a regra de negócio deixa de depender da aplicação lembrar de validá-la.

Total = mínima 1 = chave estrangeira NOT NULL; parcial = mínima 0 = chave estrangeira aceita NULL.

De quem é a nota: do aluno, da disciplina, ou de outra coisa?

A nota não pertence ao aluno nem à disciplina. Colocada em Aluno, haveria uma nota só, e o aluno cursa várias disciplinas. Colocada em Disciplina, haveria uma nota só para a turma inteira. A nota pertence ao encontro entre os dois — é atributo do relacionamento matricula-se, que é N:N. No modelo E-R ela se desenha ligada ao losango do relacionamento. Na tradução para o relacional, o relacionamento N:N vira uma tabela associativa (matricula), cuja chave primária é o par (aluno_id, disciplina_id), e a nota é uma coluna comum dessa tabela. A regra geral que fica: todo atributo que só faz sentido quando as duas pontas estão presentes é atributo do relacionamento, não das entidades.

No relacionamento matricula-se, como atributo de relacionamento — que vira coluna da tabela associativa (aluno_id, disciplina_id, nota).

Toda pessoa tem passaporte?

A crítica principal é factual: participação total do lado de Pessoa afirma que toda pessoa cadastrada tem passaporte, o que é falso na esmagadora maioria dos domínios. O correto seria (0,1) do lado da pessoa e (1,1) do lado do passaporte — todo passaporte pertence a alguém, mas nem toda pessoa tem passaporte. Modelado como está, ou o cadastro de pessoa fica impossível sem antes emitir um passaporte, ou a regra é ignorada na implementação e o modelo passa a mentir sobre o sistema. Há ainda a questão estrutural: quando um 1:1 tem participação total dos dois lados, as duas entidades sempre aparecem juntas e a recomendação usual é fundi-las numa só tabela, já que separá-las só acrescenta uma junção sem ganho. As exceções legítimas para manter separado são duas: quando os dados têm requisitos de segurança diferentes (dados sensíveis numa tabela com permissão restrita) e quando têm frequências de acesso muito diferentes (um bloco grande e raramente lido separado do núcleo consultado o tempo todo). Neste caso concreto, porém, nada disso se aplica — o problema real é que a cardinalidade mínima do lado da pessoa está simplesmente errada.

A participação total do lado de Pessoa está errada: deveria ser (0,1), pois nem toda pessoa tem passaporte. E 1:1 total dos dois lados normalmente pede fusão numa tabela só, salvo separação por segurança ou por frequência de acesso.

O que é comum sobe; o que distingue fica.

Cria-se a entidade genérica Pessoa, com nome, CPF e endereço. Aluno e Professor tornam-se especializações: Aluno acrescenta matrícula e semestre; Professor acrescenta titulação e regime de trabalho. A cobertura é parcial se a universidade puder cadastrar pessoas que não sejam nem aluno nem professor (um visitante, por exemplo), e a disjunção é compartilhada se alguém puder ser aluno e professor ao mesmo tempo — situação real em pós-graduação.

Pessoa (nome, CPF, endereço) como genérica; Aluno (matrícula, semestre) e Professor (titulação, regime) como especializações.

São duas perguntas independentes.

(a) Cobertura total e disjunção exclusiva: todo veículo é carro ou moto, e nenhum é os dois. (b) Cobertura parcial, porque existem funcionários fora das duas categorias, e disjunção exclusiva, porque ninguém acumula os papéis. O enunciado de (b) informa exatamente as duas dimensões — é assim que elas devem ser levantadas com o cliente: perguntando "existe algum que não seja nenhum dos dois?" e "pode ser os dois ao mesmo tempo?".

(a) total e exclusiva; (b) parcial e exclusiva.

Compare o que cada solução preserva do modelo original.

As duas soluções resolvem o mesmo problema e produzem, na prática, tabelas muito parecidas. A agregação é preferível quando se quer preservar no modelo a informação de que aquilo é um relacionamento entre duas entidades, e não um conceito autônomo do domínio — o vínculo entre equipamento e defeito continua sendo um vínculo, e a agregação o mantém legível como tal, com sua cardinalidade explícita. Transformar em entidade é preferível quando o conceito ganha nome próprio no vocabulário do negócio, atributos próprios e identidade independente: quando as pessoas passam a falar em "a ocorrência", "o chamado", "o atendimento", o conceito já se emancipou e insistir na agregação torna o diagrama mais difícil de ler do que precisaria. O critério prático é linguístico: se o negócio tem um substantivo para aquilo, é entidade; se só consegue descrevê-lo como "a ligação entre X e Y", é agregação.

Agregação quando o vínculo continua sendo um relacionamento e se quer preservar isso no modelo; entidade quando o conceito ganha nome próprio, atributos e identidade no vocabulário do negócio.

Pense em quantas colunas nulas e quantas junções cada opção produz.

A primeira estratégia é a tabela única com coluna discriminadora: uma tabela Produto com o tipo e todas as colunas de todas as especializações. Com 12 especializações e até 8 atributos cada, chega-se a algo em torno de 60 colunas, das quais cada linha preenche poucas — o resto é NULL. A consulta fica simples e sem junção, mas a integridade se perde: nada impede gravar um livro com prazo de validade, porque a coluna existe para todos, e restrições NOT NULL tornam-se impossíveis nos atributos específicos. A segunda é uma tabela por especialização, sem tabela para a genérica: cada tipo com suas colunas próprias mais as comuns repetidas. Ganha-se integridade e não há coluna nula, mas perde-se a genérica — listar todos os produtos exige UNION de 12 tabelas, e nenhuma chave estrangeira consegue apontar para "um produto qualquer". A terceira é uma tabela para a genérica e uma para cada especializada, ligadas por chave primária compartilhada. Não há coluna nula, a integridade específica é declarável, existe uma tabela Produto para as chaves estrangeiras apontarem, e listar tudo é ler uma tabela só. O custo é uma junção sempre que se quer o registro completo de um tipo. Com 12 especializações e atributos numerosos, recomendo a terceira: os problemas das outras duas crescem com o número de especializações, enquanto o custo da terceira é constante — uma junção — e é o mais fácil de aceitar. A primeira só se justificaria com poucas especializações e pouquíssimos atributos próprios.

Tabela única gera ~60 colunas quase sempre nulas e impede restrições; tabela por especializada impede referenciar "um produto qualquer" e exige UNION. Com 12 especializações, recomendo genérica + uma por especializada com chave compartilhada: custo fixo de uma junção.

A que não consegue depende de conhecer o negócio.

Faz automaticamente: converter o modelo conceitual em lógico aplicando as regras de transformação; gerar o script DDL para o SGBD escolhido; validar a estrutura do modelo, acusando entidade sem identificador ou chave estrangeira órfã; e fazer engenharia reversa de um banco existente. Não consegue: dizer se o modelo representa corretamente o negócio — uma cardinalidade errada ou uma entidade esquecida produzem um modelo perfeitamente válido e completamente errado.

Faz: conversão conceitual→lógico, geração de DDL, validação estrutural, engenharia reversa. Não faz: verificar se o modelo corresponde ao negócio.

Siga o diagrama até a última seta descendente.

Na geração do DDL. Até o modelo lógico, tudo é vocabulário do modelo relacional — tabelas, colunas, chaves — que vale para qualquer SGBD relacional. É na geração do script que se escolhe o produto, e aí entram tipos específicos (SERIAL do PostgreSQL contra AUTO_INCREMENT do MySQL), sintaxe de restrição e detalhes de armazenamento. A consequência prática é boa: como a dependência aparece só no último passo, migrar de SGBD não exige remodelar nada — basta gerar o DDL de novo escolhendo outro destino. É a independência de tecnologia sendo preservada até o momento em que deixar de preservá-la se torna inevitável.

Na geração do DDL. Como é o último passo, trocar de SGBD não exige remodelar: basta regerar o script para o novo destino.

O que existe no conceitual que não tem representação no banco?

Porque a conversão do conceitual para o lógico perde informação, e o que se perde não pode ser recuperado do banco. Uma generalização, por exemplo, vira tabelas ligadas por chave — mas uma tabela ligada a outra por chave compartilhada é indistinguível, no catálogo, de um relacionamento 1:1 comum; nada no banco diz "isto era uma hierarquia". Um relacionamento N:N vira tabela associativa, e no catálogo essa tabela é apenas mais uma tabela com duas chaves estrangeiras — pode ser um N:N traduzido ou uma entidade legítima do domínio. Um atributo multivalorado vira tabela, e no banco fica idêntico a uma entidade fraca. A engenharia reversa consegue reconstruir com fidelidade o que está declarado no catálogo — tabelas, colunas, tipos, chaves — porque isso é exatamente o modelo lógico. O conceitual exigiria adivinhar a intenção que produziu aquela estrutura, e várias intenções diferentes produzem a mesma estrutura. Na prática, ferramentas oferecem uma reconstrução conceitual aproximada, que serve de ponto de partida e precisa ser corrigida à mão por quem entende do domínio.

Porque a conversão conceitual→lógico perde informação: generalização, N:N e atributo multivalorado produzem no banco estruturas indistinguíveis de outras coisas. Várias intenções geram o mesmo DDL, e o catálogo não guarda a intenção.

Qual dos dois artefatos é a verdade hoje?

O primeiro problema é que o modelo virou documentação falsa, que é pior do que não ter documentação: quem consulta o diagrama toma decisões com base numa estrutura que não existe mais, e não tem como saber disso. O segundo é que a decisão de projeto se perdeu — as alterações feitas direto no banco não têm registro de por que foram feitas, e um ano depois ninguém sabe se aquela coluna nova é essencial ou resquício de um experimento. O terceiro é que regerar o banco a partir do modelo tornou-se impossível sem destruir dados, o que na prática significa que ambientes novos (teste, homologação) não podem mais ser criados a partir do artefato oficial. Quanto ao processo, a primeira coisa é decidir qual artefato é a fonte da verdade, e para um banco em produção há um ano a resposta honesta é o banco. Portanto: fazer engenharia reversa para reconstruir o modelo lógico a partir do estado atual, revisá-lo à mão para reintroduzir o que a reversa não recupera, e versioná-lo junto com o código. Daí em diante, adotar migrations — arquivos de alteração versionados, aplicados em ordem, cada um com sua justificativa na mensagem de commit — de modo que a estrutura do banco passe a ter histórico e a ser reproduzível em qualquer ambiente. O modelo gráfico deixa de ser a fonte da verdade e passa a ser documentação gerada, atualizada por engenharia reversa a cada release, o que elimina a possibilidade de ele divergir de novo.

O modelo virou documentação falsa, as decisões se perderam e não se cria mais ambiente novo a partir dele. Processo: reversa para reconstruir o modelo, adotar migrations versionadas como fonte da verdade, e regenerar o diagrama a cada release.

Um conta colunas, o outro conta linhas.

O grau é 4, porque a relação tem quatro atributos: codigo, descricao, preco e categoria. A cardinalidade é 250, porque há 250 tuplas. O grau faz parte do esquema e muda só quando a estrutura é alterada; a cardinalidade faz parte da instância e muda a cada INSERT ou DELETE.

Grau 4, cardinalidade 250.

Quem decide a ordem, e quando?

Não impor ordem no armazenamento libera o SGBD para escolher, em cada consulta, a estratégia de acesso mais rápida — ler pela ordem física, por um índice, ou em paralelo por várias partições. Se a relação tivesse ordem intrínseca, toda leitura teria de respeitá-la e essas otimizações seriam impossíveis. A ordem passa a ser uma decisão de consulta, expressa por ORDER BY, e cada consulta pede a sua: o mesmo dado sai ordenado por nome num relatório e por data em outro, sem que nada seja reorganizado no disco. É separar o que o dado é do modo como ele é apresentado — e é limitação apenas para quem escreve consulta contando com uma ordem que nunca foi prometida.

Porque libera o SGBD a escolher a melhor estratégia de acesso e transfere a ordenação para a consulta, onde cada uma pede a ordem que precisa.

Relação é conjunto; tabela é o que o produto implementa.

Contradiz, sim, e é uma das aproximações em que tabela deixa de ser relação. Por ser conjunto, uma relação não admite elemento repetido — duas tuplas idênticas são a mesma tupla. A tabela SQL, porém, é formalmente um multiconjunto (bag): admite duplicatas, e o padrão SQL assumiu isso deliberadamente, porque eliminar duplicatas exige ordenar ou construir tabela de dispersão a cada operação, e cobrar esse custo de toda consulta seria inaceitável. Daí a linguagem oferecer o controle explícito: SELECT devolve duplicatas por padrão e SELECT DISTINCT as remove quando se quer o comportamento de conjunto; UNION elimina duplicatas e UNION ALL as preserva, sendo o segundo mais rápido justamente por não precisar verificar. A consequência prática é que duas linhas idênticas são indistinguíveis e, portanto, impossíveis de atualizar ou excluir separadamente — não há como escrever um WHERE que atinja uma e não a outra. É exatamente por isso que declarar chave primária não é formalidade: é o que devolve à tabela a propriedade que faz dela uma relação.

Contradiz: a tabela SQL é multiconjunto, não conjunto, por decisão de desempenho. O efeito prático é que linhas idênticas não podem ser atualizadas nem excluídas separadamente — motivo pelo qual a chave primária é indispensável.

O que se ganha e o que se perde ao guardar estrutura dentro de uma célula?

Formalmente, uma coluna JSON ou ARRAY viola a atomicidade e, portanto, a primeira forma normal — o valor deixa de ser indivisível para o modelo. Na prática, isso não invalida o modelo relacional; mostra que os produtos foram além dele em pontos específicos, e cada um desses pontos tem um custo que é preciso conhecer. O que se perde é considerável: o SGBD não valida a estrutura interna do documento, então nada impede que uma linha guarde um campo com um nome e a linha seguinte com outro; não há chave estrangeira apontando para dentro do JSON, então a integridade referencial não alcança o conteúdo; consultar por um valor interno exige sintaxe específica do produto, o que reintroduz dependência de tecnologia; e a atualização parcial normalmente reescreve o documento inteiro. O que se ganha é a capacidade de armazenar estrutura genuinamente variável sem modelá-la. O critério de uso decorre disso. Use JSON quando a estrutura for realmente heterogênea e desconhecida em tempo de projeto — atributos que variam por fabricante num catálogo, corpo de webhook recebido de terceiros, respostas de formulário dinâmico — e quando o conteúdo for lido como um bloco, sem necessidade de consulta ou integridade sobre suas partes. Não use como atalho para não criar uma tabela: se você consulta o conteúdo, filtra por ele, ordena por ele ou precisa que ele referencie outra tabela, o dado é relacional e está no lugar errado. A regra prática mais útil é a pergunta: preciso de índice, chave estrangeira ou restrição sobre isso? Se sim, é tabela.

Viola a 1FN, mas não invalida o modelo — é extensão com custo: sem validação de estrutura, sem integridade referencial interna e com sintaxe proprietária. Use para estrutura genuinamente variável lida em bloco; se precisa de índice, FK ou restrição sobre o conteúdo, é tabela.

Qual atributo não repete nunca?

A única chave candidata é {isbn}, porque o ISBN identifica univocamente uma edição de um livro. Título pode repetir entre livros diferentes, autor publica vários livros, editora publica muitos e ano é compartilhado por milhares. Combinações como {titulo, autor, ano} podem parecer únicas, mas não há garantia — o mesmo autor pode lançar duas edições no mesmo ano. A chave primária é, portanto, isbn.

Candidata única: {isbn}, que é também a chave primária.

A palavra que diferencia é mínima.

Superchave é qualquer conjunto de atributos que identifique univocamente uma tupla, independentemente de conter atributos desnecessários. Chave candidata é uma superchave mínima: retirar qualquer atributo dela faz perder a unicidade. Em aluno(matricula, cpf, nome, semestre), o conjunto {matricula, nome} é superchave, porque conhecidos matrícula e nome identifica-se exatamente uma tupla. Não é candidata, porém, porque {matricula} sozinha já identifica — nome é supérfluo. Toda chave candidata é superchave; a recíproca é falsa.

Superchave identifica; candidata identifica e é mínima. {matricula, nome} é superchave mas não candidata, pois {matricula} basta.

O que acontece com o faturamento de 2024 quando alguém apaga um cadastro?

O problema é a perda irreversível de dado histórico e financeiro. Excluir um cliente apaga automaticamente todos os seus pedidos, e com eles — se o cascade continuar propagando — os itens desses pedidos. O faturamento de exercícios passados muda retroativamente, relatórios já emitidos deixam de ser reproduzíveis e obrigações fiscais de guarda de documentos são violadas. Pior: a operação parece bem-sucedida, ninguém recebe erro e a perda só é notada quando alguém compara um relatório novo com um antigo. A alternativa correta tem duas partes. A primeira é trocar por ON DELETE RESTRICT, de modo que o banco recuse excluir cliente com pedidos — o erro aparece na hora, para quem tentou, e não meses depois. A segunda é reconhecer que o negócio raramente quer mesmo excluir um cliente: quer pará-lo de aparecer nas telas. Isso é exclusão lógica, uma coluna ativo ou excluido_em que a aplicação filtra, preservando o dado e todo o histórico. As duas juntas resolvem: o CASCADE some, o RESTRICT protege contra o acidente, e a exclusão lógica atende à necessidade real que motivava a exclusão física.

CASCADE apaga o histórico de vendas junto com o cadastro, retroativamente e sem erro. Alternativa: ON DELETE RESTRICT para proteger, mais exclusão lógica (coluna ativo) para atender à necessidade real de "sumir da tela".

Quem mais escreve nesse banco, além da aplicação?

O argumento falha no pressuposto de que a aplicação é o único caminho até o dado, e ela nunca é. Escrevem no banco também os scripts de importação e carga inicial, o DBA em manutenção emergencial, ferramentas de BI e ETL, jobs agendados, o sistema legado que ainda não foi desligado e a próxima aplicação que alguém escreverá sem ler o código desta. Cada um desses caminhos teria de reimplementar as mesmas validações, e basta um esquecer para o dado inconsistente entrar — e uma vez dentro, ele fica, porque nada o remove. Há também a concorrência: validar na aplicação significa consultar se o cliente existe e depois inserir o pedido, e entre as duas operações outra transação pode excluir o cliente. Só uma restrição verificada pelo SGBD dentro da transação fecha essa janela; código de aplicação, por mais correto que seja, não consegue. Quanto ao desempenho, o custo existe e é conhecido: a verificação de chave estrangeira exige uma busca na tabela referenciada, barata quando há índice na chave primária — que sempre há — e é por isso que o problema real costuma ser a falta de índice na coluna da chave estrangeira, não a restrição em si. Além disso, a comparação honesta não é entre validar no banco e não validar: é entre validar no banco e validar na aplicação, e a segunda faz a mesma consulta, só que sem a garantia transacional e com uma ida e volta de rede a mais. O ganho de tirar a restrição é, portanto, menor do que parece, e o preço é abrir mão da única garantia que vale para todos os caminhos. A conclusão prática: valide nos dois lugares — na aplicação para dar mensagem de erro decente ao usuário, no banco porque é lá que a garantia é real.

A aplicação nunca é o único caminho até o dado (importações, DBA, ETL, jobs, sistemas futuros), e só a restrição no SGBD fecha a janela de concorrência entre verificar e inserir. O custo é uma busca por índice que já existe. Valide nos dois: na aplicação pela mensagem, no banco pela garantia.

É 1:N. De que lado vai a chave estrangeira?

É um relacionamento 1:N, com o lado N em Funcionario. Pela regra do 1:N, a chave estrangeira vai na relação do lado N. Resultado: departamento(codigo, nome) e funcionario(matricula, nome, codigo_departamento), com codigo_departamento sendo chave estrangeira para departamento(codigo). Como a cardinalidade mínima do lado do funcionário indica que todo funcionário pertence a um departamento, a coluna é NOT NULL.

departamento(codigo, nome); funcionario(matricula, nome, codigo_departamento NOT NULL → departamento).

Cuidado: o par (medico, paciente) basta como chave?

O N:N gera uma relação própria: consulta(crm, cpf_paciente, data, diagnostico), com crm referenciando medico e cpf_paciente referenciando paciente. A chave primária, porém, não pode ser apenas (crm, cpf_paciente): isso impediria que o mesmo médico atendesse o mesmo paciente mais de uma vez, o que é irreal. A data precisa entrar na chave, resultando em (crm, cpf_paciente, data). Se houver mais de uma consulta no mesmo dia, nem isso basta, e o caminho é reconhecer que Consulta é uma entidade com identidade própria e dar-lhe uma chave artificial (id), mantendo as duas chaves estrangeiras como colunas comuns. Esse é o sinal, visto na aula 5, de que o relacionamento quer ser entidade.

consulta(crm, cpf_paciente, data, diagnostico) com PK (crm, cpf_paciente, data) — e, se houver mais de uma no mesmo dia, promover Consulta a entidade com id próprio.

A chave da proprietária entra na chave da fraca.

A chave primária da entidade fraca combina a chave da proprietária com o identificador parcial: (matricula, nome). A chave estrangeira para funcionario deve ter ON DELETE CASCADE, porque a dependência é existencial — dependente sem funcionário não significa nada.

CREATE TABLE dependente (
  matricula       INTEGER     NOT NULL,
  nome            VARCHAR(80) NOT NULL,
  data_nascimento DATE,
  parentesco      VARCHAR(30),
  PRIMARY KEY (matricula, nome),
  FOREIGN KEY (matricula) REFERENCES funcionario(matricula)
    ON DELETE CASCADE
);

Repare que matricula desempenha dois papéis ao mesmo tempo: é parte da chave primária e é chave estrangeira. É exatamente isso que caracteriza a tradução de uma entidade fraca.

PK composta (matricula, nome), com matricula sendo também FK para funcionario e ON DELETE CASCADE pela dependência existencial.

Tente decompor e veja qual informação some.

A conversão é direta: um relacionamento ternário sempre vira uma relação própria com as chaves das três entidades. Resulta fornecimento(cnpj_fornecedor, codigo_produto, id_projeto, quantidade), com chave primária composta pelas três colunas e três chaves estrangeiras. Quanto à decomposição, a tentativa produziria três tabelas binárias: fornecedor_produto (quem fornece o quê), produto_projeto (o que vai para qual projeto) e fornecedor_projeto (quem atende qual projeto). O problema é que essas três tabelas juntas não conseguem reconstruir o fato original. Suponha que o fornecedor A forneça parafusos e porcas, que o projeto X use parafusos e porcas, e que A atenda X e Y. As três binárias ficam satisfeitas, mas não há como distinguir se A forneceu parafusos para X e porcas para Y, ou parafusos para Y e porcas para X, ou tudo para os dois. A informação que se perde é justamente a associação simultânea das três pontas, que é a única coisa que o ternário afirma. Há ainda um segundo problema: a quantidade é atributo da combinação dos três, e nas binárias não haveria onde colocá-la sem repeti-la ou perdê-la. A regra prática que fica: um ternário só é decomponível quando a associação das três pontas for consequência das associações duas a duas — o que é raro, e precisa ser verificado caso a caso, não presumido.

fornecimento(cnpj_fornecedor, codigo_produto, id_projeto, quantidade) com PK tripla. Não decompõe porque as três binárias não distinguem qual produto foi de qual fornecedor para qual projeto, e não há onde alojar a quantidade.

1FN pergunta só sobre atomicidade e grupos repetitivos.

Sim, está em 1FN: todos os valores são atômicos e não há grupos repetitivos nem colunas numeradas. A tabela tem outros problemas — nome_curso depende de curso, e não da matrícula, o que é uma dependência transitiva e viola a 3FN —, mas a 1FN pergunta apenas sobre atomicidade. É um lembrete importante: estar em 1FN não significa estar bem modelado, significa apenas ter passado pela primeira das três verificações.

Sim, está em 1FN (valores atômicos, sem grupos repetitivos), embora viole a 3FN por dependência transitiva.

Pergunte, para cada atributo, de que ele depende de fato.

As dependências são: (num_pedido, cod_produto) → quantidade, porque a quantidade depende da combinação — é a quantidade daquele produto naquele pedido; e cod_produto → desc_produto, porque a descrição depende apenas do produto, independentemente do pedido. A segunda é uma dependência parcial: desc_produto depende de parte da chave, não dela inteira. É exatamente essa dependência parcial que viola a 2FN e que motiva separar produto numa tabela própria.

(num_pedido, cod_produto) → quantidade (total) e cod_produto → desc_produto (parcial, viola a 2FN).

O que a 1FN proíbe além de valor não atômico?

A 1FN proíbe duas coisas: valores não atômicos e grupos repetitivos. As três colunas são atômicas individualmente, mas formam um grupo repetitivo — o mesmo atributo conceitual, telefone, replicado em posições numeradas. Os sintomas mostram que é o mesmo defeito de guardar tudo numa célula. Primeiro, há um limite arbitrário: o cliente com quatro telefones não cabe, e acrescentar telefone4 é alteração de esquema para um fato que deveria ser um simples INSERT. Segundo, há desperdício: a maioria das linhas deixa colunas nulas. Terceiro, e mais grave, a consulta fica antinatural — buscar quem tem determinado número exige WHERE telefone1 = ? OR telefone2 = ? OR telefone3 = ?, que precisa de três índices e ainda assim é difícil de otimizar. Quarto, a posição passa a ter significado que ninguém definiu: telefone1 é o principal? E se o cliente apagar o primeiro, o segundo sobe? A raiz de tudo é a mesma: a multiplicidade foi codificada na estrutura da tabela, em vez de virar linhas, que é o único lugar onde o modelo relacional sabe representar quantidade variável.

Porque a 1FN proíbe também grupos repetitivos, e as três colunas são o mesmo atributo replicado. O resultado é limite artificial, colunas nulas, consulta com OR entre colunas e significado indefinido para a posição.

As anomalias dependem de uma operação específica. Qual?

As três anomalias são anomalias de escrita: a de atualização acontece ao alterar, a de exclusão ao apagar, a de inserção ao inserir. Nenhuma delas se manifesta em leitura. Isso explica a aparente contradição, porque os dois ambientes têm padrões de uso opostos. Um banco transacional (OLTP) recebe escritas o tempo todo, vindas de muitas transações concorrentes, e é exatamente ali que as anomalias custam caro — por isso se normaliza. Um data warehouse (OLAP) é carregado em lote, por um processo de ETL controlado, e depois é só lido, por consultas que agregam milhões de linhas. Ali, a anomalia de atualização praticamente não existe, porque ninguém atualiza linha a linha; e o custo que domina é o das junções, que a normalização multiplica. Desnormalizar troca um problema que não se tem por um ganho que se tem. Há três condições que tornam a troca legítima, e vale enunciá-las porque é a ausência delas que transforma desnormalização em bagunça: a carga precisa ser controlada por um processo único e reproduzível, de modo que a consistência seja garantida na origem e não na tabela; o dado precisa ser histórico e imutável, para que não haja atualização a propagar; e é preciso existir a fonte normalizada da qual o warehouse é derivado, para que ele possa ser reconstruído se estiver errado. Um banco transacional desnormalizado "para evitar junção" não cumpre nenhuma das três, e por isso a comparação com o warehouse não o justifica.

As três anomalias são de escrita, e o warehouse quase só lê: é carregado em lote por ETL e depois consultado. A troca é legítima porque há carga controlada, dado histórico imutável e uma fonte normalizada da qual ele deriva — condições que um OLTP desnormalizado não cumpre.

O que é preciso existir para haver dependência parcial?

Não pode. A 2FN proíbe dependência parcial, que é a dependência de parte da chave. Com chave simples, não existe "parte da chave" — ou o atributo depende da chave inteira, ou não depende dela. Portanto toda relação em 1FN com chave primária simples está automaticamente em 2FN. Isso torna a verificação da 2FN necessária apenas em relações com chave composta, o que é uma economia útil ao normalizar um esquema grande.

Não. Sem chave composta não há "parte da chave", logo não há dependência parcial possível.

Procure o que depende de coluna que não é chave.

As dependências são: matricula → nome, cod_depto, cod_cargo; cod_depto → nome_depto; cod_cargo → nome_cargo, salario_base. A chave é simples (matricula), então a 2FN já está satisfeita. As duas últimas dependências são transitivas e violam a 3FN. Decompondo:

funcionario(matricula, nome, cod_depto, cod_cargo)
departamento(cod_depto, nome_depto)
cargo(cod_cargo, nome_cargo, salario_base)

O ganho é imediato: reajustar o salário-base de um cargo passa a ser uma linha alterada em cargo, e não uma alteração em todos os funcionários daquele cargo — com o risco de deixar um para trás.

funcionario(matricula, nome, cod_depto, cod_cargo); departamento(cod_depto, nome_depto); cargo(cod_cargo, nome_cargo, salario_base).

O preço do item é o mesmo que o preço do produto?

Não viola, e a razão é que são dois atributos diferentes com nomes parecidos. O preço na tabela de produto é o preço atual de venda; o preço no item de pedido é o preço praticado naquela venda, naquele momento. Este último depende genuinamente do par (num_pedido, cod_produto): o mesmo produto vendido em dois pedidos diferentes pode ter preços diferentes, se houve reajuste ou desconto entre eles. Portanto a dependência é total, não parcial, e a 2FN está satisfeita. Este caso é importante porque mostra o limite da verificação puramente mecânica: olhando só os nomes das colunas, preco_unitario parece depender de cod_produto, e um normalizador desatento o extrairia — destruindo o histórico de preços e fazendo notas fiscais antigas mudarem de valor quando a tabela de produtos fosse atualizada. A dependência funcional é uma afirmação sobre o significado dos dados no domínio, não sobre os nomes das colunas, e só quem conhece o domínio consegue determiná-la. O sinal de que a modelagem está correta aqui é justamente o oposto do que a intuição sugere: a repetição do preço entre pedidos não é redundância, é registro histórico.

Não viola: o preço praticado na venda depende do par (pedido, produto), não só do produto. É dependência total, e a repetição entre pedidos é registro histórico, não redundância.

Quem garante que a tabela de CEP está completa e correta?

A situação em que manter é correto tem a ver com a origem e a completude do dado. A dependência cep → cidade, estado só vale se o sistema tiver uma base de CEPs completa e mantida atualizada. Se ela não existe — e manter uma base de CEPs nacional exige atualização periódica junto aos Correios —, então extrair a tabela cria uma chave estrangeira que não consegue ser satisfeita: o cliente informa um CEP novo, que não está na base, e ou o cadastro é bloqueado por um dado que não é responsabilidade dele, ou a chave estrangeira precisa aceitar nulo, e aí a normalização não entregou a integridade que a justificava. Há um segundo argumento, de natureza histórica: o endereço registrado num cadastro pode precisar preservar o que foi informado na época, e faixas de CEP mudam. Nesse caso cidade e estado no cadastro não são derivados do CEP atual, e sim registro do que se declarou — o mesmo raciocínio do preço praticado na venda. Um terceiro argumento é operacional: se o sistema é local e atende uma cidade só, a tabela de CEP resolve um problema que não existe. A decisão madura costuma ser híbrida e vale a pena enunciá-la: manter cidade e estado na tabela de cliente como o que foi declarado, e usar a base de CEPs, quando houver, como serviço de preenchimento e validação na entrada, e não como chave estrangeira obrigatória. Assim se ganha a conveniência sem transformar a completude de uma base externa em pré-requisito para cadastrar cliente.

Quando não há base de CEPs completa e mantida (a FK ficaria insatisfazível), quando o endereço precisa registrar o que foi declarado na época, ou quando o alcance é local. O caminho usual é manter os campos e usar a base de CEP como validação na entrada, não como FK.

Três restrições ao todo.

CREATE TABLE categoria (
  id   SERIAL      PRIMARY KEY,
  nome VARCHAR(60) NOT NULL UNIQUE
);

PRIMARY KEY já implica NOT NULL e UNIQUE em id, então não é preciso declará-los. Em nome, NOT NULL e UNIQUE são independentes e ambos necessários: sem NOT NULL, seria possível gravar categoria sem nome; sem UNIQUE, duas categorias com o mesmo nome.

CREATE TABLE categoria (id SERIAL PRIMARY KEY, nome VARCHAR(60) NOT NULL UNIQUE);

Some 0,10 + 0,20 em ponto flutuante.

Porque FLOAT é ponto flutuante binário e não representa exatamente frações decimais. O valor 0,1 não tem representação finita em base 2, do mesmo modo que 1/3 não tem em base 10; o que se armazena é uma aproximação. Somando 0,10 + 0,20 obtém-se 0,30000000000000004, e o erro se acumula a cada operação. Em dinheiro isso é inaceitável: totais não fecham, comparações de igualdade falham e o balanço fica com centavos de diferença que ninguém consegue explicar. NUMERIC (ou DECIMAL) é aritmética decimal exata: armazena os dígitos e a posição da vírgula, e 0,10 + 0,20 dá exatamente 0,30. A regra é usar NUMERIC para qualquer valor que precise ser exato — dinheiro, quantidades contábeis — e reservar FLOAT para grandezas científicas, em que a aproximação já faz parte da medida.

FLOAT é binário e aproxima frações decimais, acumulando erro (0,10+0,20 = 0,30000000000000004). NUMERIC é decimal exato — obrigatório para dinheiro.

Obrigatória e única exigem cuidados diferentes.

Não é possível acrescentar de uma vez, e o UNIQUE traz uma dificuldade que o NOT NULL não tem: não existe valor de preenchimento genérico, porque preencher todas as linhas com o mesmo texto violaria a unicidade. A sequência é:

-- 1. acrescenta permitindo nulo (UNIQUE aceita vários nulos)
ALTER TABLE cliente ADD COLUMN cpf CHAR(11);

-- 2. já declara a unicidade: nulos não conflitam entre si
ALTER TABLE cliente ADD CONSTRAINT uq_cliente_cpf UNIQUE (cpf);

-- 3. preenche as 5.000 linhas com os CPFs reais
--    (carga a partir de outra fonte; não há valor genérico possível)

-- 4. só depois de tudo preenchido
ALTER TABLE cliente ALTER COLUMN cpf SET NOT NULL;

O ponto que costuma ser esquecido é o passo 3: ele não é um comando, é um projeto. Enquanto ele não termina, o passo 4 falha, e o esquema fica num estado intermediário em que a aplicação precisa tolerar cpf nulo. Por isso essa alteração se planeja com a área de negócio antes de tocar no banco.

ADD COLUMN cpf CHAR(11) nulo; ADD CONSTRAINT UNIQUE (nulos não conflitam); carregar os CPFs reais de uma fonte externa; e só então SET NOT NULL.

Compare uma regra estável com uma que muda a cada trimestre.

O critério decisivo é a estabilidade da regra, e não sua natureza. Regras que decorrem do significado do dado — quantidade positiva, percentual entre 0 e 100, data de fim posterior à de início, situação dentro de um conjunto fechado — praticamente não mudam ao longo da vida do sistema, e declará-las como CHECK dá três ganhos: valem para todos os caminhos de escrita, inclusive importações e correções manuais; são verificadas dentro da transação, sem janela de concorrência; e documentam o domínio no próprio esquema, onde quem chega depois vai olhar. Regras voláteis são o caso oposto. Um CHECK que fixa o desconto máximo em 30% precisa de ALTER TABLE toda vez que a diretoria mudar a política, e ALTER TABLE em produção é evento planejado, não configuração — a regra estaria codificada no lugar mais caro de alterar. Pior: regras assim costumam ter exceções (desconto maior mediante aprovação), e um CHECK não sabe de aprovações. Essas pertencem à aplicação, ou a uma tabela de parâmetros. Há ainda um terceiro grupo que não cabe em CHECK por limitação técnica: regras que dependem de outras tabelas ou do estado anterior — "o total do pedido não pode exceder o limite de crédito do cliente" envolve consulta a outra tabela, algo que CHECK não faz de forma confiável em nenhum SGBD. Essas exigem gatilho ou lógica de aplicação dentro de transação. A síntese prática: declare no banco o que é invariante do dado, deixe na aplicação o que é política de negócio, e reconheça que regras entre tabelas são um terceiro caso, que nenhum dos dois resolve sozinho.

Declare como CHECK o que é invariante do dado (quantidade positiva, percentual 0–100, domínio fechado): vale para todo caminho de escrita e documenta o esquema. Deixe na aplicação as políticas voláteis e as que admitem exceção. Regras que dependem de outras tabelas não cabem em CHECK e exigem gatilho ou transação.

Nomeie as colunas.

INSERT INTO categoria (id, nome) VALUES (7, 'Periféricos');

O texto vai entre aspas simples, que é o delimitador de literal do SQL padrão; aspas duplas identificam objetos, não valores. Se a coluna id fosse SERIAL, o correto seria omiti-la e deixar o banco gerar: INSERT INTO categoria (nome) VALUES ('Periféricos').

INSERT INTO categoria (id, nome) VALUES (7, 'Periféricos');

São duas condições no WHERE.

UPDATE produto
   SET preco = preco * 0.95
 WHERE categoria_id = 2
   AND preco > 500;

O cálculo usa o valor corrente da própria coluna, então não é preciso consultar antes. As duas condições ligadas por AND restringem a linhas que satisfaçam ambas. Convém rodar antes o SELECT com o mesmo WHERE para conferir quantas linhas serão afetadas.

UPDATE produto SET preco = preco * 0.95 WHERE categoria_id = 2 AND preco > 500;

Um é DML, o outro é DDL.

Quanto ao efeito imediato, ambos deixam a tabela vazia, mas por caminhos diferentes. DELETE é DML: percorre as linhas, registra cada remoção no log de transações, dispara gatilhos de exclusão e respeita chaves estrangeiras, recusando a operação se houver linhas dependentes. TRUNCATE é DDL: descarta as páginas de dados de uma vez, sem percorrer linha a linha, sem disparar gatilhos e, em vários SGBDs, sem verificar dependências a menos que se peça CASCADE. Quanto ao desempenho, a diferença é grande em tabelas volumosas — DELETE de dez milhões de linhas gera dez milhões de entradas de log e pode levar minutos, enquanto TRUNCATE é praticamente instantâneo porque não registra linha nenhuma. Quanto à reversibilidade, DELETE é transacional em qualquer SGBD e um ROLLBACK o desfaz; TRUNCATE, por ser DDL, provoca commit implícito na maioria dos produtos e é irreversível — PostgreSQL é a exceção notável, onde TRUNCATE é transacional. Há ainda um detalhe frequentemente esquecido: TRUNCATE costuma reiniciar sequências de autoincremento, e DELETE não. Na prática, use DELETE quando houver WHERE, quando gatilhos precisarem disparar ou quando a operação precisar ser desfeita; use TRUNCATE para esvaziar tabelas de carga e de teste, onde o volume importa e a reversibilidade não.

DELETE é DML: linha a linha, com log, gatilhos, respeito a FK e ROLLBACK possível. TRUNCATE é DDL: descarta tudo de uma vez, sem gatilhos, muito mais rápido, normalmente irreversível e reinicia sequências.

O que acontece entre o SELECT e o UPDATE?

O problema é uma condição de corrida clássica. Com uma unidade em estoque e duas transações simultâneas, ambas executam o SELECT e leem 1; ambas concluem que há estoque suficiente; ambas executam o UPDATE subtraindo 1; o estoque termina em -1. Nenhuma das duas fez nada errado isoladamente — o defeito está na janela entre a leitura e a escrita, durante a qual a informação lida deixou de ser verdadeira sem que a transação soubesse. Envolver os dois comandos numa transação não resolve sozinho: em nível de isolamento READ COMMITTED, que é o padrão da maioria dos SGBDs, a transação B ainda enxerga o valor confirmado antes de A escrever. Há três correções válidas. A primeira, e a mais robusta, é declarar a regra no esquema: CHECK (quantidade >= 0). Assim o segundo UPDATE falha com erro de restrição, e o estoque negativo torna-se impossível por construção, para qualquer caminho de escrita. A segunda é eliminar a janela fazendo a verificação dentro do próprio UPDATE: UPDATE estoque SET quantidade = quantidade - 1 WHERE produto_id = 10 AND quantidade >= 1 — a condição é avaliada no momento da escrita, com a linha bloqueada, e o comando afeta zero linhas quando não há estoque, o que a aplicação detecta pela contagem de linhas afetadas. A terceira é bloquear a linha na leitura com SELECT ... FOR UPDATE, forçando a segunda transação a esperar a primeira terminar; funciona, mas serializa o acesso e custa concorrência. A recomendação prática é combinar a primeira com a segunda: o CHECK como garantia final e o UPDATE condicional como caminho normal, verificando sempre quantas linhas foram afetadas antes de confirmar a venda.

Condição de corrida: as duas transações leem 1 antes de qualquer escrita e ambas subtraem. Corrija com CHECK (quantidade >= 0) no esquema e UPDATE ... WHERE quantidade >= 1, conferindo as linhas afetadas — ou SELECT ... FOR UPDATE, ao custo de serializar.

Projeção, seleção e ordenação.

SELECT descricao, preco
  FROM produto
 WHERE preco > 200
 ORDER BY preco DESC;

A lista após o SELECT é a projeção, o WHERE é a seleção e DESC inverte a ordem padrão, que é crescente.

SELECT descricao, preco FROM produto WHERE preco > 200 ORDER BY preco DESC;

O que resulta de comparar algo com desconhecido?

Porque NULL representa valor desconhecido, e comparar qualquer coisa com desconhecido produz desconhecido — nem verdadeiro nem falso. O WHERE só aceita a linha quando a condição é verdadeira, então linhas com e-mail nulo são descartadas junto com todas as outras, e a consulta devolve zero linhas sempre. O correto é WHERE email IS NULL, operador criado exatamente para testar a ausência de valor sem recorrer a comparação.

Porque comparação com NULL resulta em desconhecido, que o WHERE descarta. Use IS NULL.

IN e BETWEEN deixam isso curto.

SELECT descricao, preco, categoria_id
  FROM produto
 WHERE categoria_id IN (2, 5, 8)
   AND preco BETWEEN 50 AND 300
 ORDER BY descricao;

IN substitui três condições ligadas por OR e BETWEEN substitui duas comparações, incluindo os extremos 50 e 300. ORDER BY sem qualificador é ascendente, que é a ordem alfabética pedida.

SELECT descricao, preco, categoria_id FROM produto WHERE categoria_id IN (2,5,8) AND preco BETWEEN 50 AND 300 ORDER BY descricao;

Quantos clientes têm cidade em branco?

Os clientes com cidade nula desapareceram do relatório. A comparação cidade <> 'Porto Alegre' avalia, nessas linhas, desconhecido <> 'Porto Alegre', cujo resultado é desconhecido — e o WHERE descarta o que não é verdadeiro. O resultado é que o cliente sem cidade cadastrada não aparece nem entre os de Porto Alegre nem entre os que não são, e a soma dos dois relatórios fica menor que o total do cadastro. A correção depende do que o negócio quer dizer. Se cidade desconhecida deve contar como "não é de Porto Alegre", escreve-se WHERE cidade <> 'Porto Alegre' OR cidade IS NULL. Se deve ser tratada à parte, o relatório precisa de uma terceira categoria, explícita. O que não se pode é deixar como está, porque a omissão é silenciosa: ninguém recebe erro, e o problema só aparece quando alguém confere os totais. A lição geral é que toda condição de desigualdade sobre coluna que admite nulo precisa de uma decisão consciente sobre os nulos — e é bom motivo para declarar NOT NULL sempre que o domínio permitir.

Linhas com cidade NULL somem, porque a desigualdade avalia desconhecido e o WHERE a descarta. Corrija com OR cidade IS NULL, ou trate os nulos como categoria própria.

Como um índice ordenado encontra uma palavra que pode estar no meio?

Um índice B-tree armazena os valores ordenados, e essa ordenação só ajuda quando se conhece o início do texto procurado. Com LIKE 'Teclado%', o SGBD desce a árvore até o primeiro valor que começa com "Teclado" e percorre a partir dali — trabalho proporcional ao número de acertos. Com LIKE '%teclado%', o trecho pode estar em qualquer posição, o prefixo é desconhecido e não há por onde começar a descida; resta ler todas as linhas e testar uma a uma, o que é varredura completa e cresce linearmente com o tamanho da tabela. Quando a busca por trecho é requisito, há três caminhos. O primeiro, e o mais indicado quando se busca palavras, é usar busca textual de verdade: índice de texto completo, que tokeniza o conteúdo em palavras e indexa cada uma, permitindo encontrar "teclado" onde quer que esteja, com tratamento de radicais e acentos. O segundo, para busca por trecho arbitrário e não por palavra, é um índice de trigramas, que indexa todas as sequências de três caracteres e transforma a busca por substring em busca indexada. O terceiro, quando o volume é pequeno ou a busca é rara, é aceitar a varredura — otimizar o que não dói é desperdício. O que não funciona é criar um índice B-tree comum na coluna e esperar que ele ajude: ele será simplesmente ignorado pelo otimizador, que sabe que não serve.

Porque o curinga inicial impede usar a ordenação do índice B-tree, forçando varredura completa. Soluções: índice de texto completo para busca por palavra, índice de trigramas para trecho arbitrário, ou aceitar a varredura se o volume for pequeno.

Uma junção interna pela chave estrangeira.

SELECT p.descricao, c.nome AS categoria
  FROM produto   p
  JOIN categoria c ON c.id = p.categoria_id;

A junção casa a chave estrangeira categoria_id com a chave primária de categoria. Como se usou JOIN sem qualificador, a junção é interna: produtos sem categoria não apareceriam.

SELECT p.descricao, c.nome FROM produto p JOIN categoria c ON c.id = p.categoria_id;

LEFT JOIN mais IS NULL.

SELECT p.codigo, p.descricao
  FROM produto     p
  LEFT JOIN item_pedido i ON i.produto_id = p.id
 WHERE i.produto_id IS NULL;

O LEFT JOIN preserva todos os produtos; os que nunca apareceram em item de pedido ficam com as colunas de item nulas, e o WHERE filtra exatamente esses. É o padrão de busca de órfãos, e funciona com qualquer par de tabelas ligadas por chave estrangeira.

SELECT p.codigo, p.descricao FROM produto p LEFT JOIN item_pedido i ON i.produto_id = p.id WHERE i.produto_id IS NULL;

Em que momento o WHERE é avaliado?

O WHERE é avaliado depois da junção, sobre o resultado dela. Os clientes sem pedido chegam a esse resultado, mas com todas as colunas de pedido nulas, inclusive situacao. A condição p.situacao = 'pago' avalia então NULL = 'pago', que é desconhecido, e o WHERE descarta a linha. O efeito prático é que o LEFT JOIN foi anulado: o resultado é idêntico ao de um INNER JOIN, sem que nenhum erro seja emitido. A correção é mover a condição para o ON:

SELECT c.nome, p.id
  FROM cliente c
  LEFT JOIN pedido p
    ON p.cliente_id = c.id
   AND p.situacao = 'pago';

No ON, a condição faz parte do critério de casamento: clientes sem pedido pago simplesmente não encontram par e permanecem na saída com colunas nulas. A regra geral que vale memorizar: numa junção externa, condição sobre a tabela preservada vai no WHERE; condição sobre a tabela opcional vai no ON. Trocar isso de lugar muda o resultado sem mudar a aparência da consulta.

O WHERE age após a junção, e as linhas sem par têm situacao NULL, que a comparação descarta — anulando o LEFT JOIN. Mova a condição para o ON.

Quantas linhas passa a ter cada pedido se o cliente tem três telefones?

O problema é a multiplicação de linhas provocada por junções com relacionamentos de cardinalidade N em ramos independentes. Antes, cada item de pedido gerava uma linha, e a soma dos valores estava correta. Ao acrescentar a junção com telefone, cada linha existente passou a ser combinada com cada telefone daquele cliente: um cliente com três telefones faz cada item aparecer três vezes, e a soma triplica. O ponto importante é que não há erro de sintaxe nem de condição de junção — a junção com telefone está correta, casando cliente_id com cliente_id. O que aconteceu é que a consulta passou a percorrer dois caminhos N a partir do mesmo cliente (itens de um lado, telefones do outro), e a junção produz o produto cartesiano entre eles dentro de cada cliente. É uma armadilha especialmente perigosa porque o valor errado é plausível: ninguém desconfia de um faturamento maior. Há três saídas. A mais simples é não juntar: se os telefones não são usados na agregação, tirá-los da consulta e buscá-los separadamente. Se forem necessários na mesma saída, a segunda opção é agregar antes de juntar, calculando o total por cliente numa subconsulta e só então juntar com telefone — assim o total já está pronto e a multiplicação não o atinge. A terceira, quando se quer apenas um telefone, é reduzir o ramo a no máximo uma linha, escolhendo o telefone principal com uma subconsulta correlacionada. O diagnóstico geral: sempre que uma agregação envolver mais de um caminho N a partir da mesma entidade, o resultado está inflado até prova em contrário.

Dois ramos N a partir do mesmo cliente (itens e telefones) geram produto cartesiano entre si: cada item se repete uma vez por telefone e a soma multiplica. Corrija removendo a junção desnecessária ou agregando numa subconsulta antes de juntar.

Uma linha por categoria.

SELECT categoria_id,
       COUNT(*)   AS quantidade,
       AVG(preco) AS preco_medio
  FROM produto
 GROUP BY categoria_id;

categoria_id aparece no SELECT fora de função de agregação, então precisa constar do GROUP BY — sem isso o SGBD recusa a consulta, porque não haveria valor único a exibir para o grupo.

SELECT categoria_id, COUNT(*), AVG(preco) FROM produto GROUP BY categoria_id;

Pense na ordem de execução.

WHERE filtra tuplas individuais antes do agrupamento; HAVING filtra grupos depois da agregação. A consulta que conta pedidos por cliente somente de 2026 ilustra a diferença. Com WHERE p.data >= '2026-01-01', apenas pedidos de 2026 entram nos grupos, e COUNT devolve quantos pedidos cada cliente fez em 2026 — clientes sem pedido em 2026 nem aparecem. Se a mesma condição fosse posta em HAVING, ela seria avaliada sobre grupos já formados com todos os pedidos de todos os anos, e p.data nem estaria disponível como valor único do grupo, resultando em erro ou em um filtro sobre um valor arbitrário. Além da diferença de resultado, há a de desempenho: o WHERE reduz o volume antes de agrupar, e o HAVING agrupa tudo para descartar depois.

WHERE filtra linhas antes de agrupar; HAVING filtra grupos após agregar. Filtrar data no HAVING agruparia todos os anos antes de descartar — resultado diferente e mais lento.

Cada forma conta uma coisa diferente.

COUNT(*) devolve 100: conta tuplas, sem olhar o conteúdo de coluna nenhuma, então os nulos entram. COUNT(email) devolve 70: conta apenas os valores não nulos da coluna, descartando os 30 nulos. COUNT(DISTINCT email) devolve 65: parte dos 70 não nulos e elimina as 5 repetições, contando cada valor uma única vez. A distinção importa muito em relatórios: perguntar "quantos clientes temos" pede COUNT(*), "quantos informaram e-mail" pede COUNT(email) e "quantos e-mails diferentes temos para envio" pede COUNT(DISTINCT email). Usar um pelo outro produz números plausíveis e errados.

COUNT(*) = 100; COUNT(email) = 70; COUNT(DISTINCT email) = 65.

São dois problemas diferentes: quem aparece e o que aparece na coluna.

A consulta é:

SELECT c.nome,
       COUNT(p.id)             AS pedidos,
       COALESCE(SUM(p.total),0) AS faturado
  FROM cliente c
  LEFT JOIN pedido p ON p.cliente_id = c.id
 GROUP BY c.id, c.nome
 ORDER BY faturado DESC;

O primeiro cuidado é a junção externa. Com INNER JOIN, o cliente sem pedido não encontra par e desaparece antes mesmo do agrupamento; o LEFT JOIN o preserva, com as colunas de pedido nulas. O segundo cuidado é o tratamento do nulo resultante. Para esse cliente, o grupo contém uma única linha, com p.id e p.total nulos: COUNT(p.id) devolve 0 corretamente, porque conta valores não nulos — e é por isso que se usa COUNT(p.id) e não COUNT(*), que devolveria 1 e diria que o cliente fez um pedido. Já SUM(p.total) devolve NULL, não zero, porque não há valor algum a somar; COALESCE converte isso no zero que a diretoria pediu. Vale notar que os dois cuidados são independentes e ambos silenciosos: esquecer o LEFT JOIN omite clientes sem aviso, e usar COUNT(*) inventa um pedido que não existe. Um terceiro cuidado, se houver mais junções, é o da aula anterior: nenhum outro ramo N pode entrar na consulta, sob pena de multiplicar as somas.

LEFT JOIN para preservar quem não comprou; COUNT(p.id) — nunca COUNT(*), que devolveria 1 — e COALESCE(SUM(p.total), 0), porque SUM de conjunto vazio é NULL.

CREATE VIEW ... AS SELECT.

CREATE VIEW vw_produto_caro AS
SELECT codigo, descricao, preco
  FROM produto
 WHERE preco > 1000;

A visão não guarda linha nenhuma: guarda esta consulta. Um produto que sofra reajuste e ultrapasse 1.000 passa a aparecer nela automaticamente, sem que nada precise ser recalculado.

CREATE VIEW vw_produto_caro AS SELECT codigo, descricao, preco FROM produto WHERE preco > 1000;

Não basta criar a visão.

CREATE VIEW vw_funcionario_publico AS
SELECT id, nome, setor FROM funcionario;

REVOKE ALL ON funcionario TO consulta;   -- ou: FROM consulta
GRANT SELECT ON vw_funcionario_publico TO consulta;

O passo que costuma ser esquecido é o REVOKE. Criar a visão não restringe nada por si só: se o usuário mantiver privilégio de SELECT sobre a tabela funcionario, basta consultá-la diretamente para ver os salários, e a visão vira apenas uma conveniência. A proteção existe justamente na combinação — negar a tabela e conceder a visão.

CREATE VIEW com as três colunas; REVOKE ALL ON funcionario do usuário; GRANT SELECT na visão. Sem o REVOKE, não há proteção alguma.

Quantas linhas de origem cada linha da visão representa?

Porque não existe mapeamento único de volta para as tuplas de origem. Tome vw_faturamento(cliente_id, faturado), definida como SUM(total) agrupado por cliente. Se o cliente 1 tem cinco pedidos somando 4.000 e alguém executa UPDATE ... SET faturado = 5000 WHERE cliente_id = 1, o SGBD precisaria decidir como distribuir os 1.000 de diferença entre os cinco pedidos: tudo no primeiro? no último? proporcionalmente? criando um sexto pedido? Todas as opções são defensáveis e nenhuma está na consulta — a informação necessária para desfazer a agregação simplesmente não existe. É por isso que o padrão SQL restringe a atualizabilidade a visões em que cada linha da visão corresponde a exatamente uma linha de uma única tabela base: só nesse caso a alteração tem destino inequívoco. Quando é preciso oferecer escrita através de uma visão complexa, o caminho é declarar explicitamente a regra de mapeamento por meio de um gatilho INSTEAD OF, que intercepta a operação e executa, em seu lugar, o comando que o programador determinou. Aí a ambiguidade deixa de existir porque alguém a resolveu à mão.

Porque cada linha da visão resume várias da origem e não há como saber como distribuir a alteração entre elas. Só é resolvível declarando a regra num gatilho INSTEAD OF.

Quem mais fala com o banco além da aplicação?

O argumento a favor da visão é o mesmo da integridade declarada no banco, discutido na aula 10: a aplicação não é o único caminho até o dado. Ferramentas de BI, scripts de extração, o cliente SQL do analista e o sistema seguinte que ninguém previu falam com o banco diretamente, e um controle implementado apenas na aplicação não os alcança. Com visão mais GRANT/REVOKE, a restrição vale para toda conexão, qualquer que seja a ferramenta, porque é o SGBD que a aplica. Há um segundo ganho: a regra fica declarada num lugar inspecionável — é possível auditar quem tem acesso a quê consultando o catálogo, o que não se consegue lendo código de aplicação espalhado. As limitações também são reais. Visões controlam bem o acesso por coluna e por linha estática, mas ficam desconfortáveis quando a regra depende do usuário conectado de forma dinâmica — "cada vendedor vê apenas seus clientes" exige funções de sessão dentro da visão, e a solução moderna para isso é segurança em nível de linha, não visão. Além disso, uma camada espessa de visões sobre visões dificulta a otimização e a depuração, e o número de objetos a manter cresce rápido. Também não substituem controle de acesso funcional: quem pode aprovar um pedido, quem pode cancelar uma venda, isso é regra de aplicação e não se expressa como privilégio de tabela. A conclusão prática é que não são alternativas concorrentes, e sim camadas complementares: o banco garante o que é acesso a dado, a aplicação garante o que é permissão de ação, e a primeira é a que continua valendo quando alguém abre um cliente SQL.

Visão + GRANT vale para toda conexão, inclusive BI, scripts e acesso manual, e é auditável no catálogo — a aplicação só protege o próprio caminho. Mas não cobre regra dinâmica por usuário (caso de row-level security) nem permissão de ação. São camadas complementares.

Uma seleção dentro de uma projeção.

π descricao, preco ( σ preco > 500 (produto) ). Lê-se de dentro para fora: primeiro a seleção escolhe as tuplas com preço acima de 500, depois a projeção escolhe os dois atributos. Escrever na ordem inversa — projetar antes e selecionar depois — seria inválido aqui, porque após projetar apenas descricao e preco o atributo preco ainda existiria, mas em geral projetar antes pode remover justamente o atributo de que a seleção precisa.

π descricao, preco ( σ preco > 500 (produto) )

Relação é conjunto; tabela é o quê?

Porque operam sobre estruturas diferentes. Na álgebra, o resultado de qualquer operação é uma relação, e relação é conjunto no sentido matemático — não admite elemento repetido. Projetar apenas a coluna cidade de uma tabela de clientes devolve, portanto, cada cidade uma única vez. Em SQL, a tabela e o resultado de consulta são multiconjuntos, que admitem repetição, e o SELECT preserva todas as ocorrências. A razão da escolha do SQL é de desempenho: eliminar duplicatas exige ordenar o resultado ou construir uma tabela de dispersão, custo que seria cobrado de toda consulta, inclusive das que não se importam com repetição. Por isso a eliminação é opcional e explícita, com DISTINCT — e o mesmo raciocínio explica UNION eliminar duplicatas enquanto UNION ALL, mais rápido, as preserva.

Porque a álgebra opera sobre conjuntos e o SQL sobre multiconjuntos. Eliminar duplicatas custa ordenação ou dispersão, e o SQL tornou esse custo opcional via DISTINCT.

O custo da junção depende de quê?

O custo de uma junção cresce com o tamanho das relações de entrada — no pior caso, uma varredura aninhada processa o produto das cardinalidades. Aplicar a seleção antes reduz uma das entradas, e a redução se propaga: com um milhão de pedidos dos quais cinquenta mil são de 2026, filtrar primeiro faz a junção trabalhar com vinte vezes menos tuplas, e o ganho aparece também em memória, em leitura de disco e no volume intermediário que precisa ser mantido. Filtrar depois obriga a construir o resultado completo da junção para então descartar quase tudo — trabalho feito para ser jogado fora. Há situações em que não faz diferença. A primeira, e a mais comum na prática, é que o otimizador já aplica essa transformação sozinho: escrever a consulta "na ordem certa" não muda nada, porque o plano é o mesmo. A segunda é quando a seleção é pouco seletiva — se o filtro mantém 95% das tuplas, antecipá-lo economiza pouco e ainda custa uma passagem a mais. A terceira é quando a condição não pode ser antecipada por definição: um predicado que envolve colunas das duas tabelas, como p.data > c.data_cadastro, só é avaliável depois que as tuplas foram casadas. E há o caso já visto na aula 17, em que antecipar não é apenas inútil mas errado: numa junção externa, mover a condição da tabela opcional para antes da junção muda o resultado, transformando LEFT em INNER.

Porque o custo da junção cresce com o tamanho das entradas, e filtrar antes encolhe o que será processado. Não faz diferença quando o otimizador já faz isso, quando o filtro é pouco seletivo, ou quando o predicado envolve colunas das duas tabelas e só é avaliável depois do casamento.

O que muda num banco sem ninguém alterar código?

A primeira hipótese, e a mais provável, é a mudança de plano por estatísticas desatualizadas. O volume dos dados cresceu ou sua distribuição mudou, e o otimizador passou a decidir com informação velha — trocando, por exemplo, um Index Scan por um Seq Scan, ou invertendo a ordem de junção. Investiga-se com EXPLAIN ANALYZE, comparando as linhas estimadas com as reais: divergência grande confirma a hipótese, e a correção é atualizar as estatísticas com ANALYZE. A segunda é o crescimento puro do volume: a consulta sempre foi ineficiente, mas com poucos dados isso não aparecia. Compara-se a cardinalidade atual das tabelas com a de meses atrás e observa-se se o plano contém alguma operação cujo custo cresce mais que linearmente. A terceira é a degradação física: em bancos com controle de versão de linhas, atualizações e exclusões deixam versões mortas que continuam sendo lidas; o sintoma é uma tabela ocupando muito mais espaço do que o volume de dados justifica, e a correção é a manutenção de rotina (VACUUM ou equivalente) e a reconstrução de índices fragmentados. A quarta é contenção: a consulta não está lenta, está esperando — bloqueada por outra transação de longa duração. Investiga-se olhando as sessões ativas e os bloqueios no momento em que a lentidão ocorre, e o sinal característico é a lentidão ser intermitente em vez de constante. A quinta é ambiental: menos memória disponível para cache, disco mais lento, concorrência maior no servidor. Compara-se com métricas de sistema no período. O método para separar as hipóteses é começar sempre pelo EXPLAIN ANALYZE, porque ele distingue de imediato entre "o plano mudou" e "o plano é o mesmo e ficou lento" — e essa bifurcação elimina metade das hipóteses de uma vez.

Hipóteses: estatísticas desatualizadas mudando o plano (a mais provável), crescimento de volume expondo ineficiência antiga, degradação física por versões mortas e índices fragmentados, contenção por bloqueio, e mudança ambiental. Comece por EXPLAIN ANALYZE: ele separa "o plano mudou" de "o mesmo plano ficou lento".