Bases de dados: Auto-associações, especialização/generalização e integridade referencial

Carlos SantosLabMM 4 - NTC - DeCA - UAAula 07, 08-03-2012

Auto-associações

Pretende-se modelar a seguinte situação numa BD:

• Num escritório os funcionários possuem (ou não) um superior hierárquico• Cada funcionário pode ter um único superior hierárquico• Cada superior hierárquico pode coordenar vários funcionários

Como modelar esta relação numa BD?

Funcionarios

idFuncionarios Nome

Auto-associações

Como a FK pode admitir valores nulos e valores repetidos

• Um funcionário pode ser superior hierárquico de vários outros• Podem existir funcionários sem superior hierárquico

Se a FK não permitir valores nulos (NOT NULL)

• Não podem existir funcionários sem superior hierárquico

Se FK não permitir valores repetidos (UNIQUE)

• Cada funcionário só pode ser superior hierárquico de um único funcionário• (a relação transforma-se numa 1:1)

Auto-associações (solução alternativa)

Utilizar uma tabela de relação com duas chaves estrangeiras que apontam para a mesma chave primária!

Cada uma das FK não admite valores nulos por ser parte duma chave primária composta. No entanto:

• Funcionarios_idFuncionarios e Funcionarios_idFuncionarios1 podem ser configuradas com o parâmetro UNIQUE para evitar os valores repetidos em cada uma das colunas

Auto-associações (solução alternativa)

Diferentes possibilidades:

• M:M - Se as duas FK admitirem valores repetidos (em cada uma das colunas)

• 1:M - Se apenas uma das FK admitir valores repetidos• 1:1 - Se nenhuma das FK admitir valores repetidos

Especialização/Generalização

Numa biblioteca pretende-se catalogar os vários tipo de publicações (livros/monografias) e (revistas/periódicos) com um sistema de numeração único

Tabela de generalização

Tabelas de especialização

Especialização/Generalização

As publicações são uma generalização dos conceitos monografias e periódicos

• A tabela PUBLICACOES armazena as características comuns a todas as publicações

As monografias e os periódicos são especializações do conceito publicações

• As tabelas MONOGRAFIAS e PERIODICOS armazenam as características específicas (especiais) de cada tipo de publicação

As monografias e periódicos “herdam” todas as características comuns definidas em publicações

Erros comuns na integridade dos dados

Erros tipográficos na introdução dos dados

Erros na introdução de dados num campo, cujo conjunto de valores possíveis deveria estar bem delimitado (escolher um país da lista de países)

• Na BD poder-se-ão usar tipos de dados como o SET e ENUM ou tabelas dicionário

Erros entre os dados introduzidos em diferentes campos

• Exemplo: todas as datas relacionadas com a vida de um indivíduo têm de ser posteriores à data do seu nascimento

Prevenir ou minorar os efeitos destes erros com:

• HTML/JavaScript• PHP• MySQL

Integridade referencial

A integridade referencial implica que se deva garantir que todos os valores atribuídos à FK (tabela de chegada) existam do lado da PK (tabela de partida)

No mySQL, o motor InnoDB, com o seu suporte a chaves estrangeiras, já implementa mecanismos de preservação da integridade referencial da BD

Existe no entanto um “problema”:

• Quando um registo da tabela de partida (do lado da PK) é removido o que deve acontecer ao(s) registo(s) na tabela de chegada (do lado da FK) que o referenciava(m)?

Integridade referencial

Removendo na tabela CLIENTES, o registo onde a PK toma o valor 2 o que acontecerá aos registos na tabela ENCOMENDAS onde a FK toma esse valor?

ENCOMENDASENCOMENDASidENCOMENDAS DataEncomenda DataPagamento CLIENTES_idCLIENTES

1 2008-­‐02-­‐23 2008-­‐01-­‐25 12 2008-­‐04-­‐11 2008-­‐02-­‐23 23 2008-­‐03-­‐13 2008-­‐03-­‐23 24 2008-­‐05-­‐21 2008-­‐04-­‐23 35 2008-­‐06-­‐25 2008-­‐08-­‐23 2

CLIENTESCLIENTESidCLIENTES Nome

1 João2 Maria3 Manuel

Normalmente, nas aplicações Web não se removem registos! Os registos “removidos” são guardados num estado de inactivos/invisíveis.

Solução: Adicionar coluna extra à tabela (estado: activo/inactivo, 0/1)

Integridade referencial

No Workbench, no separador Foreign Keys da tabela de chegada (do lado da FK), devem configurar-se as Foreign Key Options

Isso permite decidir o que acontece nessa tabela, quando se actualiza/apaga um registo na tabela de partida (do lado da PK)

Foreign Key Options [Foreign Key Constraints]

RESTRICT

• Não é permitido actualizar/apagar um registo na tabela de partida se este tiver registos relacionados na tabela de chegada

NO ACTION

• Funcionamento idêntico ao RESTRICT

CASCADE

• Ao actualizar/apagar um registo na tabela de partida essa operação é executada também nos registos relacionados na tabela de chegada

SET NULL

• Ao actualizar/apagar um registo na tabela de partida, são colocados a NULL os valores da chave estrangeira nos registos relacionados (isto só é possível, se a definição da FK o permitir, por exemplo, se não tiver sido parametrizada com o NOT NULL)

CASCADE DELETE

Resultados potencialmente catastróficos para a base de dados!

• Exemplo: na base de dados “Multiverso” (exercício P 05) todos os corpos celestes (500k registos) foram adicionados ao “Universo 1”.• Se todas as relações da BD estiverem com CASCADE DELETE, o que

acontece se o registo do “Universo 1” for apagado?

E se for uma actualização do valor da chave primária?

Os mecanismos que permitem definir como reagir ao evento de apagar existem também para o evento de actualizar.