Transformação E-R para Relacional
Exercício Abaixo aparece um esquema parcial para um banco de dados
relacional. Identifique neste esquema as chaves primárias e chaves estrangeiras:Aluno(CodigoAluno, Nome, CodigoCurso)
Curso(CodigoCurso, Nome)
Disciplina(CodigoDisciplina, Nome, Creditos, CodigoDepartamento)
Curriculo (CodigoCurso, CodigoDisciplina,Obrigatoria-Opcional)
Conceito(CodigoAluno, CodigoDisciplina, Ano-Semestre, Conceito)
Departamento(CodigoDepartamento, Nome)
Paciente(CodigoConvenio, NumeroPaciente, Nome) CodigoConvenio referencia Convenio
Convenio (CodigoConvenio, Nome)
Medico(CRM, Nome, Especialização)
Consulta (CodigoConvenio, NumeroPaciente, CRM, Data_Hora) (CodigoConvenio,NumeroPaciente) referencia Paciente CRM referencia Medico
Explique que verificações devem ser feitas pelo SGBD para garantir integridade referencial nas seguintes situações:
Uma linha é incluída na tabela Consulta Uma linha é excluída da tabela Paciente O código do CRM em uma linha de Consulta é alterado O código do CRM em uma linha de Médico é alterado
ExercícioConsidere um banco de dados com o seguinte esquema:
Abordagem ER é voltada à modelagem de dados de forma independente
do SGBD considerado. Representação:
Abordagem Relacional - Modela os dados para um SGBD relacional. - Um modelo neste nível de abstração é chamado de
modelo lógico.- Representação:
nometabela2(chaveprimária,atributo1,atributo2)Atributo2 referencia nometabela1
entidade1 entidade2R
Transformação Entre Modelos
Transformação ER -> Relacional
As regras para a transformação ER para relacional foram definidas tendo em vista dois objetivos básicos:
obter um banco de dados que permita boa performance de instruções de consulta e alteração do BD (diminuir o número de acesso a disco, já que este consome tempo na execução de uma instrução em um BD);
obter um BD que simplifique o desenvolvimento e a manutenção de aplicações;
Regras gerais Aplicáveis à maioria dos casos Há situações
por exigências da aplicação, outros mapeamentos são usados
Implementadas em ferramentas CASEObjetivos básicos:
Boa performance Simplificar o desenvolvimento
Transformação ER -> Relacional
A fim de alcançar estes objetivos, as regras gerais de tradução foram definidas tendo por base, entre outros, os
seguintes princípios: Evitar junções; Diminuir o número de chaves primárias; Evitar/Diminuir o número de campos opcionais;
Regras gerais de tradução:
Junção: operação para buscar dados de diversas linhas associadas pela igualdade dos campos.
Exemplo: buscar os dados de um empregado e os dados de seu departamento (duas tabelas diferentes)
Embora os SGBD procurem implementar a junção de forma eficiente, ela envolve diversos acesso a disco;
Todos os dados de uma linha são trazidos para a memória em uma operação de acesso a disco. Isto significa que, uma vez encontrada uma linha da tabela, seus campos estão todos disponíveis sem necessidade de acesso adicionais a disco;
Regras gerais de tradução: Evitar junções
Preferível: ter os dados necessários a uma consulta em uma única linha;
Embora as junções são implementações NORMAIS em BD. Aqui a idéia é evitar junções desnecessárias.
Regras gerais de tradução: Diminuir o número de chaves primárias
Para implementação eficiente do controle da chave primária, o SGBD usa uma estrutura de acesso auxiliar, um índice para cada chave primária.
Índices tendem a ocupar espaço considerável em disco.
Além disso, inserção ou remoção de entradas em um índice podem exigir diversos acessos a disco;
Regras gerais de tradução: Diminuir o número de chaves primárias
podendo escolher entre 2 alternativas de implementação, uma na qual os dados aparecem em 1 única tabela e outra na qual os mesmos dados aparecem em 2 ou mais tabelas com a mesma chave primária, prefira a implementação por uma única tabela.
Veja a seguir...
1a alternativaCliente (CodCliente, nome, nomeContato, rua, cep, cidade, fone)
-> chave primária da tabela: CodCliente2a alternativa
Cliente (CodCliente, Nome, NomeContato)ClienteEnder(CodCliente, rua, cep, cidade, fone) CodCliente referencia Cliente
-> cria, para cada tabela, uma chave primária (código de cliente) (onde, as dias tabelas possuem exatamente as mesmas chaves primárias, resultando em armazenamento e processamento dobrado).
Regras gerais de tradução: Usar implementações com menos chaves
Exemplo
Regras gerais de tradução: Evitar campos opcionais
Campos opcionais = campos que podem assumir o valor VAZIO (NULL em SQL).
A princípio não há problemas em usar esse tipo de campo porque o SGBD relacional não desperdiça espaço pelo fato de campos de uma linha estarem vazios;
Campos opcionais não tem influência na performance;
Uma situação conflitante é aquela na qual a obrigatoriedade ou não do preenchimento de um campo depende do valor de outros campos. Neste caso, o controle da obrigatoriedade deve ser feito pelos programas que acessam o BD.
Controle de campo opcional pode complicarprogramação
Verificar quais campos podem estar vazios, quando isto depende do tipo de linha
Regras gerais de tradução: Evitar campos opcionais
Passos da transformaçãoER para relacional
1. Tradução inicial de entidades e respectivos atributos
2. Tradução de relacionamentos e respectivos atributos
3. Tradução de generalizações/ especializações
Implementação inicial de entidades
Cada entidade é transformada em uma tabela
Cada atributo da entidade define uma coluna desta tabela
Atributos identificadores -> compõem a chave primária da tabela
Implementação inicial de entidades
Exemplo
Pessoanome
codpess dataNasc
Pessoa (CodPess, Nome, DataNasc)
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 e ífens.
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
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
Implementação de relacionamentos
Três formas básicas de tradução:
Tabela própria Adição de colunas a uma das tabelas Fusão de tabelas
O fator determinante para a tradução em relacionamentos é a cardinalidade mínima e máxima das entidades que participam do relacionamento
Implementação de relacionamentos 1: 1
Alternativa preferida – Adição de colunas, e qualquer uma das entidade pode ser escolhida.Homens(cpfh,Nome,CRes)Mulheres(cpfm,Nome, cpfh, data, regime)
Cpfh referencia Homens
MulheresCasamentoHomens
cpfh CRes Regime
Nome
(0,1)(0,1)
cpfm
nome
Data
Quando ambas entidades têm participação opcional... Em relacionamento binários 1:1
Alternativa que pode ser usada – Tabela própria
Homens(cpfh,Nome,CRes)Mulheres(cpfm,Nome)Casamento(cpfh, cpfm,Data,Regime)
cpfm referencia MulheresCpfh referencia Homens
MulheresCasamentoHomens
cpfh CRes regime
Nome
(0,1)(0,1)
cpfm
nome
Data
Quando ambas entidades têm participação opcional... Em relacionamento binários 1:1
Fusão é inviável – cpfm e cpfh podem opcionais -> fere a regra da PK
Casamento(cpfm, cpfh, data, regime, Nomeh, Nomem)
MulheresCasamentoHomens
cpfh CRes Regime
Nome
(0,1)(0,1)
cpfm
nome
Data
Quando ambas entidades têm participação opcional... Em relacionamento binários 1:1
1: 1 - Quando ambas entidades têm participação opcional discussã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
Alternativa preferida (fusão) Clientes(Codcli,Nome,Nro,Data_exped)
- com Parcialidade em uma das entidades
Cartões MagnéticosPosseClientesCodcli NroNome Data_exped
(0,1)(1,1)
Uma entidade tem participação opcional e a outra obrigatória
RuimRuim - -se existem poucos clientes com cartão
Em relacionamento binários 1:1
Pode ser usada (Adição de colunas)Clientes(Codcli,Nome)CartõesMagnéticos(Nro, Codcli,Data_exped)
Codcli referencia clientes
- com Parcialidade em uma das entidades
Cartões MagnéticosPosseClientesCodcli NroNome Data_exped
(0,1)(1,1)
Uma entidade tem participação opcional e a outra obrigatória
Em relacionamento binários 1:1
Tabela própria não recomendadoClientes(Codcli,Nome)CartõesMagnéticos(Nro,Data_exped)CartõesClientes(Nro. Codcli,Nome, Data_exped
Codcli referencia clientes Nro referencia CartõesMagneticos
- com Parcialidade em uma das entidades
Cartões MagnéticosPosseClientesCodcli NroNome Data_exped
(0,1)(1,1)
Uma entidade tem participação opcional e a outra obrigatória
Em relacionamento binários 1:1
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
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 Adição de colunas em melhor em termos de campos
opcionais Fusão de tabelas é considerada a melhor e adição de
colunas é aceitável
Deve ser usado fusão de tabelas quando ambas entidades tem participação obrigatória
ComissõesOrganizaçãoEventos
Code
ResponsávelNro Local
Nome Data_inst_comissão
(1,1)(1,1)
Produz uma única tabela (sempre! ):Eventos(Code,Nome,Data_inst_comissão,Local, Responsável_comissão)
ou
Comissões(Nro. Local, Responsável, Data_inst_comissão, Nome_Evento)
Ambas Entidades têm participação Obrigatória
Relacionamentos binários do tipo 1:1
1: 1 - Ambas obrigatóriasDiscussão
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
Relacionamentos 1: n
Esquema relacional correspondente:
Departamento(CodDep,Nome)Empregado(CodE,Nome,contratacao, CodDep, datalotacao)
CodDep referencia Departamento
Contratacao
DataLotação
Nome
(1,1) (0,N)
CodECodDep
Nome
1: n - Caso 1 - A entidade que tem cardinalidade máxima 1 é obrigatória
Departamento EmpregadoLotação
Faz-se inserção de colunas na tabela com cardinalidade máx. 1.
Adição de colunas é a preferidaDepartamentos(Codd,Nome)Empregados(CPF,Nome,Idade,Data,Codd)
Codd referencia Departamento
(1,1)(0,N)
CoddData
Nome
IdadeNom
eCPF
1: n - Caso 1 - A entidade que tem cardinalidade máxima 1 é obrigatória
Empregados
Departamentolotação
(0,N) (1,1) (1,1) (0,N)
Tabela própria pode também ser usadaDepartamentos(Codd,Nome)Empregados(CPF,Nome,Idade)Lotações(CPF, Codd , Data) Codd referencia Departamentos CPF referencia Empregados
(1,1)(0,N)
CoddData
Nome
IdadeNom
eCPF
1: n - caso 1 - A entidade que tem cardinalidade máxima 1 é obrigatória
Empregados
Departamentolotação
(0,N) (1,1) (1,1) (0,N)
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
1: n - caso 1 - A entidade que tem cardinalidade máxima 1 é obrigatória
- adição coluna – preferida; - tabela própria – pode ser usada;
(0,N)(0,1)
CodaData
modelo
IdadeNom
ecpf
Caso 2 - Em relacionamentos 1:n onde ambas entidades tem participação opcional
Pessoas Automóveis
posse
Preferida: Adição de ColunaPessoas(cpf,Nome,Idade)Automóveis(Coda,modelo,cpf, data)
cpf referencia pessoa
(0,N)(0,1)
codaData
modelo
IdadeNom
ecpf
pessoas automoveisposse
Pode ser usada Tabela própria:pessoas(cpf,Nome,Idade)automóveis(Coda,modelo)posse(cpf,coda,Data)
cpf referencia pessoacoda referencia automoveis
Caso 2 - Em relacionamentos 1:n onde ambas entidades tem participação opcional
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
Caso 2 - Em relacionamentos 1:n onde ambas entidades tem participação opcional
Departamentos(Codd,Nome)Empregados(CPF,Nome,Idade,Data,Codd)
Codd referencia Departamento
Adição de coluna – somente!
(1,1)(1,N)
CoddData
Nome
IdadeNom
eCPF
Ambas entidades têm participação obrigatóriaEm relacionamentos binários do tipo 1:N
Empregados
Departamentolotação
Trad. Preferida e única
Tabela de regras 1:n
(0,1) (0,n)
(0,1) (1,n)
(1,1) (0,n)
+- ok x
+- ok
x ok
x
x
Tabelaprópria
Adiçãocoluna
FusãoTabelasRelacionamento 1:n
(1,1) (1,n)x ok x
Tradução de entidade com relacionamento identificador
Nome
Vínculo Dependentes(1,1) (0,N)
IdDep
Empregados
cpfemp
Modelo Relacional:Empregado (cpfemp, nome)Dependentes (CPFemp, IdDep, Nome) CPFemp referencia Empregados
Um dependente é identificado, isto é, a CHAVE PRIMÁRIA é composta pelo cpf do empregado ao qual ele está vinculado e pelo IdDep do dependente
nome Entidade fraca
Tradução de entidade com relacionamento identificador
Nome
Vínculo Dependentes(1,1) (0,N)
IdDep
Empregados
cpfemp
Modelo Relacional:Empregado (cpfemp, nome)
Dependentes (CPFemp, IdDep, Nome) CPFemp referencia Empregados
nome Entidade fracaRelacionamento
Identificador
CPFemp comporáa PK de Dependentes
Implementação inicial de entidades
Tradução de entidade - relacionamento identificador
Exercício: Qual a chave primáriada tabela Dependente?
Relacionamentos n: n
Relacionamentos n: n
Produz sempre uma tabela própria para o relacionamento:
Engenheiro(CodEng,Nome,Idade)Projetos(Codproj,Título,Duração)
Atuação(CodEng,Codproj,Função)CodEng referencia EngenheiroCodProj referencia Projeto
Duração
Função
Idade
Nome
(0,N) (0,N)
CodpCodEng
Título
Engenheiro ProjetoAtuação
Relacionamentos n: n
Tabela de regras m:n
(0,n) (0,n)
(0,n) (1,n)
(1,n) (1,n)
ok x x
ok x
ok x
x
x
Tabelaprópria
Adiçãocoluna
FusãoTabelasRelacionamento m:n
Em síntese!
Relacionamentos N: N – somente aceitam tabela própria.
Relacionamentos 1: N – preferida é adição em colunas
Atenção! Pode ser usada Tabela própria Ambas tem participação opcional (0,1)(0,N) A participação opcional é da que apresenta
cardinalidade máxima 1 (0,1)(1,N)
Síntese
Relacionamentos 1: 1 – preferida é fusão quando: ambas entidades tem participação obrigatórias (só fusão!)
ou uma tem cardinalidade opcional (preferida);
Pode ser usada Adição de colunas uma tem cardinalidade opcional (0,1)(1,1)
Quando ambas forem opcionais (0,1)(0,1) Preferida – Adição colunas Pode ser usada- tabela própria
Síntese
Implementando Generalização/Especialização
Duas alternativas básicas uso de uma única tabela para toda hierarquia uso de uma tabela para cada entidade
Outra alternativa (EXÓTICA) Subdivisão de entidade genérica
Implementando Generalização/Especialização
Cliente
Pessoa Física
PessoaJurídica
CódigoNome
CPF CNPJEsquema Relacional
Cliente(CodCli, Tipo, Nome, CPF, CNPJ)
Tipo1a. OpçãoUma tabela porhierarquia
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
Uma tabela por hierarquia - CONT
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)
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
Implementando Generalização/Especialização
Esquema Relacional
Cliente(CodCli, Tipo, Nome)
PessFisica(CodCli, CPF)
CodCli referencia Cliente
PessJurid(Codcli, CNPJ)
CodCli referencia Cliente
2a. Opção: Uma Tabela por Entidade Especializada
Cliente
Pessoa Física
PessoaJurídica
Tipo
Implementando Generalização/Especialização
Vantagens de implementação por tabela única:
•Todos os dados referentes a uma ocorrência de entidade genérica, estão em uma única linha, não necessitando criar junções;
•Minimiza junções
•A chave primária é armazenada uma única vez.
Comparação
Implementando Generalização/Especialização
Vantagens de implementação com uma tabela por entidade especializada:
•As colunas opcionais que aparecem são apenas aquelas referentes a atributos que podem ser vazios do ponto de vista da aplicação;
• O controle de colunas opcionais passa a ser feito pelo aplicação com base na coluna TIPO e não pelo SGDB como na solução alternativa.
Comparação
Síntese
Generalização – Tabela única
Cliente
PessoaFísica
t
PessoaJurídica
Código
CPFNome
CGCRazão_Social
Cliente(código,nome,CPF,RazãoSocial,CGC)Tabela única
Atributos opcionais
Generalização – Tabela p/entidade
Cliente
PessoaFísica
t
PessoaJurídica
Código
CPFNome
CGCRazãoSocial
Cliente(código)Tabela p/entidade PessoaFísica(código,CPF,nome)
PessoaJurídica(código,CGC,RazãoSocial)
código referencia Cliente
Relacionamento grau > dois
Relacionamento grau> 2
Não são definidas regras específicas O relacionamento é transformado em uma
entidade São aplicadas regras de implementação de
relacionamentos binários
Relacionamento grau> 2
Esquema relacional
Produto (CodProd, Nome)Cidade (CodCid, Nome)Distribuidor (CodDistr, Nome)Distribuição (CodProd, CodDistr, CodCid, DataInicio)
CodProd referencia ProdutoCodDistr referencia DistribuidorCodCid referencia Cidade
Relacionamento grau> 2
Refinamentos do modelo relacional
Projeto (engenharia) em geral compromisso entre o ideal e o realizável dentro
das restrições de recursos impostas pelas prática
Projeto de banco de dados compromisso entre o ideal (regras de
implementação) e o alcançável frente a limitações de performance
Refinamentos do modelo relacional
Algumas vezes esquema de BD criado através do uso das regras
acima não atende requisitos de performance impostos ao sistema
Necessário buscar alternativa que resulte em melhor performance do sistema
Alternativas somente devem ser tentadas em último caso Do ponto de vista da programação são sempre
piores
Relacionamentos mutuamente exclusivos Simulação de atributos multivalorados Informações redundantes
Refinamentos do modelo relacional
Relacionamentos mutuamente exclusivos
Implementação pelas regras colunas CIC e CGC em Venda são especificadas
como opcionaisPessFis(CIC, Nome)PessJur( CGC, RazSoc)Venda( Nro, data, CIC, CGC)
CIC referencia PessFisCGC referencia PessJur
colunas CIC e CGC em Venda são especificadas como opcionais
Relacionamentos mutuamente exclusivos
Implementação alternativa criar uma única coluna na qual aparece o CIC ou
o CGC do compradorPessFis( CIC ,Nome)PessJur( CGC, RazSoc)Venda( No ,data, CIC/ CGC, TipoCompr)
Desvantagem Não é possível especificar ao SGBD que o
campo CIC/ CGC é chave estrangeira • não referencia uma única tabela
Relacionamentos mutuamente exclusivos
Tratamento de atributos multivalorados
Atributos multivaloradosimplementação padrão
Cliente (CodCli, Nome)
Telefone (CodCli, Número)CodCli referencia Cliente
Atributos multivaloradosalternativa
Condições de contorno: Raros clientes possuem mais que dois telefones.
Quando isso ocorrer é suficiente armazenarmos apenas dois números. Não há consultas ao banco de dados usando o
número de telefone como critério de seleção Números de telefone são apenas exibidos ou
impressos juntos às demais informações de cliente
Simulação de atributos multivalorados
Implementação “desnormalizada”
Cliente (CodCli, Nome, NumTel1, NumTel2)
Simular uma coluna multivalorada através dacriação de diversas colunas NumTel sufixadaspor um número
Simulação de atributos multivalorados
Permite que os telefones de um cliente sejam obtidos mais rapidamente
Implica em menos espaço ocupado não é necessária chave primária da tabela
Telefone Inconveniente
Consulta usando o número de telefone como critério de busca torna- se mais complicada
Manter os telefones "alinhados à esquerda" exige rotina complexa
Informações redundantes
Exemplo: atributos que resultam de uma operação que
envolve diversas entidades do banco de dados valor destes atributos
deve ser obtido com freqüência ou serve freqüentemente como critério de busca
de informações no banco de dados Pode ser mais eficiente (performance global do
sistema) armazenar redundantemente o atributo derivado
Informações redundantesExemplo
Aula preparada baseada no material enviado pelo prof. Heuser autor do livro Projeto de Banco de Dados