Projeto de Banco de Dados - n4n3.files.wordpress.com · ©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 1999

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


Modelo de Dados - níveis de abstração

abstração

modelo conceitual

modelo lógico

modelo físico

2


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


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


Diagrama entidade-relacionamento

Produt o

códigodescrição

Tipo deprodut o

códigodescrição

preço

n 1


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


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


Modelo lógico para o exemplo

TipoDeProduto(CodTipoProd,DescrTipoProd)

Produto(CodProd,DescrProd,PrecoProd,CodTipoProd)CodTipoProd referencia TipoDeProduto

5


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


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


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.


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


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



• 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



• Modelo de dados é representado através de um– modelo entidade-relacionamento (modelo ER)

• Modelo ER é representado graficamente– diagrama entidade-relacionamento (DER)


Conceitos centrais da abordagem ER

• Entidade

• Relacionamento

• Atributo

• Generalização/especialização

• Entidade associativa

9


Entidade

Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de

dados


Entidade – exemplos

• Sistema de informações industrial– produtos– tipos de produtos– vendas– compras

10


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)


PESSOA DEPARTAMENTO

Entidade no DER

• Representada através de um retângulo

• Retângulo contém o nome da entidade.

11


Entidade e instância

• Para referir um objeto particularfala-se em instância ou ocorrência de entidade


Entidade e instância - terminologia

conjunto elemento do conjunto

entidade instância

classe instância

conjuntode entidades

entidade

12


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


Relacionamento - conceito

Conjunto de associações entre entidades sobre as quais deseja-se manter informações

na base de dados

13


Relacionamento no DER

DEPARTAMENTO LOTAÇÃO PESSOA


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


Diagrama de ocorrências

p1 p8p7

p5p6p4

p3

p2

p1,,d1 p2,d1 p4,d2p5,d3

d1 d3d2

entidadeEMPREGADO

relacionamentoLOTAÇÃO

entidadeDEPARTAMENTO


Auto-relacionamento

PESSOA

CASAMENTOmarido esposa

15


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


Auto-relacionamentodiagrama de ocorrências

p1p8

p7

p5

p6

p4

p3

p2

p1,p3

p6,p8

maridoesposa

marido

esposa

16


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


Cardinalidade máxima no DER

LOTAÇÃODEPARTAMENTO

EMPREGADOn1

17


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


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


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


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


Relacionamentos 1:1

PESSOA

CASAMENTO

marido1 1

EMPREGADO

ALOCAÇÃO

1

1

MESA

esposa


Relacionamentos 1:n

ALUNO INSCRIÇÃO CURSO1n

EMPREGADO DEPENDENTE1 n

EMPREGADO

SUPERVISÃO

1 nsupervisor supervisionado

20


Relacionamentos n:n

ENGENHEIRO ALOCAÇÃO PROJETOn n

MÉDICO CONSULTA PACIENTEn n

PEÇA CAPACIDADE FORNECEDORn n

PRODUTO

COMPOSIÇÃO

n ncomposto componente


Relacionamento ternário

DISTRIBUIDORCIDADE

PRODUTO

DISTRIBUIÇÃO

21


Cardinalidade em relacionamento ternário

DISTRIBUIDORCIDADE

PRODUTO

DISTRIBUIÇÃO

1

n

na cardinalidade“1” refere-sea um parcidade eproduto


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


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


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


PROJETO

tipo

códigonome

Atributo

Dado ou informação que é associado a cada ocorrência de uma entidade ou de um relacionamento


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


Atributo com cardinalidade

CLIENTE

telefone (0,n)código

nome Atributo opcionale multi-valorado


Atributo em relacionamento

ENGENHEIRO ATUAÇÃO PROJETO(0,n) (0,n)

Código Nome TítuloFunção Código

25


Atributo em relacionamento 1:n

FINANCEIRA FINANCIAMENTO

VENDA(0,1)

taxa de juros

(0,n)

nº de parcelas


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


Atributo identificador

PESSOAendereço

códigonome

PRATELEIRAnúmero da prateleira

capacidadenúmero do corredor


Relacionamento identificador

• Entidade fraca

EMPREGADO DEPENDENTE(1,1) (0,n)

nomeseqüênciacódigonúmero

nome

27


Relacionamento identificador (recursão)

(1,1)

(0,n)

GRUPO código

número daempresa

FILIAL

(1,1)

(0,n)

número dafilial

EMPRESA


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


Relacionamento com atributo identificador


data/hora


Generalização/especialização

• Conceito permite– atribuir propriedades particulares

a um subconjunto das ocorrências (especializadas) de uma entidade genérica

29



CLIENTE

PESSOAFÍSICA

PESSOAJURÍDICA

nomecódigo

CIC CGC

FILIAL(1,1) (0,n)

sexo tipo deorganizaçã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


Entidade associativa (BD1: agregado)

• Modificar modelo:

• Adicionar medicamentos prescritos em uma consulta



Substituindo relacionamento por entidade

MÉDICO PACIENTE

MEDICAMENTO

PRESCRIÇÃO

(1,1)

n n

(1,1)

n

n

CONSULTA

31


Entidade associativa


PRESCRIÇÃO

MEDICAMENTO

n

n


SímbolosDER

Conceito Símbolo

Entidade

Relacionamento

Atributo

Atributoidentificador

Relacionamentoidentificador


Entidadeassociativa

(1,1)

32


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)


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


Projeto lógico

modelo ER(nível conceitual)

modelo relacional(nível lógico)

Conhecimentosobre a aplicação

TransformaçãoER para

relacional

Refinamentodo modelorelacional


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


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


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


Implementação de entidadeexemplo

PESSOAendereço

códigonomedata de

nascimento

data deadmissão

Pessoa (CodigoPess,Nome,Endereço,DataNasc,DataAdm)


Tradução de entidaderelacionamento identificador

EMPREGADO DEPENDENTE(1,1) (0,n)

nomeseqüênciacódigonúmero

nome

Dependente (CodigoEmp,NoSeq,Nome)

4


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)


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


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

6


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)


Tabela própria



Engenheiro (CodEng,Nome)Projeto (CodProj,Título)Atuação (CodEng,CodProj,Função)

CodEng referencia EngenheiroCodProj referencia Projeto

7


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


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


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


1:1 - ambas entidades opcionais exemplo

HOMEM CASAMENTO MULHER(0,1) (0,1)

Identidade Nome IdentidadeData Regime Nome

9


1:1 - ambas opcionaisadição de colunas

Mulher (IdentM,Nome,IdentH,Data,Regime)

IdentH referencia Homem

Homem (IdentH,Nome)




1:1 - ambas opcionaistabela própria



Mulher (IdentM,Nome)

Homem (IdentH,Nome)

Casamento (IdentM,IdentH,Data,Regime)

IdentM referencia Mulher

IdentH referencia Homem

10


1:1 - ambas opcionaisfusão de tabelas



Casamento (IdentM,IdentH,Data,Regime,NomeH,NomeM)


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


1:1 - Uma entidade opcionaloutra obrigatória

CORRENTISTA CARTÃOMAGNÉTICO

(1,1) (0,1)

Código Nome Código Data Exp.


1:1 - opcional/obrigatóriafusão de tabelas


(1,1) (0,1)


Correntista (CodCorrent,Nome,CodCartão,DataExp)

12


1:1 - opcional/obrigatóriaadição de colunas


(1,1) (0,1)


Correntista (CodCorrent,Nome)Cartão(CodCartão,DataExp,CodCorrent)

CodCorrent referencia Correntista


1:1 - opcional/obrigatóriatabela própria


(1,1) (0,1)


Correntista (CodCorrent,Nome)Cartão(CodCartão,DataExp)CartãoCorrentista(CodCartão,CodCorrent)

CodCorrent referencia CorrentistaCodCartão referencia Cartão

13


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


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


1:1 - Ambas entidades tem participação obrigatória




1:1 - ambas obrigatóriasfusão de tabelas



Conferência (CodConf,Nome,DataInstComOrg,EnderComOrg)

15


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


Relacionamentos 1:n



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


1:n - caso 1

• A entidade que tem cardinalidade máxima 1 é obrigatória




1:n - caso 1adição de colunas



Departamento (CodDept,Nome)Empregado (CodEmp,Nome,CodDept,DataLota)

CodDept referencia Departamento

17


1:n - caso 1tabela própria



Departamento (CodDept,Nome)Empregado (CodEmp,Nome,Lotacao(CodEmp,CodDept,DataLota)

CodDept referencia DepartamentoCodEmp referencia Empregado


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


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


1:n - caso 2adição de colunas


taxa de juros

(0,n)

nº de parcelas


Financeira (CodFin,Nome)Venda (IdVend,Data,CodFin,NoParc,TxJuros)

CodFin referencia Financeira

19


1:n - caso 2tabela própria


taxa de juros

(0,n)

nº de parcelas


Financeira (CodFin,Nome)Venda (IdVend,Data)Fianciam (IdVend,CodFin,NoParc,TxJuros)

IdVend referencia VendaCodFin referencia Financeira


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


Relacionamentos n:n



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


Relacionamentos n:n



Engenheiro (CodEng,Nome)Projeto (CodProj,Título)Atuação (CodEng,CodProj,Função)

CodEng referencia EngenheiroCodProj referencia Projeto

21


Relacionamento grau > dois

nomenome

DISTRIBUIDORCIDADE

PRODUTO

DISTRIBUIÇÃO

(0,1)

(0,n)

(0,n)código código

códigonome

data deinício


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



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



Produto (CodProd,Nome)Cidade (CodCid,Nome)Distribuidor (CodDistr,Nome)Distribuição (CodProd,CodDistr,CodCid,DataInicio)CodProd referencia ProdutoCodDistr referencia DistribuidorCodCid referencia Cidade

23


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


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


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



• 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



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


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


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


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


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.


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



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



• 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


• 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


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


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


• 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


• 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

Documents

Projeto de Banco de Dados - n4n3.files.wordpress.com · ©Carlos A. Heuser - Transparências para uso com o livro Projeto de Banco de Dados, Ed. Sagra&Luzzatto, Porto Alegre, 1999