O documento discute tabelas e chaves primárias em bases de dados. Explica como parametrizar colunas usando PRIMARY KEY, NOT NULL, UNIQUE, ZEROFILL, AUTO_INCREMENT, BINARY e DEFAULT. Também discute como escolher boas chaves primárias e modelar tabelas para evitar redundância de dados.

1. Bases de dados: Tabelas e chaves primárias
Carlos Santos
LabMM 4 - NTC - DeCA - UA
Aula 03, 21-02-2013

2. Tipos de dados e sua parametrização
MySQL Worksbench

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. 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. Parametrização
Default
• 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. 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. 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. 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. Chaves primárias (PK)
Como é que podemos obter uma boa chave primária?
• Gestão automática através do SGBDR
• Auto Increment no MySQL
Verificar se alguns dos campos da tabela têm as características
necessárias para serem considerados boas chaves primárias (chaves
candidatas)
• Número de BI?
• Número mecanográfico da UA?
• Email da UA?
• Número de telefone?

10. Chaves primárias (PK)
Valores únicos e não nulos não implicam que uma chave primária seja
constituí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. Modela uma tabela
Identificar a entidade/conceito, cujos dados irão ser armazenados
Identificar as propriedades que caracterizam a entidade e que devem ser
armazenadas
• 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. 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 coluna
Nã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. 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. 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. 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. Problemas com tabelas únicas
Informaçã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 demorado
Erros de tipografia
• Por lapso os dados podem ser introduzidos com erros
• Diferentes operadores podem tratar a mesma informação de modo
distinto
Atualizar 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. 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. 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. 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 simples
Erros de tipografia
• Se existirem erros eles apenas são introduzidos uma vez
• Possibilidade de erros introduzidos por diferentes operadores é reduzida
Atualizar 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