Modelagem de BD - Parte7 - MER Entidade

MODELO DE DADOS
Processo de
Modelagem
Mundo Real
Solução
Modelo é a representação abstrata e simplificada de

uma determinada realidade, com a qual se pode
explicar ou testar o seu comportamento, em sua
totalidade ou em partes antes de sua existência real.
Professor: Rogério Lopes
Modelagem e Projeto de Banco de Dados
MODELO DE DADOS
“Conjunto de ferramentas conceituais usadas

para a descrição de dados, relacionamentos entre
dados, semântica de dados e regras de
consistência.”
Modelo de dados
=
descrição formal da estrutura de um banco de
dados

MODELO DE BANCO DE DADOS
Para construir um modelo de dados, usa-se uma

linguagem de modelagem de dados;
Um mesmo modelo pode ser apresentado em

várias formas:
 Para usuários leigos;
 Para técnicos.
Cada apresentação do modelo é chamado de

esquema de banco de dados.
 Um projeto de Banco de Dados normalmente é
composto por dois modelos:
 Modelo Conceitual
 Modelo que captura as
necessidades da organização em termos de
armazenamento de dados independente de
implementação.
 Modelo Lógico
 Objetivo de transformar o modelo
conceitual em modelo lógico. Define como o BD
será implementado em um SGBD específico.

MODELO CONCEITUAL
 Definição
 É um modelo de dados abstrato,
que descreve a estrutura de um banco de
dados de forma independente de um SGBD.
 A técnica mais utilizada é a abordagem Entidade-

Relacionamento (ER);
 A representação é feita através de um diagrama,

chamado Diagrama Entidade-Relacionamento (DER);

MODELO CONCEITUAL
Exemplo do Modelo Entidade-Relacionamento (MER):
1 N AGÊNCIA
BANCO
Número da agência
Número do Banco

MODELO LÓGICO
 Definição
 É um modelo de dados que
representa a estrutura de dados de um
banco de dados conforme vista pelo
usuário do SGBD
 É dependente do tipo particular de SGBD que está
sendo utilizado;
 Lógico com Base em Registros
 Modelo Hierárquico
 Lógico com Base em Objetos
 Modelo Orientado a objeto
 Modelo Relacional
MODELO LÓGICO – HIERÁRQUICO
 Definição
 Um banco de dados hierárquico
é uma coleção de registros conectados
uns aos outros por meio de links.
Tarciso 505 A Gama Valmer 204 C Paranoá Cesar 713 B Ceilândia
3B4 20,00 5B2 52,25 2C3 100,00 8A1 5,00
 Exemplo: Adabas da SoftwareAG

MODELO LÓGICO – ORIENTADO A OBJETOS
 Um banco de dados orientado a objetos é um SGBD
que integra funcionalidades de bancos de dados com
funcionalidades de linguagens de programação
orientadas a objetos.
 Sua base é um conjunto de objetos e esses contém
valores armazenados em variáveis instâncias dentro do
objeto
 São mais adequados para o tratamento de objetos
complexos (textos, gráficos, imagens) e dinâmicos
(programas, simulações)
 Exemplo: db4o
 BD orientado a objetos de código aberto
para Java e .NET
MODELO LÓGICO – RELACIONAL
 Representa DADOS e RELACIONAMENTOS por um

conjunto de Tabelas (SGBD relacional);
No modelo lógico-relacional, deve-se definir quais
tabelas e campos farão parte do Banco de Dados;
As colunas de uma tabela são chamadas de atributos
e suas linhas de tuplas.
A importância do modelo relacional em nosso curso
deve-se ao fato de ser o modelo sobre o qual é baseada
a maioria dos SGBDs comerciais disponíveis hoje em
dia como (MySQL, FireBird e PostgreSQL, SQLServer,
DB2)
 Exemplo

MODELAGEM DE BANCO DE DADOS
Mundo Real
Modelo Entidade Relacionamento
nível conceitual
Modelo Relacional
nível lógico
nível físico

MER X MODELO RELACIONAL
O Modelo Relacional é Simples e sua estrutura
Uniforme é baseada em conceitos da Teoria dos
Conjuntos;
 A simplicidade do modelo relacional faz com que a
representação do mundo real através de seus conceitos
seja de certa forma ineficiente o que ocasiona perdas
semânticas consideráveis;
 O MER, ao contrário, utiliza conceitos que permitem a
representação mais fiel dos objetos do mundo real e dos
relacionamentos entre eles;
 O Modelo Relacional tem sido implementado nos vários
SGBDs tendo como LDD/LMD a linguagem SQL.

O MER é hoje a ferramenta mais usada em projetos

de banco de dados. Dizemos que o MER é um modelo
do nível conceitual, pois possui um forte poder
semântico, capaz de capturar conceitos do mundo real
com um mínimo de perdas semânticas, facilitando o
seu entendimento.
O modelo relacional é, por outro lado, um modelo do
nível lógico porque é utilizado para representação em
computador de conceitos do mundo real.

MODELO ENTIDADE RELACIONAMENTO
MER

MER
 Peter Chen (1976)
 "Um modelo conceitual ( o Modelo Entidade

Relacionamento é um tipo) é um modelo detalhado que
captura a estrutura dos dados organizacional enquanto
sendo independente de qualquer sistema de
gerenciamento de base de dados ... "
O modelo Entidade-Relacionamento (MER) tem por

base que o mundo real é formado por um conjunto de
objetos chamados de entidades e pelo conjunto dos
relacionamentos entre esses objetos;

MER
O objetivo do modelo ER é representar a
estrutura lógica do banco de dados de uma
empresa, especificando o esquema da
empresa, quais as entidades e como elas
se relacionam entre si.
O modelo ER é chamado de Modelagem

Conceitual, cujo objetivo é representar de
uma forma abstrata, independente da
implementação em computador, os dados que
serão armazenados no banco de dados.

MER
 Proporciona uma visão lógica de alto nível dos dados;
 É uma descrição abstrata de uma porção do mundo
real;
 Todos os dados são visualizados como fatos
específicos sobre entidades, relacionamentos e
atributos;
 Através do MER, podemos ter uma fotografia do
sistema;
 As entidades, relacionamentos e atributos
descrevem
as regras de negócio da empresa.
 O MER é representado graficamente pelo Diagrama
Entidade-Relacionamento (DER).
DIAGRAMA ENTIDADE RELACIONAMENTO - DER
 Convenções
Entidade
Entidade Fraca
Relacionamento
Atributo Simples
Atributo Identificador
Atributo
Multivalorado
 Convenções
Atributo Composto
Relacionamento 1 para N

 Exemplo de MER representado pelo DER
Consulta
idmed datcon
idpac idpac datnasc
nome
1,N 1,N 1,1 0,N
Médico atende Paciente Dependente
idmed
nome 0,N
1,N possui
receita
0,1
idpla
0,N Plano nomeplano
Remédio

COMPONENTES DO MER
 ENTIDADE
 Uma entidade é uma “coisa” ou um “objeto” no
mundo real que pode ser identificada de forma única em
relação aos outros objetos;
 Um conjunto de Entidades é um conjunto que
abrange entidades de mesmo tipo que compartilham as
mesmas propriedades: atributos.
 Representação de um objeto do mundo real do
qual se deseja manter informações
 Objetos concretos (pessoa, automóvel) ou abstrato
(departamento, projeto)

COMPONENTES DO MER
 ENTIDADE
 Conjunto de objetos individuais
chamados instâncias;
 Uma instância é uma simples ocorrência
de uma entidade;
 Cada instância representa um conjunto de fatos
sobre a entidade;
 Uma instância deve ter uma identidade
distinta de todas as outras;
 Agrupados em conjuntos de entidades:
RETÂNGULO Entidade

COMPONENTES DO MER
 EXEMPLO DE ENTIDADES
Empregado Departamento
Conta Corrente Cliente

COMPONENTES DO MER
 ENTIDADES DEPENDENTES (FRACAS)

 Entidades que dependem de outras
para sua existência (dependência por
existência);
 Entidades que dependem de outras
para sua identificação (dependência por
identificação)
 ENTIDADES INDEPENDENTES
 Entidades que não dependem de outras
para sua existência e identificação
COMPONENTES DO MER
 EXEMPLO DE ENTIDADES FORTES X FRACAS
1 N
Funcionário possu Dependente
i

 EXERCÍCIO
 Identifiquem as entidades para um sistema de
biblioteca.

 RELACIONAMENTO
 Um relacionamento é uma associação entre uma ou
várias entidades (objetos da realidade)
 Ex. um relacionamento entre um empregado “José”
com o departamento “Financeiro”.
 Esse relacionamento especifica que o empregado
“José” trabalha no departamento financeiro.
 Um conjunto de relacionamentos é um conjunto de
relacionamentos de mesmo tipo.
Conjuntos de relacionamentos:
LOSANGO

 RELACIONAMENTO
Relacionamento
=
Conjunto de associações entre entidades

 EXEMPLO (DER de um relacionamento)
DEPARTAMENTO Lotação Pessoa
um conjunto de objetos classificados como pessoas

(ENTIDADE pessoa);
um conjunto de objetos classificados como departamentos
(entidade DEPARTAMENTO);
um conjunto de associações, cada um ligando um
departamento a uma pessoa. (relacionamento LOTAÇÃO).
 OUTROS EXEMPLOS
Cliente Possui Conta Corrente
Empregado Trabalha Departamento

 RELACIONAMENTOS
C1 C2
C3 C4 C5 Entidade Cliente
C1,CC1 C2, CC2

C1,CC3 C4,CC3 Relacionamento
entre Cliente e
Contas Corrente
CC1 CC2 CC3 Contas Corrente

 RELACIONAMENTOS
 A função que uma entidade desempenha em um
relacionamento é chamada Papel;
 Pode ocorrer de um mesmo conjunto de entidades
participar de um conjunto de relacionamentos mais de
uma vez em diferentes papeis.
 O número de conjuntos de entidades que participa
de um conjunto de relacionamento é também o grau
desse conjunto de relacionamento. Um conjunto de
relacionamento binário é de grau dois; um
relacionamento ternário é de grau três.

 EXEMPLO
Cidade Distribuidor
Distribuição
Produto

 AUTO-RELACIONAMENTO
auto-relacionamento
=
relacionamento entre ocorrências de uma mesma
entidade

 EXEMPLO DE AUTO-RELACIONAMENTO
Funcionário
supervisiona é supervisionado
Supervisão

 CARDINALIDADE DE RELACIONAMENTOS
cardinalidade (mínima, máxima) de entidade

em relacionamento
=
número (mínimo, máximo) de ocorrências de
entidade associadas a uma ocorrência da
entidade em questão através do
relacionamento

 EXEMPLO DE CARDINALIDADE
Empregado Lotação Departamento

N 1

 CARDINALIDADE MÁXIMA
 EMPREGADO tem cardinalidade máxima 1 no
relacionamento LOTAÇÃO;
 DEPARTAMENTO tem cardinalidade máxima N no
relacionamento LOTAÇÃO.

N 1
 Logo, duas cardinalidades são relevantes:

 CARDINALIDADE máxima 1;
 CARDINALIDADE máxima N.

 CARDINALIDADE MÍNIMA
 São consideradas apenas duas cardinalidades:
 Cardinalidade mínima 0, associação opcional;
 Cardinalidade mínima 1, conhecida como
associação obrigatória.

(0, N) (1,1)

CLASSIFICAÇÃO DE RELACIONAMENTOS
 Relacionamentos 1 x 1
 Pouco utilizado;
 Leia-se Um para Um.
Funcionário Possui Armário

1 1

 Relacionamentos 1 x N
 Leia-se: Um para muitos.
Aluno Inscrição Curso

N 1

 Relacionamentos N x N
 Leia-se: Muitos para Muitos.
Médico Consulta Paciente

N N

CARDINALIDADE EM RELACIONAMENTOS TERNÁRIOS
 A cardinalidade refere-se a pares de entidades.
Cidade Distribuidor
N 1
Distribuição
N
Produto

MER – DER – JAMES MARTIN
Departamento Empregado
Exemplo de Modelagem, onde:

= muitos (N);
= um (1);
= a ocorrência do relacionamento é opcional (0);
= a ocorrência do relacionamento é obrigatória
(1).

Departamento (1,1) Trabalha Empregado

(0,N)
Departamento Empregado


EXERCÍCIO
Elaborar o MER identificando as entidades,
relacionamentos e cardinalidades do sistema abaixo:
“Os bancos resolveram informatizar o controle dos seus

clientes. Um banco possui várias agências e cada
agência pode conter múltiplas contas e empréstimos. Um
cliente pode possuir várias contas e pode também fazer
empréstimos”

ATRIBUTO
 Características particulares do conjunto de entidades;
Cada atributo de uma entidade representa uma informação
sobre essa entidade;
 Por exemplo, os atributos de um cliente
para uma aplicação financeira seriam nome, cpf,
data de nascimento e rendimento mensal, etc;
 Já um cliente para uma aplicação médica
seria descrito pelos atributos nome, tipo
sanguíneo, fator RH, sensibilidades a
medicamento, etc;
São dados elementares que permitem descrever a
entidade ou relacionamento.
ATRIBUTO
Todas as entidades do mesmo tipo possuem os mesmos
atributos, mas com valores distintos;
 Atributos e valores descrevem as instâncias de uma
entidade.
ALUNO
Idade
Nome
Matrícula
Duas instâncias da entidade ALUNO teriam os mesmos atributos, por
exemplo, Matrícula, Nome e Idade;
 A primeira instância poderia possuir os valores Matrícula =
0268134 , Nome = Alan e Idade = 30;
 A segunda instância poderia possuir os valores
Matrícula = 0890103 , Nome = Antonio e Idade = 48.
ATRIBUTO
Atributo
=
dado que é associado a cada ocorrência de uma
entidade ou de um relacionamento

ATRIBUTOS DE RELACIONAMENTOS
nº de parcelas
FINANCEIRA FINACIAMENTO VENDA

(0,1) (0,N)
nome financeira
taxa de juros
código da financeira nº da venda

TIPOS DE ATRIBUTOS
 SIMPLES
 valor único, a exemplo de um número de uma rua;
 COMPOSTO
 Pode ser referenciado hora no todo, hora na parte:
 Endereço, composto por rua, número, cidade, etc;
 Nome, composto por nome e sobrenome.
ALUNO
Nome
Matrícula
nome Sobrenome

TIPOS DE ATRIBUTOS
 MONOVALORADO
 Para toda instância um atributo possui um conjunto
unitário de valores;
 Ex: A matrícula de uma entidade específica
refere-se apenas a um número de matrícula.
 MULTIVALORADO
 Pode existir instâncias em que um atributo possua
um
conjunto de valores para uma única entidade;
 Ex: Telefone.

EXEMPLO DE ATRIBUTO MULTIVALORADO
ALUNO
Idade
Telefone
Matrícula

CARDINALIDADE DE ATRIBUTOS
 MÍNIMA
 Atributo obrigatório (cardinalidade mínima “1”) cada
entidade possui no mínimo um valor associado;
 Atributo opcional (cardinalidade mínima “0”).
 MÁXIMA
 Atributo monovalorado (cardinalidade máxima
“1”) cada entidade possui no máximo um valor
associado;
 Atributo multivalorado (cardinalidade máxima “n”).

EXEMPLO:
ALUNO Atributo Composto:

- rua, CEP.
Endereço
Telefone (0,n)
Rua CEP
Nome (1,1)
Atributo Multivalorado:
- Corresponde a nenhum ou a vários números telefônicos.
Atributo Simples:
- Corresponde a um único valor.

ATRIBUTOS IDENTIFICADORES
 Cada ENTIDADE deve possuir um identificador;
 Identificador é um conjunto de um ou mais atributos que
servem para distinguir uma ocorrência da entidade
Identificador Simples Identificador Composto
ALUNO PRATELEIRA
Idade capacidade
Nome número do corredor
Matrícula número da prateleira

ATRIBUTOS IDENTIFICADORES
Atributo identificador
=
conjunto de atributos e relacionamentos cujos
valores distinguem uma ocorrência da entidade
das demais

RELACIONAMENTO IDENTIFICADOR
EMPREGADO Possui DEPENDENTE

(1,1) (0,n)
Nome Nome
Matrícula nº sequencial

GENERALIZAÇÃO / ESPECIALIZAÇÃO
Existem casos em que uma entidade pode ser dividida em
categorias, cada qual com atributos específicos;
Uma generalização é uma entidade que se subdivide em
especializações. Os atributos e relacionamentos de uma
generalização são herdados por suas especializações;
Uma especialização tem que ter seus próprios atributos
e/ou seus próprios relacionamentos.
Generalização / Especialização

EXEMPLO - GENERALIZAÇÃO / ESPECIALIZAÇÃO
código
FILIAL POSSUI CLIENTE nome
(1,1) (0,n)
PESSOA PESSOA
FÍSICA JURÍDICA
RG SEXO CNPJ

GENERALIZAÇÃO / ESPECIALIZAÇÃO – HERANÇA DE PROPRIEDADES
Cada ocorrência da entidade especializada possui, além de suas

próprias propriedades (atributos, relacionamentos, e
generalizações/especializações), também as propriedades da ocorrência
da entidade genérica correspondente.
código
FILIAL POSSUI CLIENTE nome
(1,1) (0,n)
PESSOA PESSOA
FÍSICA JURÍDICA
RG SEXO CNPJ

GENERALIZAÇÃO/ESPECIALIZAÇÃO TOTAL
Paracada ocorrência da entidade genérica existe sempre
uma ocorrência em uma das entidades especializadas.
código
CLIENTE nome
indica que todo CLIENTE

t é ou PESSOA FÍSICA ou
PESSOA JURÍDICA
PESSOA PESSOA
FÍSICA JURÍDICA
RG SEXO CNPJ

GENERALIZAÇÃO/ESPECIALIZAÇÃO PARCIAL
Nem toda ocorrência da entidade genérica possui uma
ocorrência correspondente em uma entidade especializada.
matrícula funcional
FUNCIONÁRIO tipo de funcionário
indica que nem todo

p FUNCIONÁRIO é
MOTORISTA ou
SECRETÁRIA
MOTORISTA SECRETÁRIA
CNH

GENERALIZAÇÃO / ESPECIALIZAÇÃO
Veículo
Veículo Veículo
Terrestre Aquático
Automóvel Veículo
Barco
Anfíbio

ENTIDADE ASSOCIATIVA (AGREGAÇÃO)
Um relacionamento é uma associação entre

entidades;
 Não foi previsto no modelo ER:
 A associação entre uma entidade
e um relacionamento;
 A associação de dois relacionamentos
entre si.
Existem situações em que é desejável permitir a
associação de uma entidade a um relacionamento.
Suponha que seja necessário modificar o modelo
abaixo para incluir que medicamentos existem e
que medicamentos foram prescritos em cada
consulta.
n n
MÉDICO CONSULTA PACIENTE
A questão agora é:
 Com que entidade existente deve estar
relacionada a nova entidade (Medicamento)?
 Se Medicamento fosse relacionado a Médico:
 Teríamos apenas a informação de que médico
prescreveu que medicamento, faltando a informação
do paciente que os teve prescritos.
n n n
n
Prescrição Medicamento

 Se Medicamento fosse relacionado a Paciente:
 Faltaria a informação do
médico que prescreveu o
medicamento.
n n n
n
Medicamento Prescrição

 Solução:
 Relacionar Medicamento à Consulta, isto é, vamos
relacionar uma entidade a um relacionamento.
Como fazer isso: usar o conceito de “Entidade Associativa”
ou “Agregação”
n n
MÉDICO CONSULTA PACIENTE
n
PRESCRIÇ Uma entidade associativa
ÃO
nada mais é do que uma
redefinição de um
n
relacionamento que passa
a ser tratado como se
MEDICAMENTO
fosse também uma
entidade.
1 1
Médico Paciente
Concede n n Participa
Consulta
Prescrição
Medicamento

Entidade associativa (Agregação)

=
representa uma forma de promover um
relacionamento a uma Entidade. Assim, o
relacionamento pode se relacionar com outras
Entidades.

SIMBOLOGIA ADOTADA PELO DER
Entidade
Relacionamento
Atributo Atributo identificador
Entidade fraca Entidade associativa
Generalização/Especialização Cardinalidade mínima/máxima

(n,n)

EXERCÍCIO 1:
 Elaborar o MER completo.
“Os bancos resolveram informatizar o controle dos seus

clientes. Um banco possui várias agências e cada
agência pode conter múltiplas contas e empréstimos. Um
cliente pode possuir várias contas e pode também fazer
empréstimos. Dos Bancos, precisa-se saber qual o seu
número, localidade. Dos clientes, são importantes dados
como Nome, CPF, Endereço, se possuem dependentes
ou não, se é uma pessoa física ou jurídica. Dados de
contas, como saldo, número da conta e para os
empréstimos, quantidade de parcelas, vencimento entre
outros. ”
EXERCÍCIO 2:
Montar o MER.

SOLUÇÃO:

MODELO LÓGICO
 Definição
 É um modelo de dados que
representa a estrutura de dados de um
banco de dados conforme vista pelo
usuário do SGBD
 É dependente do tipo particular de SGBD que está
sendo utilizado;
 Lógico com Base em Registros
 Modelo Hierárquico
 Lógico com Base em Objetos
 Modelo Orientado a objeto
 Modelo Relacional
MODELO LÓGICO
 Modelo Lógico: ferramenta para

descrição de estruturas de dados em uma
forma passível de ser processada por um
SGBD;
 Nível de abstração mais baixo que
um Modelo Conceitual;
 Não considera aspectos físicos de
armazenamento, acesso e desempenho.

 Representa DADOS e RELACIONAMENTOS por um

conjunto de Tabelas (SGBD relacional);
No modelo lógico-relacional, deve-se definir quais
tabelas e campos farão parte do Banco de Dados;
As colunas de uma tabela são chamadas de atributos
e suas linhas de tuplas.
A importância do modelo relacional em nosso curso
deve-se ao fato de ser o modelo sobre o qual é baseada
a maioria dos SGBDs comerciais disponíveis hoje em
dia como (MySQL, FireBird e PostgreSQL, SQLServer,
DB2)
O MER é hoje a ferramenta mais usada em projetos

de banco de dados. Dizemos que o MER é um modelo
do nível conceitual, pois possui um forte poder
semântico, capaz de capturar conceitos do mundo real
com um mínimo de perdas semânticas, facilitando o
seu entendimento.
O modelo relacional é, por outro lado, um modelo do
nível lógico porque é utilizado para representação em
computador de conceitos do mundo real.

ABORDAGEM RELACIONAL

BANCO DE DADOS RELACIONAL
 É composto de tabelas ou relações.

 Linguagem acadêmica: relações;
 Na prática e no mercado: tabelas.
 Em nossas aulas iremos utilizar com

mais frequência a terminologia de mercado,
que é aquele tratado no mercado de
trabalho.

TABELAS (Relações)
 Conjunto não ordenado de linhas (tuplas, na

linguagem acadêmica);
 Cada linha é formada por um série de campos (valor

de atributo na linguagem acadêmica);
 O campo é identificado por um nome de campo

(nome de atributo na linguagem acadêmica);
O conjunto de campos homônimos de todas linhas de

uma tabela formam uma coluna.

=
Conjunto não ordenado de linhas (tuplas, na
linguagem acadêmica);

MODELO RELACIONAL
 Exemplo 1

MODELO RELACIONAL
 Exemplo 2

TABELAS x Sistema Convencional de arquivos
 As linhas de uma tabela não tem ordenação;
 Os valores de campo de uma tabela são

atômicos e monovalorados;
As linguagens de consulta a bases de dados

relacionais permitem acesso por quaisquer
critérios envolvendo os campos de uma ou mais
linhas.

CHAVES (Primária e Estrangeira)
O conceito básico para estabelecer relações

entre linhas de tabelas de um banco de dados
relacional;
 No modelo relacional consideramos 3 tipos de

chave
 a chave primária;
 a chave alternativa,
 a chave estrangeira.

CHAVE PRIMÁRIA
 Uma chave primária é uma coluna ou uma

combinação de colunas cujos valores distinguem
uma linha das demais dentro de uma tabela;
É uma Campo que identifica um registro como

único na tabela:
 Esse valor nunca pode se repetir;
 Este campo nunca pode ficar em branco.

CHAVE PRIMÁRIA
CHAVE PRIMÁRIA
=
É uma coluna ou uma combinação de colunas
cujos valores
distinguem uma linha das demais dentro de
uma
tabela

CHAVE PRIMÁRIA
 Exemplo

CHAVE PRIMÁRIA
A chave primária deve ser mínima:

 Uma chave é mínima quando todas suas colunas forem
efetivamente necessárias para garantir o requisito de
unicidade de valores da chave.
 Qualquer combinação de colunas que
contenha as colunas CódigoEmp e NoDepen é
uma chave primária.

CHAVE PRIMÁRIA
Na abordagem relacional, ao definir uma chave

primária, não está se definindo nenhum caminho
de acesso. Está se definindo apenas uma restrição
de integridade, isto é uma regra que deve ser
obedecida em todos estados válidos da BD;
No caso da chave primária, a regra é a de

unicidade de valores nas colunas que compõem
a chave.

CHAVE ESTRANGEIRA
 Uma chave estrangeira é uma coluna ou uma

combinação de colunas, cujos valores aparecem
necessariamente na chave primária de uma tabela;
 A chave estrangeira é o mecanismo que permite
a implementação de relacionamentos em um
banco de dados relacional.
CHAVE ESTRANGEIRA
=
coluna ou uma combinação de colunas, cujos
valores aparecem necessariamente na chave
primária de uma tabela.

CHAVE ESTRANGEIRA
 Exemplo 1

CHAVE ESTRANGEIRA
 Uma chave estrangeira é uma coluna ou uma

combinação de colunas, cujos valores aparecem
necessariamente na chave primária de uma tabela;
 A chave estrangeira é o mecanismo que permite
a implementação de relacionamentos em um
banco de dados relacional.
CHAVE ESTRANGEIRA
=
coluna ou uma combinação de colunas, cujos
valores aparecem necessariamente na chave
primária de uma tabela.

CHAVE ESTRANGEIRA
 Exemplo 2

CHAVE ESTRANGEIRA
A existência de uma chave estrangeira impõe restrições que

devem ser garantidas em diversas situações de alteração do
banco de dados:
 Quando da inclusão de uma linha na tabela que
contém a chave estrangeira: Neste caso, deve ser
garantido que o valor da chave estrangeira apareça na
coluna da chave primária referenciada.
 Quando da alteração do valor da chave
estrangeira: Deve ser garantido que o novo valor de uma
chave estrangeira apareça na coluna da chave primária
referenciada.
 Quando da exclusão de uma linha da tabela que
contém a chave primária referenciada pela chave
estrangeira: Deve ser garantido que na coluna chave
estrangeira não apareça o valor da chave primária que está
CHAVE ALTERNATIVA
Quando, em uma tabela, mais de uma coluna ou

combinações de colunas podem servir para
distinguir uma linha das demais, surge a questão
de que critério deve-se usar para determinar qual
das possíveis colunas (ou combinação de colunas)
será usada como chave primária.

DOMÍNIO E VALORES NULOS (VAZIOS)
 No modelo Relacional para cada coluna da tabela,

deve ser especificado um conjunto de valores
(alfanumérico, numérico,…) que os campos da
respectiva coluna podem assumir. Este conjunto
de valores é chamado de domínio da coluna ou
domínio do campo;
 No modelo Relacional deve ser especificado se

os campos da coluna podem estar vazios (“null”
em inglês) ou não. Estar vazio indica que o campo
não recebeu nenhum valor de seu domínio.
 Exemplo 1

As colunas nas quais não são admitidos valores vazios

são chamadas de colunas obrigatórias. As colunas nas
quais podem aparecer campos vazios são chamadas de
colunas opcionais;
 Os SGBD relacional exigem que todas colunas que
compõem a chave primária sejam obrigatórias. A
mesma exigência não é feita para a chave estrangeira.

RESTRIÇÕES DE INTEGRIDADE
 Um dos objetivos primordiais de um SGBD é a

integridade de dados.
 Os dados de um banco de dados
estão íntegros quando refletem
corretamente a realidade representada pelo
banco de dados e que são consistentes
entre si.
 Para tentar garantir a integridade de um banco

de dados os SGBD oferecem o mecanismo de
restrições de integridade.
=
uma regra de consistência de dados que é
garantida pelo próprio SGBD.

CATEGORIAS DE RESTRIÇÕES DE INTEGRIDADE
 Integridade de Domínio: o valor de um campo deve

obedecer a definição de valores admitidos para a
coluna (o domínio da coluna). Nos SGBD relacionais
comerciais, é possível usar apenas domínios pré-
definidos (número inteiro, número real, alfanumérico de
tamanho definido;
 Integridade de vazio: Neste tipo de restrição de

integridade é especificado se os campos de uma
coluna podem ou não ser vazios (se a coluna é
obrigatória ou opcional). Como já foi mencionado,
campos que compõem a chave primária sempre devem
ser diferentes de vazio.
CATEGORIAS DE RESTRIÇÕES DE INTEGRIDADE
 Integridade de chave:
 Trata-se da restrição que define que os valores
da chave primária e alternativa devem ser únicos.
 Integridade referencial
 É a restrição que define que os valores
dos campos que aparecem em uma chave
estrangeira devem aparecer na chave primária da
tabela referenciada.

ESPECIFICAÇÃO DE BANCO DE DADOS RELACIONAL
A especificação de um banco de dados relacional
(chamada de esquema do banco de dados) deve
conter no mínimo a definição do seguinte:
 Quais são as Tabelas que formam o
banco de dados;
 Quais são as Colunas que as tabelas
possuem;
 Quais as Restrições de integridade
existentes no banco de dados.
 Na prática, na definição de esquemas relacionais são

usadas diversas notações, que variam de um SGBD
para o outro.
REPRESENTAÇÃO DO MODELO LÓGICO
 Iremos utilizar uma notação resumida para modelos

lógicos relacionais em sala de aula;
Essa notação é incompleta mas compacta, que é útil

para exemplos mostrados em sala de aula, bem como
para discussões sobre a estrutura geral do banco de
dados, quando não se deseja entrar no maior nível de
detalhamento.

REPRESENTAÇÃO DO MODELO LÓGICO
NOTAÇÃO
Emp
(CodigoEmp,Nome,CodigoDepto,CategFuncional,CIC)
CodigoDept referencia Dept
Dept (CodigoDepto,Nome)
TRANSFORMAÇÕES
ENTRE
MODELOS

TRANSFORMAÇÕES ENTRE MODELOS
Modelo ER
(nível conceitual)
Engenharia reversa projeto lógico

de BD relacional de BD relacional
Modelo Relacional
(nível lógico)
VISÃO GERAL DO PROJETO LÓGICO
Modelo ER (nível conceitual)
conhecimento sobre Transformação ER

a aplicação para relacional
Refinamento do Modelo relacional

modelo relacional (nível lógico)

REGRAS DE TRANSFORMAÇÃO ER -> RELACIONAL
Objetivo das Regras
 Obter um banco de dados que permita boa performance

de instruções de consulta e alteração do banco de dados.
Obter boa performance significa basicamente diminuir o
número de acessos a disco, já que estes consomem o
maior tempo na execução de uma instrução de banco de
dados;
 Obter um banco de dados que simplifique o

desenvolvimento e a manutenção de aplicações.

IMPLEMENTAÇÃO DE ENTIDADES
1º Passo Mapeamento das Entidades Regulares (fortes)
 Cada Entidade é traduzida para uma Tabela;
 Cada Atributo da entidade define uma Coluna desta

tabela;
 Para cada atributo simples, incluir uma coluna na tabela;
 No caso de atributos compostos, incluir
somente seus atributos simples
Atributos identificadores da entidade correspondem

às colunas que compõem a chave primária da tabela;
EXEMPLO
Prim nome
telefone NumMed
Medico (NumMedico, PrimNome,
UltNome, Especialidade, Telefone,
nome Médico Endereco)
Endereco
Ult nome Especialidade
Trata-se de uma tradução inicial. Pelas próximas regras, as tabelas

definidas nesta etapa ainda poderão ser fundidas, no caso de
algumas alternativas de implementação de relacionamentos 1:1 e
hierarquias de generalização/especialização.
OBSERVAÇÕES
Não é aconselhável simplesmente transcrever os nomes
de atributos para nomes de colunas;
No SGBD relacional, o nome de uma coluna não pode
conter brancos. Assim, nomes de atributos compostos de
diversas palavras devem ser abreviados.
 Os nomes de atributos Prim nome e Ult nome foram
traduzidos para os nomes de colunas PrimNome e UltNome
respectivamente.
 Não é recomendado incluir no nome de uma coluna o
nome da tabela em que ela aparece;
 Exceção: nome coluna chave primária.
2º Passo Mapeamento das Entidades Fracas
 Criar uma Tabela para cada tipo de entidade fraca;
 Inserir como chave estrangeira dessa Tabela, os
atributos que são chaves primárias da entidade forte;
A chave primária dessa Tabela é a combinação das
chaves primárias das Entidades Fortes e da chave
parcial;
 As chaves primárias vindas das
entidades fortes são chaves estrangeiras nessa
Tabela.

EXEMPLO
NumPac
Endereco nome
Paciente (NumPac, Nome, Endereco)
Paciente
1,1
possui
0,N
Dependente
Dependente (NumPac, NumDepe,
Numdepe Nome)
Nome
NumPac referencia Paciente

IMPLEMENTAÇÃO DE RELACIONAMENTOS
O fator determinante para a tradução a adotar no caso de

relacionamentos é a cardinalidade mínima e máxima das
entidades que participam do relacionamento;
 São três as formas básicas de tradução de
relacionamentos para o modelo relacional:
 Tabela Própria;
 Adição de colunas nas tabelas;
 Fusão de Tabelas de Entidades.
 Depois das três formas básicas, será detalhada as
alternativas para cada tipo de relacionamento.

TABELA PRÓPRIA
 Nesta tradução, o relacionamento é implementado
através de uma tabela própria.
 Esta tabela contém as seguintes colunas:
 colunas correspondentes aos
identificadores das entidades relacionadas;
 colunas correspondentes aos
atributos do relacionamento.
A chave primária desta tabela é o conjunto das
colunas correspondentes aos identificadores das
entidades relacionadas.
EXEMPLO: TABELA PRÓPRIA
Engenheiro (CodEng, Nome)

Projeto (CodProj, Titulo)
Atuação (CodEng,CodProj,Funcao)
CodEng referencia Engenheiro
CodProj referencia Projeto
ADIÇÃO DE COLUNAS
Esse tipo de tradução somente é possível quando uma
das entidades que participa do relacionamento tem
cardinalidade máxima um;
A tradução consta em inserir na tabela correspondente
à entidade com cardinalidade máxima 1 as seguintes
colunas;
 Colunas correspondentes ao identificador da
entidade relacionada; estas colunas formam uma chave
estrangeira em relação à tabela que implementa a entidade
relacionada;
 Colunas correspondentes aos atributos do relacionamento.

EXEMPLO: ADIÇÃO DE COLUNAS
Departamento (CodDept, Nome)

Empregado (CodEmp, Nome, CodDept,DataLota)
Atuação (CodEng,CodProj,Funcao)
CodDept referencia Departamento

FUSÃO DE TABELAS DE ENTIDADES
 Esta tradução somente pode ser aplicada quando o
relacionamento é de tipo 1:1.
A tradução consta de implementar todos atributos de

ambas entidades, bem como os atributos do
relacionamento em uma única entidade.

EXEMPLO: FUSÃO DE TABELAS DE ENTIDADES
Conferencia (CodConf, Nome, DataInstComOrg,

EnderComOrg)

DETALHES DA IMPLEMENTAÇÃO DE RELACIONAMENTOS
A regra específica que deve ser usada na tradução de um
relacionamento é determinada pelas cardinalidades mínima
e máxima das entidades envolvidas;

DETALHES DA IMPLEMENTAÇÃO DE RELACIONAMENTOS

RELACIONAMENTOS 1 X 1 (Ambas Opcionais 0,0)
 Pela Regra: Adição de Colunas.
Mulher (IdentM,Nom, IdentH, Data, Regime)

IdentH referencia Homem
Homem (IdentH, Nome)

RELACIONAMENTOS 1 X 1 (Algum Obrigatório)
 Pela Regra: Fusão de Tabelas.
Correntista (CodCorrent, Nome, CodCartao, DataExp)

RELACIONAMENTOS 1 X N
 Pela Regra: Adição de Colunas.
Inserirna tabela do lado N, como chave estrangeira, a
chave primária da tabela do lado 1.
Plano
NumPlano
0,1
Plano (NumPlano, Nome)
nome
Tem
Paciente (NumPac, Nome,NumPlano)
NumPac nome NumPlano referencia Plano
0,N
Paciente

RELACIONAMENTOS N X N
 Pela Regra: Criação de Tabela;
Inserir como chave estrangeira da Tabela, as chaves
primárias das relações. A concatenação delas formará a
chave primária da Tabela.
Engenheiro Atuação Projeto
(0,n) (0,n)
Cod Nome Função Numero Descrição
Engenheiro (CodEng, Nome) Projeto (NumProj, Descricao)

AtuaProjeto (CodEng, NumProj, Funcao)
CodEng referencia Engenheiro
NumProj referencia Projeto

RELACIONAMENTO DE GRAU MAIOR QUE DOIS
 As regras anteriores apresentadas, aplicam-se
somente à implementação de relacionamentos
binários, isto é, que envolvem apenas duas entidades;
 Seguem-se dois passos para sua implementação :
1. O relacionamento é transformado em uma
entidade. Esta nova entidade é ligado através de um
relacionamento binário a cada uma das entidades que
participavam do relacionamentos original;
2. Aplica-se as regras de implementação de entidades e
relacionamentos binários apresentadas às entidades e
aos relacionamentos binários assim criados.

RELACIONAMENTO DE GRAU MAIOR QUE DOIS
Distribuicao
Produto (CodProd,Nome)
(CodProd,CodDistr,CodCid,DataInic)
Cidade (CodCid,Nome)
Distribuidor (CodDistr,Nome) CodProd referencia Produto
CodDistr referencia Distribuidor
CodCid referencia Cidade
IMPLEMENTAÇÃO DE GENERALIZAÇÃO/ESPECIALIZAÇÃO
Uma tabela por entidade especializada
 Criar uma tabela para cada entidade que

compõe a hierarquia, aplicando as regras
correspondentes à implementação de entidades e
relacionamentos já apresentadas nas seções
anteriores;
 O único acréscimo que deve ser feito
àquelas regras é a inclusão da chave primária
da tabela correspondente à entidade genérica.,
em cada tabela correspondente a uma
entidade especializada.
IMPLEMENTAÇÃO DE GENERALIZAÇÃO/ESPECIALIZAÇÃO
Emp (CodEmp,Tipo,Nome,CIC,Codpt)
CodDept referencia Depto
Motorista (CodEmp, CartHabil)
CodEmp referencia Emp
Engenheiro (CodEmp,CREA,CodRamo)
CodRamo referencia Ramo
Depto (CodDept, Nome)
Ramo (CodRamo,Nome)
ProcessTexto
(CodProc,Nome) Domínio
(CodEmp,CódigoProc)
CodProc referencia ProcessTexto
Projeto (CodProj,Nome)
Participação (CodEmp,CodProj)
Professor: Rogério Lopes CodProj referencia Projeto
IMPLEMENTAÇÃO DE ATRIBUTOS MULTIVALORADOS
Cliente (CodCli, Nome)

Telefone (CodCli,Numero)
CodClie referencia Cliente

EXERCÍCIOS DE TRANSFORMAÇÃO ENTRE MODELOS
1) Desenvolva o modelo Lógico




4) Desenvolva o modelo Lógico ATRIBUTOS:
EMPREGADO = Código,
Nome, Tipo de
empregado, CPF
DEPARTAMENTO =
Código, Nome
SECRETÁRIA =
habilitação linguística
MOTORISTA = carteira
de habilitação
ENGENHEIRO = CREA
PROCESSADOR DE
TEXTO = Código, Nome
RAMO DA
ENGENHARIA =
Código, Nome
PROJETO = Código,
Nome
NORMALIZAÇÃO

DEPENDÊNCIA FUNCIONAL
 Conceito importante para entendimento de Normalização;

 Uma dependência funcional é um relacionamento muitos
para um entre dois conjuntos de atributos de uma
determinada relação R;
 Ela é uma espécie particularmente comum e importante de
restrição de integridade;
 Sejam os seguintes subconjuntos de atributos de um
esquema T: A = (A1, A2, ..., An) e B = (B1, B2, ..., Bn)
 Dizemos que B é dependente funcionalmente de um outro
atributo A contido em T se a cada valor de A existir nas
linhas da relação T, em que aparece, um único valor de B.
Notação: A -> B

DEPENDÊNCIA FUNCIONAL
 Em uma tabela relacional, diz-se que uma coluna C2
depende funcionalmente de uma coluna C1 (ou que a
coluna C1 determina a coluna C2) quando, em todas
linhas da tabela, para cada valor de C1 que aparece
na tabela, aparece o mesmo valor de C2.

PROPRIEDADES FUNCIONAIS DAS DEPENDÊNCIAS
Propriedade da SEPARAÇÂO
 A -> BC então A -> B e A -> C
Exemplo:
 CPF -> nome, endereço então CPF -> nome e CPF ->
endereço
 Leia o exemplo acima da seguinte maneira:
 Se com um número de CPF eu encontro o nome e o
endereço de uma pessoa, então com este mesmo
número eu posso encontrar apenas o nome e com
este mesmo número eu posso encontrar apenas o
endereço.

Propriedade da ACUMULAÇÃO
 A -> B então AC -> B
Exemplo:
 CPF -> endereço então CPF, idade -> endereço
 Leia o exemplo acima da seguinte maneira:
 Se com um número de CPF eu encontro o endereço
de uma pessoa, então com este mesmo número
mais a idade da pessoa eu posso encontrar o
endereço também.

Propriedade da TRANSITIVIDADE
 A -> B e B -> C então A -> C
Exemplo:
CPF -> código-cidade e código-cidade -> nome-cidade
então CPF -> nome-cidade
Leia o exemplo acima da seguinte maneira:
 Se com um número de CPF eu encontro o
código da cidade de uma pessoa, e com o código da
cidade eu encontro o nome da cidade, então com o
número do CPF eu posso encontrar o nome da
cidade.
NORMALIZAÇÃO
Considere o seguinte esquema de um

BD: Pacientes (Id, Nome, Endereço, Telefone, Sexo,
Dta_nasc, Sig_conv, Nom_conv, End_convênio)
Esse é um exemplo de mau projeto!

Os dados de pacientes e os de convênios não deveriam
estar na mesma tabela.
Os dados de um convênio (nome, endereço e telefone do

convênio) são repetidos para cada paciente associado a esse
convênio. Por exemplo, os dados CASSI serão repetidos
para cada associado
NORMALIZAÇÃO
Certas DFs causam redundância!

 Para cada associado de um convênio, os dados do
convênio são repetidos na tabela Pacientes. A causa
desse problema é a DF;
 Se uma relação estiver numa certa forma normal (FNBC
ou
3FN), os problemas são evitados ou minimizados;
 As formas normais são definidas em termos de
dependências funcionais.
 Elas nos fornecem critérios para decidir o esquema
de uma relação deve ser decomposto em sub-
esquemas ou não.
 Existem várias formas normais: 2FN, 3FN, FNBC, 4FN.
 Estudaremos as que têm importância prática -> 3FN.
NORMALIZAÇÃO
 Conjunto de Normas (ou Formas Normatizadas)

que representam restrições às quais uma Relação
deve atender.
 Estas normas são definidas com base nas chaves

das relações e nas dependências funcionais entre
seus atributos.
 O processo consiste em projetar relações normalizadas

a partir de um conjunto de relações não normalizadas
até que sejam eliminadas as possibilidades de
anomalias de atualização.

NORMALIZAÇÃO
 Processo de substituição de um conjunto de entidades e

relacionamentos por outro, o qual se apresenta
"purificado" em relação às anomalias as quais podem
causar certos problemas, tais como:
 grupos repetitivos (atributos multivalorados) de dados;
 variação temporal de certos atributos, dependências
funcionais totais ou parciais em relação a uma
chave concatenada;
 redundâncias de dados desnecessárias;
 perdas acidentais de informação;
 dificuldade na representação de fatos da realidade
observada;
 dependências transitivas entre atributos.
NORMALIZAÇÃO
Definição:
 Técnica que permite depurar um projeto de banco de
dados, através da identificação de inconsistências
(informações em duplicidade, dependências funcionais
mal resolvidas, etc).
Porque normalizar?
 À medida que um conjunto de relações passa para uma
forma normal, vamos construindo um banco de dados
mais confiável;
 O objetivo da normalização não é eliminar todos
as inconsistências, e sim controlá-las.

NORMALIZAÇÃO – ANOMALIAS DE BD DESNORMALIZADO
 Anomalia de inserção
 Quando se inserir um paciente é preciso inserir
também os dados do convênio, mesmo que já estejam
cadastrados.
 Não é possível inserir um convênio sem inserir
também um paciente.
 Anomalia de exclusão
 Ao se excluir um paciente, se este for o único
associado de um convênio então os dados do
convênio serão perdidos.
 Anomalia de modificação
 Para se modificar os dados de um convênio, é
preciso atualizar os mesmos dados em todas as
tuplas
NORMALIZAÇÃO
Porque Normalizar?

NORMALIZAÇÃO
Porque Normalizar?
O Órgão compras
será excluído também
NORMALIZAÇÃO
Porque Normalizar?
Deverão ser alteradas todas as

ocorrências de Desenvolvimento
NORMALIZAÇÃO
Porque Normalizar?
Deverá ser acrescentado um funcionário no campo “Qt.

FUN” em todas as ocorrências com “DESENVOLVIMENTO
1ª FORMA NORMAL – 1FN
 Uma relação está na 1FN se, e somente se, todos os

seus atributos contêm apenas valores atômicos (simples,
indivisíveis) e não contém tabelas aninhadas;
 Atributos multivalorados ou compostos (estruturas

de dados) devem ser eliminados, assim como
tabelas aninhadas;
 Quando encontrarmos um atributo multivalorado, deve-

se criar um novo atributo que individualize a
informação que esta multivalorada:
 Quando encontrarmos um atributo não atômico,
deve- se dividi-lo em outros atributos que sejam
atômicos:
 Quando encontrarmos um atributo multivalorado, deve-se criar
um novo atributo que individualize a informação que esta
multivalorada:
 BOLETIM (matricula-aluno, materia, notas)
 No caso acima, cada nota seria individualizada identificando
a prova a qual aquela nota se refere:
 BOLETIM (matricula-aluno, materia, numero-prova,
nota)
 Quando encontrarmos um atributo não atômico, deve-se dividi-
lo
em outros atributos que sejam atômicos:
 PESSOA (CPF, nome-completo)
 Vamos supor que, para a aplicação que utilizará esta
relação, o atributo nome-completo não é atômico, a solução
então será:
 Quando encontrarmos uma tabela aninhada, devemos construir
uma tabela referente a própria tabela que está sendo
normalizada e uma tabela para cada tabela aninhada.
Exemplo:
 Proj (CodProj, Tipo, Descr, (CodEmp, Nome, Cat, Sal,
DataIni, TempAl)) ;
 Proj (CodProj, Tipo, Descr)
 ProjEmp (CodProj,CodEmp, Nome, Cat, Sal,
DataIni,
TempAl)

Outro Exemplo

 Uma Relação está em 2ª Forma Normal se, e somente

se, estiver em 1ª FN e todos os atributos não chave são
TOTALMENTE dependentes da chave primária.
 Logo, duas condições são obrigatórias:

 A relação estiver na primeira forma normal;
 Todos os atributos não chaves dependerem
funcionalmente da totalidade da chave primária, ou
seja, não pode ser dependente de apenas parte da
chave.

 A relação abaixo atende a 2FN?

 CONSULTAS (IdPaciente, IdMédico, Data, Hora,
NomePaciente, NomeMédico, CRMMédico)
 Dependências Funcionais:
 {IdPaciente, IdMédico} -> {Data, Hora}
 {IdPaciente} -> {NomePaciente}
 {IdMédico} -> {NomeMédico, CRMmédico}
 A relação Consultas não está bem projetada, misturando

conceitos diversos, i.e. Pacientes, Médicos e Consultas.

2ª Forma Normal
=
uma tabela encontra-se na Segunda Forma Normal,
quando, além de estar na 1FN, não contém
dependências parciais.

 Como colocar a relação Consultas em 2 FN?

 Fazendo a pergunta: Este campo depende de toda a chave?
Se não, temos uma dependência parcial
 CONSULTAS (IdPaciente, IdMédico, Data, Hora,
NomePaciente, NomeMédico, CRMMédico)
 Tratar cada conceito em uma relação:
 Pacientes (IdPaciente, NomePaciente)
 Médicos (IdMedico, NomeMedico, CRMMedico)
 Consultas (IdPaciente, IdMedico, Data, Hora)
 O nome das Relações deve ser escolhido de acordo com a
chave
 As relações encontram-se na 2FN e todos os atributos
dependem funcionalmente de toda a chave primária!!
Exemplo:

 Analogamente à 2FN, a 3FN exige que a primeira e segunda

forma estejam satisfeitas.
 A 3FN trabalha com intuito de evitar a existência de

dependência transitiva, ou seja, evitar que um atributo não
chave dependa funcionalmente (esteja relacionado) de outro
atributo não chave;
 Logo, 3FN = 2FN + atributos não chaves

mutuamente independentes.

 Um jeito de verificar esta norma é refazer a leitura dos

campos fazendo a pergunta: Este campo depende de outro
que não seja a chave? Se Sim, temos uma dependência
transitiva.
Exemplo: empregado (RG, nomeE,numD,nomeD)
 F={RG ->{nomeE,numD}; numD -> nomeD}
 Está na 1FN: não existe atributo composto ou
multivalorado;
 Está na 2FN: a chave só possui um atributo, não é
possível haver dependência parcial da chave;
 Não está na 3FN: RG ->numD e numD ->nomeD e
numD
é não primo;
 Como normalizar?

Exempo:
 Pacientes (Id, Nome, Identidade, Telefone, Sexo, SiglaConvênio,
NomeConvênio, TelefoneConvênio)
 As dependências funcionais são:
 {Id} -> {Nome, Identidade, Telefone, Sexo, SiglaConvênio}
 {SiglaConvênio} -> {NomeConvênio, TelefoneConvênio}
Como colocar na 3FN?

 Separar os conceitos de acordo com as dependências identificadas:
 Pacientes (Id, Nome, Identidade, Telefone, Sexo,
SiglaConvênio)
 Convênios (SiglaConvênio, NomeConvênio,
TelefoneConvênio)

NORMALIZAÇÃO
Resumo


Modelagem de BD - Parte7 - MER Entidade

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelagem de BD - Parte7 - MER Entidade

Enviado por

Direitos autorais:

Formatos disponíveis

MODELO DE DADOS

Modelo é a representação abstrata e simplificada de

“Conjunto de ferramentas conceituais usadas

Professor: Rogério Lopes

Para construir um modelo de dados, usa-se uma

Um mesmo modelo pode ser apresentado em

Cada apresentação do modelo é chamado de

Professor: Rogério Lopes

 A técnica mais utilizada é a abordagem Entidade-

 A representação é feita através de um diagrama,

Professor: Rogério Lopes

Professor: Rogério Lopes

Tarciso 505 A Gama Valmer 204 C Paranoá Cesar 713 B Ceilândia

3B4 20,00 5B2 52,25 2C3 100,00 8A1 5,00

 Exemplo: Adabas da SoftwareAG

 Representa DADOS e RELACIONAMENTOS por um

Professor: Rogério Lopes

Modelo Entidade Relacionamento

Professor: Rogério Lopes

Professor: Rogério Lopes

O MER é hoje a ferramenta mais usada em projetos

Professor: Rogério Lopes

Professor: Rogério Lopes

 "Um modelo conceitual ( o Modelo Entidade

O modelo Entidade-Relacionamento (MER) tem por

Professor: Rogério Lopes

O modelo ER é chamado de Modelagem

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

Conta Corrente Cliente

Professor: Rogério Lopes

 ENTIDADES DEPENDENTES (FRACAS)

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

DEPARTAMENTO Lotação Pessoa

um conjunto de objetos classificados como pessoas

Cliente Possui Conta Corrente

Empregado Trabalha Departamento

Professor: Rogério Lopes

C1,CC1 C2, CC2

CC1 CC2 CC3 Contas Corrente

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

Professor: Rogério Lopes

cardinalidade (mínima, máxima) de entidade

Professor: Rogério Lopes

Empregado Lotação Departamento

Professor: Rogério Lopes

Empregado Lotação Departamento

 Logo, duas cardinalidades são relevantes:

Professor: Rogério Lopes

Empregado Lotação Departamento

Professor: Rogério Lopes

Funcionário Possui Armário

Professor: Rogério Lopes

Aluno Inscrição Curso