07 LabMM4 - Bases de dados

776 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
776
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
104
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

07 LabMM4 - Bases de dados

  1. 1. Bases de dados: Auto-associações,especialização/generalização e integridadereferencialCarlos SantosLabMM 4 - NTC - DeCA - UAAula 07, 08-03-2012
  2. 2. Auto-associaçõesPretende-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áriosComo modelar esta relação numa BD? Funcionarios idFuncionarios Nome
  3. 3. Auto-associaçõesComo 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árquicoSe a FK não permitir valores nulos (NOT NULL) • Não podem existir funcionários sem superior hierárquicoSe 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. 4. Auto-associações (solução alternativa)Utilizar uma tabela de relação com duas chaves estrangeiras que apontampara a mesma chave primária!Cada uma das FK não admite valores nulos por ser parte duma chaveprimá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. 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. 6. Especialização/GeneralizaçãoNuma biblioteca pretende-se catalogar os vários tipo de publicações(livros/monografias) e (revistas/periódicos) com um sistema denumeração único Tabela de generalização Tabelas de especialização
  7. 7. Especialização/GeneralizaçãoAs publicações são uma generalização dos conceitos monografias eperiódicos • A tabela PUBLICACOES armazena as características comuns a todas as publicaçõesAs monografias e os periódicos são especializações do conceitopublicações • As tabelas MONOGRAFIAS e PERIODICOS armazenam as características específicas (especiais) de cada tipo de publicaçãoAs monografias e periódicos “herdam” todas as características comunsdefinidas em publicações
  8. 8. Erros comuns na integridade dos dadosErros tipográficos na introdução dos dadosErros na introdução de dados num campo, cujo conjunto de valorespossí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árioErros 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 nascimentoPrevenir ou minorar os efeitos destes erros com: • HTML/JavaScript • PHP • MySQL
  9. 9. Integridade referencialA integridade referencial implica que se deva garantir que todos osvalores atribuídos à FK (tabela de chegada) existam do lado da PK (tabelade partida)No mySQL, o motor InnoDB, com o seu suporte a chaves estrangeiras, jáimplementa mecanismos de preservação da integridade referencial da BDExiste 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. 10. Integridade referencialRemovendo na tabela CLIENTES, o registo onde a PK toma o valor 2 o queacontecerá aos registos na tabela ENCOMENDAS onde a FK toma essevalor? 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 2Normalmente, 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. 11. Integridade referencialNo Workbench, no separador Foreign Keys da tabela de chegada (do ladoda FK), devem configurar-se as Foreign Key OptionsIsso permite decidir o que acontece nessa tabela, quando se actualiza/apaga um registo na tabela de partida (do lado da PK)
  12. 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 chegadaNO ACTION • Funcionamento idêntico ao RESTRICTCASCADE • Ao actualizar/apagar um registo na tabela de partida essa operação é executada também nos registos relacionados na tabela de chegadaSET 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. 13. CASCADE DELETEResultados 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. 14. E se for uma actualização do valor da chaveprimária?Os mecanismos que permitem definir como reagir ao evento de apagarexistem também para o evento de actualizar.

×