Aula BD3 e BD4

Sistema de Gestão de Banco de

Dados Relacionais

Técnicas e Linguagens de Programação

Professor: Lucas Pazito
 Introdução
Já vimos que existem 4 tipos de modelos de
banco de dados. Mas o modelo que merecerá o
nosso estudo será o Modelo Relacional. Neste
modelo veremos os conceitos mais
importantes, como tabelas, registos e campos,
e o modelo Relacional que inclui o processo de
Normalização.
 O Modelo Relacional
O Modelo Relacional é o mais utilizado, uma vez que utiliza
tabelas bidimensionais para representação lógica dos dados e suas
relações. O elemento principal do modelo relacional é a relação
representada numa tabela. Então podemos dizer que uma base de
dados relacional é um conjunto de tabelas relacionadas entre si.

O aspecto mais importante do modelo Relacional é a Entidade,

também chamada de Tabela.

Entidade : Conjunto de objectos da realidade modelada nas quais

se deseja manter a informação no banco de dados.
Exemplo: Numa biblioteca, uma das entidades ou
Tabelas, pode ser :
a) Livros
b) Categorias
Uma Entidade ou Tabela é composta por linhas e
colunas. As linhas são chamadas de Registos e as
Colunas são chamadas de Campos.
 Noção de Tabela
Um Banco de Dados relacional é um conjunto de
Tabelas Lógicas relacionadas entre si. Assim,
uma Tabela é a Estrutura onde estão
armazenadas uma classe de Dados do banco de
Dados.

Ex: Clientes, Fornecedores, alunos

 Noção de Registro
Um Registro é a estrutura onde está
armazenado uma única entidade de uma classe
de dados. Ou seja, dentro de uma Tabela cada
linha desta tabela representa um único Registro.

Ex: Um cliente, um Fornecedor, um Aluno

 Noção de Campo
Um Campo é a estrutura onde está armazenado
uma única informação relacionada ás entidades
de uma classe de dados.
Ex: Nome do cliente, Nome do Fornecedor,
idade de um aluno.
RESUMO
 Classificação dos Campos de Um
Tabela
Os campos de uma Tabela podem ser:
▪1-Chave Primária
▪2- Chave Candidata
▪3- Chave Estrangeira
 Chave Primária(PRIMARY KEY)
È Um atributo que permite identificar univocamente os registros de uma
Tabela
Este tipo de chave, refere-se aos conjuntos de um ou mais campos, cujos
valores, considerando a combinação de valores de todos os campos da tupla
(registro), nunca se repetem e que podem ser usadas como um índice para
os demais campos da tabela do banco de dados. Em chaves primárias, não
pode haver valores nulos nem repetição de tuplas.
Quando a chave é simples ela é formada por um único campo da tabela,
sendo que este campo não pode ter dois valores ou mais registros de
mesmo valor, e não pode conter registro nulo.
Quando a chave é composta, ou seja, formada por mais de um campo, os
valores podem se repetir, mas não a combinação desses valores
 Características de uma Chave
Primária
▪ Não pode haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na
Chave Primária;
▪ A chave primária não pode ser composta por atributo opcional , ou seja , atributo
que aceite nulo.
▪ Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada
instância de um entidade.

▪ Não devem ser usadas chaves externas. (Atributos sobre os quais você não tem
controle. Ex: CPF)
▪ Cada atributo identificador da chave deve possui um tamanho reduzido

▪ Não deve conter informação volátil.

 Chave Estrangeira (FOREIGN KEY)
È uma Chave que é primária numa tabela, mas que aparece em uma outra tabela.
Este tipo de chave é utilizado para criar os relacionamentos entre as tabelas. Imagine que
você queira cadastrar vários produtos que sejam de uma determinada categoria. Toda vez
que você preencher os dados do produto, precisaremos indicar a chave primária da tabela
categoria que seja da categoria que o nosso produto pertencerá. Ou seja, quando
inserirmos um registro na tabela de produtos com o “id_categoria”, essa chave primária da
tabela “categorias” representará uma chave estrangeira (FK) dentro da tabela de
produtos. É uma chave que vem de fora, de outra tabela.
Com essa chave estrangeira, podemos facilitar as consultas e fazer cruzamento de dados
através destas referências, o que poderia gerar uma consulta que iria pegar o nome do
produto e o nome da categoria que ele pertence para exibirmos em uma listagem dos
dados.
Perceba que a chave estrangeira não será única dentro da tabela de produtos, já que
podemos ter vários produtos de uma categoria. Já no caso da chave primária, sempre será
e deverá ser única
 Chaves Candidatas
Uma chave candidata é um identificador único que garante que
nenhuma tupla será duplicada; isto faz com que seja criado um
relacionamento em algo denominado multiconjunto, porque viola a
definição básica de um conjunto. Uma chave pode ser composta, isto é,
pode ser formada por vários atributos.
Ocorrem quando em uma relação(Tabela) existe mais de uma
combinação de atributos para a identificação única do registro.
 Tipos de Relacionamentos
De acordo com a cardinalidade existem 3 tipos básicos de
relacionamentos entre as entidades.
▪ RELACIONAMENTOS UM PARA UM
▪ RELACIONAMENTOS MUITOS PARA MUITOS
▪ RELACIONAMENTOS UM PARA MUITOS
 Um para Muitos 1:N
Um relacionamento 1:1 ocorre com frequência em situações de negócio. Às
vezes ocorre em forma de árvore ou em forma hierárquica. No exemplo
abaixo, temos a seguinte representação: Cada curso cadastrado possui vários
alunos ligados a ele, pois cada aluno, ao ser cadastrado, deverá ser ligado a
um curso obrigatoriamente. O campo codigocurso foi escolhido como chave
primária na tabela CURSO, ou seja, ela não poderá se repetir. Já na tabela
ALUNO, a chave primária é matricula e o codigocurso é chave estrangeira. A
representação ficaria assim:
 Um para UM 1:1
São relacionamentos em que uma ocorrência de uma entidade em A está associada no
máximo a uma ocorrência em uma entidade B e uma ocorrência na entidade B está associada
no máximo a uma ocorrência na entidade A.
Neste relacionamento, escolhemos qual tabela irá receber a chave estrangeira, e para cada
valor do campo na tabela A, há no máximo um valor na tabela B.
No exemplo mostrado na Figura abaixo podemos entender melhor este tipo de
relacionamento, onde estaremos definindo que um Gerente (e somente um) gerencia um (e
somente um) Departamento. Ou seja, o mesmo Gerente não pode gerenciar mais de um
Departamento e um Departamento não poderá ser gerenciado por mais de um Gerente.
Muitos para Muitos
Uma ocorrência de uma entidade em A está associada a qualquer número de
ocorrências na entidade B, e cada ocorrência da entidade em B está associada a
qualquer número de ocorrências na entidade A.

Considere o caso em que itens são vendidos. Podemos identificar imediatamente

duas entidades: VENDA e ITEM. Uma venda pode consistir em muitos itens de
mercadorias e um item de mercadoria pode aparecer em muitas vendas. Não
estamos dizendo que um mesmo item possa ser vendido muitas vezes, mas que o
tipo específico de item (por exemplo, um livro ) pode ser vendido muitas vezes;
temos, portanto, um relacionamento de muitos-para-muitos (m:m) entre VENDA
e ITEM.
Muitos para Muitos
Em um relacionamento m:m, criamos uma terceira entidade, chamada entidade associativa que é
usada para associar as entidades por meio de dois relacionamentos 1:m. De maneira geral, é
razoavelmente fácil nomear essa terceira entidade. Nesse exemplo, essa terceira entidade,
geralmente conhecida como entidade associativa, é chamada de VENDA_MERCADORIA.

Observe a figura abaixo. Observe a representação do relacionamento. Cada uma das linhas que
aparece no formulário do pedido de vendas é, em geral, conhecida no varejo como um item de
linha, onde o código da mercadoria é ligado a uma venda.
 Muitos para Muitos
Dizemos muitos para muitos porque há dois relacionamentos: CODIGO DA MERCADORIA está
relacionado com muitas VENDAS e VENDA está relacionada com muitos CÓDIGOS DE MERCADORIA.

No caso do nosso exemplo, a entidade associativa é a VENDA_MERCADORIA. Podemos fazer a leitura do

relacionamento acima da seguinte forma:

▪ UMA VENDA POSSUI VÁRIOS ITENS DE MERCADORIA

▪ CADA MERCADORIA PODERÁ ESTAR LIGADO À VÁRIAS VENDAS

Por que criamos uma terceira entidade ?

▪ Quando temos um relacionamento m:m e precisamos manter informações sobre este relacionamento,
criamos uma entidade associativa para armazenar informações sobre o relacionamento. Neste caso,
armazenamos dados sobre as mercadorias vendidas. Não podemos armazenar estes dados em VENDAS,
pois uma venda pode ter muitos itens e uma entidade só armazena ocorrências de valores simples. Da
mesma maneira, não podemos armazenar esses dados em MERCADORIAS, porque um código de
mercadoria pode aparecer em muitas vendas.