# Fundamentos de bases de dados

Dados, esquema, instância, SGBD, níveis de desenho e independência dos dados.

Página: https://resumos.rgo.pt/cadeiras/bd/fundamentos/

Ana fez duas encomendas. Se o nome dela estiver copiado nas duas, corrigir só uma deixa os dados contraditórios. Separar Cliente de Encomenda permite alterar o nome num único lugar. Essa separação é uma decisão de desenho. O sistema não a faz por nós.

Um **sistema de gestão de bases de dados**, ou SGBD, guarda dados e controla operações sobre eles. Conserva os dados de forma persistente e oferece uma linguagem para os consultar.

Além disso, verifica as restrições declaradas. Coordena acessos concorrentes quando várias aplicações escrevem ao mesmo tempo. Oferece mecanismos de recuperação após falhas. SQLite, PostgreSQL e MongoDB são exemplos de SGBDs.

## Dados, esquema e instância

Os dados são os factos concretos. Um exemplo é “o produto 10 chama-se Teclado”.

O **esquema** define a estrutura e as regras desses factos. Indica os atributos de cada tabela, os tipos, as chaves e as condições que todas as linhas têm de respeitar.

A **instância** é o conteúdo num certo momento. É o conjunto de linhas que a base de dados contém agora.

Duas instâncias do mesmo esquema `Produto(id, nome, precoCentimos, stock)`:

| id | nome | precoCentimos | stock |
| --- | --- | --- | --- |
| 10 | Teclado | 4500 | 20 |
| 11 | Rato | 2500 | 50 |

| id | nome | precoCentimos | stock |
| --- | --- | --- | --- |
| 10 | Teclado | 4500 | 18 |
| 11 | Rato | 2500 | 50 |
| 12 | Monitor | 18000 | 5 |

O esquema é o mesmo nas duas tabelas. Os atributos, a chave e as condições não mudaram.

A instância mudou em dois sentidos. O stock do teclado desceu de 20 para 18. Apareceu ainda o monitor como produto novo. Vender dois teclados muda a instância. Começar a registar a categoria muda o esquema, porque acrescenta um atributo possível.

A **chave** `id` identifica cada produto sem repetições. A condição `stock >= 0` rejeita valores negativos. Uma tabela vazia continua a ter esquema e restrições. O número de linhas não faz parte do esquema.

Uma base de dados é a coleção organizada de dados. O SGBD é o software que a guarda e interroga. Um ficheiro SQLite pode ser uma base de dados, mas o ficheiro não é o motor SQLite.

## Que problemas resolve o SGBD

O SGBD mantém dados persistentes e oferece uma linguagem de consulta. Verifica as restrições declaradas em cada escrita.

Controla acessos concorrentes e recupera após falhas, segundo as garantias do motor e da configuração. Pode criar índices e escolher uma forma de executar cada consulta.

A aplicação continua responsável por definir corretamente as regras. O nome `qtd` não é uma restrição. Se não declararmos que a quantidade é positiva, o SGBD aceita um valor negativo.

Do mesmo modo, se debitarmos dinheiro sem o creditar noutra conta, o SGBD executa essa operação errada sem interferência, desde que respeite as restrições declaradas. Integridade técnica e correção do domínio exigem por isso um desenho explícito.

## Três níveis de desenho

O modelo **conceptual** descreve o problema no vocabulário do domínio. Uma encomenda pertence a um cliente e contém produtos. Pode ser um diagrama UML, sem tipos específicos de SQLite.

O modelo **lógico** escolhe relações, atributos e chaves. A associação entre encomendas e produtos torna-se `Item(idEncomenda, idProduto, qtd, precoUnitario)`. É neste nível que verificamos dependências e formas normais.

O desenho **físico** decide como o SGBD guarda e acede aos dados. Inclui índices, organização dos ficheiros e opções de armazenamento. Criar um índice em `Encomenda(idCliente)` não muda o facto de uma encomenda pertencer a um cliente.

Esta separação permite a **independência dos dados**. A independência física deixa mudar um método de acesso sem reescrever a consulta lógica. A independência lógica procura proteger as aplicações de certas mudanças no esquema. Uma vista que mantém as colunas antigas é um exemplo típico. Nenhuma das duas significa que qualquer alteração de esquema seja invisível.

## O modelo relacional

Uma **relação** tem um conjunto de atributos e um conjunto de tuplos. Num esquema `Cliente(id, nome, email)`, cada tuplo associa um valor a cada atributo.

O **domínio** de um atributo define os valores admissíveis. Pode ser inteiros positivos, texto ou datas. A **aridade** é o número de atributos. A **cardinalidade** é o número de tuplos da instância.

Cliente tem aridade 3, mesmo quando está vazia. Inserir um cliente aumenta a cardinalidade sem mudar a aridade.

Na teoria relacional, não há tuplos duplicados. A ordem dos tuplos também não faz parte da relação. Duas apresentações com linhas em ordens diferentes representam o mesmo conjunto.

Em SQL, os resultados admitem duplicados por omissão. Só `ORDER BY` garante uma ordem na resposta. Esta diferença vai importar nas projeções, nas junções e nas contagens.

O nome “relacional” vem destas relações matemáticas. Não vem da simples existência de ligações entre tabelas. Uma base de dados de grafos também tem ligações, mas usa outro modelo.

## Uma pergunta e duas decisões

Queremos os clientes que compraram um rato. O resultado deve ter uma linha por cliente, mesmo que tenha comprado o produto em várias encomendas.

Para responder, precisamos de percorrer `Cliente → Encomenda → Item → Produto`. Precisamos ainda de eliminar repetições de clientes na resposta.

O preço atual do rato não é necessário para esta pergunta. A forma física de guardar as tabelas também não deve mudar o seu significado. Primeiro definimos a pergunta e as relações relevantes. A consulta e o plano físico vêm depois.