Boas-vindas

Este é o material completo da disciplina Banco de Dados, oferecida no quarto termo do curso de Tecnologia em Análise e Desenvolvimento de Sistemas. Você está abrindo a primeira página de um material que, ao longo do semestre, deve se tornar a sua principal referência sobre como os dados de um sistema são modelados, armazenados, consultados e protegidos. Antes de avançar para o primeiro módulo, peço que dedique alguns minutos a esta página. Ela situa o que você vai encontrar adiante, explica por que a disciplina está organizada da forma que está e estabelece um modo de estudar que vale a pena adotar desde o começo.

Uma cena para começar

Imagine um sistema que nasceu pequeno. No início era uma planilha. Cada vendedor anotava seus clientes, seus pedidos e seus produtos em abas separadas, e por um tempo funcionou. Quando o negócio cresceu, a planilha virou um conjunto de planilhas, depois um pequeno programa que gravava tudo em arquivos. E então começaram os problemas. O mesmo cliente aparecia escrito de três formas diferentes. Um pedido apontava para um produto que já não existia. Dois vendedores editavam o mesmo arquivo ao mesmo tempo e um sobrescrevia o trabalho do outro. Um dia o disco falhou, e a pergunta que ninguém sabia responder era simples e terrível: quanto, exatamente, nós perdemos?

Cada um desses problemas — dado duplicado, referência quebrada, edição concorrente, perda por falha — tem nome técnico, tem teoria por trás e tem solução consolidada há décadas. O conjunto dessas soluções é o que estudamos nesta disciplina. Um Sistema Gerenciador de Banco de Dados não é apenas um lugar para guardar informação. É a peça de engenharia que assume, de uma vez, a responsabilidade por consistência, concorrência, integridade e recuperação, e devolve à aplicação uma interface limpa para pedir o que precisa. Aprender banco de dados é aprender a confiar essa responsabilidade à ferramenta certa — e a entender o que ela faz por baixo, para não ser surpreendido quando o sistema crescer.

Dados sem um SGBD

Informação duplicada e sem padrão. Referências que apontam para o nada. Edições concorrentes que se sobrescrevem. Nenhuma garantia de que uma operação ou se completa por inteiro, ou não acontece. Recuperação após falha incerta.

Dados sob um SGBD relacional

Estrutura definida e restrições que o próprio sistema faz cumprir. Integridade referencial garantida. Controle de concorrência transparente. Transações com as propriedades ACID. Backup e recuperação como recursos de primeira classe.

O que este material é

Este material foi escrito para acompanhar você do começo ao fim da disciplina. Ele combina explicação teórica em prosa, diagramas que tornam visíveis estruturas que o texto sozinho descreveria com dificuldade, exemplos de SQL e de modelagem retirados de situações reais e definições cuidadosas dos conceitos que a área cobra com precisão. Ao longo de quinze módulos, partimos do panorama dos Sistemas Gerenciadores de Bancos de Dados Relacionais, passamos pela teoria do modelo relacional, pela modelagem conceitual e lógica, pela normalização, pela álgebra relacional, pela linguagem SQL em profundidade, e chegamos aos temas de desempenho, transações, integridade, programação no servidor e arquitetura interna do SGBD.

Como material, ele adota uma escolha de estilo deliberada. Em primeira pessoa, eu converso diretamente com você, como se estivesse ao seu lado explicando o tema. Em prosa contínua, evito reduzir a listas o que uma explicação completa expressa melhor. Em diagramas, recorro ao Mermaid sempre que uma imagem economiza palavras — e em banco de dados, onde tanto se trabalha com tabelas, relacionamentos e diagramas entidade-relacionamento, a imagem economiza muitas. Quando um conceito admite formulação precisa, ele é definido com rigor, porque a área de banco de dados tem um vocabulário técnico que não tolera frouxidão: tupla, relação, dependência funcional, chave candidata e forma normal são termos com fronteiras exatas, e parte do que você aprende aqui é justamente essa exatidão.

O que este material não é

Vale esclarecer o que este material não pretende ser. Ele não é o manual de um produto específico. Os conceitos valem para qualquer SGBD relacional — PostgreSQL, MySQL, Oracle, SQL Server, Db2, SQLite — e, quando um exemplo precisa de um dialeto concreto, isso é dito explicitamente. As particularidades de instalação, configuração e administração de cada produto ficam por conta da documentação oficial do fornecedor, à qual você deve recorrer quando for operar o sistema na prática.

Ele também não é um repositório de receitas de SQL para copiar e colar. Você não vai encontrar aqui um catálogo de consultas prontas a ser reutilizado sem entendimento. A razão é a mesma que rege toda a disciplina: uma consulta que você copia sem compreender é uma consulta que você não saberá corrigir quando ela retornar o resultado errado, nem otimizar quando ela ficar lenta sobre uma tabela de milhões de linhas. O objetivo aqui é que você construa o critério para escrever a sua própria consulta, modelar o seu próprio esquema e diagnosticar o seu próprio problema de desempenho.

Um exemplo concreto do tipo de raciocínio que será cultivado

Exemplo. Considere uma exigência banal: registrar que um pedido pertence a um cliente. Há, no mínimo, duas formas de fazer isso, e a diferença entre elas é o tema de boa parte da disciplina.

A primeira forma é ingênua. Em cada linha de pedido, repetimos o nome do cliente, seu endereço e seu telefone. É simples, funciona na primeira tentativa e parece prático. Mas observe as consequências quando o sistema cresce. Quando o cliente muda de telefone, é preciso encontrar e alterar todas as linhas de pedido em que aquele dado aparece — e basta esquecer uma para o banco passar a conter duas verdades contraditórias sobre o mesmo cliente. Pior: enquanto o cliente não tiver feito nenhum pedido, não há onde guardar seus dados. A informação do cliente ficou acoplada à existência de um pedido.

A segunda forma reorganiza a mesma exigência. Os dados do cliente vivem em uma tabela só sua, identificados por uma chave; o pedido guarda apenas uma referência a essa chave, uma chave estrangeira. O telefone do cliente passa a existir em um único lugar, e alterá-lo é uma operação única. Um cliente pode existir sem nenhum pedido, e um pedido jamais pode apontar para um cliente inexistente, porque o próprio SGBD recusa essa operação. A informação foi separada segundo aquilo que ela realmente descreve.

Esse exemplo é deliberadamente pequeno, mas contém em miniatura o coração da disciplina. A diferença entre as duas formas não é de gosto, é de projeto. A primeira mistura, em um mesmo lugar, fatos que pertencem a coisas diferentes. A segunda os separa, e a teoria que justifica e sistematiza essa separação se chama normalização. Você a verá formalmente nos módulos seis e sete, mas reconhecerá o seu espírito desde a primeira aula de modelagem.

flowchart LR
    subgraph Ingenua[Forma ingenua]
        P1[Pedido<br/>com nome, telefone<br/>e endereco do cliente repetidos]
    end
    subgraph Normalizada[Forma normalizada]
        C2[Cliente] -->|chave primaria| K((id))
        P2[Pedido] -->|chave estrangeira| K
    end

A figura mostra, lado a lado, as duas formas. À esquerda, cada pedido carrega uma cópia dos dados do cliente. À direita, o cliente existe uma única vez e o pedido apenas o referencia. Boa parte do curso pode ser entendida como o aprofundamento dessa pequena diferença e das ferramentas — modelagem, normalização, restrições, SQL — que a tornam disciplina, e não acidente.

Sobre rigor e formalidade

Nota sobre estilo. Ao longo do material você encontrará registros distintos. Quando o tema exigir precisão, o texto adota um tom rigoroso, com definições explícitas e fronteiras claras. Quando o objetivo for ilustrar, ele se solta em exemplos. Quando se tratar de apresentar um conceito pela primeira vez, desce ao nível mais didático possível, sem abrir mão da exatidão.

Boa parte dos conceitos desta disciplina admite formulação matemática, e isso não é um detalhe acessório: o modelo relacional nasceu, em 1970, de um artigo de Edgar F. Codd que o fundou sobre a teoria dos conjuntos e a lógica de predicados. Por isso, quando o material lidar com a álgebra relacional, com dependências funcionais ou com cardinalidades, a notação será apresentada com o cuidado que a forma exige. Considere, por exemplo, a noção de dependência funcional, que está na base de toda a teoria de normalização. Dizer que um atributo B depende funcionalmente de um atributo A, e escrever A \rightarrow B, significa afirmar que, para cada valor de A, existe no máximo um valor de B associado. Dessa relação aparentemente simples deriva todo o critério para decidir se um esquema está bem projetado, e o módulo seis a trata com o vínculo que ela merece.

Esse rigor é parte do que distingue um profissional que entende banco de dados de alguém que apenas memoriza comandos. Sem vocabulário preciso, não se discute o projeto de um esquema; sem definições exatas, não se justifica por que um esquema é melhor do que outro.

O arco do semestre

A disciplina caminha em espiral. Começa no chão — o que é e para que serve um SGBD — e sobe em camadas até a arquitetura interna que faz tudo funcionar. Os quinze módulos se agrupam em cinco grandes blocos, e enxergar esse mapa antes de começar muda a forma como você estuda cada módulo.

flowchart TD
    A["Fundamentos<br/>Modulos 01-02<br/>SGBDR, modelo relacional e ACID"]
    B["Modelagem<br/>Modulos 03-05<br/>Entidade-relacionamento e mapeamento logico"]
    C["Normalizacao<br/>Modulos 06-07<br/>Formas normais, teoria e pratica"]
    D["Consulta aos dados<br/>Modulos 08-10<br/>Algebra relacional e SQL"]
    E["Desempenho, integridade e arquitetura<br/>Modulos 11-15<br/>Indices, transacoes, restricoes, programacao e SGBD por dentro"]
    A --> B --> C --> D --> E

No primeiro bloco, fundamentos, situamos o terreno: o que é um Sistema Gerenciador de Banco de Dados Relacional, como a tecnologia evoluiu e por que se tornou dominante, e em seguida a teoria do modelo relacional e as propriedades ACID que sustentam a confiabilidade das transações. No segundo bloco, modelagem, aprendemos a traduzir um problema do mundo real em um modelo entidade-relacionamento, a representá-lo em diagramas, a tratar relacionamentos complexos, entidades fracas e generalização, e por fim a mapear esse modelo conceitual para tabelas concretas. No terceiro bloco, normalização, sistematizamos o critério para distinguir um bom esquema de um ruim, percorrendo as formas normais na teoria e depois enfrentando as decisões reais de quando normalizar e quando, conscientemente, desnormalizar. No quarto bloco, consulta aos dados, estudamos primeiro a álgebra relacional, que é a fundação formal, e depois a linguagem SQL em profundidade, dos comandos básicos às consultas avançadas. No quinto e último bloco reunimos os temas que fazem um banco funcionar bem e com segurança em produção: índices e otimização, transações e controle de concorrência, integridade e restrições, gatilhos e procedimentos armazenados, e a arquitetura interna do próprio SGBD.

Cada bloco prepara o seguinte. A modelagem só faz sentido depois de entender o modelo relacional; a normalização refina o que a modelagem produziu; o SQL consulta as tabelas que a modelagem desenhou; e os temas de desempenho e arquitetura explicam o que o SGBD faz para executar tudo isso com eficiência. Um módulo perdido empobrece os seguintes; um módulo bem absorvido enriquece todos os que vêm depois.

Mentalidade recomendada para o semestre

Há três disposições que, ao longo dos anos, mostram-se as mais eficazes para aproveitar o curso. A primeira é o hábito de praticar de mãos no teclado. Banco de dados não se aprende apenas lendo; aprende-se modelando esquemas e escrevendo consultas que rodam de verdade, vendo o resultado e, sobretudo, errando e corrigindo. Instale um SGBD, crie suas tabelas, povoe-as com dados e teste cada conceito novo contra um banco real. A segunda é a paciência com a teoria nos módulos iniciais. É tentador pular direto para o SQL, que parece a parte “útil”, mas é a modelagem e a normalização que decidem se o seu SQL será simples ou um pesadelo; quem investe nos fundamentos colhe nas consultas. A terceira é a constância. A disciplina retoma temas em profundidade crescente, e o estudo regular, módulo a módulo, é incomparavelmente mais eficaz do que a maratona véspera de prova. Não há atalho, e o assunto recompensa quem o trata com seriedade.

O que vem a seguir

A partir daqui, o caminho natural é o Módulo 01, que apresenta os Sistemas Gerenciadores de Bancos de Dados Relacionais: o que são, quais funções desempenham, como evoluíram e qual é o panorama atual do mercado. Ele estabelece o vocabulário e a visão geral sobre os quais todo o resto se apoia. Recomendo que você o leia com calma, sem pressa de chegar ao SQL, porque a segurança conceitual que ele oferece é exatamente o que separa quem decora comandos de quem realmente entende o que está fazendo.

flowchart LR
    Aqui["Esta pagina<br/>Boas-vindas"] --> M01["Modulo 01<br/>SGBDR: conceitos e panorama"]
    M01 --> M02["Modulo 02<br/>Modelo relacional e ACID"]
    M02 --> Resto["Modelagem, normalizacao,<br/>SQL e arquitetura"]

Seja bem-vindo. O semestre é exigente, mas o tipo de exigência que ele traz é o que forma um bom profissional de dados — aquele em quem uma equipe confia para projetar o esquema sobre o qual todo o sistema vai se apoiar. Eu, como professor, escrevi este material para acompanhá-lo de perto. Você, como estudante, é o agente do próprio aprendizado. Vamos começar.