Bases de dados: Tipos de dados, tabelas e chaves primárias

1. Bases de dados: Tipos de dados, tabelas e
chaves primárias
Carlos Santos
LabMM 4 - NTC - DeCA - UA
Aula 03, 23-02-2012

2. Tipos de dados no MySQL
Organização em 3 grupos
• Numeric
• Todo o tipo de valores numéricos
• Integer (inteiros) -> 2
• Floating point (números com parte decimal [, ou .]) -> 2.345
• Date and Time
• Dados relacionados com datas, horas, …
• String
• Sequência de caracteres, texto, símbolos (frases, palavras)

3. Dados numéricos inteiros (MySQL)
Especificar: Signed ou Unsigned
TINYINT (1 Byte)
• -128 … 127 ou 0 … 255
SMALLINT (2 Bytes)
• -32768 … 32767 ou 0 … 65535
MEDIUMINT (3 Bytes)
• -8388608 … 8388607 ou 0 … 16777215
INT (4 Bytes)
• -2147483648 … 2147483647 ou 0 … 4294967295

4. Dados numéricos inteiros (MySQL)
BIGINT (8 Bytes)
• -9223372036854775808 … 9223372036854775807
• 0 … 18446744073709551615
BOOL, BOOLEAN
• FALSE = 0, TRUE ≠ 0

5. Dados numéricos com parte decimal (MySQL)
DECIMAL
• Número armazenado como String (texto)
DOUBLE
• -1,798E+308 … -2,225E-308
• 2,225E-308 … 1,798E+308
FLOAT
• -3,403E+38 … -1,175E-38
• 1,175E-38 … 3,403E+38

6. Dados Date e Time
DATE
• YYYY-MM-DD
DATETIME
• YYYY-MM-DD HH:MM:SS
TIMESTAMP (M)
• (14) YYYY-MM-DD HH:MM:SS
• (8) YYYY-MM-DD
• (4) YY-MM
• (2) YY

7. Dados Date e Time
TIME
• HH:MM:SS
YEAR (2|4)
• YY (1970-2069)
• YYYY (1901-2155)

8. Dados String
CHAR(M)
• (1-255) Sequência de caracteres de tamanho fixo
VARCHAR(M)
• Sequência de caracteres de tamanho variável
• Pode armazenar até um máximo de M caracteres
• Otimiza o espaço necessário ao armazenamento

9. Dados String
TINYTEXT
• 255 caracteres
TEXT
• 65535 caracteres
MEDIUMTEXT
• 16777215 caracteres
LONGTEXT
• 4294967295 caracteres

10. Dados String
Strings binárias
• Permitem armazenar ficheiros (imagens, sons, vídeos, etc) na BD
BLOB (Binary Large Object)
• Sequência de caracteres que codificam uma imagem, som
TINYBLOB - 255 caracteres
BLOB - 65535 caracteres
MEDIUMBLOB - 16777215 caracteres
LONGBLOB - 4294967295 caracteres

11. Dados String
Strings de elementos
• Definem uma gama de valores possíveis, para os dados a armazenar
ENUM (“elemento1”, “elemento2”,…,”elemento65535”)
• Armazena um elemento do conjunto
SET (“elemento1”, “elemento2”,…,”elemento64”)
• Armazena zero ou mais elementos do conjunto

12. Tipos de dados e sua parametrização

13. 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 excepção dos nulos que se
poderão repetir)

14. 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

15. Parametrização
Default
• Assegura que existe 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

16. Motores de armazenamento para as tabelas
No MySQL
• MyISAM
• Motor tradicional no MySQL
• Maior portabilidade das tabelas
• Armazena mais dados, num menor espaço
• Permite a compressão dos dados
InnoDB
• Suporta chaves estrangeiras
• Mecanismos de recuperação
• Suporta transacções

17. 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

18. 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

19. 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

20. 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?
• Número de telefone?

21. 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!

22. 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
Alunos
NumMec
Nome
Apelido
AnoEntradaUA
DataNascimento

23. 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)
• Optimizar o armazenamento de dados que se repitam frequentemente...

24. 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
Encomendas
NrEnco
NomeVend
DataEnco
NomeCliente
CustoEncomenda

25. Será uma solução adequada?
Encomendas
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

26. Será uma solução adequada?
Encomendas
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

27. 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
Actualizar ou modificar informação
• Operações de alteração ou modificação de dados podem ser difíceis de
implementar se esses dados são repetidos muitas vezes na tabela

28. Solução - BD com várias tabelas!
Narrativa: identificar entidades/objectos
• 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

29. Solução - BD com várias tabelas!
Encomendas
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
Vendedores Clientes
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

30. 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 adoptadas 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
Actualizar 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