banco de dados i - buchinger.github.io · projeto lógico É um modelo baseado em regras objetivos...

Banco de Dados I

Prof. Diego Buchinger

[email protected]

[email protected]

Profa. Rebeca Schroeder Freitas

Prof. Fabiano Baldo

Projeto Lógico

Projeto Lógico

Pode haver “n” maneiras de

“implementar” uma representação

abstrata (conceitual)

Modelo representado de forma textual

Representa como os dados serão agrupados

Se baseia na tecnologia de BD

Modelo

Conceitual

Modelo

Lógico #1

Modelo

Lógico #n

Projeto Lógico

É um modelo baseado em regras

Objetivos e Princípios:

Bom desempenho

Evitar junções de registros – ter os dados necessários em

um único registro

Diminuir número de chaves; evitar chaves desnecessárias –

chaves ocupam espaço adicional em disco

Evitar campos opcionais

Menor manutenibilidade

Projeto Lógico

Passos para a transformação [conceito] → [lógico]

1. Tradução das Entidades e seus Atributos

2. Tradução de Generalizações / Especializações

3. Tradução de Relacionamentos e seus Atributos

* Passos para a transformação em modelo relacional

Projeto Lógico

Nomenclatura :

Chave Primária: atributo identificador;

identifica unicamente um registro

Chave Estrangeira: uma referência a chave primária

de outra tabela

Chave Alternativa: atributo identificador que não é

uma boa chave primária, pois seria uma chave

estrangeira ruim

Representação:

NomeTabela (coluna1, coluna2, ... , coluna n)

Mapeamento de Entidades e Atributos

Entidade → Tabela

Atributo de Entidade → Coluna da Tabela

Atributos Identificadores → Chave Primária

Livros (#ISBN, titulo, edicao)

Notação:

# – atributo que faz parte de chave primária

& – atributo que faz parte de chave estrangeira

[] – atributo opcional

Mapeamento de Entidades e Atributos

Exemplo: Como ficaria o mapeamento lógico?

Mapeamento de Atributo

Opcional, Composto e Multivalorado

Atributo opcional se torna uma coluna opcional

Atributo composto é decomposto em colunas

Atributo multivalorado se torna uma nova tabela

Clientes ( #RG , nome , [CNH] , rua , bairro , CEP )

Email ( #&RG , #email ) ou Email ( #cod, &RG , email )

Poderia ser

Email( #&RG, email )

???

Mapeamento de Especializações

Tabela única para toda hierarquia

Atributos de entidade especializada vira opcional

Cria-se restrições de integridade para especializações

Restrições de Integridade:

se Pessoa Física

→ tipo = 1 / CPF ≠ null

se Pessoa Jurídica

→ tipo = 2 / CNPJ ≠ null

Pessoas ( #código , nome, endereco, [CPF] , [CNPJ] )


Tabelas para entidade genérica e especializadas

Entidades especializadas ganham chave estrangeira

Pessoas ( #código , nome , endereco )

PessoasFisicas (#&código , CPF )

PessoasJurídicas (#&código , CNPJ )


Tabelas somente para as entidades especializadas

Entidades especializadas herdam atributos da

entidade genérica

Não aplicável a especializações parciais!

PessoasFisicas (#&código ,

nome , endereco , CPF )

PessoasJurídicas (#&código ,

nome , endereco , CNPJ )


As especializações podem ser projetadas como:

Tabela única para toda hierarquia

o boa quando especializações não tem muitos atributos

Tabelas para entidade genérica e especializadas

o boa quando entidades genérica e especializadas

possuem muitos atributos e/ou relacionamentos

Tabelas somente para as entidades especializadas

o boa quando a entidade genérica possui poucos atributos

e relacionamentos, mas não aplicável em alguns casos


Exercício 2: Como ficaria o mapeamento lógico?

Mapeamento de Relacionamentos

• O projeto lógico dos relacionamentos depende da

cardinalidade mínima e máxima

• Os relacionamentos podem ser projetadas como:

Fusão entre entidades relacionadas

oComum para cardinalidades menores

Adição de colunas para representar relacionamento

o Comum para relacionamentos opcionais

Nova tabela para relacionamento

o Comum para cardinalidades maiores

Mapeamento Relacionamento 1:1

Relacionamento obrigatório em ambos os sentidos

Fusão de entidades

Eventos ( #código, nome, dataInstCom, nroCom, nomeCom )


Relacionamento opcional em um dos sentidos

Opção 1: fusão de entidades

Bibliotecárias ( #código, nome, [codArea],

[nomeArea], [periodicidade] )


Relacionamento opcional em um dos sentidos

Opção 2: uso de chave estrangeira em uma tabela

Bibliotecárias ( #código, nome )

Áreas ( #codArea, &codBiblio, nome, periodicidade )


Relacionamento opcional em ambos os sentidos

Opção 1: criar tabela para relacionamento

Pessoa ( #RG, nome ) [usada para esposa e marido]

Casamento ( #&RGM, #&RGE, regime )

(+) organização

(-) mais chaves


Relacionamento opcional em ambos os sentidos

Opção 2: uso de chaves estrangeiras na(s) tabela(s)

Pessoa ( #RG, nome, [&RGConjuge], [Regime] ) [usada para esposa e marido]

(+) simples

(-) atributos opcionais

Mapeamento Relacionamento 1:N

Relacionamento obrigatório ou opcional no lado N

Uso de chaves estrangeiras no lado N

Editoras ( #código, nome )

Livros ( #ISBN, titulo, &codEditora, dataPublicacao )


Relacionamento opcional no lado 1

Opção 1: criar tabela para relacionamento com chave

da tabela do lado N

Estantes ( #número, capacidade )

Livros ( #ISBN, titulo)

Localizacao ( #&ISBN, &nroEstante, nroControle )


Relacionamento opcional no lado 1

Opção 2: criar chave estrangeira na tabela do lado N

Estantes ( #numero, capacidade )

Livros ( #ISBN, titulo, [&nroEstante], [nroControle] )

Mapeamento de Entidades Fracas

Chave primária da entidade forte se torna chave

estrangeira na entidade fraca

Sócios (#matrícula, dataNascimento)

Dependentes (#&matrícula, #nroSequência, nome)

Mapeamento de Entidades Fracas


Mapeamento Relacionamento N:N

Relacionamento obrigatório ou opcional em

ambos os sentidos

Criar nova tabela usando as chaves dos dois lados


Compras ( #número, ordemCompra )

Pedido ( #&ISBN, #&nroCompra, quantidade )

Mapeamento Relacionamento N:N

Relacionamento obrigatório ou opcional em

ambos os sentidos

Criar nova tabela usando as chaves dos dois lados


Compras ( #número, ordemCompra )

Pedido ( #idPed, &ISBN, &nroCompra, quantidade )

As vezes é melhor criar uma nova

chave primária para a nova tabela ao

invés de usar uma chave composta!

Mapeamento Relacionamento com

Entidades Associativas

Solução varia de acordo com as cardinalidades

Livros ( #ISBN, ... ) Clientes ( #rg, ... )

Bibliotecárias ( #rg, ... )

Empréstimos ( #idEmp, &ISBN, &rgCliente, &rgBibli, data, [dtDev] )




Conta ( #número, &rgCliente, [&nroCartao], [dataExp] )

Cliente ( #rg, ... )

Solução 1:




Conta( #nroConta, #&rgCliente )

Cliente ( #rg, ... )

CartoesMagneticos ( #número, dataExp, &nroConta )

Solução 2:

Mapeamento Relacionamento Ternários

Relacionamento N:N:N

Criar nova tabela para a relação com todas as chaves

Distribuidores ( #&cnpj, ... )

Produtos( #codigo, ... ) Cidades ( #codigo, ... )

Distribuição( #&cnpjDistr, #&codProd, #&codCidade, data )


Relacionamento 1:N:N

Criar nova tabela para a relação com todas as chaves,

sendo a chave do lado 1 apenas estrangeira

Pesquisadores ( #RG , ... ) Projetos( #número , ... )

Instituições ( #sigla, ... )

Pesquisa ( #&rgPesq, #&nroProj, &siglaInst, dataInicio )


Relacionamento 1:1:N

Entidade do lado N recebe chaves estrangeiras

Bairros ( #código, ... )

Carteiros ( #rg, ... )

Correspondências ( #código, peso, &rgCarteiro, &codBairro )


Relacionamento 1:1:1

Criar uma tabela única unificada

Veículo ( #numSérie, #numModelo, nomeModelo,

códigoCarroceria, obsCarroceria )

Projeto Lógico

Exercício 5:

Mapear o

diagrama ER

ao lado em

um projeto

lógico.

Dicionário de Dados

O modelo lógico deve se preocupar também em como

os dados serão representados, ou seja, a sua tipagem.

ALUNOS

Atributo Domínio Tamanho Restrição de

Integridade Descrição

matrícula Numérico Chave

primária Matrícula do aluno

nome Texto 50 Não nulo Nome do aluno

rg Numérico Chave

alternativa RG do aluno

cred Numérico Não nulo Quantidade de

créditos cursados

Dicionário de Dados

Também pode ser produzido por software

FABForce → DBDesigner

No momento não vamos nos

preocupar com os tipos aceitos

pelos BD relacionais (cada SGBD

tem as suas peculiaridades)

http://fabforce.eu/downloads.php

https://dbdesigner.net/





Projeto Lógico

Exercício 6: Faça o mapeamento lógico do seguinte diagrama ER e

escreva o dicionário de dados:

N

Projeto Lógico

Exercício 7: Mapear o diagrama

ER ao lado em um projeto lógico

(não é necessário elaborar o

dicionário de dados)

banco de dados i - buchinger.github.io · projeto lógico É um modelo baseado em regras objetivos...

Documents