Do UML ao esquema relacional

No modelo da loja, Ana está ligada às encomendas 100 e 101. Para guardar essa ligação em relações, colocamos o id de Ana em cada encomenda. A tradução deve conservar as regras do UML: referências para existência, unicidade para máximos e validação adicional quando as chaves não exprimem um mínimo.

Relações e chaves

Cada classe origina uma relação com os seus atributos simples. Uma superchave identifica um tuplo sem ambiguidade. Uma chave candidata é uma superchave mínima: retirar qualquer atributo faz perder essa capacidade. Escolhemos uma candidata como chave primária e conservamos as outras como chaves alternativas.

Se id e email identificam clientes, ambos são candidatos, desde que o email seja obrigatório e único no domínio. id, nome é superchave mas não candidata, porque id já chega. No nosso exemplo, emails desconhecidos são permitidos, pelo que email não é chave candidata conceptual, embora exista uma restrição UNIQUE em SQL.

Uma chave estrangeira referencia uma chave candidata de outra relação ou da própria relação. Pode ser composta. As referências de uma chave composta têm de corresponder ao mesmo tuplo alvo, não a tuplos separados para cada coluna.

Associações um para muitos

Cada encomenda tem um cliente, por isso:

Cliente(id, nome, email)             PK: id
Encomenda(id, data, idCliente)        PK: id
Encomenda.idCliente → Cliente.id

A estrangeira fica em Encomenda, o lado muitos. Uma única coluna em Cliente não poderia guardar várias encomendas.

Se a encomenda tem exatamente um cliente, idCliente é NOT NULL. Se pudesse não ter cliente, admitiria NULL.

Essa referência garante que o cliente indicado existe. Não garante que todos os clientes tenham encomendas. A exigência 1..* junto de Encomenda precisa de outro mecanismo, como validação transacional ao confirmar os dados.

Muitos para muitos e um para um

Uma associação muitos para muitos origina uma relação com as duas chaves:

Item(idEncomenda, idProduto, qtd, precoUnitario)
PK: (idEncomenda, idProduto)
idEncomenda → Encomenda.id
idProduto → Produto.id

O par impede duas linhas do mesmo produto na mesma encomenda. A quantidade e o preço da compra pertencem à associação.

Acrescentar um id artificial é possível. Nesse caso, conserva UNIQUE(idEncomenda, idProduto) se essa continuar a ser a regra.

Numa associação um para um, uma estrangeira isolada ainda permitiria várias referências ao mesmo tuplo. Acrescenta UNIQUE. Para um cartão que pertence a exatamente um cliente e um cliente com no máximo um cartão:

Cartao(numero, idCliente)
PK: numero
FK: idCliente → Cliente.id, NOT NULL, UNIQUE

Esta tradução não obriga cada cliente a ter cartão. Se ambos os lados tiverem participação obrigatória, a fusão pode evitar a obrigação de manter duas linhas correspondentes, mas só faz sentido quando os objetos e os seus ciclos de vida justificam essa escolha.

Conversão completa da loja

As chaves garantem uma linha por cliente, produto e encomenda, e uma linha por par encomenda/produto. O mínimo de um produto por encomenda continua por garantir: podemos criar uma encomenda e ainda não criar Item. Um NOT NULL nas estrangeiras de Item não muda isso, porque uma tabela vazia não tem linhas que o violem.

Há uma diferença entre armazenar um estado intermédio durante a criação e aceitar esse estado como encomenda confirmada. A aplicação pode inserir a encomenda e as suas linhas numa transação, validando o mínimo antes de confirmar. A regra precisa de estar definida para todas as operações que possam quebrá-la, incluindo remover a última linha.

Associações reflexivas e qualificadas

Uma pessoa com no máximo um progenitor registado usa uma referência à própria tabela:

Pessoa(id, nome, idProgenitor)
PK: id
FK: idProgenitor → Pessoa.id, admite NULL

Uma associação muitos para muitos entre pessoas exige uma relação própria com papéis distintos. Em Amizade(idPessoaA, idPessoaB), uma chave no par elimina duplicação na mesma ordem. Para representar uma amizade não orientada uma única vez, podemos exigir idPessoaA < idPessoaB, além de duas estrangeiras. Essa condição proíbe também a autorreferência.

Para os números de membro locais ao clube:

Membro(idClube, numeroMembro, idPessoa)
PK: (idClube, numeroMembro)
FK: idClube → Clube.id; idPessoa → Pessoa.id
UNIQUE: (idClube, idPessoa), se cada pessoa só tiver uma inscrição por clube

O número sozinho não é chave. A última unicidade é uma hipótese adicional e deve ser imposta apenas se o domínio a exigir.

Associações n-árias

Traduz uma associação ternária para uma relação com as chaves dos três participantes e os atributos da ligação:

Fornecimento(idFornecedor, idProduto, idProjeto, quantidade)

Se todos os máximos forem muitos, o triplo é normalmente a chave da associação.

Se para cada Produto/Projeto houver no máximo um fornecedor, temos a dependência (idProduto, idProjeto) → idFornecedor. O par Produto/Projeto passa a identificar o fornecimento. Não escolhas mecanicamente o triplo como chave candidata quando a multiplicidade já torna parte dele redundante.

As estrangeiras verificam existência dos participantes. A chave e outras unicidades verificam as multiplicidades máximas. Mínimos que exigem a participação de todos os objetos não resultam destas estrangeiras.

Traduzir generalizações

Há três estratégias principais. Considera Pessoa(id, nome) com subclasses Aluno(curso) e Docente(departamento).

Uma relação por classe mantém Pessoa(id, nome), Aluno(id, curso) e Docente(id, departamento). O id das subclasses é simultaneamente primária e estrangeira para Pessoa. Representa naturalmente uma pessoa que é aluno e docente, mas consultar o nome e o curso exige uma junção.

Uma relação por tipo concreto guarda todos os atributos de cada tipo. Se a generalização for completa e disjunta, podemos usar apenas Aluno(id, nome, curso) e Docente(id, nome, departamento), sem uma Pessoa autónoma. Uma primária em cada tabela não impede repetir o mesmo id entre Aluno e Docente, por isso, se o id identifica pessoas globalmente, é preciso garantir essa unicidade entre os tipos e a disjunção exigida.

Se houver sobreposição, não basta copiar a mesma pessoa para duas tabelas sem coordenação: podemos precisar de tipos para as combinações de subclasses, como AlunoDocente, e o número de combinações pode crescer depressa.

Uma relação única guarda os atributos de todas as classes, por exemplo Pessoa(id, nome, eAluno, eDocente, curso, departamento). Os indicadores permitem distinguir pertença de um atributo específico desconhecido. Um único discriminador com valores Aluno/Docente serve uma generalização disjunta, mas não uma sobreposta. Precisamos de CHECKs e de regras para colunas que só se aplicam a certas subclasses.

Na estratégia por classe, duas estrangeiras para Pessoa não garantem completude nem disjunção. Uma Pessoa pode não estar em nenhuma subclasse ou estar nas duas. Estas condições precisam de validação própria se o modelo as exigir.

Composição e elementos derivados

Composição e agregação traduzem-se estruturalmente como associações. A composição pode justificar ON DELETE CASCADE, mas a política depende de como o sistema representa a eliminação. Arquivar uma encomenda não é apagar os seus tuplos.

Um total derivado pode ser calculado numa consulta ou vista. Se o guardares, introduzes uma obrigação de consistência com as linhas. Um valor derivado não é automaticamente uma coluna independente e não deve receber alterações arbitrárias.

Conferir a tradução

Para cada chave, explica por que identifica o tuplo e por que nenhum subconjunto chega. Para cada associação, localiza as estrangeiras, o máximo imposto por unicidade e os mínimos ainda por implementar. Depois testa um exemplo permitido e um proibido. Um esquema com todas as setas desenhadas pode continuar a aceitar estados que o UML proíbe.