07 Modelagem de dados usando o modelo Entidade Relacionamento

Prévia do material em texto

Modelagem de dados usando o 
modelo Entidade-Relacionamento
Disciplina: Banco de Dados
Professor: Wandré Nunes de 
Pinho Veloso
2
Importância da Modelagem de 
Dados
• A modelagem de dados é fundamental para o 
sucesso da implementação
• Uma modelagem adequada ajuda a estabelecer 
acordos entre os desenvolvedores e os 
usuários, através de uma linguagem comum
• A modelagem conceitual do banco de dados é 
cada vez mais vista como uma etapa comum 
entre o projeto de uma aplicação (Engenharia de 
Software) e o projeto do BD em si
• Existem diversas metodologias para projeto de 
BD; o modelo ER é apenas uma delas, e uma 
das mais usadas até hoje
3
Projeto de Bancos de Dados
• Etapas
– Levantamento e análise de requisitos
• Produto: requisitos do banco de dados
– Projeto conceitual
• Produto: esquema conceitual (usando modelo de dados de 
alto nível)
– Projeto lógico ou Mapeamento do Modelo de dados
• Produto: esquema lógico (conceitual) (no modelo de dados 
de um SGBD específico)
– Projeto físico
• Produto: esquema interno (esquema físico)
4
Projeto de Bancos de Dados
• Outras etapas (ligadas ao desenvolvimento da 
aplicação)
– Análise funcional
• Produto: especificação de alto nível das transações previstas
– Projeto de programas
• Produto: especificação dos programas que serão 
necessários
– Implementação das transações
• Produto: programas que compõem a aplicação
• O esquema conceitual e a análise funcional são 
as principais etapas que independem do SGBD 
que será adotado
5
Um diagrama simplificado para ilustrar as principais fases do 
projeto de um banco de dados
6
Um diagrama simplificado para ilustrar as principais fases do 
projeto de um banco de dados
7
Um diagrama simplificado para ilustrar as principais fases do 
projeto de um banco de dados
8
Exemplo “Empresa”
• Mesmo que o usuário não domine a 
técnica da modelagem ER, é possível, 
com algumas informações básicas a 
respeito da notação, “ler” o diagrama do 
esquema conceitual
• A fase inicial, de coleta e análise de 
requisitos, envolve a realização de 
entrevistas com os usuários 
(especialistas)
9
Exemplo “Empresa”: requisitos
1. A empresa é organizada em 
departamentos. Cada departamento possui 
um nome exclusivo e um funcionário em 
particular que o gerencia. Registramos a 
data inicial em que esse funcionário 
começou a gerenciar o departamento. Um 
departamento pode ter vários locais
2. Um departamento controla uma série de 
projetos, cada um deles com número 
exclusivo, um número exclusivo e um local 
exclusivo.
10
Exemplo “Empresa”: requisitos
3. Armazenamos o nome, número do Cadastro de Pessoa 
Física, endereço, salário, sexo (gênero) e data de 
nascimento de cada funcionário. Um funcionário é 
designado para um departamento, mas pode trabalhar 
em vários projetos, que não necessariamente são 
controlados pelo mesmo departamento. Registramos o 
número atual de horas por semana que um funcionário 
trabalha em cada projeto. Também registramos o 
supervisor direto de cada funcionário (que é outro 
funcionário)
4. Queremos registrar os dependentes de cada 
funcionário para fins de seguro. Para cada dependente, 
mantemos o nome, sexo, data de nascimento e 
parentesco com o funcionário
11
Um diagrama do esquema ER para o banco de dados EMPRESA
12
Entidades
• Um Tipo de Entidade (ou simplesmente Entidade) é 
representado no DER como uma caixa retangular 
contendo o seu nome
• Atributos são representados por ovais contendo seu 
nome e ligados ao tipo de entidade por linhas retas
• Atributos compostos são ligados a seus atributos 
componentes por linhas retas
• Atributos multivalorados são exibidos usando ovais 
duplos
• Atributos chave são indicados com sublinhamento
13
Dois tipos de entidade, FUNCIONARIO e EMPRESA, e algumas entidades 
membro (instâncias) de cada uma
14
Duas entidades, funcionário f1 e empresa e1, e seus atributos
15
Hierarquia de atributos compostos
16
Notação do diagrama ER e o conjunto de entidade com três entidades de uma 
entidade CARRO com dois atributos-chave
17
Projeto Conceitual Preliminar
para a EMPRESA
• Evolução do projeto
– Primeiro passo: definição dos requisitos
– Segundo passo: especificação preliminar dos tipos de 
entidades necessários
– Terceiro passo: especificação de relacionamentos (a 
seguir)
• Entidades necessárias
– DEPARTAMENTO
– PROJETO
– FUNCIONARIO
– DEPENDENTE
18
Projeto inicial dos tipos entidade para o banco de dados EMPRESA
19
Relacionamentos
• No esquema do exemplo existem já 
alguns relacionamentos implícitos
– Atributos compartilhados por duas ou mais 
entidades
• No modelo ER, tais “referências cruzadas” 
não deveriam ser especificadas como 
atributos, mas sim como relacionamentos 
entre entidades
– Representação explícita dos relacionamentos
20
Relacionamentos
• Tipos de relacionamentos
– Um tipo de relacionamento R entre n tipos de entidades E1, E2, ..., En define um conjunto de associações ou um conjunto de relacionamentos entre entidades desses tipos
– O tipo de relacionamento e o conjunto de relacionamentos 
correspondente são chamados pelo mesmo nome, R
• Matematicamente, R é um conjunto de instâncias de 
relacionamentos ri, onde cada ri associa-se a n 
entidades individuais (e1, e2, ..., en), sendo que cada 
entidade individual ej em ri é um membro do tipo de 
entidade Ej
– Assim, diz-se que cada tipo de entidade Ej participa do tipo de relacionamento R, e cada entidade individual ei participa da instância de relacionamento ri
21
Relacionamentos
• Informalmente, cada instância de 
relacionamento ri em R é uma associação de entidades, onde a associação inclui exatamente 
uma entidade de cada tipo de entidade 
participante
• Exemplo: TRABALHA_PARA, relacionamento 
entre FUNCIONARIO e DEPARTAMENTO
• Na notação do DER, o relacionamento é exibido 
como um losango, que contém o nome do 
relacionamento e é ligado por linhas retas aos 
retângulos das entidades participantes
22
Algumas instâncias do conjunto de relacionamento TRABALHA_PARA, que representa 
um tipo relacionamento TRABALHA_PARA entre FUNCIONARIO e DEPARTAMENTO
23
Relacionamentos
• Grau do relacionamento: número de entidades 
participantes
– Grau 2: binário; grau 3: ternário (exemplo)
• Relacionamentos como atributos
– Pode ser interessante imaginar relacionamentos codificados 
dentro de atributos, considerando como domínio o conjunto de 
entidades relacionadas
– Exemplo: Em TRABALHA_PARA, poderíamos ter um atributo 
DEPARTAMENTO dentro da entidade FUNCIONARIO, cujo 
domínio é o conjunto de departamentos existentes; em 
DEPARTAMENTO, poderíamos ter um atributo multivalorado 
FUNCIONARIO, cujo domínio é o conjunto de empregados
– Exemplo: Um fornecedor f, uma peça p e um projeto j, onde 
sempre que f fornece a peça p ao projeto j
24
Algumas instâncias de relacionamento do conjunto de relacionamento ternário 
FORNECE
25
Relacionamentos
• Papeis
– Cada tipo de entidade que participa em um tipo de 
relacionamento desempenha um determinado papel no 
relacionamento
• Exemplo: em TRABALHA_PARA, o FUNCIONARIO 
exerce o papel de “trabalhador”
– Nem sempre os nomes dos papeis são necessários em tipos de 
relacionamentos em que todos os participantes são distintos 
entre si
– Quando a mesma entidade exerce papeis diferentes ou se auto 
relaciona é necessário identificar os papéis para distinguir o 
significado de cada participação
• Exemplo: EMPREGADO e SUPERVISÃO
– O empregado ora exerce o papel de supervisionado, ora o de supervisor
26
Um relacionamento recursivo SUPERVISAO entre FUNCIONARIO, no papel 
de supervisor (1), e FUNCIONARIO, no papelde subordinado (2)
27
Relacionamentos
• Existem restrições que ocorrem em tipos de 
relacionamentos
• Restrição de cardinalidade
– Cardinalidade em relacionamentos binários: número 
de instâncias potencialmente envolvidas em cada 
lado do relacionamento
• Exemplo: TRABALHA_PARA: 1:N → cada departamento 
pode ter N funcionários, mas cada funcionário só pode 
trabalhar em um departamento
– Outras razões de cardinalidade: 1:1, 1:N, N:1, M:N
• Exemplo: TRABALHA_EM, entre PROJETO e 
FUNCIONARIO, é M:N
28
Um relacionamento TRABALHA_EM, M:N
FUNCIONARIO
TRABALHA_EM
PROJETO
29
Relacionamentos
• Restrições de participação e dependências de existência
– Especifica se a existência de uma entidade depende dela estar 
relacionada a outra entidade por meio do tipo de relacionamento
– Essa restrição especifica o número mínimo de instâncias de 
relacionamento em que cada entidade pode participar (também 
chamada de restrição de cardinalidade mínima)
– Existem dois tipos: total e parcial
• Exemplo: se todo funcionário deve pertencer a um departamento, então a 
participação de FUNCIONARIO em TRABALHA_PARA é chamada de 
participação total
• Exemplo: no relacionamento GERENCIA, nem todo empregado é gerente 
de departamento, e portanto a participação de FUNCIONARIO em 
GERENCIA é parcial
• Restrições de cardinalidade e restrições de participação 
compõem as restrições estruturais de um tipo de 
relacionamento
30
Um relacionamento 1:1 GERENCIA
31
Relacionamentos
• Notação de relacionamentos
– Participação total (ou dependência de existência): 
linha dupla
– Participação parcial: linha simples
• Atributos de relacionamentos
– Tipos de relacionamento também podem possuir 
atributos que os caracterizem, semelhantes aos dos 
tipos de entidades
• Exemplo: em TRABALHA_EM, um atributo possível seria o número 
de horas trabalhadas pelo FUNCIONARIO no PROJETO
• Exemplo: em GERENCIA, um atributo Data_inicio pode registrar 
quando o relacionamento foi iniciado
32
Relacionamentos
• É possível migrar com atributos de 
relacionamentos para o lado com maior 
cardinalidade; em M:N é necessário 
estabelecer uma combinação de 
entidades participantes
– Exemplo: atributo Horas no relacionamento 
M:N de TRABALHA_EM. O número de horas 
por semana que um funcionário trabalha 
atualmente em um projeto é determinado por 
uma combinação funcionário-projeto, e não 
de maneira separada por qualquer entidade
33
Um diagrama do esquema ER para o banco de dados EMPRESA
34
Tipos de Entidades Fracas
• Tipos de entidades são considerados fracos 
quando não possuem seus próprios atributos-chave
• Tipos de entidades regulares que possuem chave 
são, às vezes, chamados de tipos de entidades 
fortes
• Tipos de entidades fracas são identificadas através 
de seu relacionamento com entidades específicas 
de outro tipo, em combinação com alguns de seus 
atributos
– Entidade identificadora ou proprietária
– Relacionamento identificador
• A entidade fraca possui sempre uma restrição de 
participação total (dependência de existência)em 
seu relacionamento identificador
35
Tipos de Entidades Fracas
• Exemplo: Uma carteira de motorista não pode existir a menos que 
esteja relacionada a uma pessoa, embora tenha uma a própria 
chave e, portanto, não seja uma entidade fraca
• Exemplo: DEPENDENTE, relacionada a FUNCIONARIO
– Os atributos de dependentes de funcionários diferentes podem, 
coincidentemente, ser todos iguais, porém são instâncias diferentes de 
DEPENDENTE
– Estas entidades só são caracterizadas como entidades distintas depois que 
for determinada a instância de FUNCIONARIO à qual estão ligadas
• A entidade fraca normalmente possui uma chave parcial, que 
identifica univocamente (exclusivamente) entidades fracas que 
estão ligadas à mesma entidade identificadora
• Entidades fracas e relacionamentos identificadores são denotados 
com um retângulo/losango de borda dupla no DER; a chave parcial 
é indicada com sublinhado em linha pontilhada
• Entidades fracas podem às vezes ser definidas como atributos 
complexos (compostos, multivalorados)
36
Resumo da notação para diagramas ER
Entidade Forte
Entidade Fraca
Relacionamentos
Relacionamentos dependentes
Atributos
Atributos chave
37
Resumo da notação para diagramas ER
Atributo chave parcial (Entidades fracas)
Atributo multivalorado
Atributo composto
Atributo derivado
Cardinalidade 1:N para E1:E2 em R
Restrição de cardinalidade (min,máx)
na participação de E em R
Participação Total de R2 em R
38
Refinamento do Esquema
Conceitual para EMPRESA
• Relacionamentos especificados
– GERENCIA, 1:1 entre FUNCIONARIO e 
DEPARTAMENTO
– TRABALHA_PARA, 1:N entre DEPARTAMENTO e 
FUNCIONARIO
– CONTROLA, 1:N entre DEPARTAMENTO e PROJETO
– SUPERVISÃO, 1:N entre FUNCIONARIO (papel de 
supervisor) e FUNCIONARIO (papel de supervisionado)
– TRABALHA_EM, M:N entre FUNCIONARIO e PROJETO 
com atributo Horas
– DEPENDENTES_DE, 1:N entre FUNCIONARIO e 
DEPENDENTE
39
Refinamento do Esquema
Conceitual para EMPRESA
• É importante ter o mínimo possível de 
redundância quando projetamos o 
esquema conceitual
– Se alguma redundância for desejada no nível de 
armazenamento ou no nível de visão do usuário, ela pode ser 
introduzida mais tarde
Diagrama ER para o esquema EMPRESA, com restrições estruturais
40
41
O esquema conceitual EMPRESA em notação de diagrama 
de classe UML
42
Relacionamento ternário
43
Relacionamento ternário
44
Um diagrama ER para um esquema de banco de dados BANCO
45
Bibliografia
• Capítulo 7: Elsmari Ramez; Navathe 
Shamkant B. Sistemas de Banco de 
Dados – Fundamentos e Aplicações. 6 ed. 
Pearson, São Paulo, 2011.
• Date, C.J. Introdução a Sistema de Banco 
de Dados. 7 ed. Campus, Rio de Janeiro, 
2000.