Upload
carlos-santos
View
961
Download
3
Embed Size (px)
DESCRIPTION
Bases de dados: Tipos de dados, tabelas e chaves primárias
Citation preview
Bases de dados: Tipos de dados, tabelas e chaves primárias
Carlos SantosLabMM 4 - NTC - DeCA - UAAula 03, 23-02-2012
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)
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
Dados numéricos inteiros (MySQL)
BIGINT (8 Bytes)
• -9223372036854775808 … 9223372036854775807• 0 … 18446744073709551615
BOOL, BOOLEAN
• FALSE = 0, TRUE ≠ 0
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
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
Dados Date e Time
TIME
• HH:MM:SS
YEAR (2|4)
• YY (1970-2069)• YYYY (1901-2155)
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
Dados String
TINYTEXT
• 255 caracteres
TEXT
• 65535 caracteres
MEDIUMTEXT
• 16777215 caracteres
LONGTEXT
• 4294967295 caracteres
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
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
Tipos de dados e sua parametrização
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)
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çã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
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
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).
• 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
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
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 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?
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!
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
AlunosNumMecNomeApelido
AnoEntradaUADataNascimento
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...
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
EncomendasNrEnco
NomeVendDataEnco
NomeClienteCustoEncomenda
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
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
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
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
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
VendedoresNrVend NomeVend1 João Tomás
2 Maria Costa
3 Manuel Ribeiro
Clientes
NrCli NomeCliente
1 António Mateus
2 Manuel Lopes
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 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