Você está na página 1de 106

COLÉGIO SAPULA

TLP–Técnicas e Linguagens de Programação


Curso de Informática > 12ª Classe

Ano letivo 2016

FUNDAMENTOS DE  Gabriel Muhanda


BASE DE DADOS  gabrielcc26@gmail.com
TÉCNICAS E LINGUAGENS DE PROGRAMAÇÃO

FUNDAMENTOS DE BASE DE DADOS


CAPÍTULO 01 – INTRODUÇÂO À BASE DE DADOS
1. NOÇÕES BÁSICAS DE BASE DE
DADOS
DADOS: são os elementos básicos pertencentes a um conjunto determinado de
informações.
Fundamentos de base de dados

INFORMAÇÃO: é o resultado da aplicação de um conjunto de operações sobre os


dados.
BANCO DE DADOS OU BASE DE DADOS: são arquivos ou sistemas com uma
estrutura regular que organizam informações. Essas estruturas podem ter a forma
de uma tabela, onde cada tabela é composta por linhas e colunas.
Em sistemas computacionais, bases de dados são gerenciadas por um sistema
gerenciador de bancos de dados, ou SGBD. A apresentação dos dados pode ser
semelhante à de uma planilha eletrônica, porém os sistemas de gestão de banco
de dados possuem características especiais para o armazenamento, classificação
e recuperação dos dados
Página 2
1. NOÇÕES BÁSICAS DE BASE DE
DADOS
SISTEMA DE GERENCIAMENTO DE BASE DE DADOS(SGBD): é um software com
Fundamentos de base de dados

recursos específicos para facilitar a manipulação das informações dos bancos de


dados e o desenvolvimento de programas aplicativos, como exemplo: Oracle,
MySQL, SQL Server, etc…
DATA BASE ADMINSTRATOR(DBA):é a pessoa que cria e gere a base de dados. O
administrador do banco de dados, pode não ser um programador.

Página 3
2. CARACTERÍSTICAS DA BASE DE
DADOS
Uma base de dados deve ter basicamente as seguintes características:
Fundamentos de base de dados

Ser não redundante, não ter duplicidades de informações;


Ser independente dos programas;
Ser utilizável por todos os programas;
Incluir todas as inter-relações de dados que forem necessárias;
Possuir um método comum de recuperar, inserir e corrigir os dados d banco.

Página 4
3. TIPOS DE BASE DE DADOS
Existem maneiras diferentes de modelar uma base de dados, a escolha de cada
Fundamentos de base de dados

uma delas, geralmente depende de alguns fatores que o DBA achar conveniente,
dentre os tipo de base de dados podemos encontrar os seguintes:
Base De Dados Relacional;
Base De Dados De Redes;
Base De Dados Hierárquico;
Base De Dados Orientado a Objectos.

Página 5
3. TIPOS DE BASE DE DADOS
BASE DE DADOS RELACIONAL: neste modelo, dados e relacionamento entre
Fundamentos de base de dados

dados são representados por tabelas, cada uma com suas colunas específicas.
NOME IDADE MARCA DO TELEFONE
Anacleto 18 Xperia Z1
Anacleto 18 Nokia 1100
Anacleto 18 Phablet HP
Gabriel 17 Ascend P6
Mariano 18 Phablet HP
Mariano 18 Siemens 998
Cecília 13 Siemens 998

Página 6
3. TIPOS DE BASE DE DADOS
BASE DE DADOS DE REDE: neste modelo os dados são representados por
Fundamentos de base de dados

coleções de registros e os relacionamentos por elos.


Xperia Z1
Anacleto 18 Nokia 1100

Phablet HP
Mariano 18
Siemens 998
Cecília 15

Gabriel 17 Ascend P6

Página 7
3. TIPOS DE BASE DE DADOS
BASE DE DADOS HIERÁRQUICA: este modelo é semelhante ao modelo de rede,
Fundamentos de base de dados

com a diferença de que neste, os registros são organizados como coleções


arbitrárias de árvores.

Anacleto 18 Cecília 15 Mariano 18 Gabriel 17

Xperia Z1 Phablet HP Siemens 998 Phablet HP Siemens 998 Ascend P6

Nokia 1100

Página 8
3. TIPOS DE BASE DE DADOS
BASE DE DADOS ORIENTADO A OBJECTOS: neste modelo as informações são
Fundamentos de base de dados

armazenadas em forma de objetos, utilizando estruturas de dados.

Nesta matéria aprendermos o fundamento de base de dados relacional.

Página 9
4. VANTAGENS DO USO DE BASE DE
DADOS
Para qualquer instituição, o mais importante, não é ter todos os materiais físicos
bem controlados, as sim ter um controle rigoroso nos dados que controlam os
Fundamentos de base de dados

meios físicos.
Dentre as grandes vantagens em usar um banco de dados, temos as seguintes:
Diminuir o espaço ocupado pela informação;
Facilitar o acesso e a atualização da informação;
Aumentar a velocidade da pesquisa;
Evitar a redundância da informação;
Facilitar o backup e recuperação à falhas;
Fortificar a partilha de dados.
Página 10
TÉCNICAS E LINGUAGENS DE PROGRAMAÇÃO

FUNDAMENTOS DE BASE DE DADOS


CAPÍTULO 02 – SISTEMA DE BASE DE DADOS RELACIONAL
1. GESTÃO E ORGANIZAÇÃO DA
INFORMAÇÃO NA BASE DE DADOS
Ao criarmos uma base de dados num SGBD, antes devemos ter em conta alguns
Fundamentos de base de dados

procedimentos, procedimentos estes que facilitarão o desenho, bem como a


estrutura da base de dados.
Para construirmos eficientemente uma base dados recomenda-se as seguintes
fase:
Analise Dos Requisitos
Modelo Conceptual
Modelo Lógico
Modelo Físico

Página 12
1. GESTÃO E ORGANIZAÇÃO DA
INFORMAÇÃO NA BASE DE DADOS
ANÁLISE DE REQUISITOS: nesta fase, devemos como DBA identificar ou descrever
Fundamentos de base de dados

os dados/informações e processos pretendidos pela organização.


MODELO CONCEPTUAL: nesta fase, nos baseamos na representação da
realidade, sem termos em conta os aspectos técnicos, ou seja, nesta fase não
importa ainda a tecnologia ou o tipo de banco de dados a se utilizar.
MODELO LÓGICO: esta fase agrega mais detalhes sobre a implementação da base
de dados. Nesta da fase transformamos o modelo conceptual em um modelo que
fica muito próximo ao modelo físico da base de dados
MODELO FÍSICO: este modelo consiste em definir estruturas físicas de dados que
sejam mais adequadas num ambiente informático particular.

Página 13
2. ANALISE DE REQUISITOS
Na fase de analise de requisitos devemos ter o grande foco em obter as:
Fundamentos de base de dados

informações que descrevem as estruturas de dados, tais como as entidades,


atributos e as associações;
informação que descreva as regras ou restrições que preservem a integridade
dos dados;
informação acerca dos processamentos operacionais e de gestão necessários ao
negócio da organização.
 informações das necessidades e requisitos dos utilizadores

Página 14
2. ANALISE DE REQUISITOS
Existe vários métodos ou técnicas de levantamentos de requisitos, os mais usados
Fundamentos de base de dados

são:
Documentação;
Observação;
Entrevista.

Página 15
3. MODELO CONCEPTUAL
Existem diferentes maneiras de criar o modelo conceptual da base de dados,
Fundamentos de base de dados

particularmente, usaremos o Diagrama Entidade-Associação.


DIAGRAMA ENTIDADE-ASSOCIAÇÃO(D.E.A.): também é conhecido como
Diagrama Entidade-Relacionamento(D.E.R.) esta fase consiste em usar algumas
figuras geométricas para desenhar ou esquematizar a base de dados

ENTIDADE associacao ENTIDADE

Página 16
3. MODELO CONCEPTUAL
Os principais elementos do modelo conceptual são:
Fundamentos de base de dados

Entidade;
Atributo;
Associação;
Entidade Associativa;
Generalização.

Página 17
3. MODELO CONCEPTUAL
-ENTIDADE
ENTIDADE: são objetos ou conceitos que sobre o qual pretende-se armazenar as
Fundamentos de base de dados

informações. As entidades, devem inequivocamente identificar algo para a


organização(parte beneficiária da base de dados).
Exemplo: Aluno, Professor, Curso, Filme, Carro, Cantor, Agencia, Armazém, etc.
Graficamente as entidades são representadas geralmente por retângulos,
colocando por dentro do mesmo o nome da entidade.

NOME_DA_ENTIDADE

Os nomes das entidades por recomendações devem ser substantivos e escritos no


singular.
Página 18
3. MODELO CONCEPTUAL
-ATRIBUTO
ATRIBUTOS: são as propriedades de uma entidade. Para cada entidade de
Fundamentos de base de dados

preferência colocarmos somente os atributos relevantes ao sistema a se


desenvolver.
Exemplo: nome, numeroDoBilhete, dataDeNascimento, endereco, filiacao, etc.

Os atributos estão divididos em:


Atributo Mono-Valorado: é aquele que assume um único valor para cada registo
da entidade, também são chamados de atributos atómicos(ou indivisíveis).
Exemplo: nome, numeroDoBI, idade, etc.

Página 19
3. MODELO CONCEPTUAL
-ATRIBUTO
Atributo Multi-Valorado: é aquele que pode assumir um ou mais valores para
Fundamentos de base de dados

cada registo da entidade.


Exemplo: telefone, email, nacionalidade, etc.

Atributo Composto: é aquele que é formado por dois ou mais atributos.


Exemplo: endereco, filiacao, etc.
Independentemente do tipo, os atributos devem ser identificadores ou descritores

Página 20
3. MODELO CONCEPTUAL
-ATRIBUTO
Identificadores: são os atributos de uma entidade que identificam uma ocorrência
Fundamentos de base de dados

específica dessa entidade, diferenciando-as das restantes.


Para que um atributo seja identificador é necessário que não existam duas
ocorrências distintas dessa entidade nas quais o atributo tenha o mesmo valor.
Descritores ou Atributos Normais: são os atributos que apenas descrevem ou
caracterizam as ocorrências de uma entidade
num_BI
nome

morada
PESSOA

Página 21
3. MODELO CONCEPTUAL
-ASSOCIAÇÃO
ASSOCIAÇÕES: são as relações de grande relevância entre as entidades.
Fundamentos de base de dados

Geometricamente elas são representadas por um losangulo, sendo que dentro


deste encontramos a descrição da mesma associação, possui ainda um elo entre
as entidades relacionadas.
nome_da
Podemos encontrar os seguintes tipos de associações: associação

Associação Unária: quando a entidade relaciona a si própria;


Associação Binária: relaciona duas entidades;
Associação Complexa: relaciona várias entidades.

Página 22
3. MODELO CONCEPTUAL
-ASSOCIAÇÃO
GRAU DE UMA ASSOCIAÇÃO(CARDINALIDADE): representa quantitativamente as
ocorrências que uma entidade terá na realização da outra entidade.
Fundamentos de base de dados

Quando as entidade associam-se poderemos encontrar as seguintes


cardinalidades:
Associação 1:1 (Um para Um)
Associação 1:N (Um para Muitos)
Associações N:M (Muitos para Muitos)
As entidades participam nas associações de forma obrigatória e não obrigatória
OBRIGATÓRIA: é quando o lado da cardinalidade começa com 1
NÃO OBRIGATÓRIA: é quando o lado da cardinalidade começa com 0
Página 23
3. MODELO CONCEPTUAL
-ASSOCIAÇÃO
Associação Unária
Fundamentos de base de dados

Um funcionário pode registar nenhum o vários funcionários, e cada funcionário


é registado p 1 e somente 1 funcionário.

Funcionário regista

Página 24
3. MODELO CONCEPTUAL
-ASSOCIAÇÃO
Associação Binária
Fundamentos de base de dados

Numa escola um aluno deve ter um ou vários processos e cada processo deve
pertence a um e somente um aluno. A entidade ALUNO é obrigatória

ALUNO possui PROCESSO

Numa escola um aluno deve ter um ou vários processos e cada processo deve
pertence a um ou nenhum aluno. A entidade ALUNO não é obrigatória

ALUNO possui PROCESSO

Página 25
3. MODELO CONCEPTUAL
-ASSOCIAÇÃO
Associação Complexa
Fundamentos de base de dados

A placa mãe de um computador tem um ou nenhum gabinete, a mesma placa


mãe suporta um e somente um processador, a placa mãe também uma ou varias
entrada SATA

Página 26
3. MODELO CONCEPTUAL
-ASSOCIAÇÃO
Associação Complexa
Fundamentos de base de dados

PLACA_MAE

PROCESSADOR contem GABINETE

ENTRADA SATA

Página 27
3. MODELO CONCEPTUAL
-EXTREMIDADE DA CARDINALIDADE
Fundamentos de base de dados

Podemos usar qualquer


Um E Somente Um Ou uma das representações
mostrada ao lado.
___________________________
Nenhum Ou Um Ou O primeiro número indica
a obrigatoriedade da
entidade, ou o número
mínimo de ocorrência.
Um Ou Vários Ou ___________________________
O ultimo número indica o
número máximo de
ocorrência de uma
Nenhum Ou Vários Ou entidade

Página 28
3. MODELO CONCEPTUAL
-ENTIDADE ASSOCIATIVA
ENTIDADE ASSOCIATIVA: uma entidade é dita como associativa quando ela não
Fundamentos de base de dados

existe por si só, sendo que a sua existência está condicionada à existência de duas
ou mais entidades. Nestas o seu identificador é formado pela concatenação dos
identificadores das entidades que se associam para lhe dar origem.
As entidades associativas, pelo facto de também serem entidades, possuem
atributos próprios. Elas são representadas por um quadrado com um losango no
seu interior

NOME

Página 29
3. MODELO CONCEPTUAL
-ENTIDADE ASSOCIATIVA
As entidades associativas surgem quando a entidade A para se relacionar com a
Fundamentos de base de dados

entidade B, necessita de alguns atributos, atributos estes que não pertencem à


entidade A nem na entidade B.
Exemplo: Um aluno pode fazer nenhuma ou varias provas, mas sabe-se a sua nota
e numero de ordem em cada prova feita.

num_BI disciplina
nome
nota num_ordem
data

codigo
ALUNO faz PROVA

Página 30
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
GENERALIZAÇÃO DE ENTIDADE: é quando uma entidade possui sub-entidades.
Fundamentos de base de dados

Uma entidade A é generalizada se existe as Entidades A1, A2,….,An, tal que A1, A2,
ou An É UM TIPO DE A.
Ao caso anterior diz-se que A é uma ENTIDADE GENÉRICA ou ENTIDADE MÃE ou
SUPER-ENTIDADE e A1, A2,…, An são ENTIDADES ESPECIFICAS ou ENTIDADES
FILHAS ou SUB-ENTIDADES de A.
Na generalização, as sub-entidades herdam todos os atributos da super-entidade.
A generalização, geometricamente é representada por um triangulo, sendo que o
triangulo aponta para a entidade mãe.

Página 31
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
Exemplo: Numa escola, o
Fundamentos de base de dados

professor leciona as aulas e o


aluno participa nas aulas. Sabe-se
também que o professor e o
aluno participam nas atividades
extra escolar.

Atributos do ALUNO={num_BI, nome, sexo, num_processo, tipo_aluno}


Atributos do PROFESSOR={num_BI, nome, sexo, num_agente, escalão, categoria}
Página 32
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
Estamos perante a especificação, quando a leitura é feita da super-entidade para
Fundamentos de base de dados

a(s) sub-entidade(s)(top-down)
Estamos perante a generalização quando a leitura é feita da(s) sub-entidade(s)
para a super-entidade(bottom-up).

GENERALIZAÇÃO
ESPECIFICAÇÃO

Página 33
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
Uma generalização pode ser classificada quanto as restrições de Totalidade e de
Fundamentos de base de dados

Exclusividade.
Restrição De Totalidade ou Cobertura:
TOTAL: para cada ocorrência de uma super-entidade existe sempre uma
ocorrência em uma das sub-entidades. Esta restrição podemos representar por t.
PARCIAL: nem toda ocorrência da super-entidade possui sempre uma ocorrência
correspondente em uma sub-entidade. Esta restrição pode ser representada
pela letra p.

Página 34
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
Restrição De Exclusividade:
Fundamentos de base de dados

EXCLUSIVA: nesta restrição, uma ocorrência da super-classe possui nenhuma ou


uma correspondência nas sub-entidades(não mais do que isso). Podemos
representa-la pela letra e.
OVERLAPPING ou NÃO EXCLUSIVA: nesta restrição, uma ocorrência da super-
entidade, pode corresponder a nenhuma ou várias sub-entidades.. Podemos
representa-la pela letra o.
Nota: uma generalização nunca pode ser ao mesmo tempo EXCLUSIVA e
OVERLAPPING, nem TOTAL e PARCIAL ao mesmo tempo. As combinações
possíveis são: (t, e), (t, o), (p, e) e (p, o).

Página 35
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
Fundamentos de base de dados

Página 36
3. MODELO CONCEPTUAL
-GENERALIZAÇÃO
Fundamentos de base de dados

Página 37
3. MODELO CONCEPTUAL
-REFINAMENTO
REFINAMENTO DO MODELO CONCEPTUAL: refinar o modelo conceptual consiste
Fundamentos de base de dados

em fazer com que o desenho feito fique mais próximo do modelo lógico. Em
muitos casos usa-se o refinamento para eliminar as cardinalidades (N:M) e
promover as cardinalidades (1:N)

MODELO NÃO REFINADO

MODELO REFINADO

Página 38
4. MODELO LÓGICO
MODELO RELACIONAL ou MODELO LÓGICO: este modelo baseia-se na ideia de
que todos os dados são armazenados em tabelas. Este agrega mais detalhes da
Fundamentos de base de dados

implementação do sistema. Neste modelo ainda não usa-se uma tecnologia de


base de dados, mas devemos contudo representar o problema tendo em conta a
tecnologia que utilizaremos no modelo físico.
Exemplo: PESSOA(nome, idade, morada, sexo)
Cada entidade por normalidade dá origem a uma relação ou tabela com os
seguintes elementos:
Identificador da relação(chave da relação);
Descritor da relação;
Identificador de outra relação(chave estrangeira).
Página 39
4. MODELO LÓGICO
Uma tabela também é chamada de relação e nela podemos encontrar os
Fundamentos de base de dados

seguintes termos:
Grau  Quantidade de colunas
Atributo  Coluna
Registo ou Ocorrência  Linha
Nº NOME NÚMERO DO BILHETE IDADE SEXO MORADA TELEFONE
01 Anacleto Mimoso 00000011 16 M Cacuaco 912 01 01 01
02 Gabriel Muhanda 00200001 18 M Viana 913 02 02 02
03 Mariano Calelua 20015599 18 M Zango 914 03 03 03
04 Cecília Muhanda 10012200 25 F Quicolo 915 04 04 04

Página 40
4. MODELO LÓGICO
CHAVE CANDIDATA: é um atributo que identifica uma ocorrência. Numa relação
Fundamentos de base de dados

não existe duas ocorrência que possuem a mesma chave candidata.


Exemplo 1: PESSOA(num_BI, nome, idade, telefone, morada)
Na tabela PESSOA acima referida, podemos dizer que os atributos num_BI e
telefone, são chaves candidatas, pois elas permitem identificar uma ocorrência
única na relação.
Exemplo 2: PARTICIPAÇÃO(num_aluno, id_prova, nota, num_ordem)
A tabela PARTICIPACAO é formada por uma única chave candidata que é formada
pelos atributos num_Aluno e id_Prova.
Quando uma chave possui mais de um atributo, chamamos de Chave Composta.
Página 41
4. MODELO LÓGICO
CHAVE PRIMÁRIA(Primay Key): dentre todas as chaves candidatas de uma relação
Fundamentos de base de dados

devemos escolher uma para ser a chave efetiva da relação. Elas são escritas com
uma sublinha continua.
ALUNO(num_BI, nome, classe)
PROVA(id, disciplina)
Obs.: Toda chave primária é uma chave candidata, mas nem toda chave candidata
é uma chave primária.

Página 42
4. MODELO LÓGICO
CHAVE ESTRANGEIRA(Foreign Key): é um atributo cuja ocorrência é uma chave
Fundamentos de base de dados

primaria noutra tabela. Elas são escritas com sublinha tracejada.


Exemplo: SECRETARIO(id_secretario, hora_trabalho, id_fncionario)
Um atributos pode ser em simultâneo chave estrangeira e primária. Quando isso
acontece devemos escreve-lo com duas sublinhas: um tracejada e outra contínua.
As chaves primarias e estrangeiras também podem ser compostas.
Exemplo: ALUNO_PROVA(num_BI_aluno, id_prova, nota, numero_ordem)

Página 43
4. MODELO LÓGICO
TRANSFORMAÇÃO DO MODELO CONCEPTUAL EM RELACIONAL: nesta fase
Fundamentos de base de dados

veremos algumas regras básicas usadas para esta transformação, mas essas regras
não são absolutas. Em muitos casos haverá necessidades de aplicarmos alguns
truques lógicos para fazer a mesma transformação, isto em função das ocorrências
das entidades. Por normalidade cada entidade dá origem a uma relação.

PUBLICACAO(codigo, texto, data, legenda, localizacao, permissao_acesso)


Página 44
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO BINÁRIA 1:1 COM OBRIGATORIEDADE EM AMBOS LADOS: Nesta,
Fundamentos de base de dados

basta uma tabela para representar as duas entidades. Pra tal junta-se os atributos
das duas entidades, e dentre os dois identificadores escolhe-se um para ser a
chave primária da relação.

FUNCIONARIO-ESCRITORIO(num_contr, funcao,horas_extras, num_escritório, piso)

O atributo num_excritorio é uma chave candidata

Página 45
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO BINÁRIA 1:1 SEM OBRIGATORIEDADE EM UM LADO: neste caso,
Fundamentos de base de dados

usamos duas tabelas, sendo que colocaremos o identificador da entidade


obrigatória na tabela correspondente à entidade não obrigatória e este lá será
uma chave estrangeira e candidata.

FUNCIONARIO (num_contribuinte, funcao, horas_extras)


ESCRITORIO(num_escritório, piso, num_contribuinte)

O atributo num_contribuinte na tabela ESCRITORIO é uma chave candidata

Página 46
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO BINÁRIA 1:1 SEM OBRIGATORIEDADE EM AMBOS LADOS: neste
Fundamentos de base de dados

caso, resultará uma terceira tabelas, que será formada pelos identificadores das
duas entidades, ou seja, estes atributos serão chaves candidatas e estrangeiras, e
escolhemos um deles para ser a chave primária.

FUNCIONARIO (num_contribuinte, funcao, horas_extras)


ESCRITORIO(num_escritório, piso)
FUNCIONARIO-ESCRITORIO(num_contribuinte, num_escritorio)

O num_escritorio em FUNCIONARIO-ESCRITORIO é uma chave candidata.


Página 47
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO BINÁRIA 1:N COM OBRIGAÇÃO NO LADO 1: independentemente
Fundamentos de base de dados

se o lado N é obrigatório ou não, casos como esse cria-se apenas duas tabelas,
sendo que a chave primária da entidade do lado 1 será chave estrangeira na
tabela correspondente a entidade do lado N.

FUNCIONARIO (num_contribuinte, funcao, horas_extras, id_categoria)


CATEGORIA(id, escalao)

Página 48
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO BINÁRIA 1:N SEM OBRIGAÇÃO NO LADO 1: independentemente se
Fundamentos de base de dados

o lado N é obrigatório ou não, casos como esse cria-se três tabelas, duas para
representar as entidades, e uma para representar o relacionamento. A tabela que
representará o relacionamento, deverá ter como uma das chaves candidatas a
chave primária da entidade do lado N.

FUNCIONARIO (num_contribuinte, funcao, horas_extras)


DEPARTAMENTO(codigo, nome)
FUNCONARIO-DEPARTAMENTO(num_contribuinte, codigo_departamento)

Página 49
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO BINÁRIA N:M: independentemente das obrigatoriedades dos lados
Fundamentos de base de dados

N e M, esses casos também resolvem-se criando três tabelas, duas para


representar as entidades, e uma para representar o relacionamento. Na tabela que
representará o relacionamento, a chave primária será composta pelas chaves
primárias das tabelas que representam as duas entidades .

PESSOA(num_bi, nome, morada)


FRUTA(codigo, descricao)
PESSOA-FRUTA(num_bi, código_fruta)

Página 50
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO UNÁRIA 1:1 COM OBRIGATORIEDADE EM AMBOS LADOS: em
Fundamentos de base de dados

situações como esta cria-se uma única tabela. Deve-se representar os atributos
repetidamente devido o relacionamento.

CASAMENTO(num_bi, nome, morada, num_bi_conjuge, nome_conjuge, morada_conjuge)

O atributo num_bi_conjuge é uma chave candidata

Página 51
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO UNÁRIA 1:1 SEM OBRIGATORIEDADE EM UM LADO: em situações
Fundamentos de base de dados

como esta cria-se duas tabelas, uma representará a entidade e a outra


representara o relacionamento.

PESSOA(num_bi, nome, morada)


CASAMENTO(num_bi, num_bi_conjuge)

Na tabela CASAMENTO o atributo num_bi_conjuge é uma chave candidata

Página 52
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO UNÁRIA 1:1 SEM OBRIGATORIEDADE EM AMBOS LADOS: em
Fundamentos de base de dados

situações como esta cria-se duas tabela, uma para representar a entidade e a
outra para representar o relacionamento.

PESSOA(num_bi, nome, morada)


CASAMENTO(num_bi, num_bi_conjuge)

Na tabela CASAMENTO o atributo num_bi_conjuge é uma chave candidata

Página 53
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO UNÁRIA 1:N: independentemente das obrigatoriedades dos lados 1
Fundamentos de base de dados

e N, neste casos criar uma única tabela resolve o problema em questão.

PESSOA(num_bi, nome, morada, num_bi_ensina)

O atributo num_bi_ensina sera nulo sempre que uma pessoa não é ensinado por
alguem

Página 54
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO UNÁRIA N:M: independentemente das obrigatoriedades de ambos
Fundamentos de base de dados

lados, em situações como esta cria-se duas tabelas, sendo que uma representará a
entidade e a outra representará o relacionamento.

PESSOA(num_bi, nome, morada)


ENSINAMENTO(num_bi, num_bi2)

Página 55
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
ASSOCIAÇÃO COMPLEXA: para esses casos, geralmente o número de tabelas
Fundamentos de base de dados

criadas é igual ao número de entidades associadas, adicionada de mais uma


entidade para representar o relacionamento. A chave primária da relação
adicionada será a concatenação das chaves das entidades.

PROFESSOR(num_funcionario, nome)
DISCIPLINA(codigo_disciplina, descricao)
ALUNO(num_aluno, nome)
P-D-A(num_func, cod_disc, num_aluno)

Página 56
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
PROFESSOR(num_funcionario, nome)
Fundamentos de base de dados

DISCIPLINA(codigo_disciplina, descricao)
ALUNO(num_aluno, nome)
P-D-A(num_func, cod_disc, num_aluno)

Nota: Associações complexas são casos raros de se utilizar, pois elas podem ser
refinadas em associação binária.

Página 57
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
GENERALIZAÇÃO EXCLUSIVA: independentemente se a generalização é total ou
Fundamentos de base de dados

parcial, devemos criar tabelas de acordo com o número de entidades


(super_entidade + sub_entidades). Na entidade mãe devemos colocar um atributo
com o nome de tipo, categoria ou um nome_personalizado, este atributo é que
permitirá identificar se a super_entidade equivale a qual sub_entidade. O mesmo
valor será nulo se a generalização for parcial
(*,e)

O asterisco(*) dá o significado de que a generalização pode ser


parcial ou total

Página 58
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
Fundamentos de base de dados

O * refere que esta


(*,e) generalização pode ser
parcial ou total
______________________
O atributo categoria
na tabela FUNCIONARIO
representa o tipo de
FUNCIONARIO(num_funcionario,nome, idade, tipo) funcionário que alguém
DIRECTOR(num_funcionario, graduação,…) é, este atributo será
SECRETARIO(num_funcionario, morada,…) nulo se a
PROFESSOR(num_funcionario, hab_literaria,…) generalização for
SEGURANCA(num_funcionário, nome_empresa,…) parcial.

Página 59
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
GENERALIZAÇÃO OVERLAPING: independentemente se a generalização é total
Fundamentos de base de dados

ou parcial, devemos também criar tabelas de acordo com o número de entidades


(super_entidades + sub_entidades). Na entidade mãe podemos não colocar um
atributo identifica se super_entidade equivale a quais das sub_entidades, isto por
ser não exclusiva.
(*,o)

O asterisco(*) significa que a generalização pode ser parcial ou total

Página 60
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
Fundamentos de base de dados

FUNCIONARIO(num_funcionario, nome, idade)


DIRECTOR(num_funcionario, graduação,…)
SECRETARIO(num_funcionario, morada,…) O * refere que esta
PROFESSOR(num_funcionario, hab_literaria,…) generalização pode ser
SEGURANCA(num_funcionário, nome_empresa,…) parcial ou total.

Página 61
4. MODELO LÓGICO
-M. CONCEPTUAL VS M. LÓGICO
Notas para as generalizações:
Fundamentos de base de dados

A super-entidades e cada uma das sub-entidades resultam em tabelas distintas;


Sem tabela da super-entidade , os atributos da super-entidade são copiados
nas tabelas das sub-entidades ;
Nas generalizações as tabelas que representam as sub-entidades podem ter
chaves primária própria;
Todas as tabelas que representam as sub-entidades deverem obrigatoriamente
conter a chave primária da super-entidade como chave estrangeira e candidata.

Página 62
4. MODELO LÓGICO
-NORMALIZAÇÃO
Após a construção do modelo conceptual e a transformação do mesmo em
Fundamentos de base de dados

modelo lógico(ou relacional), o esquema relacional obtido, comummente aparece


com algumas redundâncias e inconsistências.
NORMALIZAÇÃO: são passos aplicados sobre as tabelas de modo a dar
consistência e eficiência no acesso dos dados e evitar a redundância dos mesmos
bem como as anomalias durante a inclusão, exclusão e alteração dos registos.
A normalização tem como objectivo avaliar a qualidade do esquema relacional e
transformá-lo num esquema relacional equivalente, menos redundante e mais
estável.

Página 63
4. MODELO LÓGICO
-NORMALIZAÇÃO
A normalização é baseada em processos que são chamados de formas normais.
Em base de dados, existe seis formas normais:
Fundamentos de base de dados

1. Primeira Forma Normal (1FN);


2. Segunda Forma Normal (2FN);
3. Terceira Forma Normal (3FN);
4. Forma Normal de Boyce-Codd (FNBC);
5. Quarta Forma Normal (4FN);
6. Quinta Forma Normal (5FN).
Obs.: estas formas, devem ser usadas obedecendo as respetivas ordens devido a
dependência que há entre elas.
Página 64
4. MODELO LÓGICO
-NORMALIZAÇÃO
É suficiente dizer que a base dados esta normalizada se pelo menos atingir a
Fundamentos de base de dados

Terceira Forma Normal, portanto, tendo em conta o nosso nível, colocaremos


como limite a 3FN, mas é recomendado a investigação quanto a aplicação das
outras formas.
Normalmente após a aplicação das regras de normalização, algumas tabelas
acabam sendo divididas em duas ou mais tabelas, oque faz com que o esquema
normalizado fique formado por um número maior de tabelas em relação ao
esquema não normalizado.

Página 65
4. MODELO LÓGICO
-PRIMEIRA FORMA NORMAL
PRIMEIRA FORMA NORMAL (1FN): diz-se que uma tabela está na primeira forma
Fundamentos de base de dados

normal, se todos os seus atributos forem mono-valorados, e não causadores de


grupos de repetição.
Os atributos multi-valorados e os compostos, causam sempre a repetição de
dados na tabela, por esta razão é que eles deve ser removidos da tabela.
NUM_BI NOME_COMPLETO TELEFONE ESTADO_CIVIL IDADE
012345 Muhanda Dattebayo 999 223 344 Solteiro 21
012345 Muhanda Dattebayo 944 223 344 Solteiro 21
012345 Muhanda Dattebayo 944 222 555 Solteiro 21
012380 José Mvemba 912 212 121 Casado 22
000125 Mariano Calelua 923 333 334 Casado 20
000125 Mariano Calelua 945 544 455 Casado 20
Página 66
4. MODELO LÓGICO
-PRIMEIRA FORMA NORMAL
Na tabela anterior, a pessoa Muhanda Dattebayo e o Mariano Calelua possuem os
seus dados repetido devido o facto de que o atributo telefone é um atributo
Fundamentos de base de dados

multi-valorado. As grandes inconsistência quando a tabela não esta na 1FN são:


Inserção: para registar os diferentes valores dos atributos multi-valorado, é
necessário a redundância(repetição desnecessária) dos outros atributos;
Alteração: para alterar um atributo nomo-valorado em um registo, é necessário
alterar também noutros registos repetidos;
Eliminação: para eliminar um registos com atributo multi-valorado é necessário
a remoção de outros registos relacionados.
Obs.: não existe um padrão para a resolução destes problemas, cabe ao analista
remover os atributos que causam a repetição, isto em função do problema.

Página 67
4. MODELO LÓGICO
-PRIMEIRA FORMA NORMAL
Resolucao para a tabela PESSOA:
Fundamentos de base de dados

PESSOA(num_BI, nome_completo, estado_civil, idade)


AGENDA_TELEFONICA(num_BI, num_tel)

NUM_BI NOME_COMPLETO ESTADO_CIVIL IDADE NUM_BI NUM_TEL


012345 Muhanda Dattebayo Solteiro 21 012345 999 223 344
012380 José Mvemba Casado 22 012345 944 223 344
000125 Mariano Calelua Casado 20 012345 944 222 555
012380 912 212 121
000125 923 333 334
000125 945 544 455

Página 68
4. MODELO LÓGICO
-PRIMEIRA FORMA NORMAL
Exemplo de outra tabela que não está na 1FN:
Fundamentos de base de dados

ALUNO(num_BI, nome, nome_pai, nome_mae, num_matri, classe, idade)


NUM_BI NOME NOME_PAI NOME_MAE NUM_MATRI CLASSE IDADE
012345 Jonatão Gomes Gomes Joaquim Ana Bela 112 12 18
012380 Bernarda Muhanda Pedro Adao Paula Maria 101 11 22
000125 Mariano Calelua Gomes Calelua Ana Pedro 185 8 14
012212 Marcio Marcio Pedro Adao Paula Maria 211 12 19

Imagine que o casal Gomes Calelua e Ana Pedro pretendem colocar mais dois
filhos na escola, pra tal precisaríamos de inserir novamente o nome do casal.
Para alterar o nome do encarregado Pedro Adao é necessário alterar noutro
registo .
Página 69
4. MODELO LÓGICO
-PRIMEIRA FORMA NORMAL
Resolução do problema da tabela ALUNO:
Fundamentos de base de dados

ALUNO(num_BI, nome, id_pais, num_matri, classe, idade)


PAIS(id, nome_pai, nome_mae) ID NOME_PAI NOME_MAE
1 Gomes Joaquim Ana Bela
2 Pedro Adao Paula Maria
3 Gomes Calelua Ana Pedro

NUM_BI NOME ID_PAIS NUM_MATRI CLASSE IDADE


012345 Jonatão Gomes 1 112 12 18
012380 Bernarda Muhanda 2 101 11 22
000125 Mariano Calelua 3 185 8 14
012212 Marcio Marcio 2 211 12 19

Página 70
4. MODELO LÓGICO
-DEPENDÊNCIAS FUNCIONAIS
DEPENDENCIA FUNCIONAL: é a influência que existe entre os atributos de uma
Fundamentos de base de dados

relação.
Exemplo: num_BI -> nome_pessoa
Diz-se que:
nome_pessoa depende de num_BI
ou
num_BI identifica o nome_pessoa
ou
num_BI influencia na busca do nome_pessoa
Página 71
4. MODELO LÓGICO
-DEPENDÊNCIAS FUNCIONAIS
Uma dependência funcional pode ser: total, parcial ou transitiva.
Fundamentos de base de dados

LISTA_PRESENCA_PROVA(id_aluno, id_prova, nome_aluno, num_ordem, disciplina,


nota, apto_ou_nao_apto)

DEPENDENCIA TOTAL: é quando um atributo depende totalmente da chave


primária. Exemplo: (id_aluno, id_prova)->num_ordem e (id_aluno, id_prova)->nota.
DEPENDENCIA PARCIAL: é quando um atributo pode depender de apenas uma
parte da chave primária. Exemplo: id_aluno-> nome_aluno e id_prova-> disciplina.
DEPENDENCIA TRANSITIVA: é quando um atributo além da chave primária
depende também de outros atributos. Exemplo: nota -> apto_ou_nao_apto
e (id_aluno, id_prova)->nota.

Página 72
4. MODELO LÓGICO
-SEGUNDA FORMA NORMAL
SEGUNDA FORMA NORMAL (2FN): diz-se que uma tabela está na segunda forma
Fundamentos de base de dados

normal, se está na 1FN e não contem dependências parciais.


Considere a seguinte tabela:
AVALIACAO(id_prova, id_aluno, nota, qtde_perguntas, classe_aluno)
ID_PROVA ID_ALUNO NOTA QTDE_PERGUNTAS CLASSE_ALUNO
125 1224 15 11 11
117 1141 13 8 10
100 1224 12 11 12
100 1412 18 11 12
id_prova -> qtde_perguntas | id_aluno -> classe_aluno

Página 73
4. MODELO LÓGICO
-SEGUNDA FORMA NORMAL
Solução:
Fundamentos de base de dados

PROVA(id_prova, qtde_perguntas)
ALUNO(id_aluno, classe_aluno)
AVALIACAO(id_prova, id_aluno, nota)

ID_PROVA QTDE_PERGUNTAS ID_ALUNO CLASSE_ALUNO ID_PROVA ID_ALUNO NOTA


125 9 1224 12 125 1224 15
117 12 1141 11 117 1141 10
100 11 1224 12 100 1224 12
100 13 1412 23 100 1412 18

Página 74
4. MODELO LÓGICO
-TERCEIRA FORMA NORMAL
TERCEIRA FORMA NORMAL (3FN): diz-se que uma tabela está na terceira forma
Fundamentos de base de dados

normal, se está na 2FN e não contem dependências transitivas.


Considere a seguinte tabela:
FUNCIONARIO(id, nome, grau_academico, id_cargo, descrição_cargo)
ID NOME GRAU_ACADEMICO ID_CARGO DESCRICAO_CARGO
125 Jafet Jaime Bacharel 4 Programador
117 Dom Quixote Licenciado 6 DBA
100 Roronoa Zoro Bacharel 6 DBA
214 Hatake Kakashi Mestre 9 Analista
id_cargo -> descricao_cargo

Página 75
4. MODELO LÓGICO
-TERCEIRA FORMA NORMAL
Resolução:
Fundamentos de base de dados

FUNCIONARIO(id, nome, grau_academico, id_cargo)


CARGO(id, descrição_cargo)

ID NOME GRAU_ACADEMICO ID_CARGO ID DESCRICAO_CARGO


125 Jafet Jaime Bacharel 4 4 Programador
117 Dom Quixote Licenciado 6 6 DBA
100 Roronoa Zoro Bacharel 6 9 Analista
114 Hatake Kakashi Mestre 9

Página 76
4. MODELO LÓGICO
-TERCEIRA FORMA NORMAL
Normalize atá à 3FN as seguintes tabelas:
Fundamentos de base de dados

NOTA(num_aluno, nome, curso, num_disciplina, nome_disciplina, cod_professor,


nome_professor, grau_professor, nota)
VENDA(num_pedido, cod_produto, produto, quantidade, valor_unit,subtotal)

Página 77
5. MODELO FÍSICO
-INTRODUÇÃO
MODELO FISICO: Neste modelo cria-se as estruturas que armazenarão os dados
Fundamentos de base de dados

correspondente aos campos/tabelas idealizados nos modelos anteriores, para esta


realização é necessário a escolha de um Sistema Gerenciador de Base de
Dados(SGBD).
Neste curso criaremos as estruturas, utilizando o SGBD MySQL.

Página 78
5. MODELO FÍSICO
-INTRODUÇÃO AO MYSQL
MySQL: é um Sistema de Gerenciamento de Base de Dados livre, que utiliza a
Fundamentos de base de dados

linguagem SQL(Structured Query Language) como interface(mediadora). A sua


primeira versão foi lançaada por volta do ano de 1995 na Suécia por suecos e um
finlandês: David Axmark, Allan Larsson e Michael Widenius.
Devido os seus drives, ela é compatível com as grandes linguagem de
programação como: Delphi, Java, C, C++, C#, Visual Basic, Perl, PHP, ASL e outras.
Os comando em SQL não são case sensitive, ou seja, não há diferença entre
maiúsculo e minúsculo.

Página 79
5. MODELO FÍSICO
-COMPONENTES DO SQL
A linguagem SQL tem quatro grandes componentes:
Fundamentos de base de dados

DDL(DATA DEFINITION LANGUAGE): é a componente que trata das estruturas


ou definições dos dados, tais como a: criação(create), alteração(alter),
descrição(desc) e remoção(drop);
DML(DATA MANIPULATION LANGUAGE): é a componente que trata das
manipulações dos dado, tais como a: inserção(insert), seleção(select),
atualização(update) e remoção(delete);
TML(TRANSACTION MANIPULATION LANGUAGE): é a componente que trata
das transações dos dados;
DCL(DATA CONTROL LANGUAGE): é a componente que trata do controlo dos
dados.

Página 80
5. MODELO FÍSICO
-INSTALAÇÃO DO MYSQL
Fundamentos de base de dados

A INSTALACÃO E CONFIGURAÇÃO DO MYSQL SERÁ


INSTRUIDA NA AULA PRÁTICA, PORTANTO, É
INDISPENSAVEL A PRESENCA DOS
INSTRUENDOS(ALUNOS) NA MESMA…
«instalacao; variáveis de ambiente para o mysql; IDE; criação de usuário; privilegio de usuários»

Página 81
5. MODELO FÍSICO
-COMANDOS PRELIMINARES DO MYSQL
1. CONECTAR UM USUARIO: mysql –u NOME_DO_USUARIO -p;
Fundamentos de base de dados

2. DESCONECTAR UM USUARIO: quit;


3. CRIAR USUÁRIO: create user 'NOME_DO_USUARIO'@'% ou localhost'
identified by 'SENHA';
4. DAR PRIVILEGIOS: grant all privileges on *.* to
'NOME_DO_USUARIO'@'%' with grant option;
5. VISUALIZAR OS BANCOS DE DADOS: show databases;
6. CRIAR BANCO DE DADOS: create database NOME_DA_BASE_DE_DADOS;
7. ACESSAR UM BANCO DE DADOS: use NOME_DO_BANCO_DE_DADOS;
Página 82
5. MODELO FÍSICO
-COMANDOS PRELIMINARES DO MYSQL
8. ELIMINAR UM BANCO DE DADOS: drop database NOME_DO_BANCO;
Fundamentos de base de dados

9. REGISTAR A SENHA DO USUARIO ROOT PELA 1ª VEZ: mysqladmin –u root


password;
10. ALTERAR A SENHA DO USUARIO ROOT: primeiro acede o banco de dados
“mysql” e depois digite o seguinte: update user set
password=password('NOVA_SENHA') where user='root' and
host='localhost'e depois grava os dados alterados com o
comando flush privileges;
11. ELIMINAR UM USUÁRIO: drop user NOME_DO_USUARIO;

Página 83
5. MODELO FÍSICO
-COMANDOS PRELIMINARES DO MYSQL
12. VER OS NOMES DOS USUÁRIOS: primeiro acede o banco de dados “mysql”,
Fundamentos de base de dados

depois digite o seguinte: select user from user;


13. VER AS TABELAS DE UM BANCO DE DADOS: primeiro acede um banco de
dados e depois digite o seguinte: show tables;

Página 84
5. MODELO FÍSICO
-PREPARAÇÃO DO MYSQL
1. Atribuir senha para o usuario root;
Fundamentos de base de dados

2. Incluir o diretório bin do mysql nas variáveis de ambiente do sistema operativo;


3. Activar a tela de login do phpMyAdmin;
4. Criar um usuário personalizado , com senha e todos os privilegios;
5. Remover os privilegios de outros usuarios root(os que estao sem password);

Página 85
5. MODELO FÍSICO
-TIPOS DE DADOS
Em mysql existe vários tipos de dados, nos veremos os tipos mais comuns, mas
Fundamentos de base de dados

deve ser responsabilidade do estudante investigar os demais tipos.


TIPOS NUMERICOS
TIPO EM MYSQL DESCRIÇÃO VALOR MÍNIMO VALOR MÁXIMO
Número Inteiro De
INTEGER ou INT –2147483648 2147483647
Tamanho Normal
Número Inteiro De
BIGINT –9223372036854775808 9223372036854775807
Tamanho Grande
Número Real
FLOAT
De Tamanho Normal
Número Real
DOUBLE
De Tamanho Grande
Página 86
5. MODELO FÍSICO
-TIPOS DE DADOS
TIPOS DATA
Fundamentos de base de dados

TIPO EM MYSQL DESCRIÇÃO VALOR MÍNIMO VALOR MÁXIMO


DATE ‘AAAA-MM-DD’ ‘1000-01-01’ ‘9999-12-31’
DATETIME ‘AAAA-MM-DD HH:MM:SS’ ‘1000-01-01 00:00:00’ ‘9999-12-31 23:59:59’

TIPOS TEXTO
TIPO EM MYSQL DESCRIÇÃO VALOR MÍNIMO VALOR MÁXIMO
CHAR ou CHAR(M) Texto Curto 0 Caracter 255 Caracteres
VARCHAR(M) ou
Texto Normal 0 Caracter ≈60000 Caracteres
TEXT(M)
LONGTEXT Texto Longo 0 Caracter ≈4294967295 Caracteres

Página 87
5. MODELO FÍSICO
-TABELAS-DDL
As tabelas devem ser criadas dentro de banco de dados(database)
Fundamentos de base de dados

Sintaxe básica de CRIAÇÃO:


CREATE TABLE <nome_da_tabela>( CREATE TABLE professor(
nome_atributo_1 tipo_dado, num_bilhete VARCHAR(15),
nome VARCHAR(50),
nome_atributo_2 tipo_dado, idade INT,
sexo CHAR,

altura FLOAT
nome_atributo_n tipo_dado, );
<espaço_para_restrições>
);

Página 88
5. MODELO FÍSICO
-TABELAS-DDL
Sintaxe da DESCRIÇÃO:
Fundamentos de base de dados

DESC <nome_da_tabela>;
DESC professor;

Sintaxe da REMOCÃO:
DROP TABLE <nome_da_tabela>;
DROP TABLE professor;

Sintaxe 1 da ALTERAÇÃO «adicão de atributos»:


ALTER TABLE <nome_da_tabela> ADD (atributo_1 tipo_dado, …, atributo_n tipo_dado);
ALTER TABLE professor ADD (telefone INT, peso DOUBLE);

Página 89
5. MODELO FÍSICO
-TABELAS-DDL
Sintaxe 2 da ALTERAÇÃO «remoção de um atributo»:
Fundamentos de base de dados

ALTER TABLE<nome_da_tabela> DROP nome_atributo;


ALTER TABLE professor DROP telefone;

Sintaxe 3 da ALTERAÇÃO «modificação do tipo de dado de um atributo»:


ALTER TABLE <nome_da_tabela> MODIFY nome_atributo novo_tipo_dado;
ALTER TABLE professor MODIFY peso FLOAT;

Sintaxe 4 da ALTERAÇÃO «modificação do nome da tabela»:


ALTER TABLE <nome_da_tabela> RENAME <novo_nome_tabela>;
ALTER TABLE professor RENAME pessoa;

Página 90
5. MODELO FÍSICO
-TABELAS-DDL
Sintaxe 5 da ALTERAÇÃO «modificação do nome de um atributo»:
Fundamentos de base de dados

ALTER TABLE <nome_da_tabela> CHANGE atributo_atrocar nome_novo tipo_dado;


ALTER TABLE pessoa CHANGE num_bilhete num_bi VARCHAR(15);

Página 91
5. MODELO FÍSICO
-TABELAS-DML
Sintaxe 1 de INSERÇÃO «inserção de todos os atributos»
Fundamentos de base de dados

INSERT INTO <nome_da_tabela> VALUES (valor_atributo_1, …, valor_atributo_n);


INSERT INTO pessoa VALUES (‘0001A22’, ‘João’, 15, ‘M’, 1.4, 50,44 );

Sintaxe 2 de INSERÇÃO «inserção para determinados atributos»


INSERT INTO nome_tabele (atributos) VALUES (valores_atributos);
INSERT INTO pessoa(num_bi, nome, idade ) VALUES (‘001B24’, ‘Diasenza’, 18);

Sintaxe 1 de SELECÇAO «mostrar todos os atributos»:


SELECT * FROM <nome_da_tabela>;
SELECT * FROM pessoa;

Página 92
5. MODELO FÍSICO
-TABELAS-DML
Sintaxe 2 de SELECÇÃO «mostrar atributos escolhidos»:
Fundamentos de base de dados

SELECT atributo_1, atrubuto_2, …, atributo_n FROM <nome_da_tabela>;


SELECT num_bi, sexo, nome, idade FROM pessoa;

Sintaxe 3 de SELECÇÃO «mostrar registos específicos»:


SELECT * FROM <nome_da_tabela> WHERE <condicao>;
SELECT * FROM pessoa WHERE idade>=18;

Sintaxe de ACTUALIZAÇÃO:
UPDATE <nome_da_tabela> SET atributo = novo_valor WHERE <condicao>;
UPDATE pessoa SET nome=‘Diazenza’, idade=20, altura=1.6 WHERE num_bi=‘001B24’;

Página 93
5. MODELO FÍSICO
-TABELAS-DML
Sintaxe de ELIMINAÇÃO:
Fundamentos de base de dados

DELETE FROM <nome_da_tabela> WHERE <condicao>;


DELETE FROM pessoa WHERE num_bi=‘001B24’;

Página 94
5. MODELO FÍSICO
-CONSTRAINT
CONSTRAINT: é a restrição que pode ser aplicada em colunas das tabelas.
Fundamentos de base de dados

As principais constraints são:


PRIMARY KEY (PK)  CHAVE PRIMARIA;
UNIQUE  CHAVE CANDIDATA;
FOREIGN KEY (FK)  CHAVE ESTRANGEIRA;
NOT NULL: determina que a coluna tem o preenchimento obrigatório;
DEFAULT: define o valor padrão de um determinado atributo;
AUTO_INCREMENT: permite fazer o incremento automático nos atributos.

Página 95
5. MODELO FÍSICO
-CONSTRAINT-PRIMARY KEY
Chave Primária: Exemplo 1
Fundamentos de base de dados

CREATE TABLE Pessoa(


id INT PRIMARY KEY, PESSOA(id, nome, …);

);

Chave Primária: Exemplo 2


CREATE TABLE Pessoa(
id INT, PESSOA(id, nome, …);

CONSTRAINT pk_pessoa PRIMARY KEY(id)
);
Página 96
5. MODELO FÍSICO
-CONSTRAINT-PRIMARY KEY
Chave Primária: Exemplo 3
Fundamentos de base de dados

CREATE TABLE Avaliacao(


id_prova INT, AVALIACAO(id_prova, id_aluno, nota);

id_aluno INT,
nota INT,
CONSTRAINT pk_avaliacao PRIMARY KEY(id_prova, id_aluno)
);

Página 97
5. MODELO FÍSICO
-CONSTRAINT-UNIQUE
Atributo Único: Exemplo 1
Fundamentos de base de dados

CREATE TABLE Pessoa(


id INT, PESSOA(id, nome, num_bi, …);

num_bi VARCHAR(15) UNIQUE,


nome VARCHAR(50),

CONSTRAINT pk_pessoa PRIMARY KEY(id),
);

Página 98
5. MODELO FÍSICO
-CONSTRAINT-UNIQUE
Atributo Único: Exemplo 1
Fundamentos de base de dados

CREATE TABLE Pessoa(


id INT, PESSOA(id, nome, num_bi, …);

num_bi VARCHAR(15),
nome VARCHAR(50),

CONSTRAINT pk_pessoa PRIMARY KEY(id),
CONSTRAINT unique_num_bi UNIQUE (num_bi)
);

Página 99
5. MODELO FÍSICO
-CONSTRAINT-UNIQUE
Atributo Único: Exemplo 2
Fundamentos de base de dados

CREATE TABLE Pessoa(


id INT, PESSOA(id, nome, num_bi, telefone, …);

num_bi VARCHAR(15),
nome VARCHAR(50),

CONSTRAINT pk_pessoa PRIMARY KEY(id),
CONSTRAINT unique_num_bi UNIQUE (num_bi),
CONSTRAINT unique_tel UNIQUE (telefone)

); obs.: O num_bi e o telefone são atributos únicos e independentes.


Página 100
5. MODELO FÍSICO
-CONSTRAINT-UNIQUE
Atributo Único: Exemplo 3
Fundamentos de base de dados

CREATE TABLE Aluno(


num_processo INT, ALUNO(num_precesso, nome, turma, num_aluno, …);

nome VARCHAR(50),
num_aluno INT,
turma VARCHAR(10),

CONSTRAINT pk_pessoa PRIMARY KEY(id),
CONSTRAINT unique_aluno UNIQUE (turma, num_aluno)

); obs.: A turma e o num_aluno são atributos únicos e relacionados.


Página 101
5. MODELO FÍSICO
-CONSTRAINT-FOREIGN KEY
Chave Estrangeira: Exemplo 1
Fundamentos de base de dados

CREATE TABLE Aluno(


num_processo INT, ALUNO(num_precesso, id_pessoa, …);

id_pessoa INT,

CONSTRAINT pk_aluno PRIMARY KEY(num_processo),
CONSTRAINT fk_id_aluno FOREIGN KEY (id_pessoa) REFERENCES Pessoa(id)
);

Página 102
5. MODELO FÍSICO
-CONSTRAINT-FOREIGN KEY
Chave Estrangeira: Exemplo 2
Fundamentos de base de dados

CREATE TABLE Avaliacao(


id INT, AVALIACAO(id, id_aluno, id_prova …);
id_prova INT,
id_aluno INT,

CONSTRAINT pk_avaliacao PRIMARY KEY(id),
CONSTRAINT unique_aluno UNIQUE (id_prova, num_aluno),
CONSTRAINT fk_id_aluno FOREIGN KEY (id_aluno) REFERENCES Aluno(id),
CONSTRAINT fk_id_prova FOREIGN KEY (id_prova) REFERENCES Prova(id)

); obs.: O id_aluno e o id_prova são atributos únicos e relacionados.


Página 103
5. MODELO FÍSICO
-CONSTRAINT-NOT NULL & DEFAULT
Atributo Não Nulo & Valor Padrão: Exemplo 1
Fundamentos de base de dados

CREATE TABLE Pessoa(


PESSOA(id, num_bi, idade, nome …);
id INT,
nome VARCHAR(50) NOT NULL,
idade INT DEFAULT 0,
num_bi INT NOT NULL DEFAULT ‘000000000AN000’,
Para inserir um registo com um

valor padrão definido, basta
CONSTRAINT pk_pessoa PRIMARY KEY(id), colocar o nome do atributo na
CONSTRAINT unico UNIQUE (mum_bi) inserção

); INSERT INTO pessoa VALUES(12, ‘João’, 12, num_bi, …);


Página 104
5. MODELO FÍSICO
-CONSTRAINT-AUTO_INCREMENT
Incrementacao Automática: Esta constraint só pode ser dada em atributos que
são chaves primárias e do tipo numérico, ela faz o incremento de uma unidade
Fundamentos de base de dados

ao ultimo valor inserido. Para fazer a incrementação automática explicitamente


passamos a esses atributos a palavra null.
CREATE TABLE Pessoa( PESSOA(id, …);
id INT PRIMARY KEY AUTO_INCREMENT
);
CREATE TABLE Pessoa(
id INT AUTO_INCREMENT,

CONSTRAINT pk_pessoa PRIMARY KEY(id)
);
Página 105