Um esquema de relação R está na 1FN se todos os seus atributos forem

(1)

Normalização

184

Critérios de Qualidade

Semântica dos Atributos da Relação

Projete um esquema da relação que seja fácil de explicar seu resultado.

Não combine atributos de diversos tipos de entidades e tipos de relacionamentos em uma única relação.

Projete um esquema de relação que corresponda a um único tipo de entidade ou a um único tipo de relacionamento: o significado tende a ser mais claro.

ECO031 Banco de Dados Aulas Teóricas -Fabiana Costa Guedes

185

Critérios de Qualidade

Informações Redundantes em Tuplas e Anomalias de Atualização

Projete um esquema da relação de maneira que nenhuma anomalia de modificação, remoção ou inserção ocorra nas relações.

EMP-DEPT (Nome, @Id, DataNasc, Endereco, NumDepto, NomeDepto, Gerente)

Anomalia de Modificação – ao trocar o nome de gerente de um departamento, tenho que fazê-lo em todas as tuplas de empregados que pertencem ao departamento considerado.

Anomalia de Remoção – ao remover o último empregado de um departamento, todas as informações sobre o departamento desaparecem do banco de dados.

Anomalia de Inserção – ao inserir um novo empregado em um departamento, tenho que inserir todas as informações sobre o departamento ou deixar alguns campos relativos ao departamento com valores nulos.

ECO031 Banco de Dados Aulas Teóricas

-Fabiana Costa Guedes 186

Critérios de Qualidade

Valores Nulos em Tuplas

Tanto quanto possível, evite colocar atributos em uma relação cujos valores podem ser nulos: gasto de memória, problemas de interpretação dos atributos (não se aplica a uma tupla, é

desconhecido, não foi fornecido ainda), especificação de operações de JOIN e contabilização (SUM e COUNT)

187

Critérios de Qualidade

Tuplas espúrias

Projete esquemas de relação de tal forma que elas possam ser JOINED: as novas tuplas geradas pela operação de JOIN tem significado no mundo real

EMP-LOC = {@EmpNome, @ProjLoc} EMP-PROJ = {@Id, @ProjNum, Horas, ProjNome, ProjLoc}

Após o Join:

EMP-LOC X EMP-PROJ = {Id, ProjNum, Horas, ProjNome, ProjLoc, EMpNome} com combinações que não existem na realidade.

ECO031 - Banco de Dados - Aulas Teóricas - 188

Dependência Funcional

Restrição entre dois conjuntos de atributos do BD, que estabelece que os valores de um atributo dependem ou são determinadas por valores de outro atributo.

A dependência é uma propriedade do significado ou semântica dos atributos, indicando que um conjunto de atributos relaciona-se com outro conjunto.

(2)

-189

Dependência Funcional

Sempre que houver relação entre

estes dois conjuntos de atributos, a

dependência é especificada como

uma restrição.

Esta restrição deve valer o tempo

todo, para todas as instâncias de

atributos.

Dependência Funcional

-Exemplo

O nome de um cliente de um banco é funcionalmente dependente do número da conta (NumConta NomeCliente). Dado um número de conta, é possível encontrar um único cliente (a conta não é conjunta).

O contrário não é verdade: dado o nome de um cliente, posso determinar várias contas. Assim, número de conta não é

funcionalmente dependente de nome de cliente.

191

Normalização

Processo de

decomposição

de um

esquema de relação em outros

esquemas de relação que:

não têm informação redundante, que poderia gerar problemas de atualização mantem a semântica original dos dados:

mesmo conjunto de restrições de integridade sem perda de dados e seus relacionamentos

192

Normalização

Objetiva eliminar anomalias de

armazenamento e semânticas que

implicarão em maior esforço

computacional para manter e

manipular o banco de dados.

São regras que visam atender os

critérios de qualidade.

193

Normalização

A normalização é a ferramenta para auxiliar no projeto físico, porém só é suficiente teoricamente.

Na prática provou-se que a normalização não é suficiente.

A teoria da normalização serve para verificar se os esquemas do projeto físico satisfazem algumas características básicas. Se tornou muito mais um método de verificação, do que de definição como foi proposto.

194

Forma Desnormalizada

É uma tabela na qual itens que

aparecem mais de uma vez não foram

removidos.

Não se pode gerenciar bem dados

usando este tipo de tabela em um

banco de dados relacional.

É preciso dividir a tabela.

(3)

195

Primeira Forma Normal – 1FN

Um esquema de relação

R

está na

1FN se

todos

os seus atributos forem

atômicos

e

monovalorados

, ou seja,

não possuem valores que formam

atributos compostos.

196

Primeira Forma Normal – 1FN

Refere-se a uma tabela simples,

bidimensional, resultante da divisão da

original desnormalizada.

Pode ser considerada como uma

tabela com um item em cada célula.

A tabela é dividida para que nenhum

item apareça mais de uma vez.

197

Primeira Forma Normal – 1FN

Identifique atributos (ou grupos) que possuam múltiplos valores para uma ocorrência da entidade.

Remova da entidade considerada, os atributos multivalorados e gere uma nova entidade que possuirá esses atributos mais uma cópia da chave primária.

No caso de atributos estruturados, cada campo da estrutura passa a ser um atributo da entidade a qual o atributo estruturado pertence.

Primeira Forma Normal – 1FN

- Exemplo

ESTUDANTES = {@MATRÍCULA + NOME + ENDEREÇO + CODCURSO} e ENDEREÇO é um atributo composto, ENDEREÇO = {RUA + NUMERO + BAIRRO + CIDADE + UF}.

Para colocar na 1FN faz: ESTUDANTES =

{@MATRÍCULA+NOME+RUA+NUMERO+BAIRRO+CIDADE+U F+CODCURSO}

FUNCIONÁRIOS = {@CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATAFIM}}

Para colocar na 1FN faz:

FUNCIONÁRIOS = {@CODFUNC + NOME + CARGO} FUNC_PROJ = {@CODFUNC + @PROJETO + DATAINI + DATAFIM}

Observação: todas as tabelas são relações na 1FN.

199

Primeira Forma Normal – 1FN

- Exemplo

Pedido= {@Numero_Pedido, Codigo_Cliente, Nome_cliente, Codigo_produto, quantidade_produto, Desc-Produto}

Após 1FN

Pedido= {@Numero_Pedido, Codigo_Cliente, Nome_cliente}

Item= {@Numero_Pedido, @Codigo_produto, quantidade_produto, Desc-Produto}

ECO031 - Banco de Dados - Aulas Teóricas - 200

Segunda Forma Normal – 2FN

Um esquema de relação está na 2FN se: estiver na 1FN e, além disso, todo atributo que não pertença a alguma de suas chaves for totalmente dependente da sua chave primária.

Em outras palavras, para que uma relação esteja na 2FN é preciso que esteja na 1FN e que, havendo uma chave primária composta, todos os dados que não são chaves dependem de toda a chave primária (a chave primária completa).

(4)

-201

Segunda Forma Normal – 2FN

Refere-se a uma tabela na qual uma

chave que pode identificar dados

determina os valores de outras

colunas.

A tabela é dividida para que valores

em outras colunas sejam

funcionalmente dependentes da chave

primária.

202

Segunda Forma Normal – 2FN

Identificar atributos dependentes somente de parte da chave primária

Remova da entidade considerada, os atributos dependentes e gere uma nova entidade que possuirá os atributos dependentes mais uma cópia de parte da chave primária, aquela dos quais os atributos eram dependentes.

203

Segunda Forma Normal – 2FN

- Exemplo

ESTOQUE = {PRODUTO + ALMOX + END_ALMOX + UNID_EST + QTD + PRECO}

Não está na 2FN porque alguns dados não chave dependem somente de parte da chave, como END_ALMOX depende só de ALMOX, e UNID_EST depende só de PRODUTO. Com a normalizando ficaria:

ESTOQUE1 = {@PRODUTO + UNID_EST} ESTOQUE2 = {@ALMOX + END_ALMOX} ESTOQUE3 = {@PRODUTO + @ALMOX + QTD + PRECO}

Segunda Forma Normal – 2FN

- Exemplo

Pedido= {@Numero_Pedido, Codigo_Cliente, Nome_cliente} Item= {@Numero_Pedido,

@Codigo_produto, quantidade_produto, Desc-Produto}

Após a 2FN

Item= {@Numero_Pedido, @Codigo_produto, quantidade_produto}

Produto = {@Codigo_produto, Desc_Produto}

205

Terceira Forma Normal – 3FN

Um esquema de relação está na 3FN se: estiver na 2FN e, além disso, nenhum atributo que não pertença a alguma das suas chaves for transitivamente dependente da sua chave primária. Em outras palavras, para que uma relação esteja na 3FN é preciso que esteja na 2FN e todo atributo, que não pertença a alguma chave for não dependente de algum outro atributo, que também não pertença a alguma chave.

206

Terceira Forma Normal – 3FN

Uma tabela é dividida para que um

valor não seja determinado por

nenhuma chave não-primária.

(5)

207

Terceira Forma Normal – 3FN

Identificar atributos dependentes de

outros atributos não chave

Remova da entidade considerada, os

atributos dependentes juntamente com

uma cópia do atributo do qual

depende

208

Terceira Forma Normal – 3FN

- Exemplo

MÚSICA = {@CÓDIGO + TÍTULO + GÊNERO + PAÍS_ORIGEM}, supondo que neste exemplo, o PAÍS_ORIGEM refere-se ao GÊNERO musical e não a música, sendo assim, apesar de estar na 2FN, a relação não está na 3FN, pois existe dependência entre GÊNERO e PAÍS_ORIGEM. Com a normalizando ficaria:

MÚS_1 = {@CÓDIGO + TÍTULO + GÊNERO} MÚS_2 = {@GÊNERO + PAÍS_ORIGEM}

209

Terceira Forma Normal – 3FN

- Exemplo

Item= {@Numero_Pedido, @Codigo_produto, quantidade_produto}

Produto = {@Codigo_produto, Desc_Produto} Após 3FN

Pedido= {@Numero_Pedido, Codigo_Cliente} Cliente= {@Codigo_cliente, Nome_Cliente} Item= {@Numero_Pedido, @Codigo_produto, quantidade_produto}

Produto = {@Codigo_produto, Desc_Produto}

Formas Normal

211

Exercícios

A que se refere a expressão “relação desnormalizada”? Defina primeira, segunda e terceira formas normais. Sejam os seguintes dados de uma locadora de automóveis:

A locadora aluga automóveis de uma determinada marca apenas para clientes pessoa jurídica (empresas). Estes clientes credenciam motoristas para utilizarem os veículos. preço diário de aluguel e a potência do carro dependem de seu modelo. Considerando que a locadora necessite, para seu controle, dos dados descritos na seguinte relação:

REGISTRO_ALUGUEL = {@NumCNH + NomeMotorista + DataNasc + CGCCliente + NomeCliente + EndCliente + {@PlacaCarro + Modelo + Cor + Potência + QTDDiárias + PreçoDiária}}

Faça a normalização.