Faccat Curso de Sistemas de Infomação Disciplina de Banco de Dados Prof.

Eurico Antunes Normalização O desenvolvimento de software, em algumas situações, leva o profissional da área de TI a necessidade de reaproveitamento de dados manipulados por sistemas anteriormente utilizados no ambiente onde se está trabalhando. Nestas ocasiões por vezes torna-se necessário o processo de engenharia reversa, que consiste de uma análise do sistema afim de definirmos o modelo de negócio (nível mais abstrato) implementado. Este processo é o inverso do processo de análise e projeto de software. Quando pensamos em reestruturação de sistemas, e portanto nos dados armazenados, devemos lembrar que, por vezes, os dados legados não estão estruturados da melhor forma possível quando consideramos o projeto de uma base de dados relacional. Para situações como esta existem regras para adequação dos dados ao formato relacional, regras estas que tornam o conjunto de dados corretamente projetados. Estas regras são denominadas regras de Normalização. Existem inúmeras regras de normalização, 4 delas são ditas suficientes para a construção de uma base de dados bem estruturada. Estas regras serão apresentadas a seguir: Para apresentarmos as regras de normalização utilizaremos o exemplo a seguir como exemplo de um conjunto de dados não normalizados:

Cat.O conjunto de dados apresentados acima. No caso de uma tabela não normalizada. que possui apenas uma tabela aninhada. Ao decompor uma tabela em várias tabelas. organizado em forma de tabelas não normalizadas (identificadas pela sigla NN) seria apresentada da seguinte maneira: E teríamos para tal o seguinte esquema de tabelas aninhadas: Proj (CodProj. é criada uma tabela na 1FN composta pelas seguintes coluas: . DataIni. A motivação é de ordem prática. sem as tabelas aninhadas. Considerando apenas a correção do processo de normalização. . mesmo sabendo que ela pode levar a modelos imperfeitos. fica fácil visualizar a tabela na 1FN (primeira forma normal). Tipo. Nome. 2. isto é. Passagem à prmeira forma normal Diz que uma tabela está na forma normal quando esta não contém tabelas aninhadas. Para cada tabela aninhada. a primeira alternativa é a preferida. É criada uma tabela na 1FN referente a tabela não normalizada e que contém apenas as colunas com valores atômicos. como ocorre na segunda alternativa. Descr. Sal.Construir uma tabela para cada tabela aninhada Cria-se uma tabela referente a própria tabela que está sendo normalizada e uma tabela para cada tabela aninhada. Na decomposição de tabelas. A chave primária da tabela na 1FN é idêntica a chave da tabela não normalizada. a passagem à primeira forma normal por decomposição de tabelas é feita nos seguintes passos: 1. (CodEmp. como a do exemplo. Para transformar um esquema de tabela não-normalizada em um esquema na 1FN há duas alternativas: . TempAl)) 1. Entretanto. podem ser perdidas relações entre informações. para fins práticos. preferimos a segunda alternativa.Construir uma única tabela com redundância de dados Cria-se uma tabela na qual os dados das linhas externas à tabela aninhada são repetidos para cada linha da tabela aninhada.

Tipo. Passagem à segunda forma normal Uma tabela encontra-se na segunda forma normal.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. não contém dependências parciais. TempAl) 2. após a aplicação da primeira forma normal (1FN) os seguintes esquemas: Sendo os esquemas das tabelas acima : Proj (CodProj. DataIni.a chave primária de cada uma das tabelas na qual a tabela em questão está aninhada. Cat. CodEmp.. Para o conjunto de dados utilizados neste texto teríamos então. quando. . a passagem à 2FN é o seguinte: . Para cada coluna não chave fazer a seguinte pergunta: . Descr) ProjEmp(CodProj. Dependência (funcional) parcial ocorre quando uma coluna depende apenas de ma parte de uma chave primária composta. De forma mais precisa. Nome. .Copiar para a 2FN cada tabela que tenha chave primária simples ou que não tenha colunas além chave.as colunas da própria tabela aninhada 3. Sal. além de estar na 1FN. São definidas as chaves primárias das tabelas na 1FN que correspondem a tabelas aninhadas.

Criar a coluna dependente dentro da tabela na 2FN.) Como resultado após a aplicação da segunda forma normal teremos o conjunto de dados de exemplo organizado segundo os esquemas apresentados abaixo: . CodEmp. uma tabela na 2FN que tenha como chave primária a parte da chave que é determinante da coluna em questão. Nome. Para o exemplo utilizado neste texto temos as seguintes dependências funcionais parciais: Subdividindo as tabelas e colocando-as na segunda forma normal teremos: E teremos então os seguintes esqeumas: ProjEmp(CodProj. Caso a Coluna dependa apenas de parte da chave: Criar. DataIni. TempAl) Emp(CodEmp.“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 coma chave completa na 2FN. Sal. caso ainda não existir. Cat.

além de depender da chave primária da tabela . . pois neste caso não há como haver dependências transitivas.Para tabelas com duas ou mais colunas não chave: a) Criar uma tabela no esquema da 3FN com a chave primária da tabela em questão. Passagem à terceira forma normal Uma tabela encontra-se na terceira forma normal. o processo de passagem da 2FN a 3FN é o seguinte: .3. De forma mais precisa. quando .Copiar para o esquema na 3FN cada tabela que tenha menos que duas colunas não chave. além de estar na segunda forma normal. não contém dependências transitivas. b) Para cada coluna não chave fazer a seguinte pergunta: . depende de outra coluna ou conjunto de colunas da tabela. Dependências transitivas (dependências funcionais transitivas) ocorrem quando uma coluna.

Para os exemplos apresentados identificamos as seguintes dependências funcionais transitivas e sua correspondente solução: Teremos após aplicação da 3FN a seguinte organização para o conjunto de dados: . uma tabela no esquema na 3FN que tenha como chave primária a coluna da qual há a dependência indireta. • A coluna determinante deve permanecer também na tabela original. • Copiar a coluna dependente para a tabela criada. caso ainda não exista. Caso a coluna depender de outra coluna • Criar.“A coluna depende de alguma outra cluna não chave (dependência transitiva ou indireta)?” Caso a coluna dependa apenas da chave • Copiar a coluna para a tabela na 3FN.

Uma tabela encontra-se na quarta forma normal. Para exemplificarmos esta situação utilizaremos a tabela abaixo: UTILIZAÇÃO CodProj 1 1 1 1 1 1 2 CodEmp 1 2 3 1 2 3 2 CodEquip 1 1 1 2 2 2 2 . a 4FN e a 5FN. quando. além de estar na 3FN. a decomposição até a 3FN é suficiente para obter o esquema de um banco de dados correspondente ao documento. não contém dependências multi-valoradas.4. Destas a única que tem importância na prática da engenharia reversa é a quarta forma normal (4FN). como a forma normal de Boyce/Codd. Na literatura aparecem outras formas normais. Passagem à quarta forma normal Para a maioria dos documentos e arquivos.

CodEquip 1 1 1 2 2 2 Para representar um dependência funcional multi-valorada usa-se uma expressão semelhante a usada para representar dependências funcionais simples substituindo a seta simples por uma seta dupla. Na tabela UTILIZAÇÃO (apresentada acima). há as seguintes dependências: CodProj CodProj CodEmp CodEquip Aplicando-se a 4FN teremos então: ProjEquip: CodProj 1 1 2 2 3 3 3 4 ProjEmp: CodProj 1 1 1 2 3 CodEmp 1 2 3 2 3 CodEquip 1 2 2 4 1 3 5 5 ..2 3 3 3 3 3 3 4 2 3 4 3 4 3 4 2 4 1 1 3 3 5 5 5 Podem ser observadas as dependências funcionais multi-valoradas em: UTILIZAÇÃO CodProj 1 1 1 1 1 1 CodEmp 1 2 3 1 2 3 ..

DescricaoProd) TipoProd(CodigoTipoProd. DescricaoProd. CodigoTipoProd. No caso do exercício. Devido a esta dependência. é criada a tabela Empregado. O Modelo relacional resultante da passagem à 3FN é o seguinte: 3FN ItemVenda (NumeroNF. Datavenda. CodigoTipoProd. b) Apresente a segunda e ternceira formas normais. na passagem à 3FN. DescricaoTipoProd) a) A Tabela acima está na primeira forma normal? Resposta: Sim. NumeroProd. DataVenda. NomeEmp. QtdeItem. NomeEmp) . QtdeItem.NumeroProd) DescricaoProd CodigoTipoProd DescricaoTipoProd NumeroNF DataVenda NumeroNF CodReg NumeroNF CodEmp NumeroNF NomeEmp Observe que o identificador de um produto é a chave composta pelo código do tipo do produto e pelo número do produto: A passagem a 2FN resulta nas seguintes tabelas: ItemVenda (NumeroNF. NomeEmp) A passagem a 3FN consta da eliminação das dependências funcionais transitivas ou indiretas. Considere a tabela abaixo (exercício 6. NumeroProd. CodReg. NumeroProd. pois não existem tabelas aninhadas no esquema apresentado.1 do livro do Heuser) : ItemVenda (NumeroNF. CodEmp) Empregado(CodEmp. há uma dependência funcional transitiva na tabela Venda que é CodEmp NomeEmp. CodEmp. PreçoItem. DescricaoProd) TipoProd(CodigoTipoProd. QtdeItem. DataVenda. NumeroProd. Resposta: Passagem à segunda forma normal que consiste na eliminação das dependências funcionais parciais as quais são: (CodigoTipoProd. PreçoItem) Produto (CodigoTipoProd. PreçoItem) Produto (CodigoTipoProd. CodReg. DescricaoTipoProd) Venda(NumeroNF. CodEmp. CodigoTipoProd. isto é de colunas não chave que dependem de outras colunas não chave. NumeroProd.3 4 Exercícios: 4 2 1. DescricaoTipoProd) Venda(NumeroNF. CodReg.

Sign up to vote on this title
UsefulNot useful