BD1 - O Modelo Lógico

Banco de Dados 

O Modelo Lógico 

O Modelo Lógico 

26/10/2019 1

Modelo Lógico 

• Deriva de um modelo conceitual já construído e depende da 

abordagem de banco de dados que será utilizada. 

Modelo Conceitual 

Representação abstrata 

da realidade observada 

Modelo Lógico 

Representação sob a 

forma de tabelas 

Modelo Físico 

Representação de acordo 

com o SGBD utilizado 

O Modelo Lógico 26 de outubro de 2019 2

Modelo Relacional 

• Foi criado com base na teoria dos conjuntos, na qual: 

• os dados são representados como tabelas (relações); 

• através de linhas (tuplas); 

• e colunas (atributos); 

• com os possíveis valores (domínio) definidos; 

• as operações sobre os dados são feitas por uma linguagem 

não procedural. 

• Foi criado na década de 70 por Edgard F. Codd. 



• Permite a especificação do esquema do banco de dados, através 

do Diagrama Relacional. 

CLIENTE 

PEDIDO 

ITENS 

PRODUTO 

CIDADE 

FUNCIONÁRIO 

FUNÇÃO 

TIPO 

PAÍS 

SETOR 

Esquema Lógico 

= 

Diagrama Relacional 


Terminologias 

nome do campo 

nome do atributo 

coluna, atributo, campo 

tabela 

relação 

Código 

001 

002 

003 

Nome 

José 

Antonio 

Ana 

Fone Estado 

3212.1234 PE 

3244.1212 

PB 

3237.4859 RN 

linha, tupla, registro 

valor do campo 

valor do atributo 

domínio 


Terminologias 

• Coluna, Atributo, Campo 

• Dado que se deseja armazenar sobre um objeto. Deve possuir 

um nome, um tipo de acordo com a natureza do dado e um 

tamanho específico. 

• Linha, Tupla, Registro 

• Conjunto de campos que representa uma ocorrência 

específica de um objeto. Deve ser identificado de forma única 

dentro da tabela. 

• Tabela, Relação 

• Conjunto de tuplas que contém os dados sobre um objeto 

específico. Deve possuir um nome único dentro do banco de 

dados. 


Terminologias 

• Domínio 

• Conjunto de valores distintos que podem ser definidos a um 

atributo. 

• Domínio Discreto 

• Conjunto de valores distintos, definidos previamente. 

• Domínio Contínuo 

• Conjunto de valores permitidos dentro de um intervalo. 

• Domínio Aberto 

• Conjunto de valores permitidos, sem restrições. 

• Domínio Nulo (inaplicável ou desconhecido) 

• É um valor nulo, diferente de zero ou espaço em branco. 



• É baseado no conhecimento dos dados presentes em um modelo 

conceitual já definido. 

1 N N N N 1 

CLIENTE FAZ PEDIDO 

CONTÉM PRODUTO POSSUI TIPO 

N 

N 

RESIDE 

ATENDIDO 

1 1 N 1 

RESIDE 

N 1 

CIDADE 

FUNCIONÁRIO POSSUI 

FUNÇÃO 

1 N 

N 

NASCEU 

N 

1 

PERTENCE 

TRABALHA 

DIRIGE 

1 

1 

1 

PAÍS 

1 N 

SETOR 

CHEFIA 

CLIENTE 

código 

nome 

tipo 

contato 

cargo 

endereço 

cidade (FK) 

cep 

fone 

fax 

obs 

CIDADE 

PAÍS 

código 

nome 

uf 

sigla (FK) 

sigla 

nome 

PEDIDO 

código 

cliente (FK) 

vendedor (FK) 

datapedid 

datafatura 

via 

frete 

FUNCIONÁRIO 

código 

nome 

sexo 

estcivil 

rg 

cpf 

trat 

datanasc 

natural (FK) 

dataadm 

endereço 

complement 

bairro 

cidade (FK) 

cep 

fone 

celular 

função (FK) 

setor (FK) 

salário 

email 

obs 

ITENS 

pedido (FK) 

produto (FK) 

preço 

quant 

desconto 

FUNÇÃO 

código 

nome 

gratific 

SETOR 

sigla 

nome 

ramal 

superior (FK) 

chefe (FK) 

PRODUTO 

TIPO 

código 

nome 

descrição 

apresent 

venda 

custo 

quantest 

estmin 

tipo (FK) 

situação 

código 

nome 

descrição 


Características Básicas 

• Aspecto estrutural: os dados são organizados e percebidos pelos 

usuários como tabelas relacionadas. 



• Aspecto de integridade: as tabelas devem satisfazer às restrições 

de integridade impostas ao modelo. 

INTEGRIDADE 

DE DOMÍNIO 

INTEGRIDADE 

DE UNICIDADE 

INTEGRIDADE 

DE VAZIO 

INTEGRIDADE 

REFERENCIAL 



• Integridade de domínio: 

• Especifica que um valor associado a um atributo deve 

pertencer ao domínio do atributo. 

• Integridade de unicidade: 

• Especifica que as linhas de uma tabela devem ser únicas (não 

pode haver repetição de linhas). 

• Integridade de vazio: 

• Especifica quais os atributos que podem ser nulos. 

• Integridade referencial: 

• Especifica que os relacionamentos devem manter integridade 

entre as tabelas relacionadas. 



• Aspecto manipulativo: os dados são manipulados, para efeito de 

consultas, por operadores que geram tabelas a partir de outras 

tabelas. 

• Utiliza operadores de: 

• Seleção: extrai linhas específicas de uma tabela. 

• Projeção: extrai colunas específicas de uma tabela. 

• Junção: une duas tabelas com base em valores comuns 

existentes em uma coluna comum. 

• União: une duas tabelas com a mesma estrutura. 

• Etc ... 


Chave Primária 

• Atributo ou conjunto de atributos que identifica cada linha em 

uma tabela de forma única. 

• Exemplo: 

• Tabela: CLIENTE 

• Chave primária: codcliente 

cpf 

endereco 

CLIENTE 

codcliente 

nome 



• Uma chave primária também pode ser formada pela junção de 

dois ou mais atributos. 

• Exemplo: 

• Tabela: ITENS DE PEDIDO 

• Chave primária: codpedido + codproduto 

preço quantidade 

ITENS 

codpedido 

codproduto 



• A chave primária de uma tabela corresponde ao atributo 

identificador de uma entidade. 

• Cada tabela deverá possuir uma única chave primária, que não 

admite valores repetidos ou nulos. 

• A chave primária pode ser utilizada como referência em um 

relacionamento. 

• Uma chave primária concatenada deve ser mínima, ou seja, 

todos os seus atributos são necessários para garantir a unicidade 

de valores da chave. 

• A criação de uma chave primária faz com que a tabela seja 

ordenada por essa chave. 


Chave Candidata 

• Atributo ou conjunto de atributos que identifica unicamente 

cada linha em uma tabela, de forma alternativa. 

• Exemplo: 

• Tabela: CLIENTE 

• Chave candidata: cpf 

cpf 

endereco 

CLIENTE 

codcliente 

nome 


Chave Candidata 

• Uma tabela pode possuir mais de uma chave candidata. 

• A chave candidata é também chamada de chave alternativa. 

• A chave candidata não admite repetição de valores. 

• Uma chave candidata pode ser concatenada. 

• Uma chave candidata concatenada deverá ser mínima, ou seja, 

todos os seus atributos são necessários para garantir a unicidade 

de valores da chave. 


Chave Estrangeira 

• Atributo ou conjunto de atributos que estabelece um 

relacionamento entre duas tabelas. 

• Exemplo: 

• Tabelas: CLIENTE e PEDIDO 

• Chave estrangeira: codcliente 

cpf 

endereco 

frete 

codcliente 

CLIENTE 

(1,1) (0,n) 

FAZ 

PEDIDO 

codcliente 

nome 

codpedido 

data 



Tabela PEDIDO 

codpedido data cliente vendedor 

P1 22/01/2013 C1 F1 

P2 25/01/2013 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C2 F4 

Tabela CLIENTE 

codcli nome fone 

C1 Ana 99212647 

C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 

Tabela FUNCIONÁRIO 

codfun nome fone 

F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 



• Uma tabela pode possuir várias chaves estrangeiras, uma para 

cada relacionamento. 

• Uma chave estrangeira faz referência à chave primária de uma 

tabela. 

• Dependendo da cardinalidade máxima do relacionamento, uma 

chave estrangeira pode ter valores repetidos. 

• Dependendo da cardinalidade mínima do relacionamento, uma 

chave estrangeira pode ter valores nulos. 

• As colunas pertencentes a uma chave estrangeira deverão ter o 

mesmo domínio das colunas referenciadas. 



• O valor de uma chave estrangeira pode ser: 

• Igual ao(s) valor(es) da(s) coluna(s) referenciada(s): 

✓ Neste caso linha da tabela participa do relacionamento. 

• Nulo: 

✓ Neste caso a linha da tabela não participa do 


FUNCIONÁRIO 

código 

1001 

1002 

nome 

José Paulo 

Ana Maria 

fone 

3222.2222 

3445.1231 

função 

F3 

nulo 

Existe função 

Não existe função 



• Em um auto-relacionamento de cardinalidade 1:1 ou 1:N, a chave 

estrangeira faz parte da própria tabela. 

codfun nome fone funcao chefe 

1001 José Paulo 93022222 F3 nulo 

1002 Ana Maria 91341234 nulo 1001 

1003 Marcos Pilo 88693785 F2 1001 

1004 Bruno Matias 82303787 F1 1003 

1005 Márcia Souto 88369002 F3 1003 

1006 Sandra Carla 91236547 F2 1003 


Restrições de Integridade 

• Integridade semântica 

• definida pelas regras de negócio do sistema. O usuário 

necessita implementá-las explicitamente. 

• Integridade de domínio 

• Especifica que todo valor associado a um atributo deve ser 

atômico e pertencer ao domínio do atributo. 

• Integridade de unicidade 

• especifica que os valores das chaves primárias e candidatas 

devem ser únicos (sem repetição). 

• Integridade de vazio 

• especifica quais os atributos de uma tabela que podem 

receber valores nulos. 


Integridade Semântica 

• Garante que o estado dos dados está sempre de acordo com as 

regras do negócio. 

• É implementada pelas restrições de checagem de dados, pela 

obrigatoriedade e unicidade do dado e pelos triggers. 

• Exemplos de restrições semânticas: 

• um funcionário não pode ter o salário superior ao salário do 

seu chefe imediato. 

• a quantidade de um produto em um pedido não pode ser 

superior à quantidade em estoque desse produto. 

• um funcionário do setor de vendas não pode ter a função de 

engenheiro. 


Integridade Semântica 

• Exemplos de falta de integridade semântica: 

• violação de domínio: 

• funcionário com 200 anos de idade. 

• data de nascimento no próximo ano. 

• atributos significativos sem valor: 

• nome do funcionário nulo. 

• quantidade pedida de um produto nula. 

• relacionamentos incorretos ou inexistentes: 

• um pedido para vários clientes. 

• um pedido sem produtos. 


Integridade Referencial 

• Especifica que os valores de uma chave estrangeira devem estar 

presentes na chave primária da tabela referenciada. 

• É implementada pela definição de cada uma das ações de 

atualização de dados em cada relacionamento. 

• Inclusão de dados 

• Restrita 

• Exclusão de dados: 

• Restrita e Cascata 

• Alteração de dados: 

• Restrita e Cascata 


IR - Inclusão Restrita 

• Inclusão de dados – restrita 

• Impede que seja inserido na chave estrangeira da tabela filho, 

um valor que não exista previamente na coluna referenciada 

da tabela pai. 

• Exemplo: 

• Em um relacionamento entre CLIENTE e PEDIDO, só é 

possível inserir um cliente e um vendedor na tabela 

PEDIDO, se esse cliente já existir previamente cadastrado 

na tabela CLIENTE e o vendedor na tabela de 

FUNCIONÁRIO. 

• Não pode ser inserido o cliente C5 ou o funcionário F5 na 

tabela PEDIDO. 


IR - Inclusão Restrita 

Tabela PEDIDO 


P1 22/01/2013 C1 F1 

P2 25/01/2013 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C2 F4 



C1 Ana 99212647 

C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 



F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 


IR - Exclusão Restrita 

• Exclusão de dados – restrita 

• Impede que um registro seja excluído da tabela pai, se existir 

algum registro relacionado a ele na tabela filho. 

• Exemplo: 

• Em um relacionamento entre CLIENTE e PEDIDO, não é 

possível a exclusão de um cliente se existirem pedidos 

feitos por ele. 

• A cliente Paula não pode ser excluída da tabela CLIENTE. 


IR - Exclusão Restrita 

Tabela PEDIDO 


P1 22/01/2013 C1 F1 

P2 25/01/2013 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C2 F4 



C1 Ana 99212647 

C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 



F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 


IR - Exclusão Cascata 

• Exclusão de dados – cascata 

• Quando um registro da tabela pai é excluído, todos os 

registros relacionados a ele, existentes na tabela filho, 

também são excluídos. 

• Exemplo: 

• Em um relacionamento entre CLIENTE e PEDIDO, ao se 

excluir um cliente todos os pedidos feitos por ele também 

são excluídos. 

• Quando a cliente Paula é excluída, todos os pedidos feitos 

por ela também serão. 


IR - Exclusão Cascata 

Tabela PEDIDO 


P1 22/01/2013 C1 F1 

P2 25/01/2013 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C2 F4 



C1 Ana 99212647 

C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 



F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 


IR - Alteração Restrita 

• Alteração de dados na tabela pai – restrita 

• Impede que um valor de chave primária seja alterado na 

tabela pai, se existir algum registro relacionado na tabela 

filho. 

• Exemplo: 


possível a alteração da chave primária de um cliente se 

existirem pedidos feitos por ele. 

• A chave primária da cliente Paula não poderá ser alterada 

porque ela já realizou pedido. 



Tabela PEDIDO 


P1 22/01/2013 C1 F1 

P2 25/01/2013 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C2 F4 



C1 Ana 99212647 

C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 



F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 



• Alteração de dados na tabela filho – restrita 

• Impede que um valor de chave estrangeira seja alterado na 

tabela filho, se não existir algum registro com o novo valor na 

coluna relacionada da tabela pai. 

• Exemplo: 


possível a alteração do código do cliente na tabela de 

pedidos, se não existir esse código na tabela de clientes. 

• Qualquer código de cliente ou de vendedor que exista na 

tabela PEDIDO só poderá ser alterado para um valor que 

exista nas tabelas CLIENTE e FUNCIONÁRIO. 



Tabela PEDIDO 


P1 22/01/2013 C1 F1 

P2 25/01/2013 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C2 F4 



C1 Ana 99212647 

C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 



F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 


IR - Alteração Cascata 

• Alteração de dados – cascata 

• Quando um registro da tabela pai é alterado, todos os 

registros relacionados a ele, existentes na tabela filho, 

também são alterados. 

• Exemplo: 

• Em um relacionamento entre CLIENTE e PEDIDO, ao se 

alterar um cliente todos os pedidos feitos por ele também 

são alterados. 

• Se alterar o código da cliente Paula para C8 na tabela 

CLIENTE, os valores da coluna cliente na tabela PEDIDO 

também serão alterados para esse valor. 


IR - Alteração Cascata 

Tabela PEDIDO 


P1 22/01/2013 C1 F1 

P2 25/01/2013 C8 C2 F2 

P3 28/01/2013 C3 F1 

P4 28/01/2013 C8 C2 F4 



C1 Ana 99212647 

C8 C2 Paula 88417371 

C3 João 93024677 

C4 Manuel 87568920 



F1 Paula 99867643 

F2 Carla 89879092 

F3 Marcos 93028675 

F4 Pedro 88245620 


Mapeamento E-R para Relacional 

• Pode ser realizado manualmente ou implementado através de 

ferramentas CASE. 

• Objetivos Básicos: 

• Obter bom desempenho; 

• Simplificar o desenvolvimento de aplicações. 

• Regras Gerais: 

• Evitar junções desnecessárias; 

• Diminuir o tamanho das chaves primárias; 

• Procurar evitar muitos campos opcionais. 


Notação Usada no MySQL Workbench 

Relacionamento 1:1 

Notação Peter Chen 

Relacionamento 1:1 

Notação Crow’s Foot 


Notação Usada no MySQL Workbench 

Relacionamento 1:n 

Notação Peter Chen 

Relacionamento 1:n 

Notação Crow’s Foot 


Mapeamento das Entidades e Atributos 

• Cada entidade torna-se uma tabela. 

• Pode ocorrer, em alguns casos, de algumas entidades se 

unirem para dar origem a uma única tabela (fusão de tabelas). 

• Cada atributo da entidade torna-se um campo da tabela criada, 

com um domínio definido. 

• O atributo identificador da entidade torna-se a chave primária 

da tabela. 

• Os atributos compostos e multivalorados deverão ser 

implementados. 

• Os atributos derivados deverão ser excluídos. 

• Os atributos referenciais deverão ser exibidos. 


Mapeamento das Entidades e Atributos 

Atributo composto 

Esquema E-R 

Atributo multivalorado 

Esquema Relacional 


Mapeamento dos Relacionamentos 

• A transformação dos relacionamentos pode ser realizada de três 

formas distintas: 

• Fazendo adição de colunas em uma das tabelas que 

participam do relacionamento. 

• Criando uma tabela própria para o relacionamento. 

• Fazendo a fusão das tabelas que participam do 


• A alternativa a ser escolhida depende das cardinalidades máxima 

e mínima do relacionamento. 


Adição de Colunas 

• O relacionamento é implementado através da inserção em uma 

das tabelas, das seguintes colunas: 

• Coluna(s) correspondente(s) à chave primária da tabela 

relacionada (chave estrangeira). 

• Colunas correspondentes aos atributos do relacionamento (se 

existirem). 

• As chaves primárias das tabelas que participam do 

relacionamento permanecem inalteradas, exceto em casos de 

relacionamento identificador. 





• Sempre que a entidade que cede a chave estrangeira estiver do 

lado do relacionamento que tem cardinalidade mínima igual a 0, 

a chave estrangeira poderá possuir valores nulos em algumas 

ocorrências. 

A (a1, a2, a3) 

B (b1, b2, b3, r1*, r2*, a1*) 

[a1*] referencia A 

atributos do 

relacionamento 

FK pode ser nula em 

algumas ocorrências 

Sempre que a FK for nula os 

atributos do relacionamento 

também serão. 



• Um professor ensina nenhuma ou várias disciplinas. 

• Cada disciplina tem um único professor e pode ser cadastrada 

sem haver professor para a mesma 

• Deve-se registrar a data em que o professor começou a ensinar a 

disciplina e o valor que ele recebe por esse trabalho. 

• Esquema E-R 



• Esquema Relacional 

PROFESSOR (codprof, nome, cpf, rg) 

chaves primárias (PK) 

DISCIPLINA (coddisc, nome, creditos, periodo, valor*, dtinicio*, codprof*) 

[codprof*] referencia PROFESSOR 

chave estrangeira (FK) 


Tabela Própria 

• É criada uma tabela para o relacionamento contendo: 

• Colunas correspondentes às chaves estrangeiras, oriundas das 

tabelas relacionadas. 

• Colunas correspondentes aos atributos do relacionamento (se 

existirem). 

• A chave primária desta tabela é formada: 

• Pelas duas chaves estrangeiras concatenadas; 

• A chave primária também pode ser concatenada com colunas 

do relacionamento (se existirem); 

• Se a cardinalidade do relacionamento for de 1:N (caso 

especial), a chave primária da tabela própria poderá ser 

formada por apenas uma das chaves estrangeiras. 





• Considerando que apenas as ocorrências que efetivamente 

estarão se relacionando irão aparecer na tabela própria, não 

existem chaves estrangeiras nulas na tabela criada. 

Relacionamento obrigatório 



• Um pedido contém um ou vários produtos. 

• Um produto pode estar em nenhum ou em vários pedidos. 

• Deve-se registrar a quantidade pedida e o preço pelo qual cada 

produto foi vendido em cada pedido. 





PEDIDO (codped, dataped, frete) 

PRODUTO (codprod, nome, quantest, venda) 

CONTEM (codped, codprod, quant, preco) 

[codped] referencia PEDIDO 

[codprod] referencia PRODUTO 


Fusão de Tabelas 

• O relacionamento é representado por uma única tabela, 

resultante da fusão das duas tabelas do relacionamento. 

• Todas as colunas de uma das tabelas são movidas para a outra 

tabela do relacionamento. 

• A chave primária da tabela que cedeu as colunas pode deixar de 

existir em alguns casos. 

• Todas as colunas correspondentes aos atributos do 

relacionamento (se existirem) também são movidas para a tabela 

resultante. 

• A chave primária da tabela final permanece inalterada. 



A (a1, a2, a3, b1*, b2*, b3*, r1*, r2*) 



• Um professor pode coordenar apenas um curso. 

• Um curso tem apenas um coordenador. 

• Deve-se registrar a data em que o professor começou a 

coordenar o curso e o valor que ele recebe por esse trabalho. 





PROFESSOR (codprof, nome, cpf, rg, codcurso*, nomecurso*, 

area*, duracao*, dtinicio*, valor*) 


Quando devemos realizar ... 

• Adição de Colunas: 

• Em relacionamentos com cardinalidade de 1:1 ou 1:N. 

• Tabela Própria: 

• Em relacionamentos com cardinalidade de N:N. 

• Em relacionamentos com muitos atributos e cardinalidade de 

1:N, opcional do lado 1 (caso especial). 

• Fusão de Tabelas: 

• Em relacionamentos com cardinalidade de 1:1, obrigatório em 

pelo menos um dos lados. 


Relacionamento (0,1) : (0,1) 

• Adição de Colunas 

1. Cardinalidades iguais 

dois lados do 

relacionamento → a 

FK e os atributos do 


poderão migrar para 

qualquer uma das 

duas tabelas. Vai 

depender do contexto. 

2. A cardinalidade 

mínima igual a 0 do 

lado que cede a FK 

indica que a FK e os 

atributos do 


poderão ser nulos em 

algumas ocorrências. 



Adição de Colunas - Descrição Textual 

Considerando que a 

cardinalidade máxima 

do relacionamento é de 

1:1, o valor da FK nunca 

poderá se repetir. 


CURSO (codcurso, nome, area, duracao, dtinicio*, valor*, codprof*) 





1. Para evitar FK e 

atributos nulos, a FK e 

os atributos do 


deverão migrar para a 

tabela do lado 

opcional do 






atributos do 

relacionamento nunca 

poderão ser nulos. 










CURSO (codcurso, nome, area, duracao, dtinicio, valor, codprof) 

[codprof] referencia PROFESSOR 



• Fusão de Tabelas 

Apesar desta opção ter 

uma junção a menos do 

que na adição de 

colunas, existirão vários 

valores nulos na tabela 

resultante. 

1. Todos os atributos deverão migrar para a tabela que 

estiver do lado do relacionamento com cardinalidade 

mínima igual a 1. 

2. A outra tabela e o relacionamento deixam de existir. 



Fusão de tabelas - Descrição Textual 

Os valores dos atributos 

da tabela que deixou de 

existir poderão ser nulos 

em algumas linhas da 

tabela resultante. 

PROFESSOR (codprof, nome, cpf, rg, codcurso*, nomecurso* 

area*, duracao*, dtinicio*, valor*, codprof*) 


Relacionamento (0,1) : (0,n) 


1. A FK e os atributos do 



tabela que estiver do 

lado N do 






atributos do 










1:N, o valor da FK 



DISCIPLINA (coddisc, nome, semestre, creditos, periodo*, codprof*) 









lado N do 






atributos do 


poderão ser nulos 










DISCIPLINA (coddisc, nome, semestre, creditos, periodo, codprof) 



Relacionamento (0,n) : (1,n) 

• Tabela Própria 

Inversão das cardinalidades 

1. Será criada uma tabela 

para o relacionamento. 

2. Esta tabela recebe as 

duas FKs das tabelas 

relacionadas, que 

formarão a sua PK. 

3. Nunca irão existir FKs 

nulas na tabela 

própria. 


Relacionamento (0,n) : (1,n) 

Tabela Própria - Descrição Textual 

PEDIDO (codped, data, frete) 

PRODUTO (codprod, nome, quantest, venda) 

CONTEM (codped, codprod, quant, preco) 

[codped] referencia PEDIDO 

[codprod] refereecia PRODUTO 



• Tabela Própria (caso especial) 

1. Devido à existência de 

muitos atributos no 

relacionamento pode 

ser escolhida a opção de 

tabela própria, para 

evitar valores nulos na 

tabela que recebe a FK. 

2. A PK da tabela própria 

será a FK oriunda da 


lado N do 


3. O período faz parte da 

PK para possibilitar que 

a mesma disciplina 

possa ser ensinada em 

períodos diferentes. 





DISCIPLINA (coddisc, nome, semestre, creditos) 

Por gerar uma 

junção a mais do 

que na adição de 

colunas, esta 

opção só deverá 

ser utilizado se o 


contiver muitos 

atributos. 

ENSINA (coddisc, periodo, valor, datainicio, datafim, codprof) 



Auto-Relacionamento (0,1) : (0,1) 




deverão ser inseridos 

na própria tabela. 





atributos do 












PESSOA (codpessoa, nome, cpf, rg, data*, codrepresenta*) 

[codrepresenta*] referencia PESSOA 












atributos do 











PESSOA (codpessoa, nome, cpf, rg, data, codrepresenta) 

[codrepresenta] referencia PESSOA 


Auto-Relacionamento (0,1) : (0,n) 










atributos do 












FUNCIONARIO (codfunc, nome, cpf, rg, data*, gratif*, codchefe*) 

[codchefe*] referencia FUNCIONARIO 












atributos do 











FUNCIONARIO (codfunc, nome, cpf, rg, data, gratif, codchefe) 

[codchefe] referencia FUNCIONARIO 


Auto-Relacionamento (0,n) : (0,n) 

• Tabela Própria: 




duas FKs da mesma 

tabela, que formarão a 

sua PK. 



própria. 


Auto-Relacionamento (0,n) : (0,n) 


A tabela própria 

recebe as duas FKs da 

mesma tabela, que 

poderão se repetir 

individualmente. 

DISCIPLINA (coddisc, nome, semestre, creditos) 

PREREQUISITO (coddisc, codprereq) 

[coddisc] referencia DISCIPLINA 

[codprereq] referencia DISCIPLINA 


Relacionamento Identificador 


1. A FK deverá migrar 

para a tabela que 

estiver do lado N do 


2. A PK da tabela do lado 

N do relacionamento 

será formada pela FK 

concatenada com o 

identificador desta 

tabela. 




indica que a FK nunca 

poderá ser nula. 


Relacionamento Identificador 







SOCIO (codsocio, nome, cpf, rg) 

DEPENDENTE (codsocio, numero, nome, parentesco, celular) 

[codsocio] referencia SOCIO 


Atributo Multivalorado 


1. Retirar os atributos 

multivalorados da 

tabela. 

2. Transformar os 

atributos 

multivalorados em 

uma nova tabela e 

estabelecer um 


identificador com a 

tabela do origem. 




indica que a FK nunca 

poderá ser nula. 


Atributo Multivalorado 







CLIENTE (codcliente, nome, cpf, rg) 

FONE (codcliente, fone, tipo) 

[codcliente] referencia CLIENTE 


Relacionamento Ternário 





três FKs das tabelas 

relacionadas, todas 

não nulas. 

3. A PK da tabela criada 

será formada pela 

concatenação das FKs 

oriundas de cada lado 

N do relacionamento. 

Neste caso, as três FKs 

formarão a PK. 



própria. 






• Descrição Textual 

ENGENHEIRO (codeng, nome, cpf, rg) 

PROJETO (codproj, nome, categoria, valor) 

FUNÇÃO (codfuncao, nome) 

PARTICIPA (codeng, codproj, codfuncao, dtinicio, dtfim) 

[codeng] referencia ENGENHEIRO 

[codproj] referecia PROJETO 

[codfuncao] referencia FUNCAO 







três FKs das tabelas 

relacionadas, todas 

não nulas. 

3. A PK da tabela criada 

será formada pela 

concatenação das FKs 

oriundas de cada lado 

N do relacionamento. 

Neste caso, apenas 

duas das FKs formarão 

a PK. 



própria. 







ENGENHEIRO (codeng, nome, cpf, rg) 

PROJETO (codproj, nome, categoria, valor) 

FUNÇÃO (codfuncao, nome) 

PARTICIPA (codeng, codproj, codfuncao, dtinicio, dtfim) 

[codeng] referencia ENGENHEIRO 

[codproj] referecia PROJETO 

[codfuncao] referencia FUNCAO 


Agregação 



para a entidade 

associativa. 


duas FK das tabelas 

relacionadas formando 

a sua PK, que pode ser 

concatenada com 

atributos do 



nulas na nova tabela 

criada. 

4. Deverá ser feito o 

relacionamento entre a 

nova tabela criada e a 

terceira entidade. 


Agregação 


1. A PK de CONSULTA será 

formada pelas duas FKs 

concatenadas com os 

atributos data e hora, 

para permitir que um 

médico possa consultar 

o mesmo paciente mais 

de uma vez no mesmo 

dia, porém em horários 

diferentes. 

2. É mais conveniente criar 

uma PK artificial para a 

tabela CONSULTA e 

transformar a sua PK 

natural em uma chave 

candidata. 


Agregação 


MEDICO (codmedico, nome, crm, celular) 

PACIENTE (codpaciente, nome, cpf, rg) 

CONSULTA (codmedico, codpaciente, data, hora) 

[codmedico] referencia MEDICO 

[codpaciente] referencia PACIENTE 

MEDICAMENTO (codmedic, nome, laboratorio, tipo) 

PRESCREVE (codmedico, codpaciente, data, hora, codmedic) 

[codmedico, codpaciente, data, hora] referencia 

CONSULTA 

[codmedic] referencia MEDICAMENTO 


Agregação 

• Esquema Relacional Modificado 

1. É criado o atributo 

codconsulta para ser a 

PK da tabela CONSULTA. 

2. Os quatro atributos 

que formavam a PK da 

tabela CONSULTA 

passam a formar uma 

chave candidata. 


Agregação 


MEDICO (codmedico, nome, crm, celular) 

PACIENTE (codpaciente, nome, cpf, rg) 

CONSULTA (codconsulta, codmedico, codpaciente, data, hora) 

[codmedico] referencia MEDICO 

[codpaciente] referencia PACIENTE 

MEDICAMENTO (codmedic, nome, laboratorio, tipo) 

PRESCREVE (codconsulta, codmedic) 

[codconsulta] referencia CONSULTA 

[codmedic] referencia MEDICAMENTO 


Especialização/Generalização 

• Uma tabela para cada entidade 


para cada entidade. 

2. Estabelecer um 

relacionamento de 1:1 

entre a tabela genérica 

e cada uma das tabelas 

especializadas. 

3. Esses relacionamentos 

serão obrigatórios do 

lado da tabela genérica 

e opcionais do lado das 

tabelas especializadas. 

4. A PK da tabela genérica 

será FK e também PK 

em cada uma das 

tabelas especializadas. 



• Esquema Relacional – Uma tabela para cada entidade 



• Descrição Textual – Uma tabela para cada entidade 

CLIENTE (codcliente, nome, rua, numero, bairro, cep) 

FISICA (codcliente, rg, cpf, dtnasc) 


JURIDICA (codcliente, inscest, cnpj, nomefantasia) ) 




• Uma tabela apenas para a entidade genérica 


apenas para a entidade 

genérica. 

2. Todos os atributos das 

entidades especializadas 


entidade genérica, 

podendo ser nulos. 

3. As entidades 

especializadas deixam 

de existir. 

4. Deverá ser criado um 

atributo para diferenciar 

cada linha da tabela 

resultante. 



• Esquema Relacional – Uma tabela para a entidade genérica 

Descrição Textual 

CLIENTE (codcliente, nome, rua, numero, 

bairro, cep*, rg*, cpf*, dtnasc*, 

sexo*, cnpj*, inscest*, 

razaosocial*, ramo*, tipo) 

Deverá ser criado um novo atributo 

não nulo para categorizar cada 

linha da tabela resultante. 



• Tabelas apenas para as entidades especializadas 

1. Serão criadas tabelas 

apenas para as 

entidades especializadas 

2. Todos os atributos da 

entidade genérica 

deverão migrar para 

cada tabela 

especializada, não 

podendo ser nulos. 

3. A entidade genérica 

deixa de existir. 



• Esquema Relacional - Tabelas para as entidades especializadas 

Descrição Textual 

FISICA (codcliente, nome, rua, 

numero, bairro, cep*, 

rg, cpf, dtnasc, sexo) 

JURIDICA (codcliente, nome, rua, numero, bairro, 

cep*, cnpj, inscest, razaosocial, ramo) 


Copyright © 2019 Nilton Freire Santos. 

Todos os direitos reservados. 

O Modelo Conceitual 26/10/2019 10

BD1 - O Modelo Lógico

Create successful ePaper yourself

Delete template?

Save as template?