O documento discute três tópicos principais sobre modelagem de dados em bancos de dados: 1) Auto-associações, onde uma tabela pode se referenciar a si mesma para representar relações hierárquicas como funcionários e seus supervisores. 2) Especialização/generalização, onde dados genéricos são armazenados em uma tabela geral e dados específicos são armazenados em tabelas especializadas. 3) Integridade referencial, que garante que valores de chaves estrangeiras existam nas tabelas correspondentes, e como lidar

1. Bases de dados: Auto-associações,
especialização/generalização e integridade
referencial
Carlos Santos
LabMM 4 - NTC - DeCA - UA
Aula 07, 08-03-2012

2. 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

3. 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)

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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)?

10. 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?
CLIENTES ENCOMENDAS
idCLIENTES Nome idENCOMENDAS DataEncomenda DataPagamento CLIENTES_idCLIENTES
1 João 1 2008-­‐02-­‐23 2008-­‐01-­‐25 1
2 Maria 2 2008-­‐04-­‐11 2008-­‐02-­‐23 2
3 Manuel 3 2008-­‐03-­‐13 2008-­‐03-­‐23 2
4 2008-­‐05-­‐21 2008-­‐04-­‐23 3
5 2008-­‐06-­‐25 2008-­‐08-­‐23 2
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)

11. 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)

12. 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)

13. 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?

14. 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.