LabMM4 (T03 - 12/13) - Chaves primárias
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 672 views

 

Statistics

Views

Total Views
672
Views on SlideShare
670
Embed Views
2

Actions

Likes
0
Downloads
60
Comments
0

1 Embed 2

http://campus.sapo.pt 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Bases de dados: Tabelas e chaves primáriasCarlos SantosLabMM 4 - NTC - DeCA - UAAula 03, 21-02-2013
  • Tipos de dados e sua parametrizaçãoMySQL Worksbench
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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?
  • 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!
  • 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
  • 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...
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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