Considerações sobre Modelagem de Dados

e Diagrama de Entidade Relacionamento (DER)

 Quantidade de informações;
 Definição de Banco de dados e SGBD
(DBMS);
 Sistemas Isolados X Sistemas Integrados;
◦ Redundância de Dados;
 Dados X Informações;
 Sistema de Gerência de Bancos de Dados;
 Abstração de Dados:
◦ Nível Físico, Nível Conceitual e Nível de Visões de
Usuário.
 Modelagem de Dados
 Dados: são fatos em sua forma primária. É a “matéria-prima” coletada
de uma ou mais fontes.
◦ Ex: um nome; um número; um telefone;
 José, 71, 8888-4444

 Informação:
- Quando se organiza ou arranja os fatos de uma maneira significativa;
- Conjunto de fatos organizados adquirindo valor adicional além do
valor do fato em si;
- Criada definindo-se e organizando relações entre os dados (dados
processados).
◦ Ex: O funcionário José, residente à rua Arabé no 71 possui o 8888-
4444 como número de telefone celular ;

Entrada Saída
Processamento
Dados Informação

Memória
 Modelo é a representação abstrata e
simplificada de um sistema real, com a qual
se pode explicar ou testar o seu
comportamento, em seu todo ou em partes.

 Objeto Observado:
◦ O que percebemos?
◦ Qual o efeito?
◦ Onde se enquadra?
 O Processo de Modelagem deve atender aos
seguintes requisitos:
◦ Abrangência: definir o escopo ou limite do
conjunto de variáveis observadas. Expectativas
irreais, ou mal definidas, podem levar o melhor
dos modelos a ser totalmente descartado por não
retratar o que era desejado.
◦ Nível de Detalhamento: Depois de especificado o
escopo, a seguir deve-se saber em que nível de
detalhe devemos trabalhar. Ex: Basta os
elementos predominantes? Tudo? Deve-se
adentrar nos mínimos detalhes?
 O Processo de Modelagem (Cont.)
◦ Tempo para a Produção do Modelo: determinação
das dificuldades para especificação do modelo
desejado, implicando no conhecimento das
expectativas de prazo para a conclusão do
trabalho.
◦ Recursos Disponíveis: desde início deve ser
definida a equipe alocada para participar da
modelagem. Tanto especialistas em modelagem
como indivíduos que fornecerão subsídios para
tal.
 Atendidos os Requisitos, deve-se iniciar o
processo de modelagem:
◦ Observação dos objetos (Influência: Abrangência
e Nível de Detalhamento);
◦ Entendimento dos conceitos:
 Identificá-lo;
 Conceituá-lo;
 Entendê-lo;
 Assimilá-lo.
 Essa sequência de fases faz com que algo que até certo
instante era desconhecido para nós passe a fazer parte
de nosso conhecimento e seja incorporado ao conjunto
de objetos de nosso domínio.
◦ Representação dos objetos;
 O domínio de técnicas de modelagem é necessário,
mas não é suficiente para se produzirem bons
modelos.
◦ Verificação da fidelidade e coerência;
 Novos objetos a serem agregados ao modelo
contêm anomalias e, por isso, destoam do conjunto,
devendo então ser remodelados;
 Novos elementos a serem agregados espelham
realmente os objetos observados, o que demonstra
a necessidade de tratamento de anomalias nos
elementos previamente existentes.
◦ Validação do modelo.

 Não ame seu modelo de dados!

 Se você acha que seu modelo está bom, é porque

talvez ainda não tenha olhado direito!

 Obs: Se em um processo de validação não

conseguirmos descobrir algum ponto falho, alguma
anomalia ou algo a ser melhorado, devemos então
desconfiar e ficar realmente preocupados, pois não
fizemos a validação corretamente!
 Objetivos do Modelo de Dados: A
modelagem de dados não é uma ferramenta
só para projeto de banco de dados! Seus
objetivos implicam em:
◦ Representar um ambiente observado;
◦ Servir de instrumento para comunicação;
◦ Favorecer o processo de verificação e validação;
◦ Capturar aspectos de relacionamento entre os
objetos observados;
◦ Servir como referencial para a geração de
estruturas de dados; e
◦ Estabelecer conceitos únicos a partir de visões
diversas.
 Modelagem de Dados

◦ 1a Forma: Descritiva;

◦ 2a Forma: Esquemática;

◦ 3a Forma: Modelo de Dados.

Principais fases de um Mundo real

projeto de Banco de Dados

Levantamento e Análise
de Requisitos

Requisitos de dados
Requisitos funcionais

PROJETO CONCEITUAL
ANÁLISE FUNCIONAL

Esquema conceitual
Especificação da transação (em um modelo de dados de alto nível)
de alto nível

Independente do SGBD
PROJETO LÓGICO
Específico do SGBD (Mapeamento do Modelo de Dados)

PROJETO DO PROGRAMA DE Esquema lógico (conceitual) no modelo

APLICAÇÃO de dados de um SGBD específico

IMPLEMENTAÇÃO DA TRANSAÇÃO
PROJETO FÍSICO

Programas de aplicação Esquema interno

 Forma 1: Descritiva

◦ A empresa hipotética S.A. atua no ramo de lojas

de departamentos através de uma cadeia de lojas
por todo território nacional e também com lojas
nas principais capitais internacionais.
◦ Cada loja possui uma estrutura hierárquica que é
gerenciada por um departamento de compras
central, responsável por um conjunto de
atividades específicas de negociação e
contratação.
◦ Subordinados a este departamento estão os
departamentos de venda, cada qual com seu
ramo de comercialização. Esse ramo ....
 Forma 2: Esquemática
Empresa Hipotética S.A.

Brasil Exterior
Lj3 Lj5
Lj1 Lj2
Lj4
Depto
compras

Depto Depto Depto Depto

vendas vendas vendas vendas
Fornecedor 1
prod.A prod.D prod.F
prod.F
prod.B prod.E prod.G
prod.C
prod.H Fornecedor 2
 Forma 3: Modelo de Dados

EMPRESA

1,1

possui

1,N
1,1 É 1,N
LOJA dividida DEPTº
 Forma 3: Modelo de Dados
LOJA

LOJA LOJA
NACIONAL INTERNACIONAL

0,N 0,N

situa-se situa-se

1,1 1,1
CIDADE CAPITAL
NACIONAL INTERNACIONAL
1,N
engloba c
LOCALIDADE
ESTADO 1,1
O BR Modelo é uma
ferramenta que pode ser
usada para facilitar a
criação de modelos
relacionais de um banco de
dados.
 Forma 3: Modelo de Dados
DEPTº

DEPTO DEPTO 1,1 1,1 RAMO

atua
COMPRAS VENDAS COMERCIALIZ.
CENTRAL
1,N
1,1 1,N
gerencia 1,N
engloba
1,N
PRODUTO
1,N
é direcionado 1,N
atende
é fornecido
1,N
PÚBLICO-ALVO 1,N
1,N FINALIDADE
FORNECEDOR
 Criado por Peter Chen em 1976. É um modelo
independente de aspectos de implementação
(modelo de dados conceitual).
 Definição: modelo baseado na percepção do
mundo real, que consiste em um conjunto de
objetos básicos chamados entidades e nos
relacionamentos entre esses objetos.
 A proposta do modelo E-R visa a
compreensão da realidade em que se situa o
problema.
 Esta técnica de modelagem de dados provê a
visão estática do sistema e deve ser utilizada
juntamente com outras técnicas de análise de
sistemas para formar uma visão completa do
mesmo.

 Objetivo: facilitar o projeto de banco de

dados, possibilitando a especificação da
estrutura lógica geral do banco de dados.
 Diagrama Entidade- Relacionamento
◦ A estrutura lógica geral de um banco de dados
pode ser expressa graficamente por um Diagrama
Entidade-Relacionamento.

 Componentes do Diagrama E-R (Peter Chen):

◦ Retângulos: representam conjuntos de entidades;
◦ Elipses: representam atributos;
◦ Losangos: representam conjuntos de
relacionamentos;
◦ Linhas: ligam atributos  conjuntos-entidade e
conjuntos- entidade  conjuntos-relacionamento.
 Entidade: é uma representação abstrata de
um objeto do mundo real, i.e., é um objeto
que existe no mundo real com uma
identificação distinta e com um significado
próprio.
◦ Exemplos: Estudantes, Professores, Disciplinas,
Departamentos, Atletas, Modalidades, Competições,
etc.
◦ Ex: O fornecedor Pedro, com código F1.
FORNECEDOR

Cod-Forn Estado

Nome Cidade
 Atributo: Elemento de dado que contém
informação que descreve uma entidade.
Portanto, os atributos representam as
características ou propriedades das
entidades.
◦ Ex:
FUNCIONÁRIO

Cod-Func
* Endereço
Nome Dependentes

Cidade Estado
 Atributo Monovalorado: assume um único
valor para cada elemento da entidade.
◦ Ex: Nome
 Atributo Composto: formado por um ou mais
sub- atributos.
◦ Ex: Endereço
 Atributo Multivalorado: uma única entidade
tem diversos valores para este atributo (seu
nome é sempre representado no plural).
◦ Ex: Dependentes, Telefones
 Atributo Determinante: identifica cada
entidade de um conjunto-entidade (também
conhecido como atributo chave). Alguns
atributos da entidade são considerados seus
identificadores.
◦ Os atributos identificadores da entidade formarão a
chave primária da entidade do ponto de vista de
projeto de BDs.
◦ Ex: Cod-Func

 Domínio de um Atributo: conjunto de valores

permitidos para o atributo.
◦ Ex: Sexo {M, F}
 Relacionamento: estrutura que indica a
associação de elementos de duas ou mais
entidades. É o fato ou acontecimento que liga
dois objetos do mundo real (entidades do
modelo).
◦ Ex1: mora (entre pessoa e apartamento), casado
com (entre homens e mulheres), fornece (entre
fornecedor e peça).
◦ Ex2:
N fornece N
FORNECEDOR PEÇA

 Relacionamentos também podem ter

propriedades, ou seja, atributos.
 Dependência existencial ocorre quando a existência de uma
determinada entidade está condicionada à existência de uma
outra entidade a ela relacionada. Também conhecido como
relacionamento identificador.
◦ Ex:
1 N
DEPARTAMENTO Trabalha FUNCIONÁRIO

 Uma entidade fraca não possui sequer identidade própria, sendo

seu atributo determinante composto (chave primária) pela
atributo determinante (chave estrangeira) proveniente da
entidade (forte). Por exemplo, não faz sentido a ocorrência de
um dependente sem a existência de um funcionário responsável.
◦ Ex:

1 N
FUNCIONÁRIO Mantém DEPENDENTE
 Atributo de Relacionamento: depende de
todos os conjuntos-entidade associados
entre si.
◦ Por exemplo, quando um fornecedor fornece uma
peça, e sua quantidade fornecida deve ser
guardada. Essa propriedade não pertence nem a
fornecedor e nem a peça, pois somente quando
ocorre o relacionamento é que desejamos registrar
a quantidade. Portanto, quantidade é um atributo
do relacionamento fornece.
◦ Por outro lado, poderia ser guardada a quantidade
de peças em estoque, mas neste caso esta
quantidade não dependeria do relacionamento,
devendo ser modelada como um atributo de peça.
 Atributo de Relacionamento (Cont.):
◦ Ex: QtdeEstoque

N fornece N
FORNECEDOR PEÇA

Cod-Forn Cod-Forn Quantidade Cod-Peca

Cod-Peca ValorTotal
 O exemplo a seguir demonstra uma situação em
que um funcionário pode trabalhar em diversos
projetos e em um projeto podem trabalhar diversos
funcionários. Considerando a necessidade de
armazenar a quantidade de horas trabalhadas pelo
funcionário em um projeto, percebe-se a
necessidade de adicionar um atributo de
relacionamento (já que este atributo não “cabe”
nem em Funcionário e nem em Projeto).
 a) Um-para-um: uma entidade em A está
associada no máximo a uma entidade em B e
uma entidade em B está associada no máximo
a uma entidade em A. Obs.: Chave estrangeira
em uma das entidades.
a1 b1

a2 b2

a3 b3

Conjunto-Entidade A Conjunto-Entidade B

1 Gerencia 1
FUNCIONÁRIO DEPARTAMENTO
 b) Um-para-muitos: uma entidade em A está
associada a qualquer número de entidades em
B, enquanto uma entidade em B está associada
no máximo a uma entidade A. Obs.: Chave
estrangeira na direção muitos.
b1
a1
b2
b3
a2
b4

Conjunto-Entidade A Conjunto-Entidade B

1 Lotação N
DEPARTAMENTO FUNCIONÁRIO
 b) Um-para-muitos (continuação)
 Restrições de Mapeamento
(cardinalidade)
 c) Muitos-para-muitos: Uma entidade em A
está associada a qualquer número de entidades
em B e uma entidade em B está associada a
qualquer número de entidades em A. Obs.:
Requer tabela extra para representá-lo.
a1 b1

a2 b2

a3 b3

Conjunto-Entidade A Conjunto-Entidade B

N Trabalha N
FUNCIONÁRIO PROJETO
 Chave: é um conjunto de um ou mais
atributos que, tomados coletivamente,
permite-nos identificar unicamente a
ocorrência de uma entidade.

 Integridade de Entidade: Nenhum atributo

que participe da chave de uma entidade deve
aceitar valores nulos.
 Aspectos Relevantes

◦ A questão fundamental do projeto de chaves é

reduzir ao máximo os efeitos de redundância;

◦ A alteração dos valores de campos constituintes da

chave primária ou a remoção de uma entidade pode
ocasionar problemas de integridade referencial.
 QtdeEstoque

N Pedido N
FORNECEDOR PECA

Cod-Forn Cod-Forn Quantidade Cod-Peca

Cod-Peca Preço

◦ Entidade Fornecedor  Cod-Forn

◦ Entidade Peça  Cod-Peca
◦ Relacionamento Pedido  Cod-Forn e Cod-Peca
1) Projete o diagrama E-R para uma empresa de
projetos que possui empregados. Todo
empregado pertence a um departamento. Todo
departamento possui um gerente. Um
empregado pode participar de mais de um
projeto. Todo projeto possui um líder. Todo
projeto é coordenado por um departamento. Um
empregado pode ter um ou mais dependentes.
2) Projete o diagrama E-R para uma delegacia que
deseja armazenar somente assassinatos onde os
criminosos podem assassinar várias vítimas e
cada vítima pode ser assassinada por vários
criminosos. Cada criminoso que assassina uma
vítima pode utilizar várias armas.
 Relaciona elementos de um conjunto-
entidade a elementos desse mesmo
conjunto-entidade.
◦ Um exemplo seria o fato de um funcionário possuir
um supervisor na empresa. O supervisor também é
um funcionário da empresa, possuindo os mesmos
atributos do supervisionado. Por outro lado, o
funcionário pode supervisionar vários outros
empregados.
FUNCIONÁRIO
◦ Ex:
1 N
Supervisor Supervisionado

Supervisiona
o Pessoal
 Exige a ocorrência de todas as entidades
envolvidas nesse tipo de relacionamento.
 Ex: toda vez que ocorre o relacionamento um
fornecedor deve fornecer uma peça para o
projeto
Cod-Forn Quantidade Cod-Proj

FORNECEDOR Fornece PROJETO

Cod-Peça

PEÇA
 Uma limitação do modelo E-R é que não é possível
expressar relacionamentos entre relacionamentos.
E algumas vezes é necessário relacionar uma
entidade com a ocorrência de um relacionamento.
◦ Agregação é uma abstração através da qual
relacionamentos são tratados como entidades de
nível superior.
N Trabalha N
FUNCIONÁRIO PROJETO

N N

Utiliza

N
MÁQUINA
 Usando a Agregação:

N Trabalha N
FUNCIONÁRIO PROJETO

Utiliza

N
MÁQUINA
 Usando a Agregação:

N Trabalha N
FUNCIONÁRIO PROJETO

Utiliza
A linha deve estar ligada
Ao retângulo

N
MÁQUINA
 Usando a Agregação (Entidade Associativa):

n n
Médico consulta Paciente

prescrição

n
Medicamento

Fonte: Heuser (1998)

 Existem casos em que um conjunto-entidade
pode ser dividido em categorias, cada qual
com atributos específicos.
◦ Ex: Código

FILIAL Atende CLIENTE

Nome

PESSOA PESSOA
CPF
FÍSICA JURÍDICA

Sexo CNPJ
 Generalização/Especialização Total: A entidade
referida em um certo relacionamento, deve ter todas
as ocorrências das entidades especialistas
participando daquele relacionamento.
◦ Ex:
CLIENTE

PESSOA PESSOA
FÍSICA JURÍDICA
 Generalização/Especialização Parcial: A entidade
referida em um certo relacionamento, terá algumas
ocorrências das entidades especialistas
participando daquele relacionamento dependendo
de determinadas condições.
◦ Ex:
Cargo

FUNCIONÁRIO

MOTORISTA SECRETÁRIA
 Generalização e Especialização
Não-Exclusiva
 Abrange abstratamente uma classe de
entidades, na qual as entidades especialistas
possuem existência mútua, i.e., sem
exclusão.
◦ Ex: Obs: A especialização não é exclusiva,
já que a mesma pessoa pode aparecer
PESSOA
em múltiplas especializações. Uma
pessoa pode ser professor de um curso
e ser aluno em outro curso, ou ser
aluno de pós-graduação.

PROFESSOR FUNCIONÁRIO ALUNO

 Generalização e Especialização
Não-Exclusiva
 O principal problema que este tipo de
generalização/especialização apresenta é que neste caso as
entidades especializadas não podem herdar o identificador da
entidade genérica. No caso, o identificador de pessoa não
seria suficiente para identificar professores, já que uma
pessoa pode ser múltiplas vezes professor.

Fonte: Heuser (1998)

 Generalização e Especialização
Não-Exclusiva
 Obs:

 Em casos como o mostrado no slide anterior, usa-se o

conceito de relacionamento, ao invés do conceito de
generalização/especialização.

 O modelo deveria conter três relacionamentos, associando a

entidade PESSOA com as entidades correspondentes a cada
um dos papéis de PESSOA (PROFESSOR, FUNCIONÁRIO e
ALUNO).
 Herança Múltipla:
VEÍCULO

TERRESTRE AQUÁTICO

AUTOMÓVEL VEÍCULO BARCO

ANFÍBIO
 Cod-Forn Quantidade Cod-Prod

FORNECEDOR Fornece PROJETO

Cod-Peça

PEÇA
 Cod-Forn Cod-Prod

M N
FORNECEDOR Fornece PROJETO

M M

Pode
Fornecer Cod-Peça Usa

N N
PEÇA
 Cod-Forn Quantidade Cod-Prod

FORNECEDOR FORNECE PROJETO

Cod-Peça

PEÇA
Símbolo Significado

Entidade

Entidade Fraca

Relacionamento

Relacionamento Identificado

Atributo
 Símbolo Significado
Atributo chave
*
Atributo Multivalorado ou usar um
asterisco em cima de elipse simples

...
Atributo Composto

Atributo Derivativo

1 N E2
E1 R
Cardinalidade de razão 1:N
para E1:E2 em R
 Símbolo Significado

(min, max)
R E
Restrição Estrutural (min,max)
sobre a participação de E em R

Entidade associativa (agregação)

Notação Heuser
Exemplo de cardinalidade

Ocorrência
Ocorrência opcional,
obrigatória, ou seja,
ou seja, mínimo zero,
mínimo um, máximo
máximo muitos
muitos
Departamento Funcionário

codDepto codFunc

descDepto nomeFunc
dataCriacDepto alocado dataNascFunc
salarioFunc
 A presença de um substantivo usualmente
indica uma entidade.

 A presença de um verbo é uma forte

indicação de um relacionamento.

 Um adjetivo, que é uma qualidade, é uma

forte indicação de um atributo.

 Um advérbio temporal, qualificando o verbo,

é uma indicação de um atributo do
relacionamento.
 Codcurso Nome Nome
Possui N N Possui N Cred
CURSO
Coddep Coddisc
1 Nota
Nome 1 CH
1 Está N
Matriculado Já cursou DISCIPLINA
DEPARTAMENTO

N 1
1 1
N
Matrícula
Pertence
Pertence Chefia ALUNO
Coordena Nome N N
N 1 Está N
1 Matriculado TURMA

PROFESSOR 1 Leciona N
Codturma Horário

Codprof Nome Sala

Principais fases de um Mundo real

projeto de Banco de Dados

Levantamento e Análise
de Requisitos

Requisitos de dados
Requisitos funcionais

PROJETO CONCEITUAL
ANÁLISE FUNCIONAL

Esquema conceitual
Especificação da transação (em um modelo de dados de alto nível)
de alto nível

Independente do SGBD
PROJETO LÓGICO
Específico do SGBD (Mapeamento do Modelo de Dados)

PROJETO DO PROGRAMA DE Esquema lógico (conceitual) no modelo

APLICAÇÃO de dados de um SGBD específico

IMPLEMENTAÇÃO DA TRANSAÇÃO
PROJETO FÍSICO

Programas de aplicação Esquema interno

 Projeto de Banco de Dados
◦ Autor: Carlos Aberto Heuser
◦ Instituto de Informática - UFRGS

 Sistema de de Banco de Dados

◦ Autores: Abraham Silberschatz; Henry F. Korth; S.
Sudarshan
◦ Makron Books

 Sistemas de de Banco de Dados

◦ Autores: Ramez Elmasri; Shamkant B. Navathe
◦ Person
 https://lucid.app/