BANCO DE DADOS Modelagem de Dados Normalizao Objetivo: Eliminar redundncias e inconsistncias de um banco de dados, com reorganizao mnima dos

os dados. Sub-Fases: Identificao das redundncias e outros problemas Reorganizao do banco de dados Normalizao um processo baseado nas chamadas formas normais. Uma forma normal uma regra de deve ser aplicada na construo das tabelas do banco de dados para que estas fiquem bem projetadas. Segundo autores, existem 5 formas normais. Vamos trabalhar com as 3 primeiras, sendo as principais. Devemos aplicar as 3 formas normais em cada tabela, ou grupo de tabelas relacionadas. As formas tm uma ordem e so dependentes, isto , para se aplicar a segunda norma, deve-se obrigatoriamente ter aplicado a primeira e assim por diante. 1 - Forma Normal: Verificao de Tabelas Aninhadas 1FN Uma relao estar na Primeira forma normal 1FN, se e somente se todos os domnios bsicos contiverem somente valores atmicos (no contiver grupos repetitivos). Em outras palavras podemos definir que a primeira forma normal no admite repeties ou campos que tenha mais que um valor. Para uma tabela estar na primeira forma normal ela no deve conter tabelas aninhadas. Um jeito fcil de verificar esta norma fazer uma leitura dos campos das tabelas fazendo a pergunta: Este campo depende de qual? Procedimentos:

Identificar a chave primria da entidade; Identificar o grupo repetitivo e remov-lo da entidade; Criar uma nova entidade com o grupo repetitivo.

Vamos exemplificar, com a tabela Venda. Este o esquema relacional da tabela: Venda(Codvenda, Cliente, Endereco, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal). O raciocnio o seguinte: A tabela Venda, deve armazenar informaes da venda. Pois bem, verificando o campo Cliente, sabemos que ele depende de CodVenda, afinal para cada Venda h um cliente. Vendo o campo Endereo, podemos concluir que Elisa Maria Pivetta UFSM/CAFW

ele no depende de Codvenda, e sim de Cliente, pois uma informao referente particularmente ao cliente. No existe um endereo de venda, existe sim um endereo do cliente para qual se fez a venda. Nisso podemos ver uma tabela aninhada. Venda (Codvenda, Cliente, Endereo, Cep, Cidade, Estado, Telefone, Produto, Quantidade, Valorunitario, Valorfinal). A soluo extrair estes campos para uma nova tabela, adicionar uma chave-primria nova tabela e relacion-la com a tabela Venda criando uma chave-estrangeira. Ficaria desta forma: Cliente (Codcliente, Nome, Endereo, Cep, Cidade, Estado, Telefone). Venda (Codvenda, Codcliente, Produto, Quantidade, Valorunitario, Valorfinal). Agora aplicamos novamente primeira forma normal as 2 tabelas geradas. Uma situao 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, tambm depende de Estado, pois no caso de a cidade ser Curitiba o estado sempre dever ser Paran, porm se o Estado for Paran, a cidade tambm poder ser Londrina. Isso o que chamamos de Dependncia funcional: onde aparentemente, uma informao depende da outra. No caso Cidade-Estado a soluo simples: Extramos Cidade e Estado, de Cliente e geramos uma nova tabela. Em seguida, o mesmo processo feito anteriormente: adicionar uma chave-primria nova tabela e relaciona-la criando uma chave-estrangeira na antiga tabela. Cidade (Codcidade, Nome, Estado). Cliente (Codcliente, Codcidade, Nome, Endereo, Cep, Telefone). Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal). Seguindo com o exemplo, a tabela Cliente encontra-se na 1 forma normal, pois no h mais tabelas aninhadas. Verificando Venda, podemos enxergar mais uma tabela aninhada. Venda (Codvenda, Codcliente, Codcidade, Produto, Quantidade, Valorunitario, Valorfinal). Na maioria das situaes, produtos tm um valor previamente especificado. O Valorunitrio depende de Produto. J a Quantidade (campo entre Produto e Valorunitario) no depende do produto e sim da Venda. Cidade (Codcidade, Nome, Estado). Cliente (Codcliente, Codcidade, Nome, Endereo, Cep, Telefone).

Elisa Maria Pivetta UFSM/CAFW

Produto (Codproduto, Nome, Valorunitario). Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal). Passando a tabela Venda pela primeira forma normal, obtivemos 3 tabelas. Vamos prxima forma. 2 Forma Normal: Verificao de Dependncias Parciais 2FN Uma tabela est na Segunda Forma Normal 2FN se ela estiver na 1FN e todos os atributos no chave forem totalmente dependentes da chave primria (dependente de toda a chave e no apenas de parte dela). Procedimentos:

Identificar os atributos que no so funcionalmente dependentes de toda a chave primria; Remover da entidade todos esses atributos identificados; Criar uma nova entidade com eles.

Para uma tabela estar na segunda formal, alm de estar na primeira forma ela no deve conter dependncias parciais. Um jeito de verificar esta norma refazer a leitura dos campos fazendo a pergunta: Este campo depende de toda a chave? Se no, temos uma dependncia parcial. Vimos antes o caso Cidade-Estado que gerava uma dependncia funcional. preciso entender este conceito para que voc entenda o que Dependncia Parcial. Aps a normalizao da tabela Venda, acabamos com uma chave composta de 4 campos: Venda (Codvenda, Codcliente, Codcidade, Codproduto, Quantidade, Valorfinal). A questo agora verificar se cada campo no-chave depende destas 4 chaves. O raciocnio seria assim: 1. O primeiro campo no-chave Quantidade. 2. Quantidade depende de Codvenda, pois para cada venda h uma quantidade especfica de itens. 3. Quantidade depende de Codvenda e Codcliente, pois para um cliente podem ser feitas vrias vendas, com quantidades diferentes. 4. Quantidade no depende de Cidade. Quem depende de Cidade Cliente. Aqui est uma dependncia parcial. 5. Quantidade depende de Codproduto, pois para cada produto da Venda uma quantidade certa. Quantidade depende de 3 campos, dos 4 que compe a chave de Venda. Quem sobrou nessa histria foi Codcidade. A tabela Cidade j est ligada com Cliente, que j est ligado com Venda. A chave Codcidade em Venda redundante, portanto podemos elimin-la. Elisa Maria Pivetta UFSM/CAFW

Venda (Codvenda, Codcliente, Codproduto, Quantidade, Valorfinal). O prximo campo no-chave Valorfinal. Verificando Valorfinal, da mesma forma que Quantidade, ele depende de toda a chave de Venda. Portanto vamos prxima norma. 3 Forma Normal: Verificao de Dependncias Transitivas 3FN Uma tabela est na Terceira Forma Normal 3FN se ela estiver na 2FN e se nenhuma coluna no-chave depender de outra coluna no-chave. Na terceira forma normal temos de eliminar aqueles campos que podem ser obtidos pela equao de outros campos da mesma tabela. Procedimentos:

Identificar todos os atributos que so funcionalmente dependentes de outros atributos no chave; Remov-los.

A chave primria da nova entidade ser o atributo do qual os atributos removidos so funcionalmente dependentes. Para uma tabela estar na segunda formal, alm de estar na segunda forma ela no deve conter dependncias transitivas. Um jeito de verificar esta norma refazer a leitura dos campos fazendo a pergunta: Este campo depende de outro que no seja a chave? Se Sim, temos uma dependncia transitiva.. No exemplo de Venda, temos um caso de dependncia transitiva: Na tabela Venda, temos Valorfinal. Este campo o resultado do valor unitrio do produto multiplicado pela quantidade, isto , para um valor final existir ele DEPENDE de valor unitrio e quantidade. O Valorunitrio est na tabela Produto, relacionada Venda e Quantidade est na prpria Venda. Valorfinal depende destes 2 campos e eles no so campos-chave, o que nos leva a pensar: Se temos valor unitrio e quantidade, porque teremos valor final? O valor final nada mais que o resultado de um clculo de dados que j est no banco, o que o torna um campo redundante. Quando for necessrio ao sistema obter o valor final, basta selecionar o valor unitrio e multiplicar pela quantidade. No h porque guardar o valor final em outro campo. Aqui a soluo eliminar o campo Valorfinal. Cidade (Codcidade, Nome, Estado). Cliente (Codcliente, Codcidade, Nome, Endereco, Cep, Telefone). Produto (Codproduto, Nome, Valorunitario). Venda (Codvenda, Codcliente, Codproduto, Quantidade).

Elisa Maria Pivetta UFSM/CAFW

Em tese, agora temos todas as tabelas normalizadas. Ainda restou o caso do campo Estado na tabela Cidade, que poder posteriormente ser normalizado. Porm o objetivo aqui mostrar conceitualmente o processo de normalizao do banco de dados. muito comum, no processo de normalizao enxergamos todas as formas normais ao mesmo tempo. Enquanto separamos as tabelas aninhadas, j conseguimos ver as dependncias transitivas e logo mais encontramos uma dependncia parcial, tudo assim, ao mesmo tempo. Isso normal. S tome cuidado, para no deixar nada passar nada.

Elisa Maria Pivetta UFSM/CAFW