Temos uma dependência parcial pois Quantidade depende de Codproduto, pois para cada produto da Venda há uma quantidade certa

 Quantidade depende de 3 campos, dos 4 que compõe a chave de Venda o Quem sobra nessa história é Codcidade

o A chave Codcidade em Venda é redundante, portanto podemos eliminá-la  Venda (Codvenda, Codcliente, Codproduto, Quantidade, PrecoTotal)  Problema:

o Existe alguma necessidade de manter CodCidade como campo não-chave?  O próximo campo não-chave é PreçoTotal

 Avaliando PreçoTotal da mesma forma que Quantidade

o Chega-se à conclusão de que ele depende de toda a chave de Venda.

3FN

 Uma relação encontra-se na 3a. Forma Normal se está na 2a. Forma Normal e se não existirem atributos descritores (não pertencentes a nenhuma Chave Candidata) a dependerem funcionalmente de outros atributos descritores (não-chaves)

 Após a aplicação das regras da 2FN se ainda restarem dados redundantes na tabela avaliada pode-se empregar a 3FN

 Terceira Forma Normal (3FN):

o Efetivamente, uma tabela encontra-se na terceira forma normal, quando, além de estar na 2FN, não contém dependências transitivas

o Dependência transitiva:

 Uma dependência funcional transitiva ocorre quando uma coluna, além de depender da chave primária da tabela, depende de outra coluna ou conjunto de colunas da tabela.

o Assim sendo, cada atributo deve depender apenas das Chaves Candidatas da relação.

Caso 5

 Em Pedidos, existem atributos que identificam:

o um cliente (nome do cliente e endereço completo) o um vendedor (nome do vendedor)

 Os dados dos atributos: o NomeCliente o EndCliente o CidCliente o UFCliente

 são dependentes de CodCliente

o Podemos criar outra entidade => Cliente

 Da mesma forma, NomeVendedor é dependente de CodVendedor

FNBC

 Uma relação está na forma normal de Boyce-Codd se e somente se, para todas as dependências funcionais X -> Y existentes na relação, X é chave ou super-chave da relação

 A 2FN e a 3FN só tratam dos casos de dependência parcial e transitiva de atributos fora de qualquer chave (primária ou candidata). Aplica-se a FNBC quando:

o Encontramos duas ou mais chaves candidatas

o As chaves candidatas são compostas (apresentam mais de um atributo)

o Todas as chaves candidatas têm um atributo em comum

 Uma tabela está na FNBC se e somente se toda DF (dependência funcional) não trivial e irredutível à esquerda tem uma chave candidata como determinante

 A Forma Normal de Boyce/Codd foi criada com a intenção de resolver algumas situações que não eram inicialmente cobertas pelas três primeiras formas normais

o Foco especial para quando haviam várias chaves na entidade formadas por mais de um atributo

o E que compartilhavam ao menos um atributo

 Isso porque as formas normais tratam atributos dependentes das chaves primárias

 Para estar na FNBC, uma entidade precisa possuir somente atributos que são chaves candidatas

Caso 6

 Assumindo que um professor possa estar associado a mais de uma escola e uma sala.  Aluno (NomeAluno, EnderecoAluno, NomeEscola, NumeroSala, NomeProfessor)  Chaves candidatas:

o NomeAluno+EnderecoAluno o NomeAluno+NumeroSala o NomeAluno+NomeProfessor  Encontramos três chaves candidatas

o Todas apresentam mais de um atributo (concatenados) o Todas compartilham um mesmo atributo: NomeAluno

 Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas o uma que contém todos os atributos que descrevem o aluno o outra que contém os atributos que designam um professor em uma

determinada escola e número de sala

 Aluno (NomeAluno, EnderecoAluno, NomeEscola, NumeroSala)  Sala (NomeEscola, NumeroSala, NomeProfessor)

Resumo

o 1. Cria-se uma tabela na 1FN referente à tabela N e que contém apenas colunas com valores atômicos, isto é, sem as tabelas aninhadas;

o 2. Para cada tabela aninhada, cria-se uma tabela na 1FN compostas pelas seguintes colunas:

 A chave primária de uma das tabelas na qual a tabela em questão está aninhada

 As colunas da própria tabela

o 3. São definidas as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas

 2FN

o 1. Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além da chave

o 2. Para cada tabela com chave primária composta e com pelo menos uma coluna não chave

 Criar na 2FN uma tabela com as chaves primárias da tabela na 1FN

 Para cada coluna não chave fazer a seguinte pergunta: ”a coluna

depende de toda a chave ou de apenas parte dela”

 Caso a coluna dependa de toda a chave

 Criar a coluna correspondente na tabela com a chave completa na 2FN

 Caso a coluna não dependa apenas de parte da chave

 Criar, caso ainda não existir, uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão

 Criar a coluna dependente dentro da tabela na 2FN  3FN

o Copiar para o esquema da 3FN cada tabela que tenha menos de duas colunas não chave, pois neste caso não há como haver dependências transitivas

o Para tabelas com duas ou mais colunas não chaves, fazer a seguinte pergunta: ”a coluna depende de alguma outra coluna não chave?”

o Caso dependa apenas da chave

 Copiar a coluna para a tabela na 3FN

o Caso a coluna depender de outra coluna

 Criar, caso ainda não exista, uma tabela no esquema na 3FN que tenha como chave primária a coluna na qual há a dependência indireta

 Copiar a coluna dependente para a tabela criada

 A coluna determinante deve permanecer também na tabela original

 Em geral uma relação na BCNF já está na 4FN e 5FN, que surgem para resolver problemas muito raros

 Uma relação encontra-se na 4FN, se está na BCFN e não existem dependências multivalor

 Uma relação R está na 5FN se não puder ser mais decomposta sem perda de informação.

 A normalização na 4a. Forma Normal requer que não exista nenhuma dependência multi-valorada não-trivial de conjuntos de atributos em algo mais de que um superconjunto de uma chave candidata

 Mesmo tendo chegado na 3FN, pode ser que a uma entidade contenha um ou mais fatos multivalorados

 Exemplos:

5FN

 A 5a. Forma Normal requisita a não existência de dependências de joins não triviais que não venham de restrições chave.

 A 5a. Forma Normal lida com relacionamentos múltiplos (ternário, quaternário, etc)

 Uma entidade estará na 5FN, se estando na 4FN, não for possível reconstruir as informações originais a partir do conteúdo dos outros registros menores

 O processo de Normalização ajuda imensamente o projetista do Banco de

Dados, porém, em alguns casos, algumas formas normais eventualmente, podem ser ignoradas, visando o aprimoramento da performance do sistema

Caso 9

 Sistema de uma loja de materiais elétricos:

o Venda de materiais como fios, fusíveis, lâmpadas, etc

o Padrões de entrada do cliente: postes de concreto, caixa de medidor, etc o Na venda de um padrão, o sistema deve baixar o estoque de cada um dos seus

componentes

o Cada um desses componentes pode ser comprado pela loja individualmente, ou sejam podem constar de vários pedidos de compra

Caso 10

 Se realizarmos uma junção dessas três entidades, utilizando o atributo NumeroPedido como o determinante, teremos como resultado o seguinte:

 Se a junção for efetuada tomando o atributo Fornecedor, o resultado será:  Entidade:

 Novamente, um registro que não existia na relação original é gerado  Durante o processo de normalização de dados, descobre-se duas situações,

diametralmente opostas:

o o número de campos das tabelas diminui enquanto o número de tabelas aumenta

 O SGBD gerencia tranquilamente e eficientemente, as associações que vão aumentando em função de análise do profissional

Exemplo