LabMM4 (T03 - 12/13) - Chaves primárias

483 visualizações

Publicada em

Publicada em: Educação
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
483
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
63
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

LabMM4 (T03 - 12/13) - Chaves primárias

  1. 1. Bases de dados: Tabelas e chaves primáriasCarlos SantosLabMM 4 - NTC - DeCA - UAAula 03, 21-02-2013
  2. 2. Tipos de dados e sua parametrizaçãoMySQL Worksbench
  3. 3. Parametrização(PK) PRIMARY KEY • Transforma a coluna numa chave primária • Nessa coluna não poderão existir valores nulos ou repetidos • Identifica de forma unívoca cada novo registo na tabela(NN) NOT NULL • Nessa coluna não poderão existir valores nulos/vazios(UQ) UNIQUE • Na coluna todos os valores serão únicos (com exceção dos nulos que se poderão repetir)
  4. 4. Parametrização(ZF) ZEROFILL • Preenche com zeros à esquerda a representação de um valor numérico • 5 -> 000005(AI) AUTO INCREMENT • Auto incrementa o valor inteiro que será armazenado na coluna a cada novo registo (último valor +1) • Usado normalmente com chaves primárias (PK)(BIN) BINARY • Usado com os tipos CHAR e VARCHAR
  5. 5. ParametrizaçãoDefault • Define um valor por defeito para a coluna, caso não seja introduzido qualquer valor(UN) UNSIGNED • Permite armazenar apenas valores positivos (sem sinal) do tipo de dados selecionado
  6. 6. Chaves primárias (PK)Regra Nr. 2 (Codd) – Garantia de acesso • Qualquer e todo o dado armazenado numa base de dados relacional tem que ser garantidamente acessível através de uma combinação única de nome da tabela, valor da chave primária e nome da coluna (campo). id nMec Nome Apelido AnoEntradaUA DataNascimento 1 23594 João Gomes 2002 10-04-1978 2 34921 Lurdes Costa 2008 19-02-1980 3 33482 Manuel Martins 2007 23-03-1981 4 18923 Ana Lopes 1995 08-12-1977 • Todas as tabelas têm que possuir uma chave primária • Simples (uma coluna) ou Composta (associação de múltiplas colunas) • Todos os valores de uma chave primária têm que ser distintos e não nulos
  7. 7. Quais os erros? id nMec Nome Apelido AnoEntradaUA DataNascimento 1 23594 João Gomes 2002 10-04-1978 20 34921 Lurdes Costa 2008 19-02-1980 3 33482 Manuel Martins 2007 23-03-1981 4 Ana Lopes 1995 08-12-1977 3 22111 Bernardete Aveiro 2004 04-12-1980 43000 Marco António 2000 24-10-1985
  8. 8. Quais os erros? id nMec Nome Apelido AnoEntradaUA DataNascimento 1 23594 João Gomes 2002 10-04-1978 20 34921 Lurdes Costa 2008 19-02-1980 3 33482 Manuel Martins 2007 23-03-1981 4 OK Ana Lopes 1995 08-12-1977 3 22111 Bernardete Aveiro 2004 04-12-1980 NOK 43000 Marco António 2000 24-10-1985
  9. 9. Chaves primárias (PK)Como é que podemos obter uma boa chave primária? • Gestão automática através do SGBDR • Auto Increment no MySQLVerificar se alguns dos campos da tabela têm as característicasnecessárias para serem considerados boas chaves primárias (chavescandidatas) • Número de BI? • Número mecanográfico da UA? • Email da UA? • Número de telefone?
  10. 10. Chaves primárias (PK)Valores únicos e não nulos não implicam que uma chave primária sejaconstituída apenas por um campo da tabela! • A chave primária de uma tabela pode ser construída pela associação de vários campos (normalmente não se utilizam mais do que 2) • Código postal (3810-193)? • Como regra geral, podemos afirmar que é preferível evitar criar chaves primárias a partir de vários campos. No entanto, iremos verificar que em casos especiais a sua utilização é essencial!
  11. 11. Modela uma tabelaIdentificar a entidade/conceito, cujos dados irão ser armazenadosIdentificar as propriedades que caracterizam a entidade e que devem serarmazenadas • Exemplo: Tabela para armazenar alunos da UA • Entidade: Aluno da UA • Propriedades: Características que descrevem um aluno da UA Aluno NumMec Nome Apelido AnoEntradaUA DataNascimento
  12. 12. Modelar uma tabela (dicas)Perguntar sempre: • Que dados quero armazenar na tabela? • Que dados quero extrair da tabela?Garantir a consistência dos dados • Escolher o tipo de dados mais adequado para cada coluna • Parametrizar os dados que irão ser armazenados em cada colunaNão armazenar dados redundantes • Não armazenar dados que possam ser calculados através de outros existentes na tabela (ou na BD) • Otimizar o armazenamento de dados que se repitam frequentemente...
  13. 13. BD com uma única tabela (Problemas)Narrativa • Armazenar todas as encomendas de uma loja de decoração, sendo necessário registar o nome do vendedor, a data da encomenda, o nome do cliente e o custo da encomenda Encomenda NrEnco NomeVend DataEnco NomeCliente CustoEncomenda
  14. 14. Será uma solução adequada? Encomenda NrEnco NomeVend DataEnco NomeCliente CustoEnco 1 João Tomás 01-03-2000 Sr. António Mateus 200 2 Maria Costa 01-06-1999 António Mateus 150 3 Maria Costa 01-06-1999 Manuel Lopes 100 4 Manuel Ribeiro 01-10-2002 Prof. Ant. Mateus 300 5 Maria C. 01-06-1999 Luis Sousa 200
  15. 15. Será uma solução adequada? Encomenda NrEnco NomeVend DataEnco NomeCliente CustoEnco 1 João Tomás 01-03-2000 Sr. António Mateus 200 2 Maria Costa 01-06-1999 António Mateus 150 3 Maria Costa 01-06-1999 Manuel Lopes 100 4 Manuel Ribeiro 01-10-2002 Prof. Ant. Mateus 300 5 Maria C. 01-06-1999 Luis Sousa 200
  16. 16. Problemas com tabelas únicasInformação redundante • Informação é repetida na tabela • Ocupa mais espaço e potencia consultas com respostas mais lentas • Torna o processo de inserir novos dados repetitivo e demoradoErros de tipografia • Por lapso os dados podem ser introduzidos com erros • Diferentes operadores podem tratar a mesma informação de modo distintoAtualizar ou modificar informação • Operações de alteração ou modificação de dados podem ser difíceis de implementar para dados que são repetidos muitas vezes na tabela
  17. 17. Solução - BD com várias tabelas!Narrativa: identificar entidades/objetos (procurar nomes) • Armazenar todas as encomendas de uma loja de decoração, sendo necessário registar o nome do vendedor, a data da encomenda, o nome do cliente e o custo da encomenda
  18. 18. Solução - BD com várias tabelas! Encomenda NrEnco NrVend DataEnco NrCli CustoEnco 1 1 01-­‐03-­‐2000 1 200 2 2 01-­‐06-­‐1999 1 150 3 2 01-­‐06-­‐1999 2 100 4 3 01-­‐10-­‐2002 1 300 5 2 01-­‐06-­‐1999 3 200 Vendedor Cliente NrVend NomeVend NrCli NomeCliente 1 João  Tomás 1 António    Mateus 2 Maria  Costa 2 Manuel  Lopes 3 Manuel  Ribeiro 3 Luís  Sousa
  19. 19. Problemas foram resolvidos?Informação redundante • A informação de cada vendedor é armazenada apenas uma vez na tabela VENDEDORES • Para cada encomenda o espaço ocupado para armazenar a informação do vendedor é muito reduzido • Para cada encomenda, caso sejam adotadas as estratégias adequadas, identificar o vendedor é um processo rápido e simplesErros de tipografia • Se existirem erros eles apenas são introduzidos uma vez • Possibilidade de erros introduzidos por diferentes operadores é reduzidaAtualizar ou modificar informação • Qualquer tipo de alteração relativa à informação dos vendedores apenas tem que ser realizada num único local, sendo por isso um processo simples e rápido de realizar

×