Apresentação do PowerPoint

Banco de Dados II
Prof. Fiorin
[email protected]
Recapitulando

Na aula passada falamos sobre

Modelagem Conceitual

2
Modelo/Diagrama Entidade-Relacionamento
[email protected]
Aula 02
Mapeamento entre Modelos
3
[email protected]
Modelos de Dados

Definições

Modelo de dados: descrição de tipos de informações que estão
armazenadas em um banco de dados.
Modelo de Dados
=
Descrição formal da estrutura
de um banco de dados
4
[email protected]
Modelos de Dados

5
Definições

Modelo conceitual: descreve os dados de maneira próxima ao
modo como os usuários percebem os dados.

Modelo lógico: modelo intermediário (mapeamento interno).

Modelo físicos: descrevem os detalhes de como os dados são
armazenados no computador.
[email protected]
Modelos de Dados

Definições

Modelo conceitual: É uma descrição do banco de dados de
forma independente de implementação ou SGBD.

Registra quais dados podem aparecer no banco de dados, mas
não registra como são armazenados.
Modelo Conceitual
=
Modelo de dados abstrato, que
descreve a estrutura de um
banco de dados
independente de um SGBD
6
[email protected]
Modelos de Dados

7
Modelo Conceitual

A técnica mais utilizada na modelagem conceitual é a abordagem
Entidade-Relacionamento (ER).

Representado através de um diagrama (DER).
[email protected]
Modelos de Dados

Definições

Modelo Lógico: descrição de um banco de dados no nível de
abstração visto pelo usuário do SGBD.

Depende do SGBD que está sendo utilizado.
Modelo Lógico
=
Modelo de dados que
representa a estrutura de
dados conforme vista pelo
usuário do SGBD
8
[email protected]
Modelos de Dados

Modelo Lógico

Exemplo
TipoDeProduto (CodTipoProd, DescrTipoProd)
Produto (CodProd, DescrProd, PrecoProd, CodTipoProd)
CodTipoProd referencia TipoDeProduto.
9
[email protected]
Modelos de Dados

10
Modelo Físico

Detalhes de armazenamento interno.

Não influencia na programação de aplicações no SGBD.

Influencia na performance das aplicações.

Usados por profissionais que fazem sintonia (tunning) de banco
de dados, para otimizar a performance.

Linguagem padronizada de acordo com o produto.
[email protected]
Modelos de Dados

O projeto de banco de dados é dividido em 3 fases:

Modelagem conceitual


Projeto lógico


Transformação do modelo conceitual em um modelo lógico. Define
como o banco de dados será implementado em um SGBD.
Projeto físico

11
Construção do modelo conceitual na forma de DER. Identificação das
necessidades da organização em termos de armazenamento de
dados de forma independente de implementação.
Especificação dos detalhes de hardware.
[email protected]
Modelos de Dados

12
Projeto de Banco de Dados
[email protected]
Mapeamento entre modelos
13
[email protected]
Mapeamento entre modelos

Regras gerais de tradução

Evitar junções (diminuir linhas de consultas SQL)


Diminuir o número de chaves

Evitar campos opcionais (campos que aceitam valores nulos)

14
Mais acessos a disco
Em alguns SGBDs, controle de obrigatoriedade deve ser feito pelos
programas de aplicação cliente.
[email protected]
Mapeamento entre modelos

15
Passos para a transformação do DER para o modelo
lógico
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
[email protected]
Mapeamento entre modelos

Implementando as entidades

Cada entidade é transformada em uma tabela;

Cada atributo da entidade define uma coluna da tabela;

Atributos identificadores da entidade correspondem a chave
primária da tabela;

Tradução inicial

16
Algumas regras podem “fundir” tabelas
[email protected]
Mapeamento entre modelos

Transformação do DER para o modelo lógico

Entidades fracas
Empregado (codigo, nome)
Dependente (CodEmp, nSeq, nome)
17
[email protected]
Mapeamento entre modelos

Transformação do DER para o modelo lógico

18
Entidades fracas recursivas
[email protected]
Mapeamento entre modelos

Nomenclatura de colunas

Não necessariamente precisam ser iguais aos nomes definidos no
DER;

São frequentemente referenciados em programas e outras formas
de texto em computador;

Elaborar nomes curtos, porém específicos para as colunas


19
Facilita o trabalho dos programadores
Os nomes de colunas não podem conter espaços (SGBD)
[email protected]
Mapeamento entre modelos

20
Nomenclatura de colunas

Da mesma forma que as entidades, o nome dos atributos é
especificado sempre no singular;

Nomes de atributos compostos de mais de uma palavra devem
ser abreviados;

Nome de colunas não necessitam conter o nome da tabela

É preferível usar o nome de coluna Nome ao invés de usar nomes de
colunas como NomePessoa (exceto para chaves estrangeiras!).

Muitas vezes, no SQL, o nome da tabela deve ser especificado antes
do nome do atributo (coluna). Exemplo:
– Pessoa.Nome
[email protected]
Mapeamento entre modelos

Nomenclatura de colunas – Chave Primária

Pode aparecer em outras tabelas na forma de chave estrangeira;

Dica altamente recomendável


Nomes das colunas que compõem a chave primária devem ser
sufixados ou prefixados com a sigla (ou nome) da tabela no qual ela
aparece como chave primária.
Exemplo:
–
CodEmpresa
– idPessoa
– nCliente
21
[email protected]
Mapeamento entre modelos

Alternativas

22
A implementação de relacionamentos depende diretamente da
cardinalidade do relacionamento

Tabela própria

Adição de colunas em uma das tabelas

Fusão de tabelas
[email protected]
Mapeamento entre modelos

Tabela própria
Engenheiro (codEng, nome)
Projeto (codProj, titulo)
Atuacao (codEng, codProj, funcao)
codEng referencia a tabela Engenheiro
codProj referencia a tabela Projeto
23
[email protected]
Mapeamento entre modelos

Adição de colunas
Departamento (codDep, nome)
Empregado (codEmp, nome, codDep, dataLota)
codDep rereferencia a tabela Departamento
24
[email protected]
Mapeamento entre modelos

Fusão de tabelas
Conferencia (codConf, nome, dataInstComOrg, EnderComOrg)
25
[email protected]
Mapeamento entre modelos

26
Relacionamentos 1:1
[email protected]
Mapeamento entre modelos

27
Relacionamento 1:1, ambas entidades opcionais
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, ambas entidades opcionais –
Adição de Colunas
Homem (idH, nome)
Mulher (idM, nome, idH, data, regime)
idH referencia a tabela Homem
28
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, ambas entidades opcionais – Tabela
Própria
Homem (idH, nome)
Mulher (idM, nome)
Casamento (idH, idM, data, regime)
idH referencia a tabela Homem
idM referencia a tabela Mulher
29
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, ambas entidades opcionais – Fusão
de Tabelas
Casamento (idH, nomeH, data, regime, idM, nomeM)
30
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, ambas entidades opcionais

Solução por fusão é inviável!


Solução por colunas é a melhor



31
Chave primária artificial
Menor número de junções
Menor número de chaves
Solução por tabela própria é aceitável
[email protected]
Mapeamento entre modelos

32
Relacionamento 1:1, uma entidade opcional e outra
obrigatória
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, uma entidade opcional e outra
obrigatória – Fusão de Tabelas
Correntista (codCor, nome, codCartao, dtExp)
33
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, uma entidade opcional e outra
obrigatória – Adição de Colunas
Correntista (codCor, nome)
Cartao (codCartao, dtExp, codCor)
codCor referencia a tabela Correntista
34
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, uma entidade opcional e outra
obrigatória – Tabela Própria
Correntista (codCor, nome)
Cartao (codCartao, dtExp)
CartaoCorrentista (codCartao, codCor)
codCor referencia a tabela Correntista
codCartao referencia a tabela Cartao
35
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, uma entidade opcional e outra
obrigatória

36
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
[email protected]
Mapeamento entre modelos

37
Relacionamento 1:1, ambas entidades obrigatórias
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, ambas entidades obrigatórias –
Fusão de Tabelas
Conferencia (codConf, nome, dtInstComOrg, EnderComOrg)
38
[email protected]
Mapeamento entre modelos

Relacionamento 1:1, ambas entidades obrigatórias

Nenhuma das outras alternativas atende plenamente

Em ambas




39
Entidades que participam do relacionamento seriam representadas
através de duas tabelas distintas;
Estas tabelas teriam a mesma chave primária e relação 1:1 entre
suas linhas;
Maior número de junções;
Maior número de chaves primárias.
[email protected]
Mapeamento entre modelos

40
Relacionamentos 1:n
[email protected]
Mapeamento entre modelos

41
Relacionamento 1:n, entidade com cardinalidade máxima
1 obrigatória
[email protected]
Mapeamento entre modelos

Relacionamento 1:n, entidade com cardinalidade máxima
1 obrigatória – Adição de colunas
Departamento (codDep, nome)
Empregado (codEmp, nome, codDep, dtLotacao)
codDep referencia a tabela Departamento
42
[email protected]
Mapeamento entre modelos

Relacionamento 1:n, entidade com cardinalidade máxima
1 obrigatória – Tabela Própria
Departamento (codDep, nome)
Empregado (codEmp, nome)
Lotacao (codEmp, codDep, dtLotacao)
codDep referencia a tabela Departamento
codEmp referencia a tabela Empregado
43
[email protected]
Mapeamento entre modelos

Relacionamento 1:n, entidade com cardinalidade máxima
1 obrigatória

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


44
Menor número de chaves
Menor número de junções
[email protected]
Mapeamento entre modelos

45
Relacionamento 1:n, entidade com cardinalidade máxima
1 opcional
[email protected]
Mapeamento entre modelos

Relacionamento 1:n, entidade com cardinalidade máxima
1 opcional – Adição de Colunas
Financeira (codFin, nome)
Venda (idVenda, codFin, nParc, txJuros)
codFin referencia a tabela Financeira
46
[email protected]
Mapeamento entre modelos

Relacionamento 1:n, entidade com cardinalidade máxima
1 opcional – Tabela Própria
Financeira (codFin, nome)
Venda (idVenda, data)
Financiam (idVendA, codFin, nParc, txJuros)
codFin referencia a tabela Financeira
codVenda referencia a tabela Venda
47
[email protected]
Mapeamento entre modelos

Relacionamento 1:n, entidade com cardinalidade máxima
1 opcional

48
Implementação por tabela própria também é aceitável, porém
perde em relação a junções e número de chaves
[email protected]
Mapeamento entre modelos

49
Relacionamentos n:n
[email protected]
Mapeamento entre modelos

Relacionamento n:n – Tabela própria (regra geral)
Engenheiro (codEng, nome)
Projeto (codProj, titulo)
Atuacao (codEng, codProj, funcao)
codEng referencia a tabela Engenheiro
codProj referencia a tabela Projeto
50
[email protected]
Mapeamento entre modelos

Implementação de Generalização/Especialização

51
Existem duas alternativas
básicas

Uso de uma tabela para
cada entidade

Uso de uma única tabela
para toda a hierarquia
[email protected]
Mapeamento entre modelos

Implementação de Generalização/Especialização

52
Uma tabela por hierarquia

Todas as tabelas referentes às especializações são fundidas em uma
única tabela

A tabela deve conter
–
A 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.
[email protected]
Mapeamento entre modelos

Implementação de Generalização/Especialização

53
Uma tabela por hierarquia

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).
[email protected]
Mapeamento entre modelos

Implementação de Generalização/Especialização

Uma tabela por hierarquia – Exemplo
Empregado (codEmp, nome, CIC, codDep, tipo, cnh, CREA, codRamo)
codDep referencia a tabela Departamento
codRamo referencia a tabela Ramo
Departamento (codDep, Nome)
Ramo (codRamo, nome)
ProcessTexto (codProc, nome)
Dominio (codEmp, codProc)
codEmp referencia a tabela Empregado
codProc referencia a tabela ProcessTexto
Projeto (codProj, nome)
Participacao (codEmp, codProj)
codEmp referencia a tabela Empregado
codEmp referencia a tabela Projeto
54
[email protected]
Mapeamento entre modelos

Implementação de Generalização/Especialização

55
Uma tabela por entidade especializada

Criar uma tabela para cada entidade que compõe a hierarquia.

Incluir a chave primária da tabela correspondente da entidade
genérica, em cada tabela correspondente de uma entidade
especializada.
[email protected]
Mapeamento entre modelos

Implementação de Generalização/Especialização

Uma tabela por entidade especializada – Exemplo
Empregado (codEmp, tipo, nome, CIC, codDep)
codDep referencia Departamento
Motorista (codEmp, cnh)
codEmp referencia Empregado
Engenheiro (codEmp, CREA, codRamo)
codEmp referencia Empregado
codRamo referencia Ramo
Departamento (codDep, nome)
Ramo (codRamo, nome)
Projeto (codProj, nome)
ProcessTexto (codProc, nome)
Participacao (codEmp, codProj)
Dominio (codEmp, codProc)
codEmp referencia Empregado
codEmp referencia Engenheiro
codProc referencia ProcessTexto
codProj referencia Projeto
56
[email protected]
Referências
57

HEUSER, C. A. Projeto de Banco de Dados. Sagra
Luzzatto. Porto Alegre, 1998.

Elmasri, Navathe – Sistemas de banco de dados. 6ª
edição. Pearson.
[email protected]