Fundamentos de bases de dados

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.