BD1 - O Modelo Lógico
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Banco de Dados<br />
O <strong>Modelo</strong> <strong>Lógico</strong><br />
O <strong>Modelo</strong> <strong>Lógico</strong><br />
26/10/2019 1
<strong>Modelo</strong> <strong>Lógico</strong><br />
• Deriva de um modelo conceitual já construído e depende da<br />
abordagem de banco de dados que será utilizada.<br />
<strong>Modelo</strong> Conceitual<br />
Representação abstrata<br />
da realidade observada<br />
<strong>Modelo</strong> <strong>Lógico</strong><br />
Representação sob a<br />
forma de tabelas<br />
<strong>Modelo</strong> Físico<br />
Representação de acordo<br />
com o SGBD utilizado<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 2
<strong>Modelo</strong> Relacional<br />
• Foi criado com base na teoria dos conjuntos, na qual:<br />
• os dados são representados como tabelas (relações);<br />
• através de linhas (tuplas);<br />
• e colunas (atributos);<br />
• com os possíveis valores (domínio) definidos;<br />
• as operações sobre os dados são feitas por uma linguagem<br />
não procedural.<br />
• Foi criado na década de 70 por Edgard F. Codd.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 3
<strong>Modelo</strong> Relacional<br />
• Permite a especificação do esquema do banco de dados, através<br />
do Diagrama Relacional.<br />
CLIENTE<br />
PEDIDO<br />
ITENS<br />
PRODUTO<br />
CIDADE<br />
FUNCIONÁRIO<br />
FUNÇÃO<br />
TIPO<br />
PAÍS<br />
SETOR<br />
Esquema <strong>Lógico</strong><br />
=<br />
Diagrama Relacional<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 4
Terminologias<br />
nome do campo<br />
nome do atributo<br />
coluna, atributo, campo<br />
tabela<br />
relação<br />
Código<br />
001<br />
002<br />
003<br />
Nome<br />
José<br />
Antonio<br />
Ana<br />
Fone Estado<br />
3212.1234 PE<br />
3244.1212<br />
PB<br />
3237.4859 RN<br />
linha, tupla, registro<br />
valor do campo<br />
valor do atributo<br />
domínio<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 5
Terminologias<br />
• Coluna, Atributo, Campo<br />
• Dado que se deseja armazenar sobre um objeto. Deve possuir<br />
um nome, um tipo de acordo com a natureza do dado e um<br />
tamanho específico.<br />
• Linha, Tupla, Registro<br />
• Conjunto de campos que representa uma ocorrência<br />
específica de um objeto. Deve ser identificado de forma única<br />
dentro da tabela.<br />
• Tabela, Relação<br />
• Conjunto de tuplas que contém os dados sobre um objeto<br />
específico. Deve possuir um nome único dentro do banco de<br />
dados.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 6
Terminologias<br />
• Domínio<br />
• Conjunto de valores distintos que podem ser definidos a um<br />
atributo.<br />
• Domínio Discreto<br />
• Conjunto de valores distintos, definidos previamente.<br />
• Domínio Contínuo<br />
• Conjunto de valores permitidos dentro de um intervalo.<br />
• Domínio Aberto<br />
• Conjunto de valores permitidos, sem restrições.<br />
• Domínio Nulo (inaplicável ou desconhecido)<br />
• É um valor nulo, diferente de zero ou espaço em branco.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 7
<strong>Modelo</strong> Relacional<br />
• É baseado no conhecimento dos dados presentes em um modelo<br />
conceitual já definido.<br />
1 N N N N 1<br />
CLIENTE FAZ PEDIDO<br />
CONTÉM PRODUTO POSSUI TIPO<br />
N<br />
N<br />
RESIDE<br />
ATENDIDO<br />
1 1 N 1<br />
RESIDE<br />
N 1<br />
CIDADE<br />
FUNCIONÁRIO POSSUI<br />
FUNÇÃO<br />
1 N<br />
N<br />
NASCEU<br />
N<br />
1<br />
PERTENCE<br />
TRABALHA<br />
DIRIGE<br />
1<br />
1<br />
1<br />
PAÍS<br />
1 N<br />
SETOR<br />
CHEFIA<br />
CLIENTE<br />
código<br />
nome<br />
tipo<br />
contato<br />
cargo<br />
endereço<br />
cidade (FK)<br />
cep<br />
fone<br />
fax<br />
obs<br />
CIDADE<br />
PAÍS<br />
código<br />
nome<br />
uf<br />
sigla (FK)<br />
sigla<br />
nome<br />
PEDIDO<br />
código<br />
cliente (FK)<br />
vendedor (FK)<br />
datapedid<br />
datafatura<br />
via<br />
frete<br />
FUNCIONÁRIO<br />
código<br />
nome<br />
sexo<br />
estcivil<br />
rg<br />
cpf<br />
trat<br />
datanasc<br />
natural (FK)<br />
dataadm<br />
endereço<br />
complement<br />
bairro<br />
cidade (FK)<br />
cep<br />
fone<br />
celular<br />
função (FK)<br />
setor (FK)<br />
salário<br />
email<br />
obs<br />
ITENS<br />
pedido (FK)<br />
produto (FK)<br />
preço<br />
quant<br />
desconto<br />
FUNÇÃO<br />
código<br />
nome<br />
gratific<br />
SETOR<br />
sigla<br />
nome<br />
ramal<br />
superior (FK)<br />
chefe (FK)<br />
PRODUTO<br />
TIPO<br />
código<br />
nome<br />
descrição<br />
apresent<br />
venda<br />
custo<br />
quantest<br />
estmin<br />
tipo (FK)<br />
situação<br />
código<br />
nome<br />
descrição<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 8
Características Básicas<br />
• Aspecto estrutural: os dados são organizados e percebidos pelos<br />
usuários como tabelas relacionadas.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 9
Características Básicas<br />
• Aspecto de integridade: as tabelas devem satisfazer às restrições<br />
de integridade impostas ao modelo.<br />
INTEGRIDADE<br />
DE DOMÍNIO<br />
INTEGRIDADE<br />
DE UNICIDADE<br />
INTEGRIDADE<br />
DE VAZIO<br />
INTEGRIDADE<br />
REFERENCIAL<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 10
Características Básicas<br />
• Integridade de domínio:<br />
• Especifica que um valor associado a um atributo deve<br />
pertencer ao domínio do atributo.<br />
• Integridade de unicidade:<br />
• Especifica que as linhas de uma tabela devem ser únicas (não<br />
pode haver repetição de linhas).<br />
• Integridade de vazio:<br />
• Especifica quais os atributos que podem ser nulos.<br />
• Integridade referencial:<br />
• Especifica que os relacionamentos devem manter integridade<br />
entre as tabelas relacionadas.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 11
Características Básicas<br />
• Aspecto manipulativo: os dados são manipulados, para efeito de<br />
consultas, por operadores que geram tabelas a partir de outras<br />
tabelas.<br />
• Utiliza operadores de:<br />
• Seleção: extrai linhas específicas de uma tabela.<br />
• Projeção: extrai colunas específicas de uma tabela.<br />
• Junção: une duas tabelas com base em valores comuns<br />
existentes em uma coluna comum.<br />
• União: une duas tabelas com a mesma estrutura.<br />
• Etc ...<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 12
Chave Primária<br />
• Atributo ou conjunto de atributos que identifica cada linha em<br />
uma tabela de forma única.<br />
• Exemplo:<br />
• Tabela: CLIENTE<br />
• Chave primária: codcliente<br />
cpf<br />
endereco<br />
CLIENTE<br />
codcliente<br />
nome<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 13
Chave Primária<br />
• Uma chave primária também pode ser formada pela junção de<br />
dois ou mais atributos.<br />
• Exemplo:<br />
• Tabela: ITENS DE PEDIDO<br />
• Chave primária: codpedido + codproduto<br />
preço quantidade<br />
ITENS<br />
codpedido<br />
codproduto<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 14
Chave Primária<br />
• A chave primária de uma tabela corresponde ao atributo<br />
identificador de uma entidade.<br />
• Cada tabela deverá possuir uma única chave primária, que não<br />
admite valores repetidos ou nulos.<br />
• A chave primária pode ser utilizada como referência em um<br />
relacionamento.<br />
• Uma chave primária concatenada deve ser mínima, ou seja,<br />
todos os seus atributos são necessários para garantir a unicidade<br />
de valores da chave.<br />
• A criação de uma chave primária faz com que a tabela seja<br />
ordenada por essa chave.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 15
Chave Candidata<br />
• Atributo ou conjunto de atributos que identifica unicamente<br />
cada linha em uma tabela, de forma alternativa.<br />
• Exemplo:<br />
• Tabela: CLIENTE<br />
• Chave candidata: cpf<br />
cpf<br />
endereco<br />
CLIENTE<br />
codcliente<br />
nome<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 16
Chave Candidata<br />
• Uma tabela pode possuir mais de uma chave candidata.<br />
• A chave candidata é também chamada de chave alternativa.<br />
• A chave candidata não admite repetição de valores.<br />
• Uma chave candidata pode ser concatenada.<br />
• Uma chave candidata concatenada deverá ser mínima, ou seja,<br />
todos os seus atributos são necessários para garantir a unicidade<br />
de valores da chave.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 17
Chave Estrangeira<br />
• Atributo ou conjunto de atributos que estabelece um<br />
relacionamento entre duas tabelas.<br />
• Exemplo:<br />
• Tabelas: CLIENTE e PEDIDO<br />
• Chave estrangeira: codcliente<br />
cpf<br />
endereco<br />
frete<br />
codcliente<br />
CLIENTE<br />
(1,1) (0,n)<br />
FAZ<br />
PEDIDO<br />
codcliente<br />
nome<br />
codpedido<br />
data<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 18
Chave Estrangeira<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 19
Chave Estrangeira<br />
• Uma tabela pode possuir várias chaves estrangeiras, uma para<br />
cada relacionamento.<br />
• Uma chave estrangeira faz referência à chave primária de uma<br />
tabela.<br />
• Dependendo da cardinalidade máxima do relacionamento, uma<br />
chave estrangeira pode ter valores repetidos.<br />
• Dependendo da cardinalidade mínima do relacionamento, uma<br />
chave estrangeira pode ter valores nulos.<br />
• As colunas pertencentes a uma chave estrangeira deverão ter o<br />
mesmo domínio das colunas referenciadas.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 20
Chave Estrangeira<br />
• O valor de uma chave estrangeira pode ser:<br />
• Igual ao(s) valor(es) da(s) coluna(s) referenciada(s):<br />
✓ Neste caso linha da tabela participa do relacionamento.<br />
• Nulo:<br />
✓ Neste caso a linha da tabela não participa do<br />
relacionamento.<br />
FUNCIONÁRIO<br />
código<br />
1001<br />
1002<br />
nome<br />
José Paulo<br />
Ana Maria<br />
fone<br />
3222.2222<br />
3445.1231<br />
função<br />
F3<br />
nulo<br />
Existe função<br />
Não existe função<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 21
Chave Estrangeira<br />
• Em um auto-relacionamento de cardinalidade 1:1 ou 1:N, a chave<br />
estrangeira faz parte da própria tabela.<br />
codfun nome fone funcao chefe<br />
1001 José Paulo 93022222 F3 nulo<br />
1002 Ana Maria 91341234 nulo 1001<br />
1003 Marcos Pilo 88693785 F2 1001<br />
1004 Bruno Matias 82303787 F1 1003<br />
1005 Márcia Souto 88369002 F3 1003<br />
1006 Sandra Carla 91236547 F2 1003<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 22
Restrições de Integridade<br />
• Integridade semântica<br />
• definida pelas regras de negócio do sistema. O usuário<br />
necessita implementá-las explicitamente.<br />
• Integridade de domínio<br />
• Especifica que todo valor associado a um atributo deve ser<br />
atômico e pertencer ao domínio do atributo.<br />
• Integridade de unicidade<br />
• especifica que os valores das chaves primárias e candidatas<br />
devem ser únicos (sem repetição).<br />
• Integridade de vazio<br />
• especifica quais os atributos de uma tabela que podem<br />
receber valores nulos.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 23
Integridade Semântica<br />
• Garante que o estado dos dados está sempre de acordo com as<br />
regras do negócio.<br />
• É implementada pelas restrições de checagem de dados, pela<br />
obrigatoriedade e unicidade do dado e pelos triggers.<br />
• Exemplos de restrições semânticas:<br />
• um funcionário não pode ter o salário superior ao salário do<br />
seu chefe imediato.<br />
• a quantidade de um produto em um pedido não pode ser<br />
superior à quantidade em estoque desse produto.<br />
• um funcionário do setor de vendas não pode ter a função de<br />
engenheiro.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 24
Integridade Semântica<br />
• Exemplos de falta de integridade semântica:<br />
• violação de domínio:<br />
• funcionário com 200 anos de idade.<br />
• data de nascimento no próximo ano.<br />
• atributos significativos sem valor:<br />
• nome do funcionário nulo.<br />
• quantidade pedida de um produto nula.<br />
• relacionamentos incorretos ou inexistentes:<br />
• um pedido para vários clientes.<br />
• um pedido sem produtos.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 25
Integridade Referencial<br />
• Especifica que os valores de uma chave estrangeira devem estar<br />
presentes na chave primária da tabela referenciada.<br />
• É implementada pela definição de cada uma das ações de<br />
atualização de dados em cada relacionamento.<br />
• Inclusão de dados<br />
• Restrita<br />
• Exclusão de dados:<br />
• Restrita e Cascata<br />
• Alteração de dados:<br />
• Restrita e Cascata<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 26
IR - Inclusão Restrita<br />
• Inclusão de dados – restrita<br />
• Impede que seja inserido na chave estrangeira da tabela filho,<br />
um valor que não exista previamente na coluna referenciada<br />
da tabela pai.<br />
• Exemplo:<br />
• Em um relacionamento entre CLIENTE e PEDIDO, só é<br />
possível inserir um cliente e um vendedor na tabela<br />
PEDIDO, se esse cliente já existir previamente cadastrado<br />
na tabela CLIENTE e o vendedor na tabela de<br />
FUNCIONÁRIO.<br />
• Não pode ser inserido o cliente C5 ou o funcionário F5 na<br />
tabela PEDIDO.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 27
IR - Inclusão Restrita<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 28
IR - Exclusão Restrita<br />
• Exclusão de dados – restrita<br />
• Impede que um registro seja excluído da tabela pai, se existir<br />
algum registro relacionado a ele na tabela filho.<br />
• Exemplo:<br />
• Em um relacionamento entre CLIENTE e PEDIDO, não é<br />
possível a exclusão de um cliente se existirem pedidos<br />
feitos por ele.<br />
• A cliente Paula não pode ser excluída da tabela CLIENTE.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 29
IR - Exclusão Restrita<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 30
IR - Exclusão Cascata<br />
• Exclusão de dados – cascata<br />
• Quando um registro da tabela pai é excluído, todos os<br />
registros relacionados a ele, existentes na tabela filho,<br />
também são excluídos.<br />
• Exemplo:<br />
• Em um relacionamento entre CLIENTE e PEDIDO, ao se<br />
excluir um cliente todos os pedidos feitos por ele também<br />
são excluídos.<br />
• Quando a cliente Paula é excluída, todos os pedidos feitos<br />
por ela também serão.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 31
IR - Exclusão Cascata<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 32
IR - Alteração Restrita<br />
• Alteração de dados na tabela pai – restrita<br />
• Impede que um valor de chave primária seja alterado na<br />
tabela pai, se existir algum registro relacionado na tabela<br />
filho.<br />
• Exemplo:<br />
• Em um relacionamento entre CLIENTE e PEDIDO, não é<br />
possível a alteração da chave primária de um cliente se<br />
existirem pedidos feitos por ele.<br />
• A chave primária da cliente Paula não poderá ser alterada<br />
porque ela já realizou pedido.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 33
IR - Alteração Restrita<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 34
IR - Alteração Restrita<br />
• Alteração de dados na tabela filho – restrita<br />
• Impede que um valor de chave estrangeira seja alterado na<br />
tabela filho, se não existir algum registro com o novo valor na<br />
coluna relacionada da tabela pai.<br />
• Exemplo:<br />
• Em um relacionamento entre CLIENTE e PEDIDO, não é<br />
possível a alteração do código do cliente na tabela de<br />
pedidos, se não existir esse código na tabela de clientes.<br />
• Qualquer código de cliente ou de vendedor que exista na<br />
tabela PEDIDO só poderá ser alterado para um valor que<br />
exista nas tabelas CLIENTE e FUNCIONÁRIO.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 35
IR - Alteração Restrita<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 36
IR - Alteração Cascata<br />
• Alteração de dados – cascata<br />
• Quando um registro da tabela pai é alterado, todos os<br />
registros relacionados a ele, existentes na tabela filho,<br />
também são alterados.<br />
• Exemplo:<br />
• Em um relacionamento entre CLIENTE e PEDIDO, ao se<br />
alterar um cliente todos os pedidos feitos por ele também<br />
são alterados.<br />
• Se alterar o código da cliente Paula para C8 na tabela<br />
CLIENTE, os valores da coluna cliente na tabela PEDIDO<br />
também serão alterados para esse valor.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 37
IR - Alteração Cascata<br />
Tabela PEDIDO<br />
codpedido data cliente vendedor<br />
P1 22/01/2013 C1 F1<br />
P2 25/01/2013 C8 C2 F2<br />
P3 28/01/2013 C3 F1<br />
P4 28/01/2013 C8 C2 F4<br />
Tabela CLIENTE<br />
codcli nome fone<br />
C1 Ana 99212647<br />
C8 C2 Paula 88417371<br />
C3 João 93024677<br />
C4 Manuel 87568920<br />
Tabela FUNCIONÁRIO<br />
codfun nome fone<br />
F1 Paula 99867643<br />
F2 Carla 89879092<br />
F3 Marcos 93028675<br />
F4 Pedro 88245620<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 38
Mapeamento E-R para Relacional<br />
• Pode ser realizado manualmente ou implementado através de<br />
ferramentas CASE.<br />
• Objetivos Básicos:<br />
• Obter bom desempenho;<br />
• Simplificar o desenvolvimento de aplicações.<br />
• Regras Gerais:<br />
• Evitar junções desnecessárias;<br />
• Diminuir o tamanho das chaves primárias;<br />
• Procurar evitar muitos campos opcionais.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 39
Notação Usada no MySQL Workbench<br />
Relacionamento 1:1<br />
Notação Peter Chen<br />
Relacionamento 1:1<br />
Notação Crow’s Foot<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 40
Notação Usada no MySQL Workbench<br />
Relacionamento 1:n<br />
Notação Peter Chen<br />
Relacionamento 1:n<br />
Notação Crow’s Foot<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 41
Mapeamento das Entidades e Atributos<br />
• Cada entidade torna-se uma tabela.<br />
• Pode ocorrer, em alguns casos, de algumas entidades se<br />
unirem para dar origem a uma única tabela (fusão de tabelas).<br />
• Cada atributo da entidade torna-se um campo da tabela criada,<br />
com um domínio definido.<br />
• O atributo identificador da entidade torna-se a chave primária<br />
da tabela.<br />
• Os atributos compostos e multivalorados deverão ser<br />
implementados.<br />
• Os atributos derivados deverão ser excluídos.<br />
• Os atributos referenciais deverão ser exibidos.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 42
Mapeamento das Entidades e Atributos<br />
Atributo composto<br />
Esquema E-R<br />
Atributo multivalorado<br />
Esquema Relacional<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 43
Mapeamento dos Relacionamentos<br />
• A transformação dos relacionamentos pode ser realizada de três<br />
formas distintas:<br />
• Fazendo adição de colunas em uma das tabelas que<br />
participam do relacionamento.<br />
• Criando uma tabela própria para o relacionamento.<br />
• Fazendo a fusão das tabelas que participam do<br />
relacionamento.<br />
• A alternativa a ser escolhida depende das cardinalidades máxima<br />
e mínima do relacionamento.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 44
Adição de Colunas<br />
• O relacionamento é implementado através da inserção em uma<br />
das tabelas, das seguintes colunas:<br />
• Coluna(s) correspondente(s) à chave primária da tabela<br />
relacionada (chave estrangeira).<br />
• Colunas correspondentes aos atributos do relacionamento (se<br />
existirem).<br />
• As chaves primárias das tabelas que participam do<br />
relacionamento permanecem inalteradas, exceto em casos de<br />
relacionamento identificador.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 45
Adição de Colunas<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 46
Adição de Colunas<br />
• Sempre que a entidade que cede a chave estrangeira estiver do<br />
lado do relacionamento que tem cardinalidade mínima igual a 0,<br />
a chave estrangeira poderá possuir valores nulos em algumas<br />
ocorrências.<br />
A (a1, a2, a3)<br />
B (b1, b2, b3, r1*, r2*, a1*)<br />
[a1*] referencia A<br />
atributos do<br />
relacionamento<br />
FK pode ser nula em<br />
algumas ocorrências<br />
Sempre que a FK for nula os<br />
atributos do relacionamento<br />
também serão.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 47
Adição de Colunas<br />
• Um professor ensina nenhuma ou várias disciplinas.<br />
• Cada disciplina tem um único professor e pode ser cadastrada<br />
sem haver professor para a mesma<br />
• Deve-se registrar a data em que o professor começou a ensinar a<br />
disciplina e o valor que ele recebe por esse trabalho.<br />
• Esquema E-R<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 48
Adição de Colunas<br />
• Esquema Relacional<br />
PROFESSOR (codprof, nome, cpf, rg)<br />
chaves primárias (PK)<br />
DISCIPLINA (coddisc, nome, creditos, periodo, valor*, dtinicio*, codprof*)<br />
[codprof*] referencia PROFESSOR<br />
chave estrangeira (FK)<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 49
Tabela Própria<br />
• É criada uma tabela para o relacionamento contendo:<br />
• Colunas correspondentes às chaves estrangeiras, oriundas das<br />
tabelas relacionadas.<br />
• Colunas correspondentes aos atributos do relacionamento (se<br />
existirem).<br />
• A chave primária desta tabela é formada:<br />
• Pelas duas chaves estrangeiras concatenadas;<br />
• A chave primária também pode ser concatenada com colunas<br />
do relacionamento (se existirem);<br />
• Se a cardinalidade do relacionamento for de 1:N (caso<br />
especial), a chave primária da tabela própria poderá ser<br />
formada por apenas uma das chaves estrangeiras.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 50
Tabela Própria<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 51
Tabela Própria<br />
• Considerando que apenas as ocorrências que efetivamente<br />
estarão se relacionando irão aparecer na tabela própria, não<br />
existem chaves estrangeiras nulas na tabela criada.<br />
Relacionamento obrigatório<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 52
Tabela Própria<br />
• Um pedido contém um ou vários produtos.<br />
• Um produto pode estar em nenhum ou em vários pedidos.<br />
• Deve-se registrar a quantidade pedida e o preço pelo qual cada<br />
produto foi vendido em cada pedido.<br />
• Esquema E-R<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 53
Tabela Própria<br />
• Esquema Relacional<br />
PEDIDO (codped, dataped, frete)<br />
PRODUTO (codprod, nome, quantest, venda)<br />
CONTEM (codped, codprod, quant, preco)<br />
[codped] referencia PEDIDO<br />
[codprod] referencia PRODUTO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 54
Fusão de Tabelas<br />
• O relacionamento é representado por uma única tabela,<br />
resultante da fusão das duas tabelas do relacionamento.<br />
• Todas as colunas de uma das tabelas são movidas para a outra<br />
tabela do relacionamento.<br />
• A chave primária da tabela que cedeu as colunas pode deixar de<br />
existir em alguns casos.<br />
• Todas as colunas correspondentes aos atributos do<br />
relacionamento (se existirem) também são movidas para a tabela<br />
resultante.<br />
• A chave primária da tabela final permanece inalterada.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 55
Fusão de Tabelas<br />
A (a1, a2, a3, b1*, b2*, b3*, r1*, r2*)<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 56
Fusão de Tabelas<br />
• Um professor pode coordenar apenas um curso.<br />
• Um curso tem apenas um coordenador.<br />
• Deve-se registrar a data em que o professor começou a<br />
coordenar o curso e o valor que ele recebe por esse trabalho.<br />
• Esquema E-R<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 57
Fusão de Tabelas<br />
• Esquema Relacional<br />
PROFESSOR (codprof, nome, cpf, rg, codcurso*, nomecurso*,<br />
area*, duracao*, dtinicio*, valor*)<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 58
Quando devemos realizar ...<br />
• Adição de Colunas:<br />
• Em relacionamentos com cardinalidade de 1:1 ou 1:N.<br />
• Tabela Própria:<br />
• Em relacionamentos com cardinalidade de N:N.<br />
• Em relacionamentos com muitos atributos e cardinalidade de<br />
1:N, opcional do lado 1 (caso especial).<br />
• Fusão de Tabelas:<br />
• Em relacionamentos com cardinalidade de 1:1, obrigatório em<br />
pelo menos um dos lados.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 59
Relacionamento (0,1) : (0,1)<br />
• Adição de Colunas<br />
1. Cardinalidades iguais<br />
dois lados do<br />
relacionamento → a<br />
FK e os atributos do<br />
relacionamento<br />
poderão migrar para<br />
qualquer uma das<br />
duas tabelas. Vai<br />
depender do contexto.<br />
2. A cardinalidade<br />
mínima igual a 0 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento<br />
poderão ser nulos em<br />
algumas ocorrências.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 60
Relacionamento (0,1) : (0,1)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:1, o valor da FK nunca<br />
poderá se repetir.<br />
PROFESSOR (codprof, nome, cpf, rg)<br />
CURSO (codcurso, nome, area, duracao, dtinicio*, valor*, codprof*)<br />
[codprof*] referencia PROFESSOR<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 61
Relacionamento (1,1) : (0,1)<br />
• Adição de Colunas<br />
1. Para evitar FK e<br />
atributos nulos, a FK e<br />
os atributos do<br />
relacionamento<br />
deverão migrar para a<br />
tabela do lado<br />
opcional do<br />
relacionamento.<br />
2. A cardinalidade<br />
mínima igual a 1 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento nunca<br />
poderão ser nulos.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 62
Relacionamento (1,1) : (0,1)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:1, o valor da FK nunca<br />
poderá se repetir.<br />
PROFESSOR (codprof, nome, cpf, rg)<br />
CURSO (codcurso, nome, area, duracao, dtinicio, valor, codprof)<br />
[codprof] referencia PROFESSOR<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 63
Relacionamento (1,1) : (0,1)<br />
• Fusão de Tabelas<br />
Apesar desta opção ter<br />
uma junção a menos do<br />
que na adição de<br />
colunas, existirão vários<br />
valores nulos na tabela<br />
resultante.<br />
1. Todos os atributos deverão migrar para a tabela que<br />
estiver do lado do relacionamento com cardinalidade<br />
mínima igual a 1.<br />
2. A outra tabela e o relacionamento deixam de existir.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 64
Relacionamento (1,1) : (0,1)<br />
Fusão de tabelas - Descrição Textual<br />
Os valores dos atributos<br />
da tabela que deixou de<br />
existir poderão ser nulos<br />
em algumas linhas da<br />
tabela resultante.<br />
PROFESSOR (codprof, nome, cpf, rg, codcurso*, nomecurso*<br />
area*, duracao*, dtinicio*, valor*, codprof*)<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 65
Relacionamento (0,1) : (0,n)<br />
• Adição de Colunas<br />
1. A FK e os atributos do<br />
relacionamento<br />
deverão migrar para a<br />
tabela que estiver do<br />
lado N do<br />
relacionamento.<br />
2. A cardinalidade<br />
mínima igual a 0 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento<br />
poderão ser nulos em<br />
algumas ocorrências.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 66
Relacionamento (0,1) : (0,n)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:N, o valor da FK<br />
poderá se repetir.<br />
PROFESSOR (codprof, nome, cpf, rg)<br />
DISCIPLINA (coddisc, nome, semestre, creditos, periodo*, codprof*)<br />
[codprof*] referencia PROFESSOR<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 67
Relacionamento (1,1) : (0,n)<br />
• Adição de Colunas<br />
1. A FK e os atributos do<br />
relacionamento<br />
deverão migrar para a<br />
tabela que estiver do<br />
lado N do<br />
relacionamento.<br />
2. A cardinalidade<br />
mínima igual a 1 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento nunca<br />
poderão ser nulos<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 68
Relacionamento (1,1) : (0,n)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:N, o valor da FK<br />
poderá se repetir.<br />
PROFESSOR (codprof, nome, cpf, rg)<br />
DISCIPLINA (coddisc, nome, semestre, creditos, periodo, codprof)<br />
[codprof] referencia PROFESSOR<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 69
Relacionamento (0,n) : (1,n)<br />
• Tabela Própria<br />
Inversão das cardinalidades<br />
1. Será criada uma tabela<br />
para o relacionamento.<br />
2. Esta tabela recebe as<br />
duas FKs das tabelas<br />
relacionadas, que<br />
formarão a sua PK.<br />
3. Nunca irão existir FKs<br />
nulas na tabela<br />
própria.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 70
Relacionamento (0,n) : (1,n)<br />
Tabela Própria - Descrição Textual<br />
PEDIDO (codped, data, frete)<br />
PRODUTO (codprod, nome, quantest, venda)<br />
CONTEM (codped, codprod, quant, preco)<br />
[codped] referencia PEDIDO<br />
[codprod] refereecia PRODUTO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 71
Relacionamento (0,1) : (0,n)<br />
• Tabela Própria (caso especial)<br />
1. Devido à existência de<br />
muitos atributos no<br />
relacionamento pode<br />
ser escolhida a opção de<br />
tabela própria, para<br />
evitar valores nulos na<br />
tabela que recebe a FK.<br />
2. A PK da tabela própria<br />
será a FK oriunda da<br />
tabela que estiver do<br />
lado N do<br />
relacionamento.<br />
3. O período faz parte da<br />
PK para possibilitar que<br />
a mesma disciplina<br />
possa ser ensinada em<br />
períodos diferentes.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 72
Relacionamento (0,1) : (0,n)<br />
Tabela Própria - Descrição Textual<br />
PROFESSOR (codprof, nome, cpf, rg)<br />
DISCIPLINA (coddisc, nome, semestre, creditos)<br />
Por gerar uma<br />
junção a mais do<br />
que na adição de<br />
colunas, esta<br />
opção só deverá<br />
ser utilizado se o<br />
relacionamento<br />
contiver muitos<br />
atributos.<br />
ENSINA (coddisc, periodo, valor, datainicio, datafim, codprof)<br />
[codprof] referencia PROFESSOR<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 73
Auto-Relacionamento (0,1) : (0,1)<br />
• Adição de Colunas<br />
1. A FK e os atributos do<br />
relacionamento<br />
deverão ser inseridos<br />
na própria tabela.<br />
2. A cardinalidade<br />
mínima igual a 0 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento<br />
poderão ser nulos em<br />
algumas ocorrências.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 74
Auto-Relacionamento (0,1) : (0,1)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:1, o valor da FK nunca<br />
poderá se repetir.<br />
PESSOA (codpessoa, nome, cpf, rg, data*, codrepresenta*)<br />
[codrepresenta*] referencia PESSOA<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 75
Auto-Relacionamento (1,1) : (0,1)<br />
• Adição de Colunas<br />
1. A FK e os atributos do<br />
relacionamento<br />
deverão ser inseridos<br />
na própria tabela.<br />
2. A cardinalidade<br />
mínima igual a 1 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento nunca<br />
poderão ser nulos.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 76
Auto-Relacionamento (1,1) : (0,1)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:1, o valor da FK nunca<br />
poderá se repetir.<br />
PESSOA (codpessoa, nome, cpf, rg, data, codrepresenta)<br />
[codrepresenta] referencia PESSOA<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 77
Auto-Relacionamento (0,1) : (0,n)<br />
• Adição de Colunas<br />
1. A FK e os atributos do<br />
relacionamento<br />
deverão ser inseridos<br />
na própria tabela.<br />
2. A cardinalidade<br />
mínima igual a 0 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento<br />
poderão ser nulos em<br />
algumas ocorrências.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 78
Auto-Relacionamento (0,1) : (0,n)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:N, o valor da FK<br />
poderá se repetir.<br />
FUNCIONARIO (codfunc, nome, cpf, rg, data*, gratif*, codchefe*)<br />
[codchefe*] referencia FUNCIONARIO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 79
Auto-Relacionamento (1,1) : (0,n)<br />
• Adição de Colunas<br />
1. A FK e os atributos do<br />
relacionamento<br />
deverão ser inseridos<br />
na própria tabela.<br />
2. A cardinalidade<br />
mínima igual a 1 do<br />
lado que cede a FK<br />
indica que a FK e os<br />
atributos do<br />
relacionamento nunca<br />
poderão ser nulos.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 80
Auto-Relacionamento (1,1) : (0,n)<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:N, o valor da FK<br />
poderá se repetir.<br />
FUNCIONARIO (codfunc, nome, cpf, rg, data, gratif, codchefe)<br />
[codchefe] referencia FUNCIONARIO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 81
Auto-Relacionamento (0,n) : (0,n)<br />
• Tabela Própria:<br />
1. Será criada uma tabela<br />
para o relacionamento.<br />
2. Esta tabela recebe as<br />
duas FKs da mesma<br />
tabela, que formarão a<br />
sua PK.<br />
3. Nunca irão existir FKs<br />
nulas na tabela<br />
própria.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 82
Auto-Relacionamento (0,n) : (0,n)<br />
Tabela Própria - Descrição Textual<br />
A tabela própria<br />
recebe as duas FKs da<br />
mesma tabela, que<br />
poderão se repetir<br />
individualmente.<br />
DISCIPLINA (coddisc, nome, semestre, creditos)<br />
PREREQUISITO (coddisc, codprereq)<br />
[coddisc] referencia DISCIPLINA<br />
[codprereq] referencia DISCIPLINA<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 83
Relacionamento Identificador<br />
• Adição de Colunas<br />
1. A FK deverá migrar<br />
para a tabela que<br />
estiver do lado N do<br />
relacionamento.<br />
2. A PK da tabela do lado<br />
N do relacionamento<br />
será formada pela FK<br />
concatenada com o<br />
identificador desta<br />
tabela.<br />
3. A cardinalidade<br />
mínima igual a 1 do<br />
lado que cede a FK<br />
indica que a FK nunca<br />
poderá ser nula.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 84
Relacionamento Identificador<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:N, o valor da FK<br />
poderá se repetir.<br />
SOCIO (codsocio, nome, cpf, rg)<br />
DEPENDENTE (codsocio, numero, nome, parentesco, celular)<br />
[codsocio] referencia SOCIO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 85
Atributo Multivalorado<br />
• Adição de Colunas<br />
1. Retirar os atributos<br />
multivalorados da<br />
tabela.<br />
2. Transformar os<br />
atributos<br />
multivalorados em<br />
uma nova tabela e<br />
estabelecer um<br />
relacionamento<br />
identificador com a<br />
tabela do origem.<br />
3. A cardinalidade<br />
mínima igual a 1 do<br />
lado que cede a FK<br />
indica que a FK nunca<br />
poderá ser nula.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 86
Atributo Multivalorado<br />
Adição de Colunas - Descrição Textual<br />
Considerando que a<br />
cardinalidade máxima<br />
do relacionamento é de<br />
1:N, o valor da FK<br />
poderá se repetir.<br />
CLIENTE (codcliente, nome, cpf, rg)<br />
FONE (codcliente, fone, tipo)<br />
[codcliente] referencia CLIENTE<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 87
Relacionamento Ternário<br />
• Tabela Própria<br />
1. Será criada uma tabela<br />
para o relacionamento.<br />
2. Esta tabela recebe as<br />
três FKs das tabelas<br />
relacionadas, todas<br />
não nulas.<br />
3. A PK da tabela criada<br />
será formada pela<br />
concatenação das FKs<br />
oriundas de cada lado<br />
N do relacionamento.<br />
Neste caso, as três FKs<br />
formarão a PK.<br />
4. Nunca irão existir FKs<br />
nulas na tabela<br />
própria.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 88
Relacionamento Ternário<br />
• Esquema Relacional<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 89
Relacionamento Ternário<br />
• Descrição Textual<br />
ENGENHEIRO (codeng, nome, cpf, rg)<br />
PROJETO (codproj, nome, categoria, valor)<br />
FUNÇÃO (codfuncao, nome)<br />
PARTICIPA (codeng, codproj, codfuncao, dtinicio, dtfim)<br />
[codeng] referencia ENGENHEIRO<br />
[codproj] referecia PROJETO<br />
[codfuncao] referencia FUNCAO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 90
Relacionamento Ternário<br />
• Tabela Própria<br />
1. Será criada uma tabela<br />
para o relacionamento.<br />
2. Esta tabela recebe as<br />
três FKs das tabelas<br />
relacionadas, todas<br />
não nulas.<br />
3. A PK da tabela criada<br />
será formada pela<br />
concatenação das FKs<br />
oriundas de cada lado<br />
N do relacionamento.<br />
Neste caso, apenas<br />
duas das FKs formarão<br />
a PK.<br />
4. Nunca irão existir FKs<br />
nulas na tabela<br />
própria.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 91
Relacionamento Ternário<br />
• Esquema Relacional<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 92
Relacionamento Ternário<br />
• Descrição Textual<br />
ENGENHEIRO (codeng, nome, cpf, rg)<br />
PROJETO (codproj, nome, categoria, valor)<br />
FUNÇÃO (codfuncao, nome)<br />
PARTICIPA (codeng, codproj, codfuncao, dtinicio, dtfim)<br />
[codeng] referencia ENGENHEIRO<br />
[codproj] referecia PROJETO<br />
[codfuncao] referencia FUNCAO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 93
Agregação<br />
• Tabela Própria<br />
1. Será criada uma tabela<br />
para a entidade<br />
associativa.<br />
2. Esta tabela recebe as<br />
duas FK das tabelas<br />
relacionadas formando<br />
a sua PK, que pode ser<br />
concatenada com<br />
atributos do<br />
relacionamento.<br />
3. Nunca irão existir FKs<br />
nulas na nova tabela<br />
criada.<br />
4. Deverá ser feito o<br />
relacionamento entre a<br />
nova tabela criada e a<br />
terceira entidade.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 94
Agregação<br />
• Esquema Relacional<br />
1. A PK de CONSULTA será<br />
formada pelas duas FKs<br />
concatenadas com os<br />
atributos data e hora,<br />
para permitir que um<br />
médico possa consultar<br />
o mesmo paciente mais<br />
de uma vez no mesmo<br />
dia, porém em horários<br />
diferentes.<br />
2. É mais conveniente criar<br />
uma PK artificial para a<br />
tabela CONSULTA e<br />
transformar a sua PK<br />
natural em uma chave<br />
candidata.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 95
Agregação<br />
• Descrição Textual<br />
MEDICO (codmedico, nome, crm, celular)<br />
PACIENTE (codpaciente, nome, cpf, rg)<br />
CONSULTA (codmedico, codpaciente, data, hora)<br />
[codmedico] referencia MEDICO<br />
[codpaciente] referencia PACIENTE<br />
MEDICAMENTO (codmedic, nome, laboratorio, tipo)<br />
PRESCREVE (codmedico, codpaciente, data, hora, codmedic)<br />
[codmedico, codpaciente, data, hora] referencia<br />
CONSULTA<br />
[codmedic] referencia MEDICAMENTO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 96
Agregação<br />
• Esquema Relacional Modificado<br />
1. É criado o atributo<br />
codconsulta para ser a<br />
PK da tabela CONSULTA.<br />
2. Os quatro atributos<br />
que formavam a PK da<br />
tabela CONSULTA<br />
passam a formar uma<br />
chave candidata.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 97
Agregação<br />
• Descrição Textual<br />
MEDICO (codmedico, nome, crm, celular)<br />
PACIENTE (codpaciente, nome, cpf, rg)<br />
CONSULTA (codconsulta, codmedico, codpaciente, data, hora)<br />
[codmedico] referencia MEDICO<br />
[codpaciente] referencia PACIENTE<br />
MEDICAMENTO (codmedic, nome, laboratorio, tipo)<br />
PRESCREVE (codconsulta, codmedic)<br />
[codconsulta] referencia CONSULTA<br />
[codmedic] referencia MEDICAMENTO<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 98
Especialização/Generalização<br />
• Uma tabela para cada entidade<br />
1. Será criada uma tabela<br />
para cada entidade.<br />
2. Estabelecer um<br />
relacionamento de 1:1<br />
entre a tabela genérica<br />
e cada uma das tabelas<br />
especializadas.<br />
3. Esses relacionamentos<br />
serão obrigatórios do<br />
lado da tabela genérica<br />
e opcionais do lado das<br />
tabelas especializadas.<br />
4. A PK da tabela genérica<br />
será FK e também PK<br />
em cada uma das<br />
tabelas especializadas.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 99
Especialização/Generalização<br />
• Esquema Relacional – Uma tabela para cada entidade<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 100
Especialização/Generalização<br />
• Descrição Textual – Uma tabela para cada entidade<br />
CLIENTE (codcliente, nome, rua, numero, bairro, cep)<br />
FISICA (codcliente, rg, cpf, dtnasc)<br />
[codcliente] referencia CLIENTE<br />
JURIDICA (codcliente, inscest, cnpj, nomefantasia) )<br />
[codcliente] referencia CLIENTE<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 101
Especialização/Generalização<br />
• Uma tabela apenas para a entidade genérica<br />
1. Será criada uma tabela<br />
apenas para a entidade<br />
genérica.<br />
2. Todos os atributos das<br />
entidades especializadas<br />
deverão migrar para a<br />
entidade genérica,<br />
podendo ser nulos.<br />
3. As entidades<br />
especializadas deixam<br />
de existir.<br />
4. Deverá ser criado um<br />
atributo para diferenciar<br />
cada linha da tabela<br />
resultante.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 102
Especialização/Generalização<br />
• Esquema Relacional – Uma tabela para a entidade genérica<br />
Descrição Textual<br />
CLIENTE (codcliente, nome, rua, numero,<br />
bairro, cep*, rg*, cpf*, dtnasc*,<br />
sexo*, cnpj*, inscest*,<br />
razaosocial*, ramo*, tipo)<br />
Deverá ser criado um novo atributo<br />
não nulo para categorizar cada<br />
linha da tabela resultante.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 103
Especialização/Generalização<br />
• Tabelas apenas para as entidades especializadas<br />
1. Serão criadas tabelas<br />
apenas para as<br />
entidades especializadas<br />
2. Todos os atributos da<br />
entidade genérica<br />
deverão migrar para<br />
cada tabela<br />
especializada, não<br />
podendo ser nulos.<br />
3. A entidade genérica<br />
deixa de existir.<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 104
Especialização/Generalização<br />
• Esquema Relacional - Tabelas para as entidades especializadas<br />
Descrição Textual<br />
FISICA (codcliente, nome, rua,<br />
numero, bairro, cep*,<br />
rg, cpf, dtnasc, sexo)<br />
JURIDICA (codcliente, nome, rua, numero, bairro,<br />
cep*, cnpj, inscest, razaosocial, ramo)<br />
O <strong>Modelo</strong> <strong>Lógico</strong> 26 de outubro de 2019 105
Copyright © 2019 Nilton Freire Santos.<br />
Todos os direitos reservados.<br />
O <strong>Modelo</strong> Conceitual 26/10/2019 10