07 labmm4 - bases de dados
TRANSCRIPT
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.