TIC - Base de Dados

MÓDULO 2 – BASES DE DADOS
TECNOLOGIAS DA INFORMAÇÃO E
COMUNICAÇÃO
10º ANO
Professor: Alexandre Lourenço
Teoria de Base de Dados Relacionais

Modelos de bases de dados
 modelo hierárquico;
 modelo em rede;
 modelo relacional

Modelo hierárquico
 Consiste numa colecção de registos
(records) que se encontram
relacionados entre si, através de
ligações (ou ponteiros).
 Diagrama de árvore.
 Pode fazer-se uma navegação de

registo em registo, subindo ou
descendo na estrutura hierárquica.

Modelo em Rede
 Consiste num conjunto de
registos relacionados entre si
através de ligações (ou ponteiros).
 A estrutura é em forma de rede.
 Os registos podem ser

relacionados uns com os outros
de uma forma mais flexível, em
conformidade com as relações no
mundo real que pretendermos
representar.

Modelo Relacional
 Surgiu fundamentalmente para
ultrapassar algumas dificuldades e
limitações colocadas ao nível dos dois
modelos anteriores.
 A utilização de uma base de dados estava

demasiado dependente dos
programadores que a haviam concebido.
 Procurou uma forma de organização dos

dados mais simples e, ao mesmo tempo,
mais flexível - as tabelas.

Modelo Relacional
 As tabelas são representações de entidades ou ocorrências, por exemplo:
empresas, empregados, clientes, produtos, encomendas, pagamentos,
movimentos de contas, etc.).
 As colunas das tabelas representam campos de informação ou atributos

das entidades (por exemplo: para uma entidade Clientes, podemos ter os
seguintes atributos: CódigoCliente, NomeCliente, Endereço, Telefone,
etc.).
 As linhas das tabelas representam entidades singulares ou ocorrências

concretas – correspondentes aos registos (records) das bases de dados
tradicionais.

Modelo Relacional
 Os SGBD relacionais permitem a criação e utilização de bases de dados

relacionais, ou seja, bases de dados constituídas por tabelas e
relacionamentos entre elas. A correcta estruturação das tabelas e seus
relacionamentos garantirá, conjuntamente com um SGBD relacional, um
funcionamento coerente e consistente de uma base de dados, relativamente
às operações que lhes são típicas, como: consultas, actualizações,
acrescentos e eliminações.
SGBD (Sistema de Gestão de Base de Dados).

Atributos e Chaves
 As unidades fundamentais do modelo relacional de bases de dados são

as entidades - que são representadas ou traduzidas em tabelas.
 As entidades são definidas em termos de atributos - que são

representados ou traduzidos nos campos das tabelas.

Atributos e Chaves
Por exemplo, a entidade Aluno, definida pelos seguintes atributos:
Nº de Inscrição, Nome, Data de Nascimento, Sexo, Morada.
Traduzindo para uma notação que é usual, poderíamos representar a

entidade Aluno assim:
Aluno (N_Aluno, Nome, DataNasc, Sexo, Morada)

Atributos e Chaves
 Um princípio basilar do modelo relacional diz que cada atributo (de uma
entidade) ou cada campo (de uma tabela) deve ser o mais elementar
possível, "atómico" ou indecomponível - princípio da atomicidade.
 Por exemplo, N_Aluno (N.o de um aluno) e Sexo. Os dados de N_Aluno

serão, por exemplo: 1001, 1002, etc. Os dados de Sexo serão, por
exemplo: M ou F.

Atributos e Chaves
 Nome ou Morada, já não se pode considerar que sejam indecomponíveis.
 O nome completo de uma pessoa pode ser decomposto, por exemplo,

em PrimeiroNome, ÚltimoNome, OutrosNomes.
 A morada pode ser decomposta, por exemplo, em Rua, Número,

Localidade, etc. Nestes casos, estamos perante o que podem ser
considerados atributos compostos – formados por atributos mais
elementares.

Atributos e Chaves
Exemplo de duas entidades.

Atributos e Chaves
 Entre os vários atributos que constituem uma entidade (ou tabela) pode
existir um ou mais que identificam de forma unívoca os diferentes registos
dessa entidade (tabela).
 Por exemplo, na entidade Aluno, o atributo N_Aluno (Nº do aluno) deve

identificar cada aluno de forma unívoca, uma vez que cada aluno tem um
número de inscrição diferente de todos os outros (atributo
identificador/chave).

Atributos e Chaves
 Um atributo identificador é um atributo (campo) que identifica de forma
unívoca cada registo de uma entidade (tabela).
 Uma chave, em relação a uma entidade ou tabela, é um atributo ou

conjunto de atributos que, por si só ou em conjunto, são capazes de
identificar de forma unívoca os diferentes registos dessa entidade ou tabela.
 Uma entidade ou tabela pode não ter nenhum atributo que, por si só, seja
capaz de identificar univocamente os registos, mas, reunindo dois ou mais
atributos em conjunto, já se consiga essa identificação unívoca (chave
composta - constituída por mais do que um atributo).

Atributos e Chaves
Exemplos de tabelas e chaves primárias.

Chaves Primárias
 Uma chave primária é um atributo ou conjunto de

atributos que desempenham, relativamente a uma tabela, a
função de identificar de forma unívoca cada registo dessa
tabela.

Chaves Primárias
 Nas bases de dados relacionais, as chaves primárias desempenham um
papel muito importante, por duas ordens de razões:
 a chave primária de uma tabela garante integridade de entidades, ou seja,

cada registo é identificado univocamente e, por isso, nunca poderão existir
dois registos exactamente iguais na tabela. Na chave primária, nunca serão
admitidos valores repetidos ou valores nulos;
 é através das chaves primárias que se estabelecem os relacionamentos

entre tabelas. Quando uma chave primária é constituída por um só atributo,
diz-se que é uma chave primária simples. Quando uma chave primária é
constituída por mais do que um atributo, diz-se que é uma chave primária
composta.
Chaves Primárias
 Em entidades em que não há a garantia de que um atributo possa

desempenhar o papel de chave primária, é mais seguro criar um campo que
possa ser, sem qualquer dúvida, identificador unívoco da entidade em causa
e, portanto, chave primária da respectiva tabela.
 É o que acontece na tabela Alunos e na tabela Cursos.
 Na tabela Alunos, a chave primária é o campo NºAluno.
 Na tabela Cursos, a chave primária é o campo CodCurso.

Chaves Primárias
 Na tabela Aluno_Curso (que visa registar as frequências dos alunos em
relação aos cursos), nenhum campo dos apresentados pode, por si só,
desempenhar o papel de chave primária.
 A dupla formada pelos campos NºAluno e CodCurso é uma possível chave

primária.
 Mas, se um aluno puder inscrever-se mais do que uma vez num mesmo
curso, em datas diferentes, teremos de incluir também Datalns (data de
inscrição) na chave primária.

Relacionamentos entre entidades
 Os sistemas de bases de dados relacionais caracterizam-se

por permitirem criar bases de dados com tabelas
relacionadas entre si.
 Os relacionamentos entre entidades baseiam-se nas chaves

das tabelas.

Exemplo:
 A empresa X comercializa vários artigos, os quais são adquiridos a um

conjunto de fornecedores e necessitamos de registar na base de dados os
artigos e os respectivos fornecedores.
 Temos duas entidades que podemos definir como:

 Fornecedores (CodFornec, Nome, Morada)
 Artigos (CodArtigo, Artigo, CodFornec)

Fornecedores tem
como chave primária o
campo CodFornec.
Artigos tem como

chave primária o campo
CodFornec.
Através das chaves estabelecemos um relacionamento entre a tabela Artigos e a

tabela Fornecedores, indicando, para cada artigo, qual o respectivo fornecedor

Muito importante nas bases de dados relacionais
 O campo (CodFornec) é chave primária numa tabela (Fornecedores) e

aparece também como campo de uma outra tabela (Artigos). Nestas
situações, estamos perante o que se chama uma chave externa.
Uma chave externa é um atributo de uma entidade que é chave

primária numa outra entidade.
É através das chaves primárias e das chaves externas que se

estabelecem os relacionamentos entre as tabelas, nas bases de
dados relacionais.

Preservação da integridade da informação
 O modelo relacional obriga a que a realização das operações de

actualização numa base de dados deve decorrer de forma a que a
informação se mantenha consistente (assegurada pelo SGBD ou pelas
aplicações que forem criadas a partir desse mesmo SGDB).
 Uma base de dados relacional deve assegurar dois tipos de integridade:
1- integridade de entidade;
2 - integridade referencial.

 A 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.
 A integridade referencial impõe que um valor de uma chave externa tem

obrigatoriamente de existir como elemento constituinte da chave primária
da tabela relacionada com aquela chave externa.

Exemplificação de violações da integridade referencial: Introdução

Exemplificação de violações da integridade referencial: Eliminação

Modelação da informação - Formas Normais
Normalização das tabelas
 A normalização de dados é uma série de passos (formas

normais) que devem ser seguidos no desenho de uma base de
dados. Permite um armazenamento consistente e um eficiente
acesso aos dados numa base de dados relacional. Esses passos
reduzem a redundância de dados e as possibilidades dos dados
se tornarem inconsistentes.

Modelação da informação - Formas Normais
Inicialmente foram estabelecidas três formas normais:
• 1ª Forma Normal (1FN);

• 3ª Forma Normal (3FN).
 Posteriormente surgiram outras Formas Normais:
• Forma Normal de Boyce-Codd (FNBC);

• 5ª Forma Normal (5FN).

Modelação da informação - Modelo E-R
 O modelo Entidade-Relacionamento (modelo
E-R), é um modelo conceptual para a
estruturação da informação com vista à
elaboração de bases de dados.
 O modelo E-R, como a sua própria designação

indica, parte dos conceitos básicos de entidades
(compostas por atributos) e relacionamentos
entre essas entidades. A sua expressão mais
característica são os diagramas E-R.

Modelação da informação - Modelo E-R
 Utiliza os mesmos conceitos de entidade, atributo, chave primária, chave

externa, etc, que estão associados ao modelo relacional. O principal
objectivo do modelo E-R consiste em fornecer, sobretudo através dos
diagramas E-R, instrumentos conceptuais que ajudem a compreender
melhor e tornem mais fácil o desenho de uma base de dados.
 A partir desta formalização ou esquematização dos relacionamentos entre as

entidades torna-se possível deduzir, com maior rigor, as tabelas necessárias
à base de dados em análise

Exemplo de Modelo E-R

Tipos de Relação
A situação típica dos relacionamentos são entre duas entidades –
relacionamentos binários.
No entanto, temos outras situações também possíveis:
• relacionamentos unários - que se estabelecem entre os elementos de uma

mesma entidade;
• relacionamentos binários - que se estabelecem entre duas entidades;
• relacionamentos ternários - que se estabelecem entre três entidades.

Tipos de Relação
 Uma questão importante que há a considerar é o número de vezes que cada
elemento de cada entidade pode participar num determinado
relacionamento.
Cardinalidade de um relacionamento
 relacionamento 1 para 1 (1:1) (ou um para um)
 relacionamentos 1 para M (1:M) (ou um para muitos)
 relacionamentos M para 1 (M:1) (ou muitos para um)
 relacionamentos M para M (M:M) (ou muitos para muitos)

Tipos de Relação
Relacionamento 1 para 1 (1:1) (ou um para um)
 Cada elemento ou ocorrência de cada parte (entidade) participa apenas uma vez
no relacionamento com a outra parte;
Relacionamentos 1 para M (1:M) (ou um para muitos)
 Nesta situação verifica-se o seguinte: numa das entidades, cada elemento

participa no relacionamento apenas uma vez, ao passo que, na outra entidade,
esse elemento pode ter várias ocorrências nesse mesmo relacionamento;

Tipos de Relação
Relacionamentos M para 1 (M:1) (ou muitos para um)
 Situação simétrica da anterior.
Relacionamentos M para M (1:M) (ou muitos para muitos)
 Situação em que cada elemento de cada uma das partes do relacionamento

pode participar múltiplas vezes nesse relacionamento.

Tipos de Relação
Tipos de relacionamento quanto à cardinalidade ou número de vezes que

cada elemento de cada entidade pode participar no relacionamento.
Tipos de Relação
Relacionamentos unários
 Estabelece-se entre os elementos ou ocorrências de uma mesma entidade

(relacionamento recursivo).
 Os relacionamentos - sejam unários ou binários podem ser diferentes quanto à

cardinalidade ou número de vezes que cada elemento pode participar num
relacionamento; assim, temos:
a) relacionamentos unários 1:1 (um para um);

b) relacionamentos unários 1:M (um para muitos);
c) relacionamentos unários M:M (muitos para muitos).

Tipos de Relação
Relacionamentos unários 1:1 (um para um)
 Por exemplo: para traduzir o

relacionamento "casado com", numa
tabela Pessoas(CodPessoa, Nome,
DataNasc), bastaria acrescentar,
nessa tabela, o campo Conjuge.

Tipos de Relação
Relacionamentos unários 1:M (um para muitos) ou M:1 (muitos para um)
 Por exemplo: para traduzir o

relacionamento "chefe de“ para a
entidade Empregados (basta uma
única tabela). Na tabela da figura o
campo Chefe permite registar, em
relação a cada empregado, o código
identificativo de um outro elemento
dessa mesma tabela, que é o seu
chefe.

Tipos de Relação
Relacionamentos unários M:M (muitos para muitos)
 Considerando, por exemplo, a seguinte situação: uma empresa pretende

registar os seus produtos numa base de dados, sendo que entre esses produtos
existe um relacionamento em que uns são componentes dos outros (e,
reciprocamente, cada produto, é composto por alguns outros produtos).
 Trata-se de um relacionamento unário (há só uma entidade: Produtos - tipo

M:M), visto que cada produto pode ser constituído por vários outros e, pelo
menos alguns deles, podem entrar na composição de vários outros.

Tipos de Relação
Relacionamentos unários M:M (muitos para muitos)
 Em situações como esta são necessárias duas tabelas: uma para registar
os elementos da entidade em causa e outra para registar os
relacionamentos existentes entre esses elementos.

Regras para construção de BD
Regra 1 – Relacionamento Binário 1:1 - participação de ambas as entidades
obrigatória
 Apenas é necessária uma tabela. A chave primária dessa tabela pode ser a
chave de qualquer das entidades.

Regra 2 – Relacionamento Binário 1:1 - participação obrigatória de uma só entidade
 São necessárias duas tabelas - uma para cada entidade - sendo a chave de
cada entidade usada como chave primária para cada tabela. A chave da
entidade com participação não obrigatória tem que ser usada como atributo
da relação respeitante à entidade com participação obrigatória

Tipos de Relação
Relacionamentos binários "um para um"
Mantêm-se as duas
tabelas já existentes,
correspondentes a cada
uma das entidades e
coloca-se a chave externa
(CodFunction) na tabela
com participação
obrigatória (Departamento)
a referenciar a chave
primária da outra tabela.

Tipos de Relação
Entidade principal e duas A entidade

subclasses ou variantes Empregados pode,
da entidade principal. em muitos casos,
englobar empregados
com situações muito
diferenciadas, por
exemplo: empregados
do quadro,
contratados a prazo,
etc.

Regra 3 – Relacionamento Binário 1:1 – sem participação obrigatória
 São necessárias 3 tabelas: uma para cada entidade, com a chave da entidade
a servir de chave primária para a tabela correspondente e uma para o
relacionamento. A que corresponde ao relacionamento terá entre os seus
atributos as chaves das duas entidades

Regra 4 – Relacionamento Binário 1:M – participação obrigatória do lado M
 São necessárias duas tabelas, uma para cada uma das entidades, com a chave de
cada entidade a servir de chave primária para a correspondente tabela. Além
disso, a chave da entidade do lado 1 tem que ser usada como atributo na relação
correspondente à entidade do lado M

Tipos de Relação
Relacionamentos binários "um para muitos"
Na tabela Produtos (lado M) incluímos o campo CodFornec, como chave

externa, a fazer referência à chave primária de Fornecedores.

Regra 5 – Relacionamento Binário 1:M – participação não obrigatória do lado M
 São necessárias três tabelas: uma para cada uma das duas entidades, com a
chave de cada entidade a servir de chave primária para a correspondente
relação, e uma para o relacionamento, que terá entre os seus atributos as
chaves de cada uma das entidades.

Relacionamento Binário 1:M
A terceira tabela
específica para o
relacionamento. Deve
incluir necessariamente
os campos que são
chave primária nas duas
outras tabelas (para
além de outros campos
Supondo que há possíveis).
empregados sem
departamento

Regra 6 – Relacionamento Binário M:M – independentemente da classe de participação
 São necessárias três tabelas: uma para cada uma das duas entidades, com a
chave de cada entidade a servir de chave primária para a correspondente
relação, e uma para o relacionamento, que terá entre os seus atributos as
chaves de cada uma das entidades


Regra 7 – Relacionamento Ternário
 Quando um relacionamento é ternário, são necessárias quatro tabelas: uma

para cada uma das duas entidades, com a chave de cada entidade a servir de
chave primária para a correspondente relação, e uma para o relacionamento,
que terá entre os seus atributos as chaves primárias de cada uma das outras
relações.

Exercícios
Problema 1
 No Aeroporto ViagensLongas é necessário que o cobrador de bilhetes

verifique os Passaportes (nome, país) dos passageiros (n_bi, nome,
nacionalidade)
Pressupostos
 Partindo do principio que cada Passageiro tem um e um só Passaporte
 Elabore um esquema de base de dados com diagrama E-R para o problema

acima representado.

Exercícios
Problema 2
 O Banco MuitoDinheiro tem vários clientes (CodCliente, NomeCliente,,

TelefoneCliente) que movimentam contas (nº conta, saldo).
Pressupostos
 Partindo do principio que cada cliente pode movimentar mais de uma
conta e cada conta só pode ter como titular um cliente.

acima representado.
Exercícios
Problema 3
 A empresa de calçado «CalçaTudo» tem um conjunto de vários clientes

(CodCliente, NomeCliente, MoradaCliente, TelefoneCliente) que lhe compra
vários artigos (Referência, Designação, PreçoUnitário).
Pressupostos
 Partindo do principio que cada cliente pode comprar mais que um par de
sapatos e o mesmo par de sapatos pode ser comprado por mais de um cliente.

acima representado.

Exercícios
Problema 4
 O Aeroporto ViagensLongas fornecem voos para vários destinos e através

de vários aviões com passageiros muito diversos.
Pressupostos
 Partindo do principio que cada avião efectua vários voos para destinos
variados e que cada cliente pode viajar várias vezes para vários destinos.

acima representado.

Exercícios
Problema 5
 O campeonato de Sueca tem várias equipas (nome, localidade) onde

poderão jogar, em cada equipa, vários jogadores (nome, idade).
Pressupostos
 Partindo do principio que cada jogador só pode jogar numa equipa.

acima representado.

Exercícios
Problema 6
 Elabore um esquema de base de dados com diagrama E-R para gerir uma
frota de pesca:
Barcos (Nº, tipo, cor e dimensão)

Marinheiros (Nº, nome, salário e morada e data de nascimento)
Donos dos barcos (Nº, nome e morada).
 Considere como pressupostos que, um marinheiro só trabalha num barco,

um barco tem 5 marinheiros, um dono pode possuir mais de um barco e
cada barco só tem um dono.

Tipos de Relação
 Neste caso, em cada uma das entidades envolvidas, só há, no máximo, uma
ocorrência de cada elemento no relacionamento.
Exemplo: Departamento e Funcionário
 Consideremos que cada departamento tem de ter um e só um director e que

cada indivíduo só pode ser, na melhor das hipóteses, director de um
departamento.

Tipos de Relação
 Os relacionamentos binários ocorrem entre duas entidades ou classes de

entidades diferentes.
 Consoante o número de vezes que cada elemento de cada parte pode entrar no
relacionamento podemos ter diferentes tipos de relacionamentos binários:
a) relacionamentos binários 1:1 (um para um);

b) relacionamentos binários 1:M (um para muitos);
c) relacionamentos binários M:M (muitos para muitos).

Tipos de Relação
 Dizem respeito a situações muito frequentes nos relacionamentos entre

duas entidades. Numa dessas entidades, cada elemento participa, no
máximo, uma só vez (pode não participar nenhuma - participação não
obrigatória).
 Na outra entidade, cada elemento pode participar várias vezes no

relacionamento (podendo ter participação obrigatória, ou não obrigatória,
consoante os casos).

Tipos de Relação
 Exemplo: as entidades Fornecedores e Produtos.
 Consideremos que cada produto só tem um fornecedor e que cada fornecedor

pode fornecer vários produtos diferentes.
Na tabela do lado M, terá de ser incluído um campo (como chave

externa) que fará referência à chave primária da outra tabela. É
através desse campo que é efectuado o relacionamento entre as duas
entidades.

TIC - Base de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TIC - Base de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

MÓDULO 2 – BASES DE DADOS

Professor: Alexandre Lourenço

Teoria de Base de Dados Relacionais

Teoria de Base de Dados Relacionais

 Pode fazer-se uma navegação de

Teoria de Base de Dados Relacionais

 A estrutura é em forma de rede.

 Os registos podem ser

Teoria de Base de Dados Relacionais

 A utilização de uma base de dados estava

 Procurou uma forma de organização dos

Teoria de Base de Dados Relacionais

 As colunas das tabelas representam campos de informação ou atributos

 As linhas das tabelas representam entidades singulares ou ocorrências

Teoria de Base de Dados Relacionais

 Os SGBD relacionais permitem a criação e utilização de bases de dados

SGBD (Sistema de Gestão de Base de Dados).

Teoria de Base de Dados Relacionais

 As unidades fundamentais do modelo relacional de bases de dados são

 As entidades são definidas em termos de atributos - que são

Teoria de Base de Dados Relacionais

Por exemplo, a entidade Aluno, definida pelos seguintes atributos:

Nº de Inscrição, Nome, Data de Nascimento, Sexo, Morada.

Traduzindo para uma notação que é usual, poderíamos representar a

Aluno (N_Aluno, Nome, DataNasc, Sexo, Morada)

Teoria de Base de Dados Relacionais

 Por exemplo, N_Aluno (N.o de um aluno) e Sexo. Os dados de N_Aluno

Teoria de Base de Dados Relacionais

 O nome completo de uma pessoa pode ser decomposto, por exemplo,

 A morada pode ser decomposta, por exemplo, em Rua, Número,

Teoria de Base de Dados Relacionais

Exemplo de duas entidades.

 Por exemplo, na entidade Aluno, o atributo N_Aluno (Nº do aluno) deve

Teoria de Base de Dados Relacionais

 Uma chave, em relação a uma entidade ou tabela, é um atributo ou

Teoria de Base de Dados Relacionais

Exemplos de tabelas e chaves primárias.

Teoria de Base de Dados Relacionais

 Uma chave primária é um atributo ou conjunto de

Teoria de Base de Dados Relacionais

 a chave primária de uma tabela garante integridade de entidades, ou seja,

 é através das chaves primárias que se estabelecem os relacionamentos

 Em entidades em que não há a garantia de que um atributo possa

 É o que acontece na tabela Alunos e na tabela Cursos.

 Na tabela Alunos, a chave primária é o campo NºAluno.

 Na tabela Cursos, a chave primária é o campo CodCurso.

Teoria de Base de Dados Relacionais

 A dupla formada pelos campos NºAluno e CodCurso é uma possível chave

Teoria de Base de Dados Relacionais

 Os sistemas de bases de dados relacionais caracterizam-se

 Os relacionamentos entre entidades baseiam-se nas chaves

Teoria de Base de Dados Relacionais

 A empresa X comercializa vários artigos, os quais são adquiridos a um

 Temos duas entidades que podemos definir como:

Teoria de Base de Dados Relacionais

Artigos tem como

Através das chaves estabelecemos um relacionamento entre a tabela Artigos e a

Teoria de Base de Dados Relacionais

 O campo (CodFornec) é chave primária numa tabela (Fornecedores) e

Uma chave externa é um atributo de uma entidade que é chave

É através das chaves primárias e das chaves externas que se

Teoria de Base de Dados Relacionais

 O modelo relacional obriga a que a realização das operações de