1
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19991
Projeto de Banco de Dados
Transparências selecionadas
Autor: Prof Carlos Heuser (UFRGS)
Livro: Projeto de Banco de Dados
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19992
Modelo de Dados - níveis de abstração
abstração
modelo conceitual
modelo lógico
modelo físico
2
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19993
Modelo conceitual
• Independente de tipo de SGBD
• Registra – Estrutura dos dados podem aparecer no banco de
dados
• Não registra– Como estes dados estão armazenados a nível de
SGBD
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19994
Modelo conceitual - diagrama ER
• Técnica mais difundida de modelagem conceitual– Abordagem entidade-relacionamento (ER)
• Modelo conceitual é representado através de diagrama entidade-relacionamento (DER)
3
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19995
Diagrama entidade-relacionamento
Produt o
códigodescrição
Tipo deprodut o
códigodescrição
preço
n 1
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19996
Modelo lógico
• Nível de abstração visto pelo usuário do SGBD
• Dependente do tipo particular de SGBD que está sendo usado
4
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19997
Modelo lógico
• SGBD relacional para o exemplo
ProdutoCodProd DescrProd PrecoProd CodTipoProd
1 PC desktop modelo X 2.500 12 PC notebook ABC 3.500 13 Impressora jato de tinta 600 24 Impressora laser 800 2
TipoDeProdutoCodTipoProd DescrTipoProd
1 Computador2 Impressora
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19998
Modelo lógico para o exemplo
TipoDeProduto(CodTipoProd,DescrTipoProd)
Produto(CodProd,DescrProd,PrecoProd,CodTipoProd)CodTipoProd referencia TipoDeProduto
5
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19999
Modelo Físico
• Contém detalhes de armazenamento interno de informações
• Detalhes que– não têm influencia sobre a programação de aplicações
no SGBD– influenciam a performance da aplicações
• Usados por profissionais que fazem sintonia de performance em banco de dados
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199910
Idéia fundamental do projeto de banco de dados
Através da identificação das entidades que terão informações
representadas no banco de dados, é possível identificar os arquivos que
comporão o banco de dados
6
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199911
Modelo conceitual tem dupla interpretação
• modelo da organização– Define as entidades da organização que tem
informações armazenadas no banco de dados
• modelo do banco de dados– Define que arquivos (tabelas) farão parte do banco de
dados.
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199912
Projeto de BD
• Duas fases:1 Modelagem conceitual2 Projeto lógico
• Adequado para a construção de um novo banco de dados
• Caso já exista um banco de dados ou um conjunto de arquivos convencionais usar reengenharia
7
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199913
Abordagem Entidade-Relacionamento
• Técnica para construir modelos conceituais de bases de dados
• Técnica de modelagem de dados mais difundida e utilizada
• Criada em 1976 por Peter Chen
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199914
Abordagem Entidade-Relacionamento
• Padrão de fato para modelagem conceitual
• Não é única:– NIAM/ORM (técnica européia da década de 70)– UML (Técnica para modelos Orientados a Objetos)
• Técnicas de modelagem orientada a objetos (UML) baseiam-se nos conceitos da abordagem ER
8
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199915
Abordagem Entidade-Relacionamento
• Modelo de dados é representado através de um– modelo entidade-relacionamento (modelo ER)
• Modelo ER é representado graficamente– diagrama entidade-relacionamento (DER)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199916
Conceitos centrais da abordagem ER
• Entidade
• Relacionamento
• Atributo
• Generalização/especialização
• Entidade associativa
9
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199917
Entidade
Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de
dados
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199918
Entidade – exemplos
• Sistema de informações industrial– produtos– tipos de produtos– vendas– compras
10
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199919
Entidade – exemplos
• Sistema de contas correntes– clientes– contas correntes– cheques– agências
• Entidade pode representar– objetos concretos da realidade (uma pessoa, um
automóvel)– objetos abstratos (um departamento, um endereço)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199920
PESSOA DEPARTAMENTO
Entidade no DER
• Representada através de um retângulo
• Retângulo contém o nome da entidade.
11
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199921
Entidade e instância
• Para referir um objeto particularfala-se em instância ou ocorrência de entidade
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199922
Entidade e instância - terminologia
conjunto elemento do conjunto
entidade instância
classe instância
conjuntode entidades
entidade
12
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199923
Propriedades de entidades
• Entidade isoladamente não informa nada
• É necessário atribuir propriedades às entidades
• Propriedades especificadas na forma de – Relacionamentos– Atributos– Generalizações/especializações
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199924
Relacionamento - conceito
Conjunto de associações entre entidades sobre as quais deseja-se manter informações
na base de dados
13
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199925
Relacionamento no DER
DEPARTAMENTO LOTAÇÃO PESSOA
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199926
Relacionamento e instância
• Relacionamento é um conjunto de associações entre instâncias de entidades
• Uma instância (ocorrência) é uma associação específica entre determinadas instâncias de entidade
• Exemplo (relacionamento LOTAÇÃO)– ocorrência = par específico formado por uma
ocorrência de PESSOA e uma ocorrência de DEPARTAMENTO
14
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199927
Diagrama de ocorrências
p1 p8p7
p5p6p4
p3
p2
p1,,d1 p2,d1 p4,d2p5,d3
d1 d3d2
entidadeEMPREGADO
relacionamentoLOTAÇÃO
entidadeDEPARTAMENTO
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199928
Auto-relacionamento
PESSOA
CASAMENTOmarido esposa
15
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199929
Papel de relacionamento
• Função que uma ocorrência de uma entidade cumpre em uma ocorrência de um relacionamento
• Relacionamento de casamento– Uma ocorrência de pessoa exerce o papel de marido– Uma ocorrência de pessoa exerce o papel de esposa
• Relacionamentos entre entidades diferentes:– não é necessário indicar os papéis das entidades
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199930
Auto-relacionamentodiagrama de ocorrências
p1p8
p7
p5
p6
p4
p3
p2
p1,p3
p6,p8
maridoesposa
marido
esposa
16
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199931
Cardinalidade de relacionamentos
• Propriedade importante de um relacionamento– Quantas ocorrências de uma entidade podem estar
associadas a uma determinada ocorrência de entidade através do relacionamento
• Chamada de cardinalidade de uma entidade em um relacionamento
• duas cardinalidades– máxima – mínima
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199932
Cardinalidade máxima no DER
LOTAÇÃODEPARTAMENTO
EMPREGADOn1
17
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199933
Cardinalidade máxima - DER
LOTAÇÃODEPARTAMENTO
EMPREGADOn1
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
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199934
Cardinalidade máxima no DER
expressa que a uma ocorrência de DEPARTAMENTO (entidade ao lado
oposto da anotação) podem estar associadas muitas (“n”) ocorrências de
EMPREGADO
LOTAÇÃO
DEPARTAMENTO
EMPREGADOn1
18
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199935
Cardinalidade máxima - valores
• Para projeto de BD relacional– não é necessário distinguir entre diferentes
cardinalidades máximas > 1
• Dois valores de cardinalidades máximas são usados– cardinalidade máxima 1– cardinalidade máxima “muitos”, referida pela letra n
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199936
Classificação de relacionamentos
• Cardinalidade máxima pode ser usada para classificar relacionamentos binários
• Relacionamento binário – é aquele cujas instâncias envolvem duas instâncias de
entidades
• Relacionamentos binários– n:n (muitos-para-muitos)– 1:n (um-para-muitos)– 1:1 (um-para-um)
19
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199937
Relacionamentos 1:1
PESSOA
CASAMENTO
marido1 1
EMPREGADO
ALOCAÇÃO
1
1
MESA
esposa
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199938
Relacionamentos 1:n
ALUNO INSCRIÇÃO CURSO1n
EMPREGADO DEPENDENTE1 n
EMPREGADO
SUPERVISÃO
1 nsupervisor supervisionado
20
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199939
Relacionamentos n:n
ENGENHEIRO ALOCAÇÃO PROJETOn n
MÉDICO CONSULTA PACIENTEn n
PEÇA CAPACIDADE FORNECEDORn n
PRODUTO
COMPOSIÇÃO
n ncomposto componente
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199940
Relacionamento ternário
DISTRIBUIDORCIDADE
PRODUTO
DISTRIBUIÇÃO
21
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199941
Cardinalidade em relacionamento ternário
DISTRIBUIDORCIDADE
PRODUTO
DISTRIBUIÇÃO
1
n
na cardinalidade“1” refere-sea um parcidade eproduto
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199942
Cardinalidade mínima
• 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 fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas– cardinalidade mínima 0– cardinalidade mínima 1
• Denominação alternativa:– cardinalidade mínima 1 = “associação obrigatória”– cardinalidade mínima 0 = “associação opcional”
22
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199943
Cardinalidade mínima - DER
EMPREGADO
ALOCAÇÃO
e1e4
e3
e2
e1,m1 e2,m
2
(0,1)
(1,1)
MESA
e4,m4
m1 m6m4m3
m2 m5
e3,m6
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199944
Exemplo - entidades e relacionamentos
DEPARTAMENTO RESPONSÁVEL DISCIPLINA(1,1) (0,n)
ALUNO INSCRIÇÃO CURSO(1,1)(0,n)
(0,n)
(0,n)
DISC-CURSO
PRÉ-REQUIS
(0,n) (0,n)liberadora
liberada
23
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199945
PROJETO
tipo
códigonome
Atributo
Dado ou informação que é associado a cada ocorrência de uma entidade ou de um relacionamento
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199946
Atributos com cardinalidade
• Cardinalidade mínima– atributo obrigatório (cardinalidade mínima “1”)
• cada entidade possui no mínimo um valor associado)– atributo opcional (cardinalidade mínima “0”)
• Cardinalidade máxima– atributo monovalorado (cardinalidade máxima “1”)
• cada entidade possui no máximo um valor associado)– atributo multivalorado (cardinalidade máxima “n)
24
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199947
Atributo com cardinalidade
CLIENTE
telefone (0,n)código
nome Atributo opcionale multi-valorado
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199948
Atributo em relacionamento
ENGENHEIRO ATUAÇÃO PROJETO(0,n) (0,n)
Código Nome TítuloFunção Código
25
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199949
Atributo em relacionamento 1:n
FINANCEIRA FINANCIAMENTO
VENDA(0,1)
taxa de juros
(0,n)
nº de parcelas
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199950
Identificador de entidade
• Cada entidade deve possuir um identificador
• identificador=conjunto propriedades de uma entidade (atributos e relacionamentos) cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade
26
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199951
Atributo identificador
PESSOAendereço
códigonome
PRATELEIRAnúmero da prateleira
capacidadenúmero do corredor
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199952
Relacionamento identificador
• Entidade fraca
EMPREGADO DEPENDENTE(1,1) (0,n)
nomeseqüênciacódigonúmero
nome
27
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199953
Relacionamento identificador (recursão)
(1,1)
(0,n)
GRUPO código
número daempresa
FILIAL
(1,1)
(0,n)
número dafilial
EMPRESA
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199954
Identificador de relacionamento
• Uma ocorrência de relacionamento diferencia-se das demais do mesmo relacionamento pelas ocorrências de entidades que dela participam.
ENGENHEIRO ALOCAÇÃO PROJETOn n
28
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199955
Relacionamento com atributo identificador
MÉDICO CONSULTA PACIENTEn n
data/hora
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199956
Generalização/especialização
• Conceito permite– atribuir propriedades particulares
a um subconjunto das ocorrências (especializadas) de uma entidade genérica
29
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199957
Generalização/especialização
CLIENTE
PESSOAFÍSICA
PESSOAJURÍDICA
nomecódigo
CIC CGC
FILIAL(1,1) (0,n)
sexo tipo deorganização
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199958
Generalização/especialização
• Herança de propriedades
• Herdar propriedades significa– cada ocorrência da entidade especializada possui
• além de suas próprias propriedades)• também as propriedades da ocorrência da entidade
genérica correspondente
30
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199959
Entidade associativa (BD1: agregado)
• Modificar modelo:
• Adicionar medicamentos prescritos em uma consulta
MÉDICO CONSULTA PACIENTEn n
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199960
Substituindo relacionamento por entidade
MÉDICO PACIENTE
MEDICAMENTO
PRESCRIÇÃO
(1,1)
n n
(1,1)
n
n
CONSULTA
31
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199961
Entidade associativa
MÉDICO CONSULTA PACIENTEn n
PRESCRIÇÃO
MEDICAMENTO
n
n
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199962
SímbolosDER
Conceito Símbolo
Entidade
Relacionamento
Atributo
Atributoidentificador
Relacionamentoidentificador
Generalização/especialização
Entidadeassociativa
(1,1)
32
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199963
DER de uma farmácia
PRODUTO
FABRICANTE
LOTE
FORNECEDOR
MEDICAMENTO PERFUMARIA
VENDA
RECEITAMÉDICA
(1,n)(0,n)
(1,1)
(0,n)
(1,n)(0,n)
(1,1)
(0,n)
(0,n)
(0,n)(0,n)(0,1)
(0,n)
(1,n)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199964
DER recursos humanos
EMPREGADO DEPARTAMENTO
GERENTE SECRETÁRIA ENGENHEIRO
PROCESSADORDE TEXTOS
PROJETO
DOMÍNIO PARTICIPAÇÃO
LOTAÇÃO
tipo deempregado
nome
CREA
CIC(1,1)(0,n)
(1,n)
(0,n) (0,n)
(0,n)
GERÊNCIA
(1,n)
(0,1)
p
1
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19991
Projeto lógico
modelo ER(nível conceitual)
modelo relacional(nível lógico)
Conhecimentosobre a aplicação
TransformaçãoER para
relacional
Refinamentodo modelorelacional
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19992
Transformação ER para relacional
• Regras gerais– Aplicáveis à maioria dos casos– Há situações
• por exigências da aplicação, outros mapeamentos são usados
– Implementadas em ferramentas CASE
• Objetivos básicos: – Boa performance– Simplificar o desenvolvimento
2
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19993
Passos da transformaçãoER para relacional
• Tradução inicial de entidades e respectivos atributos
• Tradução de relacionamentos e respectivos atributos
• Tradução de generalizações/especializações
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19994
Implementação inicial de entidades
• Cada entidade é traduzida para uma tabela
• Cada atributo da entidade define uma colunadesta tabela
• Atributos identificadores da entidade correspondem a chave primária da tabela.
• Tradução inicial:– Regras que seguem podem fundir tabelas
3
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19995
Implementação de entidadeexemplo
PESSOAendereço
códigonomedata de
nascimento
data deadmissão
Pessoa (CodigoPess,Nome,Endereço,DataNasc,DataAdm)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19996
Tradução de entidaderelacionamento identificador
EMPREGADO DEPENDENTE(1,1) (0,n)
nomeseqüênciacódigonúmero
nome
Dependente (CodigoEmp,NoSeq,Nome)
4
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19997
Relacionamento identificadorrecursão
(0,n)
GRUPO
EMPRESA
(1,1)
(1,1)
(0,n)
código
número daempresa
número doempregado EMPREGADO DEPENDENTE
(1,1) (0,n)
nomeseqüêncianúmero de
nome
nome
nome Grupo (CodGrup,Nome)
Empresa (CodGrup,NoEmpresa,Nome)
Empregado(CodGrup,NoEmpresa,NoEmpreg,
Nome)
Dependente (CodGrup,NoEmpresa,NoEmpreg,NoSeq,Nome)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19998
Nomes de colunas
• Referenciados freqüentemente em programas e outras formas de texto em computador
• Para diminuir o trabalho de programadores– manter os nomes de colunas curtos.
• SGBD relacional– nome de uma coluna não pode conter brancos
5
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 19999
Nomes de atributose nomes de colunas
• Não transcrever os nomes de atributos para nomes de colunas.
• Nomes de atributos compostos de diversas palavras devem ser abreviados
• Nomes de colunas não necessitam conter o nome da tabela– Preferível usar o nome de coluna Nome a usar os
nomes de coluna NomePess ou NomePessoa– SQL já exige muitas vezes forma
• Pessoa.Nome
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199910
Nome da coluna chave primária
• Chave primária– pode aparecer em outras tabelas na forma de chave
estrangeira
• Recomendável– nomes das colunas que compõem a chave primária
• sufixados ou prefixados com o nome ou sigla da tabela na qual aparecem como chave primária
– Exemplo• CodigoPess
6
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199911
Implementação de relacionamento alternativas
• Tabela própria
• Adição de colunas a uma das tabelas
• Fusão de tabelas
• Alternativa depende da cardinalidade (máxima e mínima do relacionamento)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199912
Tabela própria
ENGENHEIRO ATUAÇÃO PROJETO(0,n) (0,n)
Código Nome TítuloFunção Código
Engenheiro (CodEng,Nome)Projeto (CodProj,Título)Atuação (CodEng,CodProj,Função)
CodEng referencia EngenheiroCodProj referencia Projeto
7
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199913
Adição de colunas
DEPARTAMENTO LOTAÇÃO EMPREGADO(1,1) (0,n)
Código Nome NomeData lotação Código
Departamento (CodDept,Nome)Empregado (CodEmp,Nome,CodDept,DataLota)
CodDept referencia Departamento
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199914
Fusão de tabelas
CONFERÊNCIA ORGANIZAÇÃO COMISSÃO(1,1) (1,1)
Código Nome EnderData Instalação
Conferência (CodConf,Nome,DataInstComOrg,EnderComOrg)
8
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199915
Implementação de relacionamentos 1:1
Regra de implementaçãoTipo de relacionamento Tabela
própriaAdiçãocoluna
Fusãotabelas
(0,1) (0,1) ± 4 5
(0,1) (1,1) 5 ± 4
(1,1) (1,1) 5 5 4
4Alternativa preferida ± Pode ser usada5 Não usar
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199916
1:1 - ambas entidades opcionais exemplo
HOMEM CASAMENTO MULHER(0,1) (0,1)
Identidade Nome IdentidadeData Regime Nome
9
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199917
1:1 - ambas opcionaisadição de colunas
Mulher (IdentM,Nome,IdentH,Data,Regime)
IdentH referencia Homem
Homem (IdentH,Nome)
HOMEM CASAMENTO MULHER(0,1) (0,1)
Identidade Nome IdentidadeData Regime Nome
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199918
1:1 - ambas opcionaistabela própria
HOMEM CASAMENTO MULHER(0,1) (0,1)
Identidade Nome IdentidadeData Regime Nome
Mulher (IdentM,Nome)
Homem (IdentH,Nome)
Casamento (IdentM,IdentH,Data,Regime)
IdentM referencia Mulher
IdentH referencia Homem
10
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199919
1:1 - ambas opcionaisfusão de tabelas
HOMEM CASAMENTO MULHER(0,1) (0,1)
Identidade Nome IdentidadeData Regime Nome
Casamento (IdentM,IdentH,Data,Regime,NomeH,NomeM)
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199920
1:1 - ambas opcionaisdiscussão
• Solução por fusão de tabelas é inviável– Chave primária artificial
• 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
11
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199921
1:1 - Uma entidade opcionaloutra obrigatória
CORRENTISTA CARTÃOMAGNÉTICO
(1,1) (0,1)
Código Nome Código Data Exp.
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199922
1:1 - opcional/obrigatóriafusão de tabelas
CORRENTISTA CARTÃOMAGNÉTICO
(1,1) (0,1)
Código Nome Código Data Exp.
Correntista (CodCorrent,Nome,CodCartão,DataExp)
12
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199923
1:1 - opcional/obrigatóriaadição de colunas
CORRENTISTA CARTÃOMAGNÉTICO
(1,1) (0,1)
Código Nome Código Data Exp.
Correntista (CodCorrent,Nome)Cartão(CodCartão,DataExp,CodCorrent)
CodCorrent referencia Correntista
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199924
1:1 - opcional/obrigatóriatabela própria
CORRENTISTA CARTÃOMAGNÉTICO
(1,1) (0,1)
Código Nome Código Data Exp.
Correntista (CodCorrent,Nome)Cartão(CodCartão,DataExp)CartãoCorrentista(CodCartão,CodCorrent)
CodCorrent referencia CorrentistaCodCartão referencia Cartão
13
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199925
1:1 - opcional/obrigatóriadiscussão
• Solução por tabela própria é pior que a solução por adição de colunas– Maior número de junções– Maior número de índices– Nenhum têm problema de campos opcionais
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199926
1:1 - opcional/obrigatóriadiscussão
• Adição de colunas versus fusão de tabelas– Fusão de tabelas é melhor em termos de número de
junções e número de chaves– Adicão de colunas em melhor em termos de campos
opcionais– Fusão de tabelas é considerada a melhor e adição de
colunas é aceitável
14
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199927
1:1 - Ambas entidades tem participação obrigatória
CONFERÊNCIA ORGANIZAÇÃO COMISSÃO(1,1) (1,1)
Código Nome EnderData Instalação
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199928
1:1 - ambas obrigatóriasfusão de tabelas
CONFERÊNCIA ORGANIZAÇÃO COMISSÃO(1,1) (1,1)
Código Nome EnderData Instalação
Conferência (CodConf,Nome,DataInstComOrg,EnderComOrg)
15
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199929
1:1 - Ambas obrigatórias
• Nenhuma das demais alternativas atende plenamente
• Em ambas– Entidades que participam do relacionamento seriam
representadas através de duas tabelas distintas– Estas tabelas teriam a mesma chave primária e
relação um-para-um entre suas linhas– Maior número de junções– Maior número de chaves primárias
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199930
Relacionamentos 1:n
Regra de implementaçãoTipo de relacionamento Tabela
própriaAdiçãocoluna
Fusãotabelas
(0,1) (0,n) ± 4 5
(0,1) (1,n) ± 4 5
(1,1) (0,n) 5 4 5
(1,1) (1,n) 5 4 5
4Alternativa preferida ± Pode ser usada5 Não usar
16
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199931
1:n - caso 1
• A entidade que tem cardinalidade máxima 1 é obrigatória
DEPARTAMENTO LOTAÇÃO EMPREGADO(1,1) (0,n)
Código Nome NomeData lotação Código
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199932
1:n - caso 1adição de colunas
DEPARTAMENTO LOTAÇÃO EMPREGADO(1,1) (0,n)
Código Nome NomeData lotação Código
Departamento (CodDept,Nome)Empregado (CodEmp,Nome,CodDept,DataLota)
CodDept referencia Departamento
17
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199933
1:n - caso 1tabela própria
DEPARTAMENTO LOTAÇÃO EMPREGADO(1,1) (0,n)
Código Nome NomeData lotação Código
Departamento (CodDept,Nome)Empregado (CodEmp,Nome,Lotacao(CodEmp,CodDept,DataLota)
CodDept referencia DepartamentoCodEmp referencia Empregado
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199934
1:n - caso 1discussão
• Fusão de tabelas– Não se aplica– Implicaria em
• redundância de dados de departamento, ou• tabela aninhada
• Adição de colunas é melhor que tabela própria– Menor número de chaves– Menor número de junções– Não há o problema de campos opcionais
18
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199935
1:n - caso 2
• A entidade que tem cardinalidade máxima 1 é opcional
FINANCEIRA FINACIAM VENDA(0,1)
taxa de juros
(0,n)
nº de parcelas
Código Nome Id Data
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199936
1:n - caso 2adição de colunas
FINANCEIRA FINACIAM VENDA(0,1)
taxa de juros
(0,n)
nº de parcelas
Código Nome Id Data
Financeira (CodFin,Nome)Venda (IdVend,Data,CodFin,NoParc,TxJuros)
CodFin referencia Financeira
19
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199937
1:n - caso 2tabela própria
FINANCEIRA FINACIAM VENDA(0,1)
taxa de juros
(0,n)
nº de parcelas
Código Nome Id Data
Financeira (CodFin,Nome)Venda (IdVend,Data)Fianciam (IdVend,CodFin,NoParc,TxJuros)
IdVend referencia VendaCodFin referencia Financeira
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199938
1:n - caso 2discussão
• Implementação por tabela própria também é aceitável– É melhor em relação a campos opcionais– Perde em relação a junções e número de chaves
20
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199939
Relacionamentos n:n
Regra de implementaçãoTipo de relacionamento Tabela
própriaAdiçãocoluna
Fusãotabelas
(0,n) (0,n) 4 5 5
(0,n) (1,n) 4 5 5
(1,n) (1,n) 4 5 5
4Alternativa preferida 5 Não usar
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199940
Relacionamentos n:n
ENGENHEIRO ATUAÇÃO PROJETO(0,n) (0,n)
Código Nome TítuloFunção Código
Engenheiro (CodEng,Nome)Projeto (CodProj,Título)Atuação (CodEng,CodProj,Função)
CodEng referencia EngenheiroCodProj referencia Projeto
21
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199941
Relacionamento grau > dois
nomenome
DISTRIBUIDORCIDADE
PRODUTO
DISTRIBUIÇÃO
(0,1)
(0,n)
(0,n)código código
códigonome
data deinício
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199942
Relacionamento grau>2
• Não são definidas regras específicas– O relacionamento é transformado em uma entidade– São aplicadas regras de implementação
relacionamentos binários
22
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199943
Relacionamento grau>2
DISTRIBUIDORCIDADE
PRODUTO
(0,n)
DISTRIBUIÇÃO
(1,1)
(1,1)
(1,1)
(0,n)
(0,n)
nomenomecódigo código
códigonome
data deinício
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199944
Relacionamento grau>2
Produto (CodProd,Nome)Cidade (CodCid,Nome)Distribuidor (CodDistr,Nome)Distribuição (CodProd,CodDistr,CodCid,DataInicio)CodProd referencia ProdutoCodDistr referencia DistribuidorCodCid referencia Cidade
23
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199945
Implementação de generalização/especialização
• Duas alternativas básicas– uso de uma tabela para cada entidade– uso de uma única tabela para toda hierarquia
• Outra alternativa (exótica)– Subdivisão de entidade genérica
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199946
Generalização/especializaçãoexemplo
código nome código nome
CREA
EMPREGADO DEPARTAMENTO
SECRETÁRIAENGENHEIRO
PROCESSADOR DE
TEXTOSPROJETO
DOMÍNIO PARTICIPAÇÃO
LOTAÇÃO
tipo deempregado
nome
carteira dehabilitação
CIC(1,1)(0,n)
(1,n)
(0,n)(0,n)
(0,n)
p
RAMO DAENGENHARIA
(0,n)
(1,1)
MOTORISTA
códigocódigo nome
código nome
24
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199947
Uma tabela por hierarquia
• Todas tabelas referentes às especializações são fundidas em uma única tabela
• Tabela contém:– Chave primária correspondente ao identificador da entidade mais
genérica– Caso não exista, adicionar uma coluna Tipo– Uma coluna para cada atributo da entidade genérica – Colunas referentes aos relacionamentos dos quais participa a
entidade genérica e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade genérica
segue
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199948
Uma tabela por hierarquia
• Tabela contém (continuação):– Uma coluna para cada atributo de cada entidade especializada
(opcional)– Colunas referentes aos relacionamentos dos quais participa cada
entidade especializada e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade (campo opcional)
25
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199949
Uma tabela por hierarquia
Emp (CódigoEmp,Tipo,Nome,CIC,CodigoDept,CartHabil,CREA,CódigoRamo)
CódigoDept referencia DeptoCódigoRamo referencia Ramo
Depto (CódigoDept, Nome)Ramo (CódigoRamo,Nome)ProcessTexto (CódigoProc,Nome)Domínio (CódigoEmp,CódigoProc)
CódigoEmp referencia EmpCódigoProc referencia ProcessTexto
Projeto (CódigoProj,Nome)Participação (CódigoEmp,CodigoProj)
CódigoEmp referencia EmpCódigoProj referencia Projeto
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199950
Uma tabela por entidade especializada
• Criar uma tabela para cada entidade que compõe a hierarquia
• Incluir a chave primária da tabela correspondente à entidade genérica, em cada tabela correspondente a uma entidade especializada
26
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199951
Uma tabelapor entidadeespecializada
Emp (CódigoEmp,Tipo,Nome,CIC,CódigoDept)CódigoDept referencia Depto
Motorista(CódigoEmp,CartHabil)CódigoEmp referencia Emp
Engenheiro(CódigoEmp,CREA,CódigoRamo)CódigoEmp referencia EmpCódigoRamo referencia Ramo
Depto (CódigoDept, Nome)Ramo (CódigoRamo,Nome)ProcessTexto (CódigoProc,Nome)Domínio (CódigoEmp,CódigoProc)
CódigoEmp referencia EmpCódigo Proc referencia ProcessTexto
Projeto (CódigoProj,Nome)Participação (CódigoEmp,CódigoProj)
CódigoEmp referencia EngenheiroCódigoProj referencia Projeto
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199952
Vantagens da implementaçãocom tabela única
• Dados referentes à entidade genérica + dados referentes às especializações– em uma única linha
• Minimiza junções
• Menor número de chaves
27
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199953
Vantagens da implementação com uma tabela por entidade especializada
• Colunas opcionais – apenas aquelas referentes a atributos que podem ser
vazios do ponto de vista da aplicação.
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199954
Subdivisão da entidade genérica
• Uma tabela para cada entidade especializada que não possua outra especialização (entidade folha da árvore)
• Tabela contém– dados da entidade especializada +– dados da entidade genérica
28
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199955
Subdivisão da entidade genérica
EmpOutros (CódigoEmp,Tipo,Nome,CIC,CódigoDept)CódigoDept referencia Depto
Motorista(CódigoEmp, Nome,CIC,CódigoDept,CartHabil)Engenheiro(CódigoEmp, Nome,CIC,CódigoDept, CREA,CódigoRamo)
CódigoRamo referencia RamoDepto (CódigoDept, Nome)Ramo (CódigoRamo,Nome)ProcessTexto (CódigoProc,Nome)Domínio (CódigoEmp,CódigoProc)
Código Proc referencia ProcessTextoProjeto (CódigoProj,Nome)Participação (CódigoEmp,CódigoProj)
CódigoProj referencia Projeto
©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 199956
Subdivisão da entidade genérica
• Desvantagem:– Unicidade da chave primária
• não é garantida pelo SGBD• deve ser garantida pela aplicação
– Não há como especificar ao SGBD restrições de integridade referenciais, que façam referência ao conjunto de empregados como um todo
1
Projeto de Banco de Dados
Há múltiplas modelagens possíveis… qualescolher?
Pessomóvel (Id, Nome, Chassis, Modelo, Ano…)
Pessoas Possuem Automóveis1 N
2
Problemas na Concepção
• Redundância (espaço de armazenamento)>Proprietário de diversos automóveis !
• Atualização inconsistente>Alteração de nome em uma tupla… em todas ?!
• Anomalias de Atualização>(inclusão) Pessoa que não tem automóvel;>(exclusão) Perde informações da pessoa
quando último carro é vendido!
3
Teoria da Normalização
• Formalismos para “boa” concepção de um esquema de BD relacional>Sem informações redundantes>Evita anomalias de atualizações
• Principais conceitos envolvidos>Dependências funcionais (DFs)>Formas normais >Algoritmos de decomposição
4
Dependências Funcionais(1/8)
• O que são “Dependências” ?>Especificam propriedades sobre dados válidos
no banco de dados6Dependência de inclusão:
– “todo aluno é uma pessoa”
6Dependência funcional:– “todo empregado trabalha no máximo em um
departamento”
5
Dependências Funcionais(2/8)
• Utilização:>Verificação de restrições de integridade>Otimização de consultas>Concepção de esquemas: formas normais
• Sejam>R (A1, A2, … An); >X e Y subconjuntos de {A1, A2, … An }
6
Dependências Funcionais(3/8)
X Y“X determina Y ou
Y depende funcionalmente de X” sse
t1[X] = t2[X] ⇒ t1[Y] = t2[Y] ∀ tuplas t1, t2 em r instância de R
7
Dependências Funcionais(4/8)
Observações…• DF é assertiva para toda realização de R• DF representa restrição que deve ser sempre
verificada• DFs fazem parte do esquema de um BD>São declaradas pelo administrador do banco de
dados e controladas pelo SGBD
8
Dependências Funcionais(7/8)
• F+: Fecho de Conjunto de DFs F:>Todas DFs implicadas logicamente por F6F: {A B; B C} F+: {A B; B C; A C}
Sejam R (A1, A2,… An); F e X ⊆ {A1, A2,…An }
X é chave de R se X {A1, A2,… An } ∈ F+ enão há Y ⊆ X tal que Y {A1, A2,… An } ∈ F+
9
Dependências Funcionais(8/8)
• Se há mais de uma chave para R…>Chaves candidatas6A que for escolhida é dita chave primária
• Conceito de super-chave:>X ⊆ {A1, A2,…An } e X {A1, A2,… An } ∈ F+
6Minimalidade não exigida
• Atributo primo:>Ai ∈ {A1, A2,…An }, Ai ∈ X, com X chave de R
10
Decomposição de Esquema
A decomposição do esquema relacional R consisteda substituição de R por um conjunto de sub-esquemas { R1, R2 … Rk } onde
>Ri ⊆ R (1 ≤ i ≤ k )
>R1 ∪ R2 ∪ ... ∪ Rk = R
• Obs. Os sub-esquemas Ri não precisam ser (e normalmente não o são) disjuntos !
11
Objetivos da Decomposição
Particionar R em esquemas relacionais menores de forma a eliminar, parcial ou totalmente, as redundâncias e anomalias de atualização, com as seguintes propriedades:
> Os sub-esquemas contém a mesma informação que R> As DFs locais aos sub-esquemas são as DFs de R mapeadas para
cada Ri
Restrições e informações reproduzidas integralmente !
12
Propriedades das Decomposições
• Decomposição sem perdas>lossless join: junção das partes é equivalente ao todo!>Mais do que “perder” informações, o que se deseja é
evitar gerar informações inexistentes na relaçãooriginal!
• Decomposição preservando as DFs>As DFs válidas para R devem continuar válidas em
cada Ri da decomposição
13
Formas Normais(1/3)
• Primeira Forma Normal (1FN)>Uma relação R está em 1FN se todos os atributos são
atômicos/indivisíveis
• Segunda Forma Normal (2FN)>Uma relação R está em 2FN se estiver em 1FN e
nenhum atributo não-primo depender funcionalmentede uma parte da chave
Obs. 1FN e 2FN têm mais valor histórico…(e.g modelo NF2)
14
Formas Normais(2/3)
• Terceira Forma Normal (3FN)>Uma relação R está em 3FN se estiver em 2FN e todo
atributo não primo depender apenas de um atributoprimo; >Equivalentemente, toda DF não trivial X A de R for
tal que ora X é superchave, ora A é atributo primo
Teorema: Toda relação R admite uma decomposição em 3FN sem perdas e preservando as DFs