Banco de Dados - Teoria

Prévia do material em texto

Banco de Dados 1
Banco de Dados
UNIP
Prof. Wagner
Modelagem de Dados 2
Parte 1 
Características e 
arquitetura de um SGBD
3
A abordagem tradicional
SISTEMA 1
Dados Exclusivos
Do Sistema 1
SISTEMA 1 SISTEMA 1
Dados Exclusivos
Do Sistema 2
SISTEMA 2
 Cada sistema define e controla seus próprios dados
 Redundâncias de dados entre sistemas
 Ausência de integração entre os sistemas
4
A abordagem com Banco de Dados
SISTEMA 1 SISTEMA 2
SGBD
Processador de consultas
Gerenciador de transações
 ...
Base de Dados
Integrada
SGBD
Sistema Gerenciador
De Banco de Dados
 Os dados de todos 
os sistemas ficam na 
mesma base de 
dados, que é 
compartilhada
 A única forma de ter 
acesso aos dados é 
através do SGBD
5
O que é um Banco de Dados?
 Uma grande coleção integrada de dados
 Modelos do mundo real 
 Entidades (ex. estudantes, cursos)
Relacionamentos (ex. Madonna está cursando CS564)
Um Sistema Gerenciador de Banco 
de Dados (SGBD) é um software 
construído com a função específica de 
guardar e gerenciar um banco de 
dados
Um Sistema Gerenciador de Banco 
de Dados (SGBD) é um software 
construído com a função específica de 
guardar e gerenciar um banco de 
dados
6
Porque usar um SGBD?
 Os dados constituem um bem para a organização 
e requerem controle integrado
 Acesso independente e eficiente a dados
 Redução no tempo de desenvolvimento das 
aplicações
 Integridade e segurança dos dados
 Administração uniforme dos dados
 Acesso concorrente (compartilhamento)
 Recuperação de “crashes”
 Produtividade para o programador
 Independência dos dados
7
Funções Básicas dos SGBDs
 Definição do Esquema integrado dos dados
DDL – Data Definition Language
Dicionário de Dados
 Contém a definição de todos os objetos do Banco de Dados
 Armazenado no próprio Banco de Dados
 Acesso e Manutenção dos Dados
DML – Data Manipulation Language
 Incluir novos dados
 Excluir dados existentes
 Alterar dados existentes
Consultar (recuperar) dados 
8
Características dos SGBDs
 Independência dos dados:
 Aplicações isoladas da maneira que os dados são 
estruturados e armazenados
 Invisibilidade ou transparência dos detalhes para o 
usuário (organização, estrutura de armazenamento e 
estratégia de acesso)
 Transparência da estratégia lógica de acesso
 Transparência da organização física do armazenamento e 
acesso
Uma mudança na estrutura dos dados não afeta 
programas ou sistemas que não utilizam a estrutura 
modificada
9
Características dos SGBDs
 Esquema integrado
Usuários têm uma visão uniforme dos dados
Usuários vêem apenas relações no modelo relacional
 Integridade declarativa e garantia de consistência
 1.000 ≤ Salário ≤ 10.000 
Nenhum empregado pode ter um salário maior que 
seu/sua gerente
O usuário especifica a regra e o sistema a garante
 Visões individualizadas
Restrições a certas relações
Reorganização das relações por certas classes de 
usuários
10
Características dos SGBDs
 Acesso declarativo
 Linguagem de consulta – SQL
 Esquemas são definidos usando uma DDL
Dados são modificados/consultados usando uma DML
 O sistema determina a execução
 Processador de consultas e otimizador
 Controle de concorrência
11
Controle de concorrência
 Controle da concorrência de processos é essencial 
para uma boa performance do SGBD
 Acessos a discos são freqüentes e lentos, é importante 
deixar a CPU alocada a diversos processos 
concorrentemente
 Executar ações de diferentes processos poderia 
levar a contradições
 Ex.: o cheque compensado enquanto é feito um depósito 
ou um saque na mesma conta corrente
 O SGBD evita tais problemas: cada usuário pode 
atuar como se fosse o único usuário do sistema
12
Controle de Transações
 Execução das solicitações do usuário como uma 
seqüência atômica de ações no BD (unidade de 
leituras/gravações)
 Pode conter uma ou múltiplas operações
 Cada transação, executada completamente, deve 
deixar o BD em um estado consistente (se o BD é 
consistente quando a transação começa)
Usuários podem especificar alguma restrições
O SGBD não entende a semântica dos dados
13
Transações
 Transparência na concorrência:
Múltiplos usuários podem acessar o banco de dados, 
porém com uma visão pessoal
Controle de concorrência
 Transparência nas falhas:
Mesmo que ocorra uma falha, a consistência da base de 
dados é garantida
Mecanismos de logging e recuperação
14
Propriedades das transações
 Atomicidade:
 Propriedade tudo-ou-nada
 Consistência:
Cada transação está correta e não viola a consistência 
da base de dados
 Isolamento:
 Transações concorrentes não interferem umas com as 
outras
 Durabilidade:
Uma vez que a transação completa seu trabalho 
(commit), seus efeitos têm garantia de serem refletidos 
no banco independente do que possa ocorrer
15
Assegurando a Integridade do BD
 O SGBD assegura a Integridade Física e Lógica do BD
 Registra um Log (história) de todas as ações realizadas
 LOG: imagem (cópia fiel) do que mudou no BD
 Inserir: imagem depois
 Excluir: imagem antes
 Alterar: imagem antes e depois
 Antes da mudança ser feita no BD é feito o registro no LOG
 Log é seguro e freqüentemente duplicado
 Todas as atividades relacionadas ao log são gerenciadas 
transparentemente pelo SGBD
 Em caso de um problema com o BD, os efeitos das 
transações parcialmente executadas são desfeitos usando 
o log, garantindo a integridade do BD
16
Estrutura do sistema
indexes
data files
catalog
Query Evaluation Engine
File & Access
 Methods
Buffer Manager
Disk Space Manager
R
ec
ov
er
y 
M
an
ag
er DDLCompilerTransaction
&
Lock
Manager
SGBD
Forms
Application
Front ends
DML/CLI 
interface DDL
DBAPGMsusers
SQL commands
17
Mecanismos de recuperação
 Backups
 Logs
 Recuperação na inicialização do sistema 
(redo/undo)
 Recuperação em caso de “crash” do BD
Reconstrói o BD vazio
Recupera o Backup (recover) – recria o BD até o 
momento do Backup
 Aplica todas as Transações registradas como bem 
sucedidas no Log
18
Tipos de SGBDs
 Hierárquico
 Década 1960 (IBM IMS/DB ainda em uso)
 Representação de dados de forma hierárquica (pai-filho)
 Apontadores armazenados fisicamente junto com os dados
 Em Redes
 Padrão estabelecido por grupo de normatização (CODASYL) 1969
 Representação de dados em redes
 Apontadores armazenados fisicamente junto com os dados
 Relacional
 Proposta teórica: 1970 – E.F.Codd
 Primeiras implementações – década 1980
 Dados organizados em tabelas
 Não agrega apontadores para relacionar dados
Banco de Dados 19
Parte 2 - Modelo 
Entidade-Relacionamento
Conceitos
20
O Projeto do BD
 O projeto de um novo BD dá-se em duas fases:
1. Modelagem Conceitual: o modelo conceitual é 
construído na forma de um diagrama entidade-
relacionamento
2. Projeto Lógico: define como o banco de dados 
será implementado em um SGBD específico. A 
forma mais usual é a adoção do modelo relacional, 
com o refinamento do esquema (normalização) 
para redundâncias e anomalias de atualização
21
A Abordagem Entidade-Relacionamento
 A abordagem ER foi criada em 1976 por Peter 
Chen
 Nesta abordagem:
 o modelo de dados é representado através de um 
modelo entidade-relacionamento (Modelo ER ou MER)
 o modelo ER é representado graficamente através de 
um diagrama entidade-relacionamento (DER)
22
Entidade
 O conceito fundamental da abordagem ER é o 
conceito de entidade
ENTIDADE
=
conjunto de objetos da realidade 
modelada sobre os quais 
deseja-semanter informações no 
banco de dados
23
Entidade
 Alguns exemplos de entidades: 
produtos, tipos de produtos, vendas, compras 
em um sistema de informações industrial
clientes, contas correntes, cheques e agências 
em um sistema de contas correntes de um 
banco
 Uma entidade pode representar tanto objetos 
concretos da realidade (pessoas, automóveis) 
quando objetos abstratos (departamentos, contas a 
pagar)
24
 Em um DER, uma entidade é representada através de um 
retângulo que contém o nome da entidade.
 Exemplos:
 Pessoa: designa o conjunto de todas as pessoas sobre as quais se 
deseja manter informações no banco de dados
 Departamento: designa o conjunto de todas os departamentos sobre 
os quais se deseja manter informações no banco de dados
Entidade
Pessoa Departamento
25
Atributos
 Entidade: Pessoa
Atributos: Nome, Endereço, Data de Nascimento, RG, CPF
 Entidade: Departamento
Atributos: Código do Departamento, Nome, Gerente
ATRIBUTOS
=
Propriedades ou características que definem 
uma Entidade
26
Ocorrências de uma Entidade
 Ocorrência de uma Entidade é um objeto particular do tipo da Entidade
 Cada ocorrência possui valor para cada um dos Atributos da Entidade
 Objetos diferentes no mundo real são representados por ocorrências diferentes na 
Entidade
 No exemplo abaixo, ocorrências da Entidade Empregado
Empregado
-4.000SoaresE1
C23.000SilvaE2
C55.200SantosE3
C52.300SouzaE5
Categ 
FuncionalSalárioNomeCódigo
27
Identificador de uma Entidade
 Cada Entidade possui um Atributo ou um conjunto de Atributos que identifica de forma 
única cada uma de suas ocorrências
 Identificador de uma Entidade é um Atributo ou um conjunto de Atributos que identifica de 
forma única cada ocorrência de uma Entidade e é mínimo com essa característica
 Identificador da Entidade Empregado: Código (é obrigatoriamente diferente para cada 
Empregado
Empregado
-4.000SoaresE1
C23.000SilvaE2
C55.200SantosE3
C52.300SouzaE5
Categ 
FuncionalSalárioNomeCódigo
28
Atributos
 São representados conforme diagrama 
abaixo:
 Na prática, atributos não são representados 
graficamente, para não sobrecarregar os diagramas. 
Pode-se utilizar uma representação textual dos 
atributos
PROJETO
nome
código
tipo
29
Atributos
 Simples
 Não dividido em partes
 Compostos
 Divididos em partes (outros atributos)
CLIENTE
nome
código
endereço
Endereço pode ser dividido em:
• Rua
• Número
• Complemento
• Cidade
• Estado
• CEP
30
Atributos
 Monovalorados
 Valor único (para a entidade)
 Multivalorados
 Conjunto de valores (para a entidade)
 Cardinalidade
CLIENTE
nome
código
telefone (0,n)
31
Atributos
 Nulos
 Entidade não possui valor para o atributo
 “não é aplicável”
 “desconhecido”
 Derivados
 Derivado de outros atributos ou entidades
FUNCIONÁRIO
nome
código
data contratação
tempo de casa
qtd dependentes
32
Relacionamento
 Associação entre ocorrências de Entidades
RELACIONAMENTO
=
conjunto de associações 
entre entidades
33
EmpregadoDepartamento Lotação
Relacionamento
 Em um DER, um relacionamento é representado 
através de um losango ligado, por linhas, aos 
retângulos que representam as entidades que 
participam do relacionamento
 Exemplos:
CursoAluno Matrícula
34
Relacionamento
 Cada ocorrência de um relacionamento associa 1 ocorrência de uma 
das Entidades relacionadas com 1 ocorrência da outra Entidade
Funcionário
Código do Funcionário Nome Cargo Data de Nascimento Salário
1001 José Silva Vendedor 15/1/1980 R$ 3.200,00
1002 José Oliveira Operador Maq 20/5/1974 R$ 1.800,00
1003 Maria Silva Telefonista 22/7/1982 R$ 950,00
Projeto
Código do Projeto Nome do Projeto
P01 Novo Sistema de Compras
P02 Correção Sistema Comercial
P03 Banco de Dados de Clientes
Alocação
Código do Funcionário Código do Projeto
1001 P02
1002 P02
1003 P01
ProjetoFuncionário Alocação
35
Cardinalidade de Relacionamentos
 É a propriedade que indica quantas ocorrências de 
uma entidade podem estar associadas a uma 
determinada ocorrência através do relacionamento.
 Há duas cardinalidades a considerar:
cardinalidade máxima
e
cardinalidade mínima
36
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
37
Cardinalidade de Relacionamentos
DEPARTAMENTO EMPREGADOLOTAÇÃO1 n
Expressa que a uma ocorrência de 
EMPREGADO (entidade do lado 
oposto da anotação) pode estar 
associada ao máximo uma (“1”) 
ocorrência de DEPARTAMENTO
Expressa que a uma ocorrência de 
DEPARTAMENTO (entidade do lado 
oposto da anotação) podem estar 
associadas ao máximo muitas (“n”) 
ocorrências de EMPREGADO
38
Classificação de relacionamentos binários
 A cardinalidade máxima pode ser usada para 
classificar relacionamentos binários 
(relacionamentos cujas ocorrências contém duas 
ocorrências da entidade)
 Os relacionamentos binários podem ser 
classificados em:
 n:n - muitos-para-muitos
 1:n - um-para-muitos
 1:1 - um-para-um
39
Classificação de relacionamentos binários
 Exemplos: relacionamentos 1:1
EMPREGADO
MESA
ALOCAÇÃO
1
1
PESSOA
CASAMENTO
 marido esposa
1 1
(Relacionamento binário que
envolve apenas uma 
entidade) 
40
Classificação de relacionamentos 
binários
 Exemplos: relacionamentos 1:n
CURSOINSCRIÇÃO
n 1
ALUNO
DEPENDENTE
1 n
EMPREGADO
EMPREGADO
SUPERVISÃO
supervisor supervisionado
1 n
41
Classificação de relacionamentos 
binários
 Exemplos: relacionamentos n:n
PACIENTECONSULTA
n n
MÉDICO
PROJETOALOCAÇÃO
n n
ENGENHEIRO
FORNECEDORCAPACIDADE
n n
PEÇA
PRODUTO
COMPOSIÇÃO
composto componente
n n
42
Cardinalidade Mínima
 Representa o número mínimo de ocorrências de 
entidade que são associadas a uma ocorrência de 
uma entidade através de um relacionamento
 Para o projeto de BD considera-se apenas as 
cardinalidades mínimas 0 e 1
43
Cardinalidade Mínima
 A cardinalidade mínima 1 também é chamada de 
“associação obrigatória”, pois indica que o 
relacionamento deve obrigatoriamente associar 
uma ocorrência de entidade a cada ocorrência da 
entidade em questão
 A cardinalidade mínima 0, seguindo o mesmo 
raciocínio, recebe a denominação de “associação 
opcional” 
44
Cardinalidade Mínima
 Exemplo:
e1
e2
e3
e4
e1,m1
e2,m2
e3,m6
e4,m4
m1 m6 m4m2
m5
m3
ALOCAÇÃO
(1,1)
EMPREGADO
MESA
(0,1)
Cada empregado dever ter a ele alocada obrigatoriamente uma mesa 
(cardinalidade mínima 1) e que uma mesa pode existir sem que a ela esteja 
alocado um funcionário (cardinalidade mínima 0)
45
Ex. de uso de entidades e relacionamentos
DER para o controle acadêmico de uma universidade:
RESPONSÁVEL
(1,1)
DEPARTAMENTO DISCIPLINA
(0,n)
INSCRIÇÃO(0,n)ALUNO CURSO(1,1)
DISC-CURSO
(0,n)
(0,n)
PRÉ-REQUIS
liberadoraliberada
(0,n) (0,n)
46
Atributos
 Exemplo: atributo de relacionamento n:n
Obs: um engenheiro pode atuar em diversos 
 projetos, exercendo diferentes funções
PROJETOATUAÇÃO
(0,n) (0,n)
ENGENHEIRO
NomeCódigo Código Título
Função
47
Atributos
 Exemplo: atributo de relacionamento 1:n
Obs: vendas a prazo são relacionadas a uma financeira. 
Os atributos do relacionamento poderiam estar incluídos 
na entidade VENDA, como atributos opcionais. Na opção 
acima fica explícito o fato de os atributos pertenceremsomente a vendas a prazo
VENDAFINANCIAMENTO
(0,1) (0,n)
FINANCEIRA
taxa de juros
núm. de parcelas
Banco de Dados 48
Parte 3 - Modelo 
Entidade-Relacionamento
Identificador
Generalização / Especialização
49
Identificando entidades
 No exemplo abaixo, o atributo código é 
identificador
 Cada pessoa possui um código diferente
 O atributo código é um identificador simples
PESSOA
Código
Nome
Endereço
50
Identificando entidades
 Exemplo de identificador composto:
 considera-se o almoxarifado de uma empresa de ferragens
 os produtos ficam armazenados em prateleiras
 estas prateleiras encontram-se em armários organizados em 
corredores
 para cada prateleira deseja-se saber sua capacidade em metros 
cúbicos
PRATELEIRA
número do corredor
número da prateleira
capacidade
51
Identificando entidades
 Caso onde o identificador de uma entidade é 
composto por atributos da própria entidade e 
também por relacionamentos dos quais a entidade 
participa (relacionamento identificador)
 Exemplo:
código
DEPENDENTE
(1,1) (0,n)
EMPREGADO
nome
número
sequência nome
52
Identificando entidades
 No exemplo anterior:
 cada dependente está relacionado a exatamente um 
empregado
 um dependente é identificado pelo empregado ao qual 
ele está relacionado e por um número de sequência que 
distingue os diferentes dependentes de um mesmo 
empregado
No DER, o relacionamento usado como identificador é 
indicado por uma linha mais densa
Nesse caso, alguns autores dizem que a entidade 
DEPENDENTE é uma entidade fraca
 fraca significa que a entidade só pode existir quando 
relacionada a outra entidade e que usa como parte de 
seu identificador, entidades relacionadas
53
 Conceitos de um modelo conceitual são baseados 
em mecanismos de abstração
 Os três mais importantes:
 classificação/instanciação
 generalização/especialização
 agregação/desagregação
Mecanismos de abstração
54
Classificação
 Permite que objetos compartilhando propriedades 
semelhantes sejam considerados como 
ocorrências de uma classe de objetos
 Relação inversa: instanciação
 Classificação no modelo ER:
 Entidade e ocorrência de entidade
Relacionamento e ocorrência de relacionamento
 Atributo e valor
55
Generalização/Especialização
 Define uma relação de subconjunto entre 
elementos de 2 ou mais classes
 todas as propriedades definidas para a classe 
generalizada são herdadas pelas classes especializadas
 todo elemento de um subconjunto especializado é 
também elemento do seu respectivo conjunto 
generalizado
 Relação inversa: especialização
56
Generalizacão/Especialização
 Com este conceito é possível atribuir propriedades 
particulares a um subconjunto das ocorrências 
(especializadas) de uma entidade genérica (por 
exemplo adicionar atributos descritivos a uma 
subclasse de entidades)
 No DER, o símbolo que representa a 
generalização/especialização é um triângulo 
isósceles
57
A entidade cliente é dividida em dois 
subconjuntos, as entidades PESSOA FÍSICA 
e PESSOA JURÍDICA, cada uma com 
propriedades próprias
Cada ocorrência da entidade 
especializada possui, além de
suas próprias propriedades,
a herança das propriedades da 
ocorrência da entidade genérica
correspondente
A entidade PESSOA FÍSICA possui, além de seus atributos particulares CIC 
e sexo, também todas as propriedades da ocorrência da entidade CLIENTE 
correspondente, ou seja, os atributos nome e código, seu identificador 
(atributo código) e o relacionamento com a entidade FILIAL
Generalizacão/Especialização
 Exemplo: CLIENTE nome(1,1) código
PESSOA
FÍSICA
PESSOA
JURÍDICA
CIC sexo CGC tipo de
organização
FILIAL (0,n)
58
Generalizacão/Especialização
 Restrições de Integridade - a generalização pode 
ser:
 Parcial (p) ou total (t):
 total: toda ocorrência da entidade generalizada tem de 
ser ocorrência de pelo menos uma entidade 
especializada
 parcial: uma ocorrência da entidade generalizadas não 
precisa ser ocorrência de uma entidade especializada
59
Generalizacão/Especialização
 Exclusivo (e) ou interseção (o)
 exclusivo: toda ocorrência da entidade generalizada 
pode ser ocorrência de no máximo uma entidade 
especializada
 interseção: uma ocorrência da entidade generalizada 
pode ser ocorrência de várias entidades especializadas
60
PESSOA
PROFESSOR ALUNO
(t,e)
• toda pessoa é um professor ou um aluno (t)
• um professor não pode ser aluno e vice- 
 versa (e)
Generalizacão/Especialização
 Exemplo:
61
• uma pessoa pode ser um professor ou um
 aluno (p)
• um professor não pode ser aluno e vice-
 versa (e)
Generalizacão/Especialização
 Exemplo:
PESSOA
PROFESSOR ALUNO
(p,e)
62
• uma pessoa pode ser um professor ou um
 aluno (p)
• um professor pode ser aluno e vice-versa (o)
Generalizacão/Especialização
 Exemplo:
PESSOA
PROFESSOR ALUNO
(p,o)
63
• Se nada for especificado:
• (p)
• (o)
Generalizacão/Especialização
 Exemplo:
PESSOA
PROFESSOR ALUNO
(p,o)
64
 Exemplo de generalização/especialização TOTAL 
Indica que todo CLIENTE é:
 ou PESSOA FÍSICA
 ou PESSOA JURÍDICA
CLIENTE
PESSOA
JURÍDICA
(t,e)
PESSOA
FÍSICA
PESSOAJURÍDICA IS-A CLIENTE
PESSOA FÍSICA IS-A CLIENTE
Generalizacão/Especialização
65
FUNCIONÁRIO
MOTORISTA SECRETÁRIA
(p,e)tipo de
funcionário
Indica que nem todo FUNCIONÁRIO é:
 MOTORISTA ou SECRETÁRIA
Normalmente, quando ocorre uma 
especializacão parcial, aparece 
 
um atributo na entidade genérica 
(no caso, tipo de funcionário) para 
identificar o tipo de ocorrência da 
 entidade genérica
 Este atributo não é necessário
 no caso de especializações
 totais, já que a presença da 
ocorrência em uma de suas 
especializações é suficiente para 
identificar o tipo da entidade
Generalizacão/Especialização
 Exemplo de generalização/especialização PARCIAL 
66
Generalizacão/Especialização
 Uma entidade pode ser especializada em qualquer 
número de entidades (inclusive em uma única)
No exemplo anterior, se apenas os motoristas 
possuíssem propriedades particulares, haveria 
apenas uma entidade especializada, a de 
motoristas
 Não há limite no número de níveis hierárquicos da 
generalização/especialização, ou seja:
uma entidade especializada em uma 
generalização/especialização pode ser entidade 
genérica em uma outra 
generalização/especialização
67
Generalizacão/Especialização
 Técnica: quando usar?
 Todas as ocorrências podem ser identificadas da mesma 
forma
 Existem atributos/relacionamentos comuns a uma série 
de ocorrências
 Existem ocorrências que têm atributos ou 
relacionamentos adicionais
Consegue-se dizer que a entidade especializada É um 
tipo da entidade generalizada
68
Generalizacão/Especialização
 Técnica: quando não usar?
 As entidade especializadas não têm uma forma comum 
de identificação
Não se consegue dizer que a entidade especializada é 
um tipo da entidade generalizada naturalmente
Não adicionar clareza nem riqueza semântica:
 a diferença é um único atributo? (considerar atributo opcional)
 a diferença é um relacionamento? (considerar colocar 
cardinalidade mínima 0)
 deseja-se diferenciar duas ou mais coleções de ocorrências sem 
propriedades adicionais? (considerar colocar um atributo para 
diferenciar, ou um relacionamento)
69
Entidade Associativa ou Agregações
 Numa Clínica Médica, o relacionamento Consulta associa 
Médicos e Pacientes 
 Um Médico pode ter Consulta com diversos Pacientes(N)
 Um Paciente pode ter Consulta com diversos Médicos (N)
 Um dado Paciente somente pode ter uma Consulta com um 
dado Médico: o relacionamento Consulta não permite 
múltiplas consultas do um Paciente com um mesmo Médico
PACIENTECONSULTA
(0n) (0,n) 
MÉDICO
70
Entidade Associativa ou Agregações
 Para o Modelo de Dados permitir que um Paciente 
possa agendar diversas consultas com o mesmo 
Médico é necessário transformar Consulta em uma 
Entidade
 Consulta: Data, Hora, Local, CRM Médico, Código 
Paciente
 Uma entidade associativa é uma redefinição de um 
relacionamento que passa a ser uma entidade
71
Entidade Associativa ou Agregações
Necessário alterar o modelo incluindo os relacionamentos entre Médico e 
Consulta e entre Consulta e Paciente
PACIENTECONSULTA
n n
MÉDICO
72
Entidade Associativa
Sendo CONSULTA uma entidade, 
é possível associá-la através de 
relacionamentos a outras entidades
(0,N)
PRESCRIÇÃO
 MEDICAMENTO
 CONSULTA MEDICO PACIENTE
(0,N)
(0,N)(0,N)(1,1) (1,1)
M-C P-C
73
Construir um Modelo de Dados para a seguinte situação:
- Cada Empregado está lotado em um Departamento
- Cada Empregado tem um Cargo
- Cada Cargo tem um valor de salário
- Cada Departamento pode ter um Empregado que é o seu Chefe
- Um Empregado somente pode ser Chefe de um Departamento
- Cada Empregado pode participar de diversos Projetos. Em cada Projeto 
ele desempenha uma Função específica
Os seguintes dados precisam esta no Modelo:
- Data de contratação de um Empregado
- Data de entrada de um Empregado em um Projeto
- Todos os cargos ocupados por um Empregado e respectivos salários 
- Data de entrada de um Empregado em um Departamento
- Data em que um Empregado assumiu a chefia de um Departamento
74
Construir um Modelo de Dados para a seguinte situação:
Uma Administradora de Imóveis trabalha com administração 
de condomínios e com a administração de aluguéis
- Os condomínios são formados por unidades condominiais
- Cada unidade condominial é de propriedade de uma ou mais 
pessoas. Uma pessoa pode possuir diversas unidades
- Cada unidade pode ser alugada para apenas uma pessoa. 
Uma pessoa pode alugar diversas unidades
Os seguintes dados precisam estar no Modelo:
- Dados da unidade: metragem, quartos
- Data de inicio do aluguel, valor do aluguel
- Valor do condomínio 
75
Construir um Modelo de Dados para a seguinte situação:
São as seguintes as características de uma Locadora de Vídeo:
Possui cerca de 2.000 DVDs de filmes. Cada DVD possui um número. Para cada filme é registrado seu título e sua categoria (comédia, drama, 
aventura, etc.). Cada filme também recebe um numero identificador unico. Para cada DVD é controlado que filme ele contém. Cada DVD contém 
somente um filme. Para cada filme registrado há pelo menos um DVD, podendo haver mais de um DVD (copias) para o mesmo filme. 
Os clientes podem solicitar filmes de seus atores prediletos. Por isso, é necessário manter a informação dos atores que estrelam cada filme. Nem todo 
filme possui atores principais. Para cada ator os clientes às vezes solicitam outras informações como nome real, nacionalidade, data de nascimento.
A locadora possui muitos clientes cadastrados. Somente clientes cadastrados podem alugar filmes. Para cada cliente é registrado seu nome e 
sobrenome, seu telefone e seu endereço. Além disso, cada cliente recebe um número de associado.
As locações são cobradas por dia, sendo necessário controlar as datas de retirada e devolução dos DVDs. Sempre que um cliente solicitar o aluguel 
de um filme que ele já tenha retirado anteriormente, o sistema deverá conseguir identificar essa situação e notifica-lo disso.
Construa o modelo de dados completo, detalhando todas as entidades e/ou tabelas que constituem o modelo de dados, com seus atributos e 
identificando a chave primaria. Devem ser definidas, no mínimo, tabelas para:
Clientes
Filmes
Fitas
Atores
Categorias de Filmes
Controle dos filmes alugados pelos Clientes
Devem ser definidas outras tabelas necessárias para estabelecer os relacionamentos e os controles necessários.
O modelo de dados tem que permitir responder as seguintes consultas:
Lista de todos os títulos de filmes em ordem alfabética
Lista de todos os títulos de filmes, em ordem de categoria e dentro categoria, em ordem alfabética de título 
Lista de todos os filmes com um ator informado
Lista de todos os filmes do tipo comédia que tenha fitas disponíveis
Lista de todos os filmes com fitas disponíveis com um ator informado
Número das fitas disponíveis de um filme solicitado
Lista dos filmes atualmente alugados por um Cliente
Lista dos filmes já alugados em qualquer tempo por um Cliente
Lista de todos os filmes que estão alugados no momento
Banco de Dados 76
Banco de Dados – Parte 4
Modelo Lógico de Dados
Modelo Relacional
77
Composição de um Banco de Dados 
Relacional
 É composto de tabelas ou relações
 O termo tabela é mais comum nos produtos 
comerciais e na prática
 O termo relação foi utilizada na literatura original 
sobre a abordagem relacional (daí a denominação 
“relacional”) e é mais comum na área acadêmica
78
Tabelas
 Tabela é um conjunto não ordenado de linhas 
(tuplas, na terminologia acadêmica)
 Cada linha é composta por uma série de campos 
(valor de atributo na terminologia acadêmica)
 Cada campo é identificado por um nome de campo 
(nome de atributo, na terminologia acadêmica)
79
Tabelas
 O conjunto de campos homônimos de todas as 
linhas de uma tabela formam uma coluna
Emp
-D1SoaresE1
C2D1SilvaE2
C5D2SantosE3
C5D1SouzaE5
Categ 
FuncionalCódigoDeptoNomeCódigoEmp
80
Tabelas
 Observações:
Cada linha representa uma tupla
 As linhas de uma tabela não têm ordenação - a ordem 
de recuperação é arbitrária, a menos que uma 
ordenação seja especificada na instrução de consulta
Não existem linhas duplicadas
Não é possível referenciar linhas de uma tabela por 
posição
Os valores de campo de uma tabela são atômicos e 
monovalorados
 As consultas podem ser feitas por qualquer critério 
envolvendo os campos de uma ou mais linhas 
81
Chaves Candidatas
 Coluna ou conjunto de colunas de uma Tabela que 
identifica de forma única cada linha da tabela e é 
mínimo (no caso de conjunto) nessa condição
O fato de todas as linhas de uma tabela serem distintas 
entre si garante a existência de ao menos uma chave 
candidata na tabela
Aluno ( RA, Nome, CPF, Data_Nascimento, RG, Emissor_RG)
Chaves candidatas:
RA
CFP
(RG, Emissor_RG) (mínimo, precisa do par de valores) 
82
Chave Candidata
 Observações:
 Exige-se que seja mínima (quando todas as suas 
colunas forem efetivamente necessárias para garantir o 
requisito de unicidade de valores da chave)
Uma tabela sempre tem ao menos uma chave candidata 
e pode ter mais do que uma
Não existe uma classificação para as chaves candidatas. 
Todas a mesma relevância na tabela
83
Chave Primária
 Uma das chaves candidatas da Tabela deve ser 
escolhida com sua Chave Primária
 Não existe regra para decidir qual das chaves 
candidatas deve ser a escolhida
 Na escolha deve ser considerada a existência de 
referências a esta chave primária em outras 
tabelas (chave estrangeira)
 Ao definir uma chave primária está se definindo uma 
restrição de integridade e não um caminho de acesso 
(índice)
84
Chave Estrangeira
 É uma coluna ou uma combinação de colunas, 
cujos valores aparecem necessariamente na chave 
primária de uma tabela
 Usada para implementar relacionamento em um 
banco de dados relacional
85
Chave Estrangeira
 Exemplo:
VendasD3
EngenhariaD2
ComprasD1
NomeDeptoCódigoDepto
543523345D1SoaresE5
125323422D2SilvaE3
123124112D2SantosE2
132123123D1SouzaE1CICCódigoDeptoNomeCódigoEmp
Depto
Emp
86
Chave Estrangeira
 Observações:
No exemplo anterior, a coluna CodigoDepto da tabela 
Emp é uma chave estrangeira em relação à chave 
primária da tabela Dept
Na tabela Emp, os valores do campo CodigoDepto de 
todas as linhas devem aparecer na coluna CodigoDepto 
da tabela Dept
 A existência de uma chave estrangeira impõe 
restrições que devem ser garantidas ao executar 
as diversas operações e alteração do banco de 
dados
87
Mapeamento do Modelo Conceitual 
para o Modelo Relacional
 Um modelo conceitual construído utilizando o 
Modelo Entidade-Relacionamento pode ser 
mapeado para um modelo lógico Relacional
 A equivalência mais direta é
cada Entidade = uma Tabela
cada Atributo = uma Coluna
cada Ocorrência = uma Linha
88
Mapeamento de Entidades
 Para cada Entidade 
deve ser criada uma 
relação (tabela)
 Para cada atributo 
simples incluir uma 
coluna na tabela
 No caso de atributo 
composto, incluir 
somente os atributos 
simples que o 
compõe (Endereço)
EMPREGADO
nome
código
Endereço DataNasc
Empregado(Codigo, Nome, 
Logradouro, Numero, Bairro, Cidade, Estado,
DataNasc)
89
Nome das colunas
 O nome do atributo(modelo conceitual) pode ser diferente 
do nome do campo da tabela (coluna)
 Objetivo
 Facilidade de programação como o uso de nomes curtos
 Evitar nomes iguais. Ex.: Todas entidades com o atributo nome
 Evitar espaços no nome da coluna, pois são proibidos nos BD 
relacionais
 Dica
 Defina um padrão para converter o nome dos atributos, 
principalmente dos nomes compostos que necessitam abreviação. 
Ex.: Nome do Responsável NomeRes
90
Nome para a chave primária
 É boa prática compor o nome da chave primária 
com uma identificação da tabela a qual ela 
pertence
 Como geralmente, elas se tornam chaves estrangeiras de outras 
tabelas, esta prática facilita a programação e compreensão dos 
campos
EMPREGADO
nome
código
Endereço Data de Nascimento
Empregado(CodEmp, Nome, Endereco, DataNasc)
91
Mapeamento de Atributos Multivalorados
 Para cada atributo 
multivalorado deve ser 
criada uma tabela formada 
pela chave primária da 
Tabela/Entidade e pelo 
atributo multivalorado
 A chave primária da nova 
tabela será o par de 
atributos
 Se o atributo multivalorado 
for composto. Por ex.: 
Ingrediente formado por 
Nome do ingrediente e 
quantidade, todo o grupo 
vai para a nova tabela
RECEITA
nome
código
Modo de Preparo
Ingrediente (n)
Receita(Codigo, Nome, Modo_Preparo)
Ingrediente_Receita (CodReceita, Ingrediente)
92
Mapeamento de Relacionamentos
 Um relacionamento pode ser transformado em:
Uma tabela
Uma coluna de uma das tabelas envolvidas
 Fusão de duas tabelas
 Esta decisão depende da cardinalidade mínima e 
máxima dos relacionamentos
 No caso da fusão devemos considerar também 
outros relacionamentos da entidade
93
Entidades Fracas
 Criar uma tabela para cada entidade fraca
 Nessa tabela incluir como chave estrangeira a chave 
primária da tabela que representa a entidade 
possuidora/identificadora
 As entidades fracas têm chave primária composta de duas 
partes:
 A chave primária da tabela (entidade) possuidora
 A chave parcial da tabela(entidade) fraca
código
DEPENDENTES
(1,1) (0,n)
EMPREGADOS
nome Codigo nome
Empregados(CodEmp, Nome) Dependentes(CodEmp, CodDep, Nome, DataNasc)
Data de Nascimento
Dependencia
94
Implementação de Relacionamentos 1:1
95
Relacionamentos Binários - Um para Um
 Ambas entidades têm participação opcional
 adição de colunas
96
Relacionamentos Binários - Um para Um
 Ambas entidades têm participação opcional
 tabela própria
97
Relacionamentos Binários - Um para Um
 Ambas entidades têm participação opcional
 fusão de tabelas
98
Relacionamentos Binários - Um para Um
 Ambas entidades têm participação opcional
 Solução por fusão de tabelas é inviável
Chave primária artificial (já que pode não estar completa)
 Solução por adição de colunas melhor
Menor número de junções
Menor número de chaves
 Solução por tabela própria aceitável
99
Implementação de Relacionamentos 1:1
100
Relacionamentos Binários - Um para Um
 Participação opcional/obrigatória
 Fusão de tabelas
101
Relacionamentos Binários - Um para Um
 Participação opcional/obrigatória
 Adição de colunas
102
Relacionamentos Binários - Um para Um
 Adição de colunas versus fusão de tabelas
 Fusão de tabelas é melhor em termos de númerode 
junções e número de chaves
 Adicão de colunas é melhor em termos de campos 
opcionais
 Fusão de tabelas é considerada a melhor e adição de 
colunas é aceitável
103
Relacionamentos Binários - Um para Muitos
104
Relacionamentos Binários - Um para Muitos
 Já temos duas tabelas, uma para cada conjunto de 
entidades que participam do relacionamento
 Incluir como chave estrangeira, na tabela do “lado 
muitos” (o “lado N”), a chave primária da tabela do 
“lado um”
 Incluir também colunas com os atributos do 
relacionamento
105
Relacionamentos Binários - Um para Muitos
106
Relacionamentos Binários – Muitos para Muitos
107
Relacionamentos Binários – Muitos para Muitos
 Já temos duas tabelas, uma para cada conjunto de 
entidades que participa do relacionamento 
 Criar uma nova tabela contendo, como chaves 
estrangeiras, as chaves primárias dessas duas 
tabelas
 A combinação dessas chaves estrangeiras forma a 
chave primária da nova tabela
 Incluir também colunas com os atributos do 
relacionamento
108
Relacionamentos Binários – Muitos para Muitos
Banco de Dados 109
Banco de Dados – Parte 5
Modelo Lógico de Dados
Modelo Relacional
Restrições de Integridade
Generalizações / Especializações
110
 Tabela: representada por um retângulo
 Relacionamentos somente binários (entre 2 
tabelas) – tipo 1:N
 Se for obrigatório, corte transversal: 
Diagrama para Modelo Lógico Relacional
111
Exemplos
Departamento
Empregado
Engenheiro
Participa_Proj
Projeto
Departamento (Codigo, Nome)
Empregado (Matricula, Nome, CodDepto)
112
Chave Estrangeira - restrições impostas
 Quando da inclusão de uma linha na tabela que 
contém a chave estrangeira:
deve ser garantido que o valor da chave 
estrangeira, se informado, exista na coluna da 
chave primária referenciada
Se o relacionamento não for do tipo obrigatório, a 
chave estrangeira pode não ser informada
Exemplo: um novo empregado deve atuar em um 
departamento já existente no banco de dados (na 
tabela Departamento)
113
Chave Estrangeira - restrições impostas
 Quando da alteração do valor da chave 
estrangeira:
deve ser garantido que o novo valor de uma chave 
estrangeira, se informado, exista na coluna da 
chave primária referenciada
Exemplo: se um empregado muda de departamento, 
deve-se garantir que o novo departamento já exista 
no banco de dados (na tabela Departamento)
114
Chave Estrangeira - restrições impostas
 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á sendo excluída
Exemplo: um departamento não pode ser excluído, 
caso exista algum empregado que o referencie
115
Chave Estrangeira - restrições impostas
 Quando da alteração do valor da chave primária 
referenciada pela chave estrangeira:
deve ser garantido que na coluna chave 
estrangeira não apareça o antigo valor da chave 
primária que está sendo alterada
Exemplo: um departamento somentepode ter o seu 
código alterado se não for referenciado por 
nenhum empregado
116
Chave Estrangeira
 Pode acontecer de uma chave estrangeira 
referenciar a chave primária da própria tabela (e 
não de uma tabela diferente, como no exemplo 
anterior). Exemplo:
Emp
 
E1D1SoaresE5
E5D2SilvaE3
 E5D2SantosE2
-D1SouzaE1
Código Emp 
GerenteCódigoDeptoNomeCódigoEmp
Código Emp Gerente é uma chave estrangeira que 
Referencia a chave da própria tabela (auto-relacionamento)
117
Valores Vazios
 Normalmente, os SGBDs relacionais exigem que 
todas as colunas que compõem a chave 
primária sejam obrigatórias
 A mesma exigência não é feita para as demais 
chaves
 Atenção: Vazio é diferente de zeros ou brancos
118
Restrições de Integridade
 Banco de dados íntegro: reflete corretamente a 
realidade representada pelo banco de dados e os 
dados são consistentes entre si
 Um SGBD deve garantir a integridade dos dados 
através do mecanismo de restrição de 
integridade
119
Restrições de Integridade
 Restrição de integridade: regra de consistência 
de dados que é garantida pelo próprio SGBD
 Na abordagem relacional as restrições de 
integridade estão classificadas em:
 Integridade de domínio
 Integridade de vazio
 Integridade de chave
 Integridade referencial
120
Restrições de Integridade
 Domínio:
 É um conjunto de valores (alfanumérico, numérico, ...) que um 
campo de uma tabela pode assumir
 É chamado de domínio da coluna ou domínio do campo
 Integridade de domínio:
 especifica que o valor de um campo deve obedecer a definição de 
valores admitidos para a coluna (o domínio da coluna)
 Nos SGBDs relacionais é possível usar domínios pré-definidos 
(número inteiro, número real, alfanumérico de tamanho definido, 
data, ...) 
 É possível usar um conjunto finito de valores: 
(Masc , Fem), (Sim , Não), (1, 2, , 5, 7, 11, 13)
 É possível usar uma fórmula: > 0 e < 1000
121
Restrições de Integridade
 Valores vazios:
 Deve-se especificar se o conteúdo de uma coluna pode estar vazio 
(em inglês “null”)
 Estar vazio significa que o campo não recebeu nenhum valor de 
seu domínio
 As colunas que podem conter valores vazios são as colunas 
opcionais
 As colunas que não podem conter valores vazios são as colunas 
obrigatórias
 Integridade de vazio:
 Especifica se os campos de uma coluna podem ou não ser vazios 
(se a coluna é obrigatória ou opcional)
 Campos que compõem a chave primária não podem ser vazios
122
Restrições de Integridade
 Integridade de chave:
 Trata-se da restrição que define que os valores da chave 
primária devem ser únicos
 Integridade referencial:
Define que os valores dos campos que aparecem em 
uma chave estrangeira devem aparecer na chave 
primária da tabela referenciada
123
Restrições de Integridade Declarativas
 As restrições citadas devem ser garantidas 
automaticamente por um SGBD relacional a 
partir da sua declaração na definição das 
tabelas, não sendo necessário nenhuma 
programação para garanti-las explicitamente
 São restrições de Integridade Declarativa:
 Chave Primária
 Unicidade (chaves candidatas)
 Integridade Referencial (Chave Estrangeira)
 Integridade de Domínio
 Integridade de Vazio
124
Restrições Semânticas de Integridade
 Existem restrições de integridade que não podem 
ser definidas de forma declarativa para um SGBD 
relacional
 São chamadas restrições semânticas
 Necessário que seja feita programação 
“procedural” na aplicação ou no SGBD
 Exemplos:
 um empregado do departamento “Finanças” não pode ter 
a categoria funcional “Engenheiro”
 um empregado não pode ter um salário maior que seu 
superior imediato
125
Generalização/Especialização (1 Tabela)
Prestadores
De Serviços
nome
CPF
Horistas Mensalistas
custoHora HorasTrabalho Salario
Endereco
Observações
•Minimizando a junções
•Menor número de chaves
•Muitos atributos opcionais
Alternativa (1 tabela):
PrestadoresServicos(CPF, Nome, Endereco, 
 CustoHora, HorasTrabalhadas, Salario, Tipo)
Regras
•Chave primária referente a entidade 
genérica
•Adicionar uma coluna Tipo
•Uma coluna para cada atributo da entidade 
genérica
 e das especializadas
•Possíveis colunas referentes aos 
relacionamentos
 envolvendo as entidades
126
Generalização/Especialização (2 Tabelas)
Prestadores
De Serviços
nome
CPF
Horistas Mensalistas
custoHora HorasTrabalho Salario
Endereco
Alternativa (2 tabelas): Horistas, Mensalistas
Horistas(CPF,Nome,Endereco,CustoHora,HorasTrabalho)
Mensalistas(CPF, Nome, Endereco Salario)
Observações
• Unicidade da chave primária não pode ser 
garantida de forma declarativa pelo SGBD, 
por serem 2 tabelas independentes
• Necessário programação procedural
127
Generalização/Especialização (3 Tabelas)
Abordagem geral (3 tabelas):
Prestadores_de_Servicos, Horistas, Mensalistas
Prestadores_de_Servicos(CPF, Nome, Endereco, Tipo)
Horistas(CPF,CustoHora,HorasTrabalhadas)
Mensalistas(CPF,Salario)
Regras
• Incluir a chave primária da tabela genérica 
em cada tabela especializada como chave 
estrangeira
•Adicionar o atributo Tipo
Observações
• Redução de atributos opcionais
• Ocorrência de uma das 2 tabelas especializadas 
conforme o valor do atributo Tipo somente pode 
ser garantida através de programação procedural
Prestadores
De Serviços
nome
CPF
Horistas Mensalistas
custoHora HorasTrabalho Salario
Endereco
Banco de Dados 128
Banco de Dados – Parte 6
Modelo Lógico de Dados
Modelo Relacional
Normalização
129
Objetivos da Normalização
 Reagrupar informações para
 eliminar redundâncias de dados
 eliminar estruturas inexistentes no modelo ER
 (atributos multivalorados)
 Processo de normalização – baseado nas Formas 
Normais
130
Forma Normal
 Regra que deve ser obedecida por uma tabela para 
ser considerada “bem projetada”
 Diversas formas normais:
Regras rígidas para verificar tabelas relacionais
 Serão abordadas: 
 Primeira Forma Normal (1FN),
 Segunda Forma Normal (2FN), 
 Terceira Forma Normal (3FN)
 Forma Normal de Boyce-Codd (FNBC)
131
Processo de Normalização
Esquema 
não 
normalizado
Esquema 
na 1FN
Esquema 
na 2FN
Esquema na 
3FN/FNBC
normalizado
1 FN
2 FN
 3FN/FNBC
132
Passagem para a primeira forma normal
Primeira forma normal (1FN)
=
Diz-se que uma tabela está na 
Primeira Forma Normal(1FN), quando
 todas as suas linhas são distintas
 e ela não contém tabelas aninhadas, 
ou seja,
todos as suas colunas são monovaloradas
Primeira forma normal (1FN)
=
Diz-se que uma tabela está na 
Primeira Forma Normal(1FN), quando
 todas as suas linhas são distintas
 e ela não contém tabelas aninhadas, 
ou seja,
todos as suas colunas são monovaloradas
133
Passagem para a primeira forma normal
 Para transformar um esquema de tabela não-
normalizada em um esquema na 1FN há duas 
alternativas:
Construir uma única tabela com redundância de dados
Construir uma tabela para cada tabela aninhada
134
Dependência Funcional
 Para entender a segunda e terceira formas 
normais, é necessário conhecer o conceito de 
Dependência Funcional
 Em uma tabela relacional, diz- se que:
 uma coluna B depende funcionalmente de uma 
coluna A (ou que a coluna A determina a coluna B) 
quando, se sempre que duas linhas tiverem o 
mesmo valor na coluna A, terão o mesmo valor na 
coluna B.
 Indica-se: A -> B
135
Dependência Funcional
 No exemplo abaixo, podemos dizer que:
 Código → Salário
 Cada valor de Código está associado sempre ao mesmo valor de 
Salário
 Salário depende funcionalmente deCódigo
 10
 10
 10
 5
 10
 5 
 10
 E1
 E3
 E1
 E2
 E3
 E2
 E1
...Salário...Código...
136
Dependência Funcional
 Exemplos:
137
Dependência Funcional
 Exemplos:
138
Dependência Funcional
 Exemplos:
139
Passagem para a segunda forma normal
 Objetiva eliminar certos tipos de redundância de 
dados
 Exemplo:
 (CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl)
 Os dados referentes a empregados (Nome, Cat e 
Sal) estão redundantes, para os empregados que 
trabalham em mais de um projeto
140
Passagem para a segunda forma normal
 Uma tabela encontra-se na segunda forma normal 
(2FN) se, além de encontrar-se na 1FN, cada 
coluna não chave depende da chave primária 
completa
 Uma tabela que não se encontra na 2FN contém 
dependências funcionais parciais, ou seja, contém 
colunas não chave que dependem apenas de uma 
parte da chave primária
141
Passagem para a segunda forma normal
 Exemplo:
142
Passagem para a segunda forma normal
Segunda forma normal (2FN)
=
Uma tabela encontra-se na segunda forma
normal quando, além de estar na 1FN, não
 contém dependências parciais
Segunda forma normal (2FN)
=
Uma tabela encontra-se na segunda forma
normal quando, além de estar na 1FN, não
 contém dependências parciais
dependência parcial
=
Uma dependência (funcional) parcial
 ocorre quando uma coluna não chave depende
apenas de parte de uma 
chave primária composta
dependência parcial
=
Uma dependência (funcional) parcial
 ocorre quando uma coluna não chave depende
apenas de parte de uma 
chave primária composta
143
Passagem para a segunda forma normal
 Dependências parciais:
144
Passagem para a segunda forma normal
 Dependências não parciais:
145
Passagem para a segunda forma normal
 Observações:
Uma tabela que está na 1FN e que possui uma chave 
primária simples não contém dependências parciais e, 
portanto, já está na 2FN
(CodProj, Tipo, Descr)
(CodProj, Tipo, Descr)
1FN
(CodProj, CodEmp, Nome, Cat, Sal, DataIni, TempAl)
2FN
146
Passagem para a segunda forma normal
 Observações (cont.):
Uma tabela que contém apenas colunas chave ou parte 
de chaves, já está na 2FN, já que não existem atributos 
não chave para depender de alguma parte da chave
147
Passagem para a segunda forma normal
 Observações (cont.):
 Se uma tabela possui chave primária com várias colunas 
e possui colunas não chave, então deve ser examinada
 Pode-se perguntar para cada coluna não chave:
 “a coluna depende de toda a chave ou só de parte?”
 “para identificar um valor da coluna é necessária toda a chave 
ou só parte dela?”
148
Passagem para a segunda forma normal
 Exemplo:
149
Passagem para a terceira forma normal
 Eliminação de outro tipo de redundância
 Exemplo
 Emp (CodEmp, Nome, Cat, Sal)
 Vamos considerar que o salário (coluna Sal) é 
determinado pela categoria funcional (coluna Cat)
O valor do salário que é pago a uma categoria funcional 
é armazenado tantas vezes quantos sejam os 
empregados possuem a categoria funcional
150
Passagem para a terceira forma normal
151
Passagem para a terceira forma normal
 Uma tabela encontra-se na 3FN quando, além de 
estar na 2FN, toda coluna não chave depende 
diretamente da chave primária, isto é, quando não 
há dependências funcionais transitivas ou indiretas
 Uma dependência funcional transitiva ou indireta 
acontece quando uma coluna não chave depende 
funcionalmente de outra coluna ou combinação de 
colunas não chave
152
Passagem para a terceira forma normal
 Exemplo de dependência transitiva:
153
Passagem para a terceira forma normal
Terceira forma normal (3FN)
=
Uma tabela encontra-se na terceira forma
 normal quando, além de estar na 2FN, não
 contém dependências transitivas
Terceira forma normal (3FN)
=
Uma tabela encontra-se na terceira forma
 normal quando, além de estar na 2FN, não
 contém dependências transitivas
dependência transitiva
=
Uma dependência (funcional) transitiva
 ocorre quando uma coluna não chave, além de
depender da chave primária da tabela, depende 
de outra coluna ou conjunto de colunas 
não chave da tabela
dependência transitiva
=
Uma dependência (funcional) transitiva
 ocorre quando uma coluna não chave, além de
depender da chave primária da tabela, depende 
de outra coluna ou conjunto de colunas 
não chave da tabela
154
Passagem para a terceira forma normal
 Na passagem para a 3FN divide-se as tabelas de 
forma a eliminar as dependências transitivas
155
Redundâncias não eliminadas pela 
Terceira Forma Normal
 Tabelas em 3FN não possuem colunas não chave que 
dependam de parte da chave primária ou de coluna não 
chave 
 Dependência não eliminada pela 3FN: 
coluna parte de uma chave depende de outra coluna 
também parte de chave
156
Redundâncias não eliminadas pela 
Terceira Forma Normal
 Exemplo
Tabela com dias em que empregados que utilizam veículos, 
sendo que um empregado sempre usa o mesmo veículo e um 
veículo pode ser utilizado por mais de um empregado. Em cada 
dia somente um empregado utiliza o veiculo
 UsoVeiculo (CodEmp, CodVeiculo, Dia)
Chaves candidatas: 
(CodEmp, Dia)
(CodVeiculo, Dia)
Dependência entre colunas: CodEmp → CodVeiculo
157
Tabela em 3FN que ainda possui 
redundâncias
CodEmp CodVeiculo Dia
E1 V1 1
E2 V2 1
E3 V3 1
E1 V1 2
E3 V3 2
E4 V2 2
E5 V1 3
E2 V2 3
E3 V3 3
E5 V1 4
E2 V2 4
E3 V3 4
Chaves candidatas: 
(CodEmp, Dia)
(CodVeiculo, Dia)
Dependência entre colunas: CodEmp → CodVeiculo
158
Forma Normal de Boyce-Codd
 Uma tabela encontra-se na FNBC se, e somente 
se, além de estar na 1FN, todas as dependências 
funcionais são dependências de chave, isto é, 
quando não há nenhuma dependência funcional 
que não seja de chave
 A FNBC, também conhecida como 3,5FN, é um 
pouco mais forte que a 3FN, porque poucas são as 
tabelas que estão em 3FN e não estão em FNBC
 As únicas tabelas que podem estar em 3FN e não 
em FNBC são tabelas como do exemplo anterior, 
UsoVeiculo, onde uma coluna parte de uma chave 
depende de outra coluna também parte de chave 
159
Forma Normal de Boyce-codd
Forma normal de Boyce-Codd (FNBC)
=
Uma tabela encontra-se na FNBC
 normal quando, além de estar na 1FN, não
 contém dependências que não sejam
de uma chave
Forma normal de Boyce-Codd (FNBC)
=
Uma tabela encontra-se na FNBC
 normal quando, além de estar na 1FN, não
 contém dependências que não sejam
de uma chave
160
Passagem para a FNBC
 Eliminar todas as dependências de coluna não chave
 Criar nova tabela com a dependência eliminada
 Tabelas em FNBC:
UsoVeiculo (CodEmp, Dia)
RespVeiculo (CodEmp, CodVeiculo)
CodEmp CodVeiculo
E1 V1
E2 V2
E3 V3
E4 V2
E5 V1
CodEmp Dia
E1 1
E2 1
E3 1
E1 2
E3 2
E4 2
E5 3
E2 3
E3 3
E5 4
E2 4
E3 4
161
 Tabela com informações de participação de 
empregados em projetos
 ParticipaProjeto (Cod_projeto, Nome_projeto, Cod_empregado, 
Nome_empregado, Cod_cargo, Nome_Cargo, 
Valor_salario_cargo, Data_entrada_Projeto, Funcao_no_Projeto)
 Exercício:
 Identificar as chaves candidatas e definir a chave primária
 Identificar dependências funcionais de coluna ou conjunto de 
colunas não chave
 Construir modelo equivalente com tabelas em 3FN
162
 Tabela com dados de trechos de Voos
 Voo (Nro_Voo, Nro_Trecho, Cod_Cia_Aerea,
Nome_Cia_Aerea, Cod_Aerop_Saida, Nome_Aerop_Saida, 
Nome_Cidade_Saida, Hora_Saida, Duracao, 
Cod_Aerop_Chegada, Nome_Aerop_Chegada, 
Nome_Cidade_Chegada, Hora_Chegada, Tipo_Aeronave,Nro_Lugares, Fabricante_Aeronave)
Exercício:
Identificar as chaves candidatas e definir a chave primária
Identificar dependências funcionais de coluna ou conjunto de 
colunas não chave
Construir modelo equivalente com tabelas em 3FN
163
 Modelagem de Dados - Estudos de Caso
 Elaborar o modelo de dados para um sistema de controle de uma Locadora de Veículos 
que atenda as condições descritas abaixo.
 Construir o modelo de dados relacional, em 3ª Forma Normal, detalhando os atributos de 
cada Tabela, indicando sua chave primária (PK) e construindo o diagrama representando 
as tabelas e os relacionamentos entre elas.
 São as seguintes as características da Locadora de Veículos:
 Possui 30 lojas. Cada loja está em um local diferente e tem um código, um nome e vários 
telefones de atendimento.
 Há um telefone central 0800 de atendimento que no momento está sendo atendido pela 
loja 4.
 Possui 500 veículos, sendo 450 automóveis e 50 ônibus. 
 Além das informações básicas de cada veículo como marca, modelo, ano, placa, chassi, 
etc, para os automóveis tem informações do número de portas, ar condicionado, direção 
hidráulica e para os ônibus, número de lugares e DVD.
 Para cada veículo são registradas a quilometragem atual e a data e quilometragem da 
última revisão.
 Os veículos são agrupados por tipo, que são os veículos que tem mesmo preço de 
aluguel.
 Os clientes podem ser pessoas ou empresas. Para cada cliente são registradas as suas 
informações de identificação.
 A locação é de um veículo é para um cliente. No caso de empresa, tem que ser 
identificado o motorista responsável.
 O contrato se liquida na devolução do veículo, quando se apura a quilometragem rodada 
para fazer a cobrança. Os contratos liquidados são mantidos por 5 anos, para efeitos 
legais.
 Os veículos não alugados e que estão disponíveis, ou seja, que não estão na oficina para 
reparos ou revisão ficam sempre em alguma loja. 
 Quando um cliente solicita em uma loja o aluguel de um veículo de um tipo não disponível 
naquela loja, o gerente da loja verifica as lojas próximas e se for o caso, solicita um 
veículo de uma dessas lojas. O gerente não pode solicitar veículo de qualquer loja, mas 
somente dessas que são consideradas próximas.
Banco de Dados 164
Banco de Dados – Parte 7
Modelo Lógico de Dados
Análise de Dados baseada 
em Visões de Dados
165
Análise de Dados baseada em Visões de 
Dados
 Visões de Dados
Documentos, relatórios, formulários, telas de sistema, 
layout de arquivos
Qualquer documento que onde apareçam dados que 
interessem ao modelo em construção
 Análise
 Todas as visões devem ser analisadas individualmente
Os dados obtidos são incorporados ao Modelo Lógico 
sendo construído, respeitando a 3ª Forma Normal 
166
Análise de Dados baseada em Visões de 
Dados - Técnica
 Análise individual da Visão
 Passo 1 – Análise dos dados não repetitivos da visão
 O conjunto de dados não repetitivos da visão devem ser tratados como uma 
Tabela Relacional em 1ª Forma Normal
 Fazer a Normalização dessa Tabela, determinando a sua chave primária e 
mantendo somente os dados que dependam unicamente da chave primária 
(3FN)
 Dependências Funcionais não da chave devem originar novas tabelas
 Análise
 Todas as visões devem ser analisadas individualmente
 Os dados obtidos são incorporados ao Modelo Lógico sendo construído, 
respeitando a 3ª Forma Normal 
	Slide 1
	Slide 2
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15
	Slide 16
	Slide 17
	Slide 18
	Slide 19
	Slide 20
	Slide 21
	Slide 22
	Slide 23
	Slide 24
	Slide 25
	Slide 26
	Slide 27
	Slide 28
	Slide 29
	Slide 30
	Slide 31
	Slide 32
	Slide 33
	Slide 34
	Slide 35
	Slide 36
	Slide 37
	Slide 38
	Slide 39
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46
	Slide 47
	Slide 48
	Slide 49
	Slide 50
	Slide 51
	Slide 52
	Slide 53
	Slide 54
	Slide 55
	Slide 56
	Slide 57
	Slide 58
	Slide 59
	Slide 60
	Slide 61
	Slide 62
	Slide 63
	Slide 64
	Slide 65
	Slide 66
	Slide 67
	Slide 68
	Slide 69
	Slide 70
	Slide 71
	Slide 72
	Slide 73
	Slide 74
	Slide 75
	Slide 76
	Slide 77
	Slide 78
	Slide 79
	Slide 80
	Slide 81
	Slide 82
	Slide 83
	Slide 84
	Slide 85
	Slide 86
	Slide 87
	Slide 88
	Slide 89
	Slide 90
	Slide 91
	Slide 92
	Slide 93
	Slide 94
	Slide 95
	Slide 96
	Slide 97
	Slide 98
	Slide 99
	Slide 100
	Slide 101
	Slide 102
	Slide 103
	Slide 104
	Slide 105
	Slide 106
	Slide 107
	Slide 108
	Slide 109
	Slide 110
	Slide 111
	Slide 112
	Slide 113
	Slide 114
	Slide 115
	Slide 116
	Slide 117
	Slide 118
	Slide 119
	Slide 120
	Slide 121
	Slide 122
	Slide 123
	Slide 124
	Slide 125
	Slide 126
	Slide 127
	Slide 128
	Slide 129
	Slide 130
	Slide 131
	Slide 132
	Slide 133
	Slide 134
	Slide 135
	Slide 136
	Slide 137
	Slide 138
	Slide 139
	Slide 140
	Slide 141
	Slide 142
	Slide 143
	Slide 144
	Slide 145
	Slide 146
	Slide 147
	Slide 148
	Slide 149
	Slide 150
	Slide 151
	Slide 152
	Slide 153
	Slide 154
	Slide 155
	Slide 156
	Slide 157
	Slide 158
	Slide 159
	Slide 160
	Slide 161
	Slide 162
	Slide 163
	Slide 164
	Slide 165
	Slide 166