Do modelo ao esquema relacional

A sessão S12 pertence ao evento E3. No esquema relacional, a linha de sessoes guarda evento_id = 3, que referencia a linha do evento. O mapeamento traduz classes e associações em tabelas e restrições. Algumas regras, como criar cada evento com pelo menos uma sessão, exigem coordenação além da chave estrangeira.

As regras de conversão

No nosso modelo sem generalizações, cada classe vira uma tabela e cada atributo vira uma coluna. Cada objeto ganha um identificador único, a chave primária. As associações viram chaves estrangeiras: colunas que referem uma chave candidata elegível da tabela referida, normalmente a primária. A tabela referida pode ser a própria tabela, como em hierarquias com parent_id.

• Associação de um para muitos (1 a 1..*): a chave estrangeira vai para o lado dos muitos. Cada sessão guarda evento_id a referir o evento. O evento não guarda nada sobre as sessões.
• Associação de muitos para muitos resolvida por classe: a ligação vira tabela própria com duas chaves estrangeiras. A tabela bilhetes guarda utilizador_id e sessao_id.
• Associação de um para um: escolhe o lado da referência segundo a obrigatoriedade e as operações, e acrescenta unicidade. Se um cartaz exige uma sessão mas uma sessão pode não ter cartaz, guardar a FK no cartaz evita referências vazias.

A direção da chave estrangeira é a decisão que mais erros causa. Pergunta sempre “cada objeto deste lado refere quantos do outro”, porque cada sessão refere um evento e por isso a coluna vive na sessão. Se a pusesses no evento, um evento só conseguiria guardar uma sessão.

-- lado dos muitos guarda a referência
sessoes (..., evento_id INTEGER NOT NULL REFERENCES eventos (id))

bilhetes (..., utilizador_id INTEGER NOT NULL REFERENCES utilizadores (id),
          sessao_id INTEGER NOT NULL REFERENCES sessoes (id))

-- exemplo: cada sessão tem no máximo um cartaz
cartazes (..., sessao_id INTEGER NOT NULL UNIQUE REFERENCES sessoes (id))

Conversão completa do exemplo

Aplicadas as regras às quatro classes da Loja de Bilhetes:

CREATE TABLE utilizadores (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    nome TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE,
    palavra_passe_hash TEXT NOT NULL
);

CREATE TABLE eventos (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    titulo TEXT NOT NULL,
    descricao TEXT,
    categoria TEXT
);

CREATE TABLE sessoes (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    evento_id INTEGER NOT NULL REFERENCES eventos (id),
    data_hora TIMESTAMP NOT NULL,
    preco NUMERIC(8, 2) NOT NULL CHECK (preco >= 0),
    lotacao INTEGER NOT NULL CHECK (lotacao > 0)
);

CREATE TABLE bilhetes (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    utilizador_id INTEGER NOT NULL REFERENCES utilizadores (id),
    sessao_id INTEGER NOT NULL REFERENCES sessoes (id),
    codigo TEXT NOT NULL UNIQUE,
    estado TEXT NOT NULL CHECK (estado IN ('reservado', 'pago', 'cancelado'))
);

Algumas restrições são locais: o email único vira UNIQUE, a lotação positiva vira CHECK e o estado limitado aos três valores vira CHECK com a lista; GENERATED ALWAYS AS IDENTITY gera os identificadores, enquanto PRIMARY KEY acrescenta unicidade e obrigatoriedade. A FK continua a ser um inteiro normal, sem gerar novos identificadores, e SERIAL é a alternativa antiga, ainda suportada. A exigência de pelo menos uma sessão por evento e o limite total de bilhetes ainda não são garantidos por este SQL; descricao aceita nulos e titulo não, pois um evento sem descrição ainda se vende, mas um evento sem título não se apresenta.

Uma violação de chave estrangeira explicada

Tenta vender um bilhete para uma sessão que não existe:

INSERT INTO bilhetes (utilizador_id, sessao_id, codigo, estado)
VALUES (1, 999, 'B-0001', 'reservado');

O PostgreSQL recusa com erro de violação de chave estrangeira, pois a sessão 999 não está na tabela sessoes e o bilhete ficaria a apontar para o vazio; esta recusa é a integridade referencial a funcionar. Sem a chave estrangeira, a inserção passava e a aplicação mostrava um bilhete para uma sessão fantasma, com erro só na página de confirmação, longe da causa. A mesma proteção vale ao apagar: não consegues apagar um evento que ainda tem sessões, porque as sessões ficariam órfãs, por isso decide por tabela o comportamento, apagar em cascata ou bloquear, em vez de descobrires a meio do projeto.

As setas apontam da estrangeira para a primária: lê “sessões refere eventos”. Se desenhares o teu esquema assim antes de escreveres o SQL, as referências em falta saltam à vista.

Seguir uma compra entre tabelas

A consulta final parte de um bilhete, segue a sessão e encontra o evento. As condições ON ligam a FK de cada linha à PK da linha que ela refere:

CREATE TABLE utilizadores (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    nome TEXT NOT NULL,
    email TEXT NOT NULL UNIQUE,
    palavra_passe_hash TEXT NOT NULL
);
CREATE TABLE eventos (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    titulo TEXT NOT NULL,
    descricao TEXT,
    categoria TEXT
);
CREATE TABLE sessoes (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    evento_id INTEGER NOT NULL REFERENCES eventos (id),
    data_hora TIMESTAMP NOT NULL,
    preco NUMERIC(8, 2) NOT NULL CHECK (preco >= 0),
    lotacao INTEGER NOT NULL CHECK (lotacao > 0)
);
CREATE TABLE bilhetes (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    utilizador_id INTEGER NOT NULL REFERENCES utilizadores (id),
    sessao_id INTEGER NOT NULL REFERENCES sessoes (id),
    codigo TEXT NOT NULL UNIQUE,
    estado TEXT NOT NULL CHECK (estado IN ('reservado', 'pago', 'cancelado'))
);
INSERT INTO eventos (titulo, descricao, categoria)
VALUES ('Noite de Fado', 'Fado na sala principal', 'musica');
INSERT INTO sessoes (evento_id, data_hora, preco, lotacao)
VALUES (1, '2026-12-14 21:30', 12.50, 100);
INSERT INTO utilizadores (nome, email, palavra_passe_hash)
VALUES ('Ana', 'ana@example.com', 'hash_apenas_para_demonstracao');
INSERT INTO bilhetes (utilizador_id, sessao_id, codigo, estado)
VALUES (1, 1, 'B-0001', 'reservado');
SELECT e.titulo, s.data_hora, b.codigo, b.estado
FROM bilhetes AS b
JOIN sessoes AS s ON s.id = b.sessao_id
JOIN eventos AS e ON e.id = s.evento_id;

O bloco usa os mesmos tipos e restrições PostgreSQL do esquema anterior. Cada execução cria uma base em memória e gera de novo os identificadores. O hash mostrado é apenas um marcador de dados de teste, não serve para autenticar.

Chaves, domínios e NULL

Uma chave primária é única e não nula. Uma chave candidata resulta das regras do domínio e é mínima; só uma é escolhida como primária, mas as outras continuam a exigir a unicidade apropriada. Uma chave artificial não substitui UNIQUE(email) quando o email deve ser único.

Em PostgreSQL, CHECK(preco >= 0) aceita a linha se a expressão der verdadeiro ou desconhecido. Para impedir um preço nulo, acrescenta NOT NULL. O DEFAULT fornece um valor quando ele é omitido; não impede a pessoa de enviar outro nem substitui uma restrição.

Por defeito, UNIQUE permite vários NULL em PostgreSQL, porque não os trata como valores iguais. Quando a regra precisa de outra semântica, considera NULLS NOT DISTINCT nas versões que o suportam, ou um desenho alternativo. Uma restrição de email único pode ainda exigir uma política para maiúsculas.

Apagar e referenciar

Não escolhas CASCADE para tudo. Eliminar uma categoria pode justificar outra ação que eliminar um documento fiscal. O sentido da FK também importa: eliminar um bilhete não apaga a sessão que ele refere.

Mapear subtipos e relações opcionais

Para uma especialização há três estratégias, cada uma com um custo diferente na verificação das regras:

• Tabela de supertipo e uma por subtipo, com a chave de cada subtipo também a ser FK para o supertipo. Partilha atributos sem os duplicar, mas a regra «todo o supertipo tem exatamente um destes subtipos» não aparece automaticamente só com essas FKs.
• Tabela única com discriminador e colunas específicas. Precisa de CHECKs que liguem o discriminador aos atributos exigidos; pode produzir muitos NULL.
• Tabela por classe concreta, repetindo nela os atributos do supertipo. Evita certas junções, mas uma consulta a todos os utilizadores pode exigir UNION. Se os subtipos se sobrepõem, a mesma pessoa pode surgir em várias tabelas, exigindo coordenação da identidade e dos atributos comuns.

A escolha depende de consultas, restrições e da forma de especialização. Explica como garantes totalidade e disjunção quando são obrigatórias, e não escolhas a terceira estratégia sem verificar as restrições da especialização.

Numa relação N:N simples, uma tabela com PK composta (utilizador_id,sessao_id) permite no máximo uma ligação por par. Bilhete tem identidade própria: a mesma pessoa pode comprar vários para a mesma sessão, logo o par não é único neste exemplo. Não apliques automaticamente a PK composta de uma associação simples a uma entidade associativa com várias ocorrências por par.

A validação do esquema continua com dependências funcionais e normalização.

Notação compacta, schema e passagem a SQL

A5 documenta cada relação em notação compacta antes do DDL. Lê bilhetes(id, utilizador_id -> utilizadores NN, sessao_id -> sessoes NN, codigo UK NN, estado NN CK estado IN Estados): cada -> é uma chave estrangeira, UK é unicidade, NN é obrigatório, CK é verificação e Estados é o domínio dos três valores. Traduz cada marca para SQL: NN vira NOT NULL, UK vira UNIQUE, CK vira CHECK, -> vira REFERENCES.

Em PostgreSQL, uma base de dados contém schemas e cada schema contém tabelas. O search_path diz em que schema o servidor procura tabelas sem prefixo. No servidor da faculdade, o schema public é partilhado: cria o schema do grupo com CREATE SCHEMA lbawXXg e começa os scripts com SET search_path TO lbawXXg, para não criar tabelas no schema partilhado.

Uma referência a um par

Numa extensão da loja com lugares numerados, o lugar 90 pertence a S12 e o lugar 91 a S13. Um bilhete que guarda lugar_id=90 e sessao_id=13 mistura referências existentes, mas descreve uma combinação impossível. Duas FKs independentes só verificariam que 90 e 13 existem.

Uma chave estrangeira composta verifica que o par existe na mesma linha da relação referida:

CREATE TABLE lugares (
  id INTEGER PRIMARY KEY,
  sessao_id INTEGER NOT NULL REFERENCES sessoes(id),
  numero TEXT NOT NULL,
  UNIQUE (sessao_id, numero),
  UNIQUE (id, sessao_id)
);
CREATE TABLE bilhetes_com_lugar (
  id INTEGER PRIMARY KEY,
  lugar_id INTEGER NOT NULL,
  sessao_id INTEGER NOT NULL,
  FOREIGN KEY (lugar_id, sessao_id) REFERENCES lugares(id, sessao_id)
);

UNIQUE(sessao_id, numero) impede dois lugares A1 na mesma sessão, mas permite A1 em sessões diferentes. UNIQUE(id, sessao_id) é redundante quanto à unicidade, pois id já é PK, mas fornece a chave declarada que esta FK composta referencia. O par (90,12) passa; (90,13) é recusado.

Os dois NOT NULL também fazem parte da regra. Com o comportamento predefinido MATCH SIMPLE, uma FK composta não exige correspondência quando algum componente é NULL. Para um bilhete que exige lugar e sessão, não deixes essa saída aberta. Se não precisas de guardar a sessão no bilhete, referir só o lugar e obter a sessão por junção evita duplicar essa informação. O exemplo mostra como garantir coerência quando ambos os campos têm de ficar guardados.

Esta regra cabe numa FK, por isso não precisa de um trigger que consulte os lugares. Usa primeiro as restrições declarativas que exprimem a invariante. A atribuição exclusiva de um lugar a bilhetes ativos é outra regra e exigiria uma restrição própria; este esquema só verifica a pertença do lugar à sessão.