Normalização
- Material filtrado da Internet: (Temporário)
1 Dependência Funcional
1.1 Categorias
2 Normalização
2.1 1FN
2.1.1 Caso 1
2.1.2 Caso 2
2.2 2FN
2.2.1 Caso 3
2.2.2 Caso 4
2.3 3FN
2.3.1 Caso 5
2.4 FNBC
2.4.1 Caso 6
2.5 Resumo
2.6 4FN
2.6.1 Caso 7
2.6.2 Caso 8
2.7 5FN
2.7.1 Caso 9
2.7.2 Caso 10
3 Exemplo
3.1 1a. Forma Normal
3.2 2a. Forma Normal
3.3 3a. Forma Normal
3.4 Forma Normal de Boyce-Codd
3.5 4a. Forma Normal
3.6 5a. Forma Normal
4 Exercícios
- Depend�ncia Funcional
Consiste numa restrição entre dois conjuntos de atributos de uma mesma entidade/relação Uma dependência funcional é representada pela relação X -> Y, em que X e Y são subconjuntos de atributos de uma relação qualquer Isso impõe uma restrição na qual um componente Y de uma tupla (registro) é dependente de um valor do componente X (ou é determinado por ele) Do mesmo modo, o valores do componente X determinam de forma unívoca os valores do componente Y Resumindo, Y é dependente funcionalmente de X
Supondo o esquema de uma relação abaixo, onde os três primeiros atributos, cujos nomes se encontram destacados, representam a chave primária da relação
MatriculaAluno CodigoCurso CodigoDisciplina NomeAluno DataMatricula NomeCurso NomeDisciplina NotaProva
- - - - - - - -
Podemos estabelecer 4 dependências funcionais neste exemplo:
1. MatriculaAluno -> {NomeAluno, DataMatricula) => O valor do atributo MatriculaAluno determina o valor dos atributos NomeAluno e DataMatricula
2. CodigoCurso -> NomeCurso => O valor do atributo CodigoCurso determina o valor do atributo NomeCurso
3. CodigoDisciplina -> NomeDisciplina => O valor do atributo CodigoDisciplina determina o valor do atributo NomeDisciplina
4. {MatriculaAluno, CodigoCurso, CodigoDisciplina} -> NotaProva => A combinação de valores dos atributos MatriculaAluno, CodigoCurso e CodigoDisciplina determina o valor do atributo NotaProva.
- Categorias
Total ou Completa:
Podemos ter situações em que não se utilizam atributos simples para determinar os valores de outros atributos
Neste caso, teremos um atributo que é dependente funcional da combinação de dois ou mais atributos
Quando um atributo que não faz parte da chave primária depende funcionalmente de todos os atributos que fazem parte da chave, tem-se uma dependência funcional total.
É considerado o 1o. tipo, onde a dependência só existe se a chave primária composta por vários atributos determinar univocamente um atributo ou um conjunto de atributos
No nosso exemplo, o atributo NotaProva é dependente total da chave primária formada pelos atributos MatriculaAluno/ CodigoCurso/CodigoDisciplina.
Exemplo: Entidade DEPENDENTE
(CodigoPaciente, DataNascimento} -> {NomeDependente} (?)
No caso, os valores dos atributos CodigoPaciente e DataNascimento determinam o valor para o atributo NomeDependente
O nome do dependente só pode ser determinado em função de dois atributos
Parcial:
Temos uma situação em que um atributo/conjunto de atributos depende de outro(s) atributo(s) que não fazem parte de uma chave primária
Quando um atributo que não faz parte da chave primária depende funcionalmente de apenas alguns dos atributos que fazem parte da chave primária
o 2o. tipo, então, ocorre quando o atributo/conjunto de atributos depende apenas de parte dos valores da chave primária
Exemplo: Banco de Dados com as entidades MEDICO e PACIENTE
CRM -> NomeMedico
CodigoPaciente -> {NomePaciente, CPF, RG }
A 1a, dependência especifica que o valor atributo CRM da entidade MEDICO determina de forma unívoca o valor do atributo NomeMedico dessa mesma entidade
O valor do atributo CodigoPaciente (entidade PACIENTE) determina o nome, o CPF e o RG do paciente
É importante notar que apenas o valor dos atributos CRM e CodigoPaciente é necessário para que seja possvel determinar o nome do médico ou o CPF e RG do paciente, ou seja, é uma dependência parcial
Transitiva ou Indireta:
Esta dependência ocorre quando a dependência funcional se realiza entre atributos que não fazem parte da chave primária
Exemplo:
Numa tabela de Vendas, temos o atributo PreçoTotal. Este campo é o resultado do valor unitário do produto multiplicado pela quantidade, isto é, para um preço total existir ele DEPENDE de valor unitário e quantidade
O ValorUnitário deve estar numa tabela Produtos, relacionada à venda e Quantidade está na própria tabela Vendas. PreçoTotal depende destes dois campos e eles não são campos-chave.
- Normalização
Após a construção do modelo conceitual dos dados (Modelo Entidade/Relacionamento) é feita a transformação para o modelo lógico (Esquema de Tabelas)
O desenho de tabelas obtido representa a estrutura da informação de um modo natural e completo.
Normalização é um processo baseado nas chamadas formais normais
Uma forma normal é uma regra que deve ser aplicada na construção das tabelas do banco de dados para que estas fiquem bem estruturadas
A normalização pode ser entendida como um processo submetido a estas varias formas normais
Objetivo principal: eliminar a redundância nos dados armazenados em tabelas, resultando na diminuição do espaço e dos riscos de inconsistências em atualizações de dados
Quando um atributo é alterado em uma tabela que não está totalmente normalizada, é necessário alterá-lo em todas as linhas em que ele ocorre, haja visto a sua repetição
Tal operação poderia ser executada apenas uma vez, caso este atributo estivesse normalizado
As formas têm uma ordem e são dependentes, isto é, para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante.
Efetivamente, a Normalização tem como objetivo avaliar a qualidade do Modelo de Tabelas e transformá-lo (em caso de necessidade) num Modelo (Conjunto de Tabelas) equivalente, menos redundante e mais estável.
- 1FN
Verificação de Tabelas Aninhadas
Uma relação está na 1a. Forma Normal se e somente se cada linha contiver exatamente um valor para cada atributo
Dado que as Relações(Tabelas) são estruturas bidimensionais, então no cruzamento de uma linha com uma coluna (atributo) só é possível armazenar valores atômicos.
Para isso, não deve conter tabelas aninhadas
Um jeito fácil de verificar esta norma é fazer uma leitura dos campos das tabelas fazendo a pergunta:
Este campo depende de algum outro?
Se sim, então devemos arrumar um método para corrigir o problema.
Método:
Remover o grupo de repetição
Expandir a chave primária
Seguindo a definição devemos normalizar a tabela decompondo-a em duas
Uma relação R está na 1FN se:
Todo valor em R for atômico
Ou seja, R não contém grupos de repetição
Considerações:
Geralmente considerada parte da definição formal de uma relação
Não permite atributos multivalorados, compostos ou suas combinações
- Caso 1
cliente (NroCliente, Nome, {End-Cliente})
Corrigindo o problema:
Solução: cliente (NroCliente, Nome, End-Cliente, CidCliente, UFCliente)
- Caso 2
Exemplificando com a tabela Venda
Esquema relacional da tabela:
Venda
Codvenda (Int)
Cliente (Str)
Endereco (Str)
Cep (Int)
Cidade (Str)
Estado (Str)
Telefone (Int)
Produto (Str)
Quantidade (Float)
ValorUnitário (Float)
PreçoTotal (Float)
Análise:
A tabela Venda, deve armazenar informações da venda
O campo Cliente é dependente de CodVenda, afinal para cada Venda há um cliente
Campo Endereço: não depende de Codvenda, e sim de Cliente, pois é uma informação particular ao cliente
Não existe um endereço de venda, existe sim um endereço do cliente para qual se fez a venda
Nisso podemos ver uma tabela aninhada. Os campos entre colchetes, são referentes ao cliente e não é venda
Venda (Codvenda, [Cliente, Endereço, Cep, Cidade, Estado, Telefone], Produto, Quantidade, ValorUnitário, PreçoTotal)
Solução:
Extrair estes campos para uma nova tabela
Adicionar uma chave-primária à nova tabela
Relacioná-la com a tabela Venda criando uma chave-estrangeira
Resultado:
Cliente (Codcliente, Nome, Endereço, Cep, Cidade, Estado, Telefone).
Venda (Codvenda, Codcliente, Produto, Quantidade, ValorUnitário, PreçoTotal).
Aplicando novamente a 1a. forma normal às 2 tabelas geradas
Uma situação comum em tabelas de cadastro é o caso Cidade-Estado
Analisando friamente pela forma normal, o Estado na tabela Cliente, depende de Cidade
No entanto Cidade, também depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre deverá ser Paraná, porém se o Estado for Paraná, a cidade também poderá ser Londrina
Isso é o que chamamos de Dependência funcional:
aparentemente, uma informação depende da outra
No caso Cidade-Estado a solução é simples:
Extraímos Cidade e Estado, de Cliente e geramos uma nova tabela
Em seguida, o mesmo processo feito anteriormente:
Adicionar uma chave-primária à nova tabela e relacioná-la criando uma chave-estrangeira na antiga tabela
Cidade (Codcidade, Nome, Estado).
Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone)
Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, ValorUnitário, PreçoTotal)
Seguindo com o exemplo, a tabela Cliente encontra-se na 1a. forma normal, pois não há mais tabelas aninhadas
Verificando Venda, identificamos mais uma tabela aninhada
Os campos entre colchetes são referente à mesma coisa: Produto de Venda
Venda (Codvenda, Codcliente, Codcidade, [Produto, Quantidade, Valorunitario, Valorfinal])
Na maioria das situações, produtos têm um valor previamente especificado
O ValorUnitário depende de Produto
Já a Quantidade não depende do Produto e sim da Venda
Cidade (Codcidade, Nome, Estado)
Cliente (Codcliente, Codcidade, Nome, Endereço, Cep, Telefone)
Produto (Codproduto, Nome, ValorUnitário)
Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)
Utilizando a 1a. Forma Normal na tabela Venda, obtivemos 3 tabelas
- 2FN
A 2a. Forma Normal exige um pouco mais de conhecimento sobre as dependências funcionais, prioritariamente para a dependência funcional total
Uma relação está na 2a. Forma Normal se estiver na 1a. e se todos os atributos descritores (não pertencentes a nenhuma chave candidata) dependerem da totalidade da chave (e não apenas de parte dela)
Isso quer dizer que uma tabela encontra-se na 2FN, quando, além de estar na 1FN, não contem dependências parciais
Dependência parcial = uma dependência parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta
Resumindo, a entidade se encontra na 2FN se, além de estar na 1a., todos os seus atributos são totalmente dependentes da chave primária composta
Significa que atributos que são parcialmente dependentes devem ser removidos.
Se observarmos as tabelas e identificarmos repetição dos dados nas tuplas requer-se a 2FN
Relendo cada campo e questionando:
Este campo depende de toda a chave?
Se não, temos uma dependência parcial
- Caso 3
Uma entidade Item possui chave primária composta que é constituída pelos atributos NumPedido e CodProduto
Os atributos Descricao e PrecoUnit não dependem totalmente dessa chave, ao contrário de Quantidade e ValorTotal
Nova entidade: Produto
Entidades:
Arquivo:BDA-Normalizacao-2FN.pdf
Tabelas populadas:
Arquivo:BDA-Normalizacao-2FN-b.pdf
- Caso 4
Reavaliando o caso Cidade-Estado que gerava uma dependência funcional
Após a normalização da tabela Venda, obtivemos uma chave composta de 4 campos:
Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, PreçoTotal)
A questão agora é verificar se cada campo não-chave depende destas 4 chaves
Procedimento:
O 1o. campo não-chave é Quantidade Quantidade depende de Codvenda => Para cada venda há uma quantidade específica de itens Quantidade depende de Codvenda e Codcliente => Para um cliente podem ser feitas várias vendas, com quantidades diferentes Quantidade não depende de Cidade e quem depende de Cidade é Cliente 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
Quem sobra nessa história é Codcidade
A tabela Cidade já está ligada com Cliente, que já está ligada com Venda
A chave Codcidade em Venda é redundante, portanto podemos eliminá-la
Venda (Codvenda, Codcliente, Codproduto, Quantidade, PrecoTotal)
Problema:
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
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):
Efetivamente, uma tabela encontra-se na terceira forma normal, quando, al�m de estar na 2FN, n�o cont�m depend�ncias transitivas
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
Assim sendo, cada atributo deve depender apenas das Chaves Candidatas da rela��o.
- Caso 5
Em Pedidos, existem atributos que identificam:
um cliente (nome do cliente e endere�o completo)
um vendedor (nome do vendedor)
Os dados dos atributos:
NomeCliente
EndCliente
CidCliente
UFCliente
s�o dependentes de CodCliente
Podemos criar outra entidade => Cliente
Da mesma forma, NomeVendedor � dependente de CodVendedor
Entidades:
Arquivo:BDA-Normalizacao-3FN.pdf
Tabelas populadas:
Arquivo:BDA-Normalizacao-3FN-B.pdf
- 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:
Encontramos duas ou mais chaves candidatas
As chaves candidatas s�o compostas (apresentam mais de um atributo)
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
Foco especial para quando haviam v�rias chaves na entidade formadas por mais de um atributo
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:
NomeAluno+EnderecoAluno
NomeAluno+NumeroSala
NomeAluno+NomeProfessor
Encontramos tr�s chaves candidatas
Todas apresentam mais de um atriobuto (concatenados)
Todas compartilham um mesmo atributo: NomeAluno
Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas
uma que cont�m todos os atributos que descrevem o aluno
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
1FN
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;
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
3. S�o definidas as chaves prim�rias das tabelas na 1FN que correspondem a tabelas aninhadas
2FN
1. Copiar para a 2FN cada tabela que tenha chave prim�ria simples ou que n�o tenha colunas al�m da chave
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
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
Para tabelas com duas ou mais colunas n�o chaves, fazer a seguinte pergunta: �a coluna depende de alguma outra coluna n�o chave?�
Caso dependa apenas da chave
Copiar a coluna para a tabela na 3FN
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
- 4FN
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:
- Caso 7
Antes da aplica��o da 4FN:
Arquivo:BDA-Normalizacao-4FN-Antes.pdf
- Caso 8
Ap�s aplica��o da 4FN:
Arquivo:BDA-Normalizacao-4FN-Apos.pdf
- 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:
Venda de materiais como fios, fus�veis, l�mpadas, etc
Padr�es de entrada do cliente: postes de concreto, caixa de medidor, etc
Na venda de um padr�o, o sistema deve baixar o estoque de cada um dos seus componentes
Cada um desses componentes pode ser comprado pela loja individualmente, ou sejam podem constar de v�rios pedidos de compra
Entidade:
Arquivo:BDA-Normalizacao-5FN-Antes.pdf
- Caso 10
Se realizarmos uma jun��o dessas tr�s entidades, utilizando o atributo NumeroPedido como o determinante, teremos como resultado o seguinte:
Repare que o pen�ltimo registro abaixo (destaque) n�o havia na rela��o original
Se a jun��o for efetuada tomando o atributo Fornecedor, o resultado ser�:
Entidade:
Arquivo:BDA-Normalizacao-5FN-Apos.pdf
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 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
[editar] 1a. Forma Normal
Uma Tabela est� na 1a. FN quando seus atributos n�o cont�m grupos de repeti��o (tabelas aninhadas):
Projeto (CodProjeto, Descricao, (CodFunc, Nome, Salario, DataInicio)) => N�o est� na 1FN
Projeto (CodProjeto, Descricao) => Est� na 1FN
ProjFunc (CodProjeto, CodFunc, Nome, Salario, DataInicio) => Est� na 1FN
[editar] 2a. Forma Normal
Ocorre quando a chave prim�ria � composta por mais de uma coluna
Neste caso, deve-se observar se todas as colunas que n�o fazem parte da chave dependem de todos os colunas que comp�em a chave
Se alguma coluna depender somente de parte da chave composta (depend�ncia funcional parcial), ent�o esta coluna deve pertencer a outra tabela
ProjFunc (CodProj, CodFunc, Nome, Cargo, Salario, DataInicio) => N�o est� na 2FN
ProjFunc (CodProj, CodFunc, DataInicio) => Est� na 2FN
Func (CodFunc, Nome, Cargo, Salario) => Est� na 2FN
[editar] 3a. Forma Normal
Uma tabela est� na 3a. Forma Normal quando cada coluna n�o chave depende diretamente da chave prim�ria, isto �, quando n�o h� depend�ncias funcionais transitivas ou indiretas
Uma depend�ncia funcional transitiva acontece quando uma coluna n�o chave prim�ria depende funcionalmente de outra coluna ou combina��o de colunas n�o chave prim�ria
Func (CodFunc, Nome, Cargo, Salario) => N�o est� na 3FN
Func (CodFunc, Nome, CodCargo) => Est� na 3FN
Cargo (CodCargo,Salario) => Est� na 3FN
[editar] Forma Normal de Boyce-Codd
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:
Encontramos duas ou mais chaves candidatas
As chaves candidatas s�o compostas (apresentam mais de um atributo)
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
Exemplo:
Assumindo que um professor possa estar associado a mais de uma escola e uma sala.
Aluno (NomeAluno, EnderecoAluno, NomeEscola, NroSala, NomeProfessor)
Chaves candidatas:
NomeAluno + EnderecoAluno
Nomeluno + NroSala
NomeAluno + NomeProfessor
Encontramos tr�s chaves candidatas
Todas apresentam mais de um atributo (concatenados)
Todas compartilham um mesmo atributo: NomeAluno
Ao aplicar-se a FNBC, a tabela Aluno deve ser dividida em duas tabelas
uma que cont�m todos os atributos que descrevem o aluno
outra que cont�m os atributos que designam um professor em uma determinada escola e n�mero de sala
Aluno (NomeAluno, EnderecoAluno, NomeEscola, NroSala) Sala (NomeEscola, NroSala, NomeProfessor)
[editar] 4a. Forma Normal
Uma tabela est� na 4a. Forma Normal caso n�o possua mais de uma depend�ncia funcional multivalorada
Uma situa��o onde temos um controle de projetos ligados a funcion�rios e a equipamentos.
Arquivo:BDA-Normalizacao-Exemplo-4FN.pdf
CodProj multidetermina de forma independente CodFunc e CodEquip.
[editar] 5a. Forma Normal
Aplicada em casos de relacionamentos m�ltiplos Trata do conceito de depend�ncia de jun��o Primeiro decomp�e-se a tabela atrav�s de uma opera��o de proje��o e em seguida faz-se a reconstru��o da mesma atrav�s de uma jun��o A tabela est� na 5a. Forma Normal quando seu conte�do n�o puder ser reconstru�do atrav�s da jun��o destas tabelas secund�rias
Arquivo:BDA-Normalizacao-Exemplo-5FN.pdf
Reconstruindo o conte�do da tabela original atrav�s da jun��o natural das tabelas secund�rias
Arquivo:BDA-Normalizacao-Exemplo-5FNApos.pdf
[editar] Exerc�cios
Normalizar sequencialmente segundo as formas normais, sempre que poss�vel:
01. Encomenda de Livros:
PedidoLivro (NomeCliente, ISBN, DataPedido, Titulo, Autor(es), Quantidade, Pre�o, ValorTotal)
Vilson:
Arquivo:Normalizacao-PedidoLivro.pdf
02. Projetos:
Empregado (NroEmpregado, NomeEmpregado, NroDepto, NomeDepto, NroGerente, NomeGerente, NroProjeto, NomeProjetom, DataInicio, FTE)
Guilherme:
Arquivo:Normalizacao-Empregado.pdf
03. Compras:
Ordem de Compra (CodOrdemCompra, DataEmissao, CodFornecedor, NumFornecedor, EndFornecedor, CodMaterial (n vezes), DescricaoMaterial (n vezes), QuantComprada (n vezes), ValorUnit (n vezes), ValorTotalItem (n vezes), ValorTotalOC)
Rog�rio:
Arquivo:Normalizacao-OC.pdf
04. Notas Fiscais:
NotasFiscais (Num_ NF, S�rie, Data emiss�o, CodCliente, Nome Cliente, EndCliente, CgcCliente, CodigoMercadoria, DescricaoMercadoria, QuantidadeVendida, PrecoVenda, TotalVendaMercadoria, TotalGeral)
Daniel:
Arquivo:Normalizacao-NF.pdf
05. Gest�o de Projetos:
Gestao Projetos (NumProjeto, NumEmpregado, NomeProjeto, NomeEmpregado, Funcao, Salario, Horas)
Vilson:
Arquivo:Normalizacao-GestaoProjetos.pdf
06. Vendas:
Vendedor (NumVendedor, NomeVendedor, EndVendedor, Telefone, Cep, Localidade, NumProduto, DescricaoProduto, Saldo, PrecoUnit�rio, NumFatura, QuantVendida, Total)
Guilherme:
Arquivo:Normalizacao-Vendedor.pdf
07. Recursos Humanos:
Funcionario (NumFuncionario, NomeFuncionario, NumEmpresa, NomeEmpresa, NumDepto, NomeDepto)
Rog�rio:
Arquivo:Normalizacao-Funcionario.pdf
08. Controle Acad�mico:
Aluno ( NroAluno, CodDepto, NomeDepto, SiglaDepto, CodOrientador, NomeOrientador,FoneOrientador, CodCurso)
As seguintes depend�ncias funcionais devem ser garantidas na normaliza��o:
CodDepto ? {NomeDepto, SiglaDepto}
CodOrientador ? {NomeOrientador, FoneOrientador}
NroAluno ? {CodDepto, CodOrientador, CodCurso}
Observa��es adicionais:
Um aluno somente pode estar associado a um departamento
Um aluno cursa apenas um �nico curso
Um aluno somente pode ser orientado por um �nico orientador
Daniel:
Arquivo:Normalizacao-Aluno.pdf
09. Corporativo:
Empresa (CodEmpresa, NomeEmpresa, EndEmpresa, NomeFundador, NacionalidadeFundador, { Filial (FilialNro, FilialLocal, FilialDataAbertura) })
As seguintes depend�ncias funcionais devem ser garantidas na normaliza��o:
CodEmpresa ? {NomeEmpresa, EndEmpresa, NomeFundador}
NomeFundador ? NacionalidadeFundador
{CodEmpresa, FilialNro} ? {FilialLocal, FilialDataAbertura}
Observa��es adicionais:
Uma empresa somente pode ter sido fundada por um �nico fundador
Ariel:
Arquivo:Normalizacao-Empresa.pdf
10. Vendas:
Vendedor (NroVendedor, NomeVendedor, SexoVendedor,{Cliente (NroCliente, NomeCliente, EndCliente ) })
As seguintes depend�ncias funcionais devem ser garantidas na normaliza��o:
NroVendedor ? NomeVendedor, SexoVendedor
NroCliente ? NomeCliente, EndCliente
Observa��es adicionais:
Um vendedor pode atender diversos clientes, e um cliente pode ser atendido por diversos vendedores
Ariel:
Arquivo:Normalizacao-Vendas.pdf