O MODELO RELACIONAL

Prof. Irina Díaz Torres

Introdução
• O modelo relacional foi criado por Edgar F. Codd, nos anos 70 e
começou a ser usado com o advento dos bancos de dados relacionais,
nos anos 80. A idéia de modelo relacional se baseia no princípio de
que as informações em uma base de dados podem ser consideradas
como relações matemáticas e que podem ser representadas, de
maneira uniforme, através do uso de tabelas onde as linhas
representam as ocorrências de uma entidade e as colunas
representam os atributos de uma entidade do modelo conceitual.
Objetivos
• Mostrar um conjunto de regras para transformar um Diagrama
EntidadeRelacionamento em um Diagrama Relacional
 Chaves
Existem diferentes tipos de chave em um modelo relacional. Vamos ver cada um dos tipos de
chave abaixo:

• Chave Primária: A chave primária é usada para identificar univocamente uma linha em uma
tabela. A chave primária pode ser composta, ter vários atributos, ou simples, um único atributo.

• Chave Candidata: A chave candidata é formada por um atributo que identifica uma única linha
na tabela. Como uma tabela pode possuir mais de um atributo identificador único podemos ter
várias chaves candidatas em uma única tabela, sendo que apenas uma das chaves candidatas
pode ser escolhida para ser a chave primária da tabela. As demais chaves permanecem como
chaves candidatas na tabela.

• Chave Estrangeira: A chave estrangeira é formada por atributos que são chave primária em
outra tabela, servindo assim para estabelecer relacionamentos entre as tabelas de um banco de
dados. Assim, quando dizemos que duas tabelas estão relacionadas através de uma coluna
devemos observar que em uma tabela esta coluna será chave primária e na outra tabela ela
será uma chave estrangeira que fará a ligação entre as duas tabelas, estabelecendo o
relacionamento.
Transformação do MER ao MR.
• A Pertença das entidades não é mais que a obrigatoriedade ou não de
que todos os exemplares de uma entidade estejam interrelacionados com
exemplares da(s) outra(s) entidade(é) envolta(s) na inter-relação. Neste
sentido a pertença de uma entidade em uma inter-relação pode ser
obrigatória ou não. diz-se que a pertença de uma entidade em uma inter-
relação é obrigatória quando todas as ocorrências dessa entidade se
interrelacionan com, ao menos, uma ocorrência da(s) outra(s) entidade(é)
da inter-relação.
• Para inter-relações entre duas entidades podem apresentar-se 3
situações típicas de pertença:
• 1.- A pertença de ambas as entidades não é obrigatória.
• 2.- A pertença de ambas as entidades é obrigatória.
• 3.- A pertença de uma entidade é obrigatória e a pertença de outra não.
Exemplo
 Regra para Inter-relações do Cardinalidade 1:1

• Regra 1. Se a Cardinalidade de uma inter-relação binária é 1:1 e a

classe de pertença de ambas as entidades é obrigatória então se
necessita somente uma relação. A chave primária desta relação pode
ser qualquer das chaves das entidades correspondentes.

Docente_Disciplina{
- id_doc,
- nome,
- telefone,
- nome_disc
}
Regra para Inter-relações do Cardinalidade 1:1
• Regra 2. Se a Cardinalidade de
uma inter-relação binária é 1:1 e a
classe de pertença de uma
entidade é obrigatória e a da
outra não, então, necessita-se
duas relações. Por cada entidade
se gera uma relação cuja chave
primária é a chave da entidade • Docente { id_doc, nome, telefone,
correspondente. Além disso a FK: id_disc }
chave da entidade cuja classe de
pertença não é obrigatória se • Disciplina{ id_disc, nome_disc }
deve adicionar em qualidade de
atributo à relação associada à
entidade cuja classe de pertença é
obrigatória.
 Regra para Inter-relações do Cardinalidade 1:1
• Regra 3. Se a Cardinalidade de
uma inter-relação binária é 1:1 e
a classe de pertença de ambas
as entidades não é obrigatória,
então se necessita três relações.
Por cada entidade se gera uma
relação cuja chave primária é a
chave da entidade
correspondente. Além disso se • Docente { id_doc, nome, telefone}
gera outra relação associada ao
enlace a qual deve conter entre
seus atributos as chaves de • Disciplina{ id_disc, nome_disc }
ambas as entidades. Esta última
pode conter outros atributos
associados à inter-relação em si. • Docente_Disciplina{ FK:id_doc,
FK:id_disc}
Regra para inter-relações do Cardinalidade 1:n
• Para este caso se necessitam somente duas regras. O critério que se
dirige aqui é a classe de pertença da entidade do lado n na
Cardinalidade. A classe de pertença da entidade associada ao lado 1
da inter-relação não tem efeito.
 Regra para inter-relações do Cardinalidade 1:n
• Regra 4. Se a Cardinalidade de
uma inter-relação binária é 1:n e
a classe de pertença da entidade
do lado n da inter-relação é
obrigatória, então se necessita
duas relações. Por cada entidade
se gera uma relação cuja chave
primária é a chave da entidade
correspondente. Além disso a • Docente { id_doc, nome, telefone}
chave da entidade associada ao
lado 1 da Cardinalidade da inter-
relação se deve adicionar em • Disciplina{ id_disc, nome_disc,
qualidade de atributo à relação FK: id_doc }
associada à entidade que aparece
em lado n da Cardinalidade.
 Regra para inter-relações do Cardinalidade 1:n
• Regra 5. Se a Cardinalidade de
uma inter-relação binária é 1:n e
a classe de pertença da entidade
do lado n na Cardinalidade da
inter-relação não é obrigatória,
então se necessitam três
relações. Por cada entidade se
horas
gera uma relação cuja chave
primária é a chave da entidade
correspondente. gera-se outra • Docente { id_doc, nome, telefone}
relação para o enlace entre cujos
atributos se devem incluir as • Disciplina{ id_disc, nome_disc }
chaves de ambas as entidades.
Pode conter além outros • Docente_Disciplina{ FK:id_doc,
atributos. FK:id_disc, horas}
Regra para inter-relações do Cardinalidade n: n

• Regra 6. Se a Cardinalidade de
uma relação binária é n:n,
independentemente da
pertença se necessita três
relações: uma por cada
entidade cuja chave primária é
a chave da entidade respectiva;
e outra relação para o enlace. A • Docente { id_doc, nome, telefone}
última deve conter entre seus
• Disciplina{ id_disc, nome_disc }
atributos as chaves das
entidades correspondentes. • Docente_Disciplina{ FK:id_doc,
FK:id_disc}
 Regra para inter-relações Ternárias
• Regra 7. No caso de inter-
relações ternárias são
necessárias quatro relações:
uma por cada entidade envolta,
onde a chave primária de cada
uma é a chave da entidade; e
uma quarta relação para o
enlace. Esta última relação
deve ter entre seus atributos as
chaves de cada uma das • Seminario { id_sem, nome_sem}
entidades envoltas. (De forma • Aluno{ id_alun, nome_alun}
análoga, se em uma inter-
relação estão envoltas N • Instrutor{ id_inst, nome_inst}
entidades se requerem N+1
relações) • Aluno-seminário-instrutor{FK:id_sem,
FK:id_alun, FK:id_inst}
Regra para Relacionamento Auto-relacionamento
• Relacionamento não
obrigatório do lado n:
Aplica-se a regra 5: Três
relações uma para cada
entidade
involucrada(neste caso é
a mesma), e uma para o
relacionamento.
• Empregado{ bi, nome, morada, salario}
• Empregado{ bi, nome, morada, salario}
• Supervisa{ FK:bi_empregado,
FK:bi_supervisor}
Relacionamento
obrigatório do lado n:
Incluir a chave primária da
entidade na própria
entidade como chave
estrangeira, gerando uma
estrutura de acesso a
partir dessa chave.
• Empregado{ bi, nome, morada,
salario, FK: bi_supervisor }
Regra para Mapeamento de Generalização/Especialização
• Deve ser criada uma tabela para a entidade pai e uma tabela para cada entidade
filha. Os atributos comuns às entidades filhas devem ser mapeados na tabela
criada para a entidade pai. As tabelas criadas para cada entidade filha devem
receber o atributo identificador da entidade pai na composição da chave
primária e receber também os atributos específicos da entidade filha
correspondente. A entidade pai e a entidade filha também podem ser mapeadas
para uma única tabela.
• Empregado{ num_empreg, telef,
endereço}
• Supervisor{num_empreg, salario,
área}

• Montador{num_empreg,
num_tarefa, salario_x_hora}
Regra para Entidade Dependente ou Fraca
• Num relacionamento de dependência a participação da entidade
fraca é sempre obrigatória. A entidade fraca terá de incluir nos seus
atributos a chave estrangeira da entidade forte.

• Funcionário{ id_func, nome_func}

• Dependente{ id_depend, nome_dep,
FK:id_func}
Regra para atributo Multivalor
• O atributo localizações é um
atributo multivalor, pois um
departamento possui varias
localizações.
• O atributo multivalor M origina
uma nova entidade que conterá
esse atributo M e a chave
estrangeira da entidade a que ele • Departamento{ numero,
pertence K. A chave primaria da data_inicio_act}
nova entidade será constituída
pela combinação de M com K • Localizações{ id_localização,
FK:numero}
 Regra para atributo Composto
• O atributo data_nasc é um
atributo composto.
• O atributo composto vai-se
descompor na mesma entidade
em atributos simples.

• Paciente{ id_paciente, nome,

endereço, dia_nasc, mês_nasc,
ano_nasc}
 Determinação das Relações a partir do Diagrama
Entidade-Inter-relação

Inter-relação Cardina Pertenença Regra

lidade aplicar

Não obrigatoria para

Trabalhador
n:n qualquer das duas Regra #6
produz Peça
entidades
Peça se n:1 Obrigatoria as duas Regra #4
armacena entidades
Armazém
Regra #6
TRABALHADOR(CIdentidad, NombreTrab, Aexperiencia, Salario, Plaza)
PEÇA(CodPieza, NombrePieza, PrecioCosto, PrecioVenta)*
REPORTE (CIdentidad, CodPieza, Cantproducida)
Regra #4
PEÇA(CodPieza, NombrePieza, PrecioCosto, PrecioVenta, NombreAlm)*
ARMAZEM (NombreAlm, Dirección, Empresa)

Relações obtidas:

TRABALHADOR (CIdentidad, NombreTrab, Aexperiencia, Salario, Plaza)

PEÇA (CodPieza, NombrePieza, PrecioCosto, PrecioVenta, NombreAlm)*
ARMAZEM (NombreAlm, Dirección, Empresa)
REPORTE (CIdentidad, CodPieza, CantProducida)