MÓDULO 13 – TÉCNICAS DE

MODELAÇÃO DE DADOS

Disciplina: Programação e Sistemas de Informação

Modelo Relacional de Bases de Dados
Bases de dados e tabelas

Nome
N_Aluno Morada
Aluno
N_Aluno
Nome
Aluno Morada
(Entidade) (Classe)

As entidades dos diagramas ER ou as classes dos diagramas de

classes vão corresponder a tabelas de dados em que os
atributos dão origem aos campos ou colunas dessas tabelas.
Modelo Relacional de Bases de Dados

Linguagem comum Linguagem formal

Tabela
nas bases de dados do modelo relacional

Colunas
Atributos
ou campos
N_Aluno Nome Localidade
1 Abel Lisboa
Linhas 2 Ana Porto
Tuplos
ou registos 3 Carla Coimbra
4 Daniel Funchal
Modelo Relacional de Bases de Dados

 Uma base de dados consiste numa coleção de dados

estruturados, organizados e armazenados de forma
persistente por uma aplicação informática.

 O software que permite

criar e/ou gerir uma base
de dados designa-se por
SGBD – Sistema de
Gestão de Bases de
Dados.
Modelo Relacional de Bases de Dados
 Um SGBD é concebido para poder implementar bases de
dados segundo um determinado modelo.

 O modelo de bases de dados mais utilizado nos sistemas de

informação é o modelo relacional. Neste modelo, a estrutura
básica é a tabela – que é vista como uma relação de dados.

Tabela é uma estrutura de dados formada por:

1. um conjunto de colunas, campos ou atributos;
2. um conjunto de linhas, registos (ou tuplos na linguagem do
modelo relacional).

e cujo objectivo é armazenar informação sobre uma entidade ou

classe.
Modelo Relacional de Bases de Dados

Atributos e Campos

 Quer uma entidade, quer uma classe são formadas por

atributos.

 Atributo – é uma característica ou propriedade que interessa

considerar relativamente a uma entidade.

 Nas bases de dados do modelo relacional, os atributos

correspondem às colunas de uma tabela que também
costumam ser designadas por campos.
Modelo Relacional de Bases de Dados

Registos

 As linhas de uma tabela correspondem a registos.

 Registo – é constituído por um conjunto de dados (atributos ou

campos) relativos a uma entidade singular ou um objecto.
Modelo Relacional de Bases de Dados

Domínios dos atributos

 Domínio de um atributo – corresponde aos valores os tipos

de dados que esse atributo (ou campo) pode assumir.

 Os domínios são importantes para a definição da estrutura

de uma tabela, pois diz respeito com os tipos de dados com
que um sistema informático e um SGBD pode trabalhar, tais
como: inteiros, reais, datas, strings, etc.
 Modelo Relacional de Bases de Dados

Atributos
ou campos
N_Aluno Nome Localidade
1 Abel Lisboa
2 Ana Porto Linhas
ou
3 Carla Coimbra
registos
4 Daniel Funchal

Abel Ana Lisboa

1 2 Carla Coimbra
3 4 Daniel Porto
… … …

Domínios
Tabelas em bases de dados relacionais

Chave primária e chaves candidatas

 Chave primária – é um atributo ou conjunto de atributos que

permite identificar de forma unívoca cada registo numa
tabela.

 Os conceitos de chave primária e chaves candidatas são

semelhantes, a única diferença é que a chave primária é
selecionada entre as chaves candidatas para desempenhar
essa função de identificar de forma unívoca cada registo
numa tabela.
Tabelas em bases de dados relacionais

Para que um atributo possa ser chave candidata, não pode

conter dados repetidos em diferentes registos – só assim pode
identificar de forma única cada registo.

Tabela Chaves candidatas

Alunos
N_Aluno Nome Localidade
1 Abel Silva Lisboa
2 Ana Nunes Porto
3 Carla Dias Porto
4 Eva Silva Lisboa

Chave primária
Tabelas em bases de dados relacionais

O campo Designação não oferece garantia de não conter

repetições para certos produtos.
Em situações como esta, inclui-se um campo com um código para
o produto (CodArtigo) e passará esse campo, a ser a chave
primária da tabela.
Chave candidata ( ? )
Tabela
Artigos Designação Categoria Preço
Portátil PP Computadores 400
Impressora X Periféricos 100
Impressora Y Periféricos 200
Tinteiro Consumíveis 20

Chave primária ( ? )
Formas de representar uma tabela
numa base de dados relacional
Tabela na sua definição de estrutura
Tabela Sócios
Número: Integer <<PK>>
Nome: String [50] {Obrigatório}
Sexo: Char {Valores = [“M”|”F”]}
Data Nascimento: Date {Obrigatório}
Morada: String

Cada campo da tabela incluí, após o respectivo nome, a

indicação do seu tipo de dados, bem como outras indicações
importantes, como se é chave primária, se é um campo de
preenchimento obrigatório, valores default, valores opcionais,
etc.
Formas de representar uma tabela
numa base de dados relacional
Tabela na sua representação analítica (forma simplificada da
vista de estrutura)

Sócio (Número, Nome, Sexo, DataNascimento, Morada)

Neste caso, indica-se o nome da tabela, seguido da lista de

atributos ou campos, dentro de parênteses curvos. O facto de o
campo Número estar sublinhado, indica que se trata da chave
primária desta tabela.
Relacionamento entre tabelas
Exemplo de um relacionamento entre duas tabelas. O campo
CodForn, que é chave primária na tabela Fornecedor, aparece
na tabela Artigo, onde toma o lugar de chave estrangeira.

Artigo é fornecido  Fornecedor

CodArtigo CodForn
Designação Nome
CodForn Morada

Numa situação como esta, estamos perante uma chave

estrangeira (FK – Foreign Key).
Relacionamento entre tabelas
Chave estrangeira – é um campo “importado” para uma tabela,
sendo chave primária na tabela de origem.

 A tabela principal é aquela que contém a chave primária a

ser importada.

 A tabela relacionada é aquela que recebe a importação da

chave primária que, nesta tabela que a recebe, passa a ser
referida como chave estrangeira.
Relacionamento entre tabelas

Artigo Fornecedor
CodArtigo Nome CodForn CodForn Nome Localidade
A1 Alicate F1 F1 FerroXis Lisboa
B2 Berbequim F1 F2 Ferrantas Porto
C3 Serra F3 F3 Ambrósio Porto
D4 Martelo F2 F4 Silva e Silva Lisboa
 Relacionamento entre tabelas
 Por vezes, o relacionamento entre duas tabelas passa por uma
terceira tabela de associação.
Departamento 1..* 1..* Empregado

Departamento Depart_Empreg Empregado

CodDep Designação CodEmp Nome
Depart_Empreg
D1 Produção E1 Aníbal
CodDep CodEmp Data_Entrada
D2 Marketing E2 Belmiro
D1 E1
D3 Informática E3 Casimiro
D2 E2

 A chave primária da tabela Depart_Empreg é composta por dois

campos: CodDep e CodEmp. Só os dois em conjunto é que identificam de
modo unívoco cada registo da tabela Depart_Empreg.
Integridade da informação numa base
de dados relacional
 A manutenção da consistência ou integridade da informação
numa base de dados deve ser assegurada pelo SGBD.

 Uma BD relacional deve assegurar dois tipos de integridade:

1. Integridade de entidade – impõe que os valores dos
atributos que correspondem à chave primária de uma
entidade não podem ser nulos nem iguais a outros já
existentes na tabela.

2. Integridade referencial – impõe que um valor de uma

chave externa exista obrigatoriamente como elemento
constituinte da chave primária da tabela relacionada com
aquela chave externa.
Exemplificação de violações da
integridade referencial
Clientes Artigos
CodCliente Nome Morada CodArtigo Artigo CodForn
C101 ABC Porto 1011 Modem 101
C102 DEF Lisboa 1022 Scanner 102
C103 GHI Faro 1033 Teclado 102
? ?
Encomendas
NºEnc DataEnc CodCliente CodArtigo Quantidade
1 2012-10-10 C101 1022 1
2 2012-10-10 C103 1011 3
3 2012-10-11 C102 1033 5
4 2012-10-11 C130 155 1
Exemplificação de violações da
integridade referencial
 Sempre que quisermos apagar ou alterar um registo numa
tabela, e esse registo estiver relacionado com outros registos
de outra tabela, estamos perante uma possibilidade de
violação da integridade referencial – ficarmos com registos
que referenciam um registo que deixou de existir.
Exemplificação de violações da
integridade referencial
Clientes Artigos
CodCliente Nome Morada CodArtigo Artigo CodForn
C101 ABC Porto 1011 Modem 101
C102 DEF Lisboa 1022 Scanner 102
C103 GHI Faro 1033 Teclado 102
?
Encomendas
NºEnc DataEnc CodCliente CodArtigo Quantidade
1 2012-10-10 C101 1022 1
2 2012-10-10 C103 1011 3
3 2012-10-11 C102 1033 5
Normalização de uma BD relacional
Formas Normais para as tabelas
 O grupo de trabalho que desenvolveu o modelo relacional de
base de dados, propôs um conjunto de normas para uma boa
estruturação das tabelas, por forma a tornar viável o
funcionamento do modelo relacional de bases de dados na
implementação prática dos SGBD.

 Este conjunto de normas ou processo de normalização é

composto pelas chamadas formas normais.
1ª Forma Normal (1FN);
2ª Forma Normal (2FN);
3ª Forma Normal (3FN);
Primeira Forma Normal (1FN)
 A normalização de uma tabela na 1ª Forma Normal (1FN)
exige que a tabela tenha uma estrutura bidimensional
correcta, ou seja, cada linha deve corresponder a um só
registo e cada coluna a um só campo.

 Além disso, cada campo deve conter dados atómicos, ou seja,

um só dado por cada registo. Cada dado só deve tomar um
valor dentro do domínio definido para esse campo.
 Primeira Forma Normal (1FN)
Exemplo: Esta tabela não respeita a 1FN, pois não tem uma
estrutura bidimensional correcta: o campo Encomendas
abrange várias colunas e existem registos que
abrangem mais do que uma linha.

Encomendas
Cod Cliente Cliente Morada
N.º Encom Data Produto Quantidade

1 2012-10-25 Ananás 10
C01 Aníbal Lisboa
5 2012-10-30 Cebolas 20
C02 Belmiro Braga 3 2012-10-26 Bananas 30
2 2012-10-25 Tomates 50
C03 Casimiro Coimbra
4 2012-10-26 Cebolas 20
 Primeira Forma Normal (1FN)
Exemplo: Esta tabela vai ao encontro daquilo que estipula a
1FN – cada coluna, cada campo; cada linha, cada
registo.

Cod Cliente Cliente Morada N.º Encom Data Produto Quantidade

C01 Aníbal Lisboa 1 2012-10-25 Ananás 10

C01 Aníbal Lisboa 5 2012-10-30 Cebolas 20
C02 Belmiro Braga 3 2012-10-26 Bananas 30
C03 Casimiro Coimbra 2 2012-10-25 Tomates 50
C03 Casimiro Coimbra 4 2012-10-26 Cebolas 20

Contudo, esta tabela apresenta problemas de redundância de

informação, ou seja, repetição desnecessária de alguns dados.
Por exemplo: repetição do nome e morada dos clientes.
Problemas das tabelas na 1FN
As tabelas normalizadas apenas na 1FN podem apresentar
problemas de:
 Redundância de informação

 Anomalias de inserção
 Anomalias de actualização
 Anomalias de eliminação
Problemas das tabelas na 1FN
 Redundância de informação – repetição desnecessária de dados.

 Anomalias de inserção – em certas situações, a inserção de um

novo registo pode implicar um ou mais campos em branco. Por
exemplo: se quisermos registar um novo cliente sem que, nesse
momento, ele tenha feito qualquer encomenda, vários campos
ficariam vazios.
Problemas das tabelas na 1FN
 Anomalias de actualização – dado que numa tabela pode existir
repetição de informação sobre um mesmo elemento, se
quisermos actualizar um dado relativo a um determinado
elemento, teremos de efectuar tantas actualizações quantas as
vezes que esse elemento aparecer na tabela.

 Anomalias de eliminação – a possibilidade de existir informação

repetida sobre um mesmo elemento, implica que se quisermos
apagar um determinado elemento da nossa base de dados,
teremos de o fazer a todos os registos em que ele figurar.
Dependências funcionais
 A compreensão da 2ª e 3ª formas normais implica a
percepção do conceito de dependência funcional.

 Quando um atributo ou conjunto de atributos identifica de

modo unívoco os registos de uma tabela, diz-se que
determina funcionalmente os outros atributos.
 Isto acontece sempre com a chave primária de uma tabela, mas
também pode acontecer em relação a outros campos.
Dependências funcionais
Exemplo:
 O conjunto de atributos NºAluno + CodDiscip determina
funcionalmente os atributos (Nome, Morada e Disciplina).

 Reciprocamente, diz-se que os atributos Nome, Morada e

Disciplina são funcionalmente dependentes do par de
atributos NºAluno e CodDiscip.
Alunos
NºAluno Nome Morada CodDiscip Disciplina

101 Ana Porto D11 Informática

101 Ana Porto D12 Inglês
108 Carlos Braga D11 Informática
109 Daniel Viseu D12 Inglês
Dependências funcionais
Além disso, podemos constatar que existem outras dependências
funcionais:
 Os atributos Nome o Morada são funcionalmente dependentes de
NºAluno.
 O atributo Disciplina é funcionalmente dependente de CodDiscip.

Alunos
NºAluno Nome Morada CodDiscip Disciplina

101 Ana Porto D11 Informática

101 Ana Porto D12 Inglês
108 Carlos Braga D11 Informática
109 Daniel Viseu D12 Inglês
Segunda Forma Normal (2FN)
 A 2ª Forma Normal diz que a tabela tem de estar na 1ª
Forma Normal e que cada atributo não chave tem de ser
funcionalmente dependente da totalidade da chave primária
e não apenas de uma parte dessa chave.

 Devemos ter em atenção os casos em que a chave primária é

constituída por mais do que um atributo (chave primária
composta) – neste caso, não pode existir nenhum atributo que
seja funcionalmente dependente de uma parte da chave.
 Segunda Forma Normal (2FN)

Antes Alunos
da 2FN
NºAluno Nome Morada CodDiscip Disciplina

Depois Alunos Disciplinas

da 2FN
NºAluno Nome Morada CodDiscip Disciplina
Segunda Forma Normal (2FN)
 Como as tabelas Alunos e Disciplinas não tinham, por si só,
nenhuma forma de se relacionarem, a solução para
estabelecer esse relacionamento passa por uma terceira
tabela – Aluno_Discip, que deverá incluir (como chaves
externas) os campos que são chaves primárias nas duas
primeiras tabelas (NºAluno e CodDiscip).
Segunda Forma Normal (2FN)
Alunos Disciplinas
NºAluno Nome Morada CodDiscip Disciplina

101 Abel Aveiro D11 Português

102 Ana Porto D12 Inglês
103 Carlos Braga D13 Informática
104 Daniel Viseu D14 Matemática

Aluno_Discip NºAluno CodDiscip DataInscr

101 D11 04-07-2012

101 D12 04-07-2012
102 D12 05-07-2012
102 D13 05-07-2012
Terceira Forma Normal (3FN)

 A 3ª Forma Normal diz que a tabela tem de estar na 2ª

Forma Normal e que nenhum atributo não chave pode
depender funcionalmente de algum outro atributo que não
seja a chave primária.
Terceira Forma Normal (3FN)
 Para normalizar uma tabela de acordo com a 3FN, devemos
analisar todos os atributos não chave e verificar se existem
algumas dependências funcionais entre eles:

 Se não existir nenhuma dependência funcional entre os

atributos não chave, a tabela está na 3FN;

 Se existir alguma dependência funcional entre os atributos

não chave, então, é necessário retirar esse conjunto de
atributos da tabela e constituir com eles uma tabela à
parte.
 Terceira Forma Normal (3FN)
Nota: Considere-se que cada aluno só pode estar inscrito num curso.

Antes Alunos
da 3FN
NºAluno Nome Morada CodCurso NomeCurso

Depois Alunos Cursos

da 3FN
NºAluno Nome Morada CodCurso CodCurso NomeCurso
 Terceira Forma Normal (3FN)
Exemplo 2
Nota: Considere-se que cada encomenda só poderá ter um produto.

Encomendas
Antes
da 3FN NºEnc CodCliente Cliente Morada CodProd Produto Preço Quantidade
 Terceira Forma Normal (3FN)
Exemplo 2
Nota: Considere-se que cada encomenda só poderá ter um produto.

Clientes Produtos
CodCliente Cliente Morada CodProd Produto Preço
Depois
da 3FN

Encomendas NºEnc CodCliente CodProd Quantidade