Você está na página 1de 51

Banco de Dados I

Modelo Relacional

Jorge Cavalcanti Fonsêca (jorge.fonseca@upe.br)


Agenda
 Modelo Relacional
 Álgebra Relacional

 Características de uma relação

 Restrições
 Domínio
 Integridade
 Semântica

 Mapeamento Modelo ER  Modelo Relacional

 Exercício
Modelo Relacional
Linha = 3 (V1, V2, V3)

Domínio

tupla

Conta = subconjunto (D1 x D2 x D3)


Os matemáticos definem uma relação como sendo um subconjunto de
um produto cartesiano de uma lista de domínio.

Essa é justamente a nossa definição de tabela


Modelo Relacional
Linha = 3 (V1, V2, V3)

Domínio

tupla

Esquema x Instância
Esquema de relação:
Esquema_conta = (número_conta, nome_agência, saldo)
Instância de relação:
A própria relação
Modelo Relacional
Mesmo tipo Nome do domínio = coluna = atributo

De maneira geral:
R (A1, A2, A3 ... An )
Grau n

telefones nomes Idade_funcionário


Guto
Pedro 15 40
81 2222-2222 Edi 19
11 3333-3333 Joabe
21 3 4444-4444
20 60
Alex 43 79 80
31 6666-6666
41 9999-9999 Renan
44 34
Erick
Leylane
Modelo Relacional
 Fundamento na álgebra relacional

 Seleção

 Projeção

 Diferença
Modelo Relacional
 Expressões equivalentes
Características de uma relação (vs. Tabelas)
 Ordenação de tuplas em uma relação
 Matematicamente: elementos de um conjunto não
possuem ordem entre eles
 Tabela (arquivo) possui uma ordem
Características de uma relação (vs. Tabelas)
 Valores atômicos
 Cada valor em uma tupla é atômico, ou seja, não é
divisível. Logo, atributos “compostos” e multivalorados
não são permitidos.
Características de uma relação (vs. Tabelas)
 Valores NULLs
 Valores NULLs são usados para representar valores
desconhecidos/indisponíveis ou não aplicáveis

 Se em uma relação clientes, 2 clientes tiverem:


 endereço = NULL - eles moram no mesmo local?
Integridade dos Dados
 Restrições no Modelo Relacional
 No banco de dados relacional, normalmente haverá
muitas relações, e as tuplas nessas relações costumam
estar relacionadas de varias maneiras
Integridade dos Dados (Restrições)
Domínio
 Restrições de Domínio
 Especificam que, dentro de cada tupla, o valor de um
atributo A deve ser um valor indivisível do domínio
dom(A).
 Ou seja, o valor de um atributo deve obedecer a definição
de valores admitidos para a coluna
Domínio
 Restrições de chave
 Uma relação não pode abrigar duas tuplas iguais.
Isto é, não pode haver a mesma combinação de
valores para todos os atributos
 Chave-primária (Primary Key - PK)

 Restrições sobre valor NULL


 Indica se valores nulls são ou não permitidos
 Uma condição NOT NULL pode ser especificada
Integridade
 Restrições de Integridade
 Integridade de Entidade
 Nenhum valor de chave primária pode ser NULL

 Integridade Referencial
 É especificada entre duas relações e usada para manter
a consistência entre tuplas nas duas relações.
 Chave Estrangeira (Foreign Key – FK)
Chave Estrangeira

esta
Funcionário alocado Departamento
N 1
Chave Estrangeira

Dadas duas relações R1 e R2, uma chave estrangeira


é uma chave primária de R1 em R2
Restrições Semânticas
 Um exemplo: O salário de um funcionário não
pode ser maior que o de um supervisor

 A idade de um funcionário deve estar entre 15 e


80 anos
Operações sobre BDs
 Existem três operações básicas que podem
mudar o estado de um banco de dados
 Inserir
 Alterar
 Excluir

 Sempre que estas operações forem executadas,


as restrições de integridade precisam ser
verificadas
Operações sobre BDs
 Inserir
 Pode violar restrições de domínio, de chave, de entidade e
integridade referencial
 Caso isso aconteça, a inserção deve ser rejeitada
 Excluir
 Pode violar a integridade referencial
 Isso ocorre quando uma tupla que é referenciada em outras
relações é excluída
 Restrict: Rejeitar a exclusão
 Cascade: propagar a exclusão
 Set null: atribui o valor null às tuplas que referenciam a tupla a ser
excluída
 Alterar
 Pode violar integridade de domínio, de chave e de integridade
referencial (quando modificamos a PK, por exemplo)
Esquema de Banco de Dados Relacional
 Dado um determinado Modelo de BD ER:
Nome Nome

CPF Vendedor Atende Cliente CPF


N M

Salario Endereço

 Um esquema de banco de dados relacional é:

Vendedor(nome, cpf, salario)


Atende(VendedorCpf, Clientecpf)
Cliente(nome, cpf, Endereço)
Como transformar um modelo ER em um
modelo/esquema relacional?
Modelo Lógico

Necessidades de dados
dos prováveis usuários 1. Modelo Conceitual
do BD (Alto nível)
(Mini-mundo)

2. Modelo Lógico
(Dados representativos)
Mapeamento ER  Relacional

3. Modelo Físico
(Baixo nível)
Mapeamento ER  Relacional
 Agora que sabemos reproduzir as necessidades dos
clientes em um modelo de alto nível

 E começamos a entender o que é um modelo


relacional e suas restrições

 Precisamos saber como transformar/mapear um


Modelo ER em um modelo relacional
Mapeamento ER  Relacional
 Capítulo 9 – Apresenta um
algoritmo de mapeamento

 7 Etapas

 Entidade forte, entidade


fraca, 1-1, 1-N, M-N,
atributos multivalorados,
relacionamento n-ário.
Modelo ER - Empresa
Etapa 1: Entidade Regular (Forte)
 Para cada tipo de entidade regular E, crie uma
relação R que inclua todos os atributos simples
de E

 Atributo-chave de E  Chave primário (PK) da


relação R.

 Informação sobre chaves candidatas devem ser


mantidas (registros, notas etc.).
Etapa 1: Entidade Regular (Forte)
Etapa 1: Entidade Regular (Forte)
Etapa 2: Entidade Fraca
 Para cada tipo de entidade fraca, crie uma
relação R e inclua todos os atributos simples
deste tipo de entidade como atributos de R

 Inclua como atributos de chave estrangeira de R


os atributos de chave primária da entidade
proprietária
Etapa 2: Entidade Fraca
Etapa 2: Entidade Fraca

PK da entidade Chave parcial da entidade Fraca


“proprietária”
Etapa 3: Relacionamento 1:1
 Dadas duas relações S e T escolha uma das
relações, digamos S, e inclua como chave
estrangeira em S a chave primária de T

 Recomenda-se selecionar a entidade que tem


participação total

 Caso haja atributos de relacionamento, inclua-os na


mesma relação que recebe a chave estrangeira
Etapa 3: Relacionamento 1:1

Participação
Total
Etapa 3: Relacionamento 1:1

Não é obrigatório renomear, mas


em vários casos facilita identificar a
semântica do atributo

Atributo da relação
Etapa 4: Relacionamento 1:N
 Identifique a relação S que representa o tipo de
entidade participante no lado N do tipo de
relacionamento

 Inclua como chave estrangeira em S a chave


primária da relação T

 Inclua quaisquer atributos simples do tipo de


relacionamento 1:N como atributos de S
Etapa 4: Relacionamento 1:N
Etapa 4: Relacionamento 1:N
Etapa 5: Relacionamento M:N
 Como representar? É possível colocar atributos de
uma relação em outra?
 Crie uma nova relação S

 Inclua como atributos de chave estrangeira em S as


chaves primárias das relações que representam os tipos
de entidade participantes

 Inclua também quaisquer atributos simples do tipo de


relacionamento M:N
Etapa 5: Relacionamento M:N
Etapa 5: Relacionamento M:N
Etapa 6: Atributos multivalorados
 Para cada atributo multivalorado A da entidade E
 Crie uma nova relação R

 A chave primária de R é a combinação de A e chave


primária da entidade E

 Se o atributo multivalorado for composto, inclua seus


componentes simples
Etapa 6: Atributos multivalorados
Etapa 6: Atributos multivalorados
Esquema de banco de dados Relacional
Empresa (Final)
Etapa 7: Relacionamentos n-ário
 Crie uma nova relação S para representar R

 Inclua como atributos de chave estrangeira as chaves


primárias das relações que representam os tipos de
entidade participantes
 Se existir cardinalidade 1 sobre qualquer entidade, a chave-
estrangeira associada a esta entidade não é chave-primária da
nova relação S.

 Inclua todos os atributos simples como atributos


Etapa 7: Relacionamentos n-ário
Fnome Proj_nome

Fornecedor Fornece Projeto


N N

N
Peça Num_peca
Etapa 7: Relacionamentos n-ário
Fnome Cli_nome

Empregado Trabalha Cliente


N 1

N
Projeto Num_proj

Não é chave primária


Correspondência: ER - Relacional
Exercício
Fazer o mapeamento ERRelacional
Banco de Dados I
Modelo Relacional

Jorge Cavalcanti Fonsêca (jorge.fonseca@upe.br)

Você também pode gostar