LabMM4 (T09 - 12/13) - Integridade referencial e normalização

  • 797 views
Uploaded on

 

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
797
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
66
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Bases de dados: Integridade referencial eNormalizaçãoCarlos SantosLabMM 4 - NTC - DeCA - UAAula 09, 14-03-2013
  • 2. 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
  • 3. 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)?
  • 4. 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 2Em muitos casos não se removem registos! Os registos “removidos” sãoguardados num estado de inactivos/invisíveis.Solução: Adicionar coluna extra à tabela (estado: activo/inactivo, 0/1)
  • 5. 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 na tabela de chegada, quando seactualiza/apaga um registo na tabela de partida (do lado da PK)
  • 6. Foreign Key Options [Foreign Key Constraints]RESTRICT • Não é permitido atualizar/apagar um registo na tabela de partida se este tiver registos relacionados na tabela de chegadaNO ACTION • Funcionamento idêntico ao RESTRICTCASCADE • Ao atualizar/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)
  • 7. CASCADE DELETEResultados potencialmente catastróficos para a base de dados! • Imaginemos um cenário de uma BD para uma loja que só tem um vendedor e que está associado a todas as vendas efetuadas. • Se todas as relações da BD estiverem com CASCADE DELETE, o que acontece se o vendedor for apagado?
  • 8. 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.
  • 9. NormalizaçãoProcesso de organizar os campos e tabelas de uma base de dadosrelacional de modo a minimizar a redundância e dependência dos dados • é essencial para que se possa tirar partido do SQLObjetivos: • libertar a BD de anomalias de edição • minimizar necessidades de redesenho da BD quando é necessário estender a sua implementação • tornar o modelo de dados mais informativo para os utilizadores • evitar tendência do modelo relativamente a um determinado padrão de queries(http://en.wikipedia.org/wiki/Database_normalization)
  • 10. Primeira regra de normalização (First normal form)Eliminação de grupos repetitivos: • A primeira regra de normalização envolve a eliminação de grupos repetitivos dentro de um qualquer campo. ENCOMENDAS NrEncom DataEncomenda DataPagamento Produto Quantidade Mesa de Sala 1 1 12-09-2000 12-09-2000 Sofá 2 Cadeira 12 Cadeira 2 2 30-08-2001 11-12-2001 Aparador 1 3 21-01-2000 24-01-2000 Sofá 3
  • 11. Segunda regra de normalização(Second normal form)Eliminação de dados redundantes (na tabela): • a primeira regra de normalização tem que ser respeitada; • todos os campos que não fazem parte da chave primária são funcionalmente dependentes da totalidade da chave primária; isto é, não podem existir campos que são dependentes apenas de uma parte da chave primária. ENCOM_PROD NrEncom ID_Produto Produto Quantidade 1 1 Cadeira 12 1 2 Mesa de Sala 1 2 3 Aparador 2 • Neste caso, o campo “Produto” é dependente do campo “ID_Produto” que é apenas uma parte da chave primária, logo a tabela não se encontra de acordo com a segunda regra de normalização.
  • 12. Terceira regra de normalização (Third normal form)Eliminação de campos que não são dependente das chaves: • a segunda regra de normalização tem que ser respeitada; • todos os campos que não são chaves têm que ser independentes entre si. Ou seja, para os campos que não são chaves, o valor de uma dado campo não pode depender do valor de outro campo. VENDEDOR NrVendedor Nome Apelido CodPostal Localidade 1 João Tomás 3810 Aveiro 1 Maria Costa 3830 Ílhavo 2 Manuel Ribeiro 1000 Lisboa • Neste caso, o campo “Localidade” é dependente do campo “CodPostal”, logo a tabela não se encontra de acordo com a terceira regra de normalização. • Por vezes, em situações práticas, pode ser conveniente não aplicar totalmente esta regra de normalização.... • Campos calculados também são “proibidos” por esta regra.
  • 13. Regras de normalizaçãoMais regras de normalização: • Boyce/Codd Normal Form • Quarta regra de normalização (Fourth normal form) • Quinta regra de normalização (Fifth normal form) • Domain Key/Normal Form • ...Estas regras raramente têm que ser aplicadas porque só fazem sentidoem situações muito complexas que raramente são encontradas no mundoreal.
  • 14. DesnormalizaçãoEm condições específicas deve ser realizada, por exemplo, para melhorara performance...
  • 15. E a seguir?SQL vs noSQLMini-teste e... PHP