Normalizao em banco de dados

1

Normalizao em banco de dadosO objetivo da normalizao de um banco de dados evitar os problemas que podem provocar falhas no projeto do banco de dados, bem como eliminar a mistura de assuntos e as correspondentes redundncias dos dados desnecessrias. A abreviao usada, (NF), vem do ingls, "Normal Form". O processo de normalizao aplica uma srie de regras sobre as tabelas (tambm chamadas de relaes) de um banco de dados, para verificar se esto corretamente projetadas. .

Formas NomaisPrimeira Forma NormalUm esquema de relao R est na 1FN se todos os seus atributos forem atmicos (simples) e monovalorados, ou seja, no so permitidos atributos multivalorados, atributos compostos ou atributos multivalorados compostos. Exemplo: FUNCIONRIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATA FIM}} Para colocar na 1FN: FUNCIONRIOS = {CODFUNC + NOME + CARGO} FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATA FIM} OBS: A chave primria de FUNCIONRIOS vai ser a chave estrangeira de FUNC_PROJ. Veja abaixo outro exemplo de tabela que no est na 1FN (considerando que o campo TELEFONES multivalorado): PESSOAS = {ID + NOME + ENDERECO + TELEFONES} Para deixar esta tabela na 1FN, deve-se separar o campo multivalorado TELEFONES em uma tabela adicional, desta forma: PESSOAS = {ID + NOME + ENDERECO} TELEFONES = {PESSOA_ID + TELEFONE} Outra forma de identificar se a tabela est na 1NF verificando se existe tabela aninhadas, ou seja, mais de um registro para uma chave primria. Observe o exemplo: Considere um Pedido nmero 00001, para este pedido se observarmos o formulrio em papel teremos muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento. PEDIDOS = {COD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR} Neste momento devemos idealizar o pedido nmero: 00001 e efetuar os seguintes testes: {COD_PEDIDO | CLIENTE | VENDEDOR | ATENDENTE | PRODUTO | QUANT | VALOR} {00001 | "DOUGLAS TYBEL"| "MARCO"| "JOAO" | "TENIS " | "1" | "50.00"} {00001 | "DOUGLAS TYBEL"| "MARCO"| "JOAO" | "SANDALIA" | "2" | "80.00"} {00001 | "DOUGLAS TYBEL"| "MARCO"| "JOAO" | "CARTEIRA" | "1" | "35.00"} Observe que para os dados do pedido 00001 lanados acima, apenas os atributos que esto em negrito SO NICOS, pois no se diferem. Os demais atributos mudam, no cumprindo a 1NF onde os atributos devem ser

Normalizao em banco de dados atmicos, quer dizer nicos. Para testarmos um dos atributos e ter certeza que este atmico, podemos efetuar uma pergunta conforme o exemplo abaixo: Podemos ter outro cliente para o pedido 00001? = No. Podemos ter apenas 1 cliente por pedido, sendo assim este atributo atmico nico para 1 pedido. Podemos ter outro vendedor para o pedido 00001? = No. Podemos ter apenas 1 vendedor por pedido. Podemos ter outro produto para o pedido 00001? = Sim. Podemos ter vrios produtos para um pedido, sendo assim, os campos aninhados devem ser extrados para outra tabela.

2

Segunda Forma NormalPara estar na 2NF uma tabela deve (1) estar na 1NF e (2) todos os seus atributos que no faam parte de alguma chave candidata devem ser determinados unicamente por qualquer chave candidata da tabela. Se todas as chaves candidatas de uma tabela contiverem somente 1 atributo, esta j se encontra na 2NF. Em outras palavras, se algum campo depender somente de parte de uma chave candidata composta (e no da chave composta como um todo), ento este campo deve ser extrado para outra tabela.[1] A tabela abaixo no est na 2NF: ALUNOS_CURSOS = {ID_ALUNO + ID_CURSO + NOTA + DESCRICAO_CURSO} O problema consiste no fato de que o campo DESCRICAO_CURSO depende somente do campo ID_CURSO (apesar da chave ser composta), que parte da chave primria da tabela. Para que esta tabela esteja na 2NF, o campo DESCRICAO_CURSO deve ser extrado para outra tabela: ALUNOS_CURSOS = {ID_ALUNO + ID_CURSO + NOTA} CURSOS = {ID_CURSO + DESCRICAO}

Terceira Forma NormalA terceira forma normal (3NF) exige que a tabela esteja em 2NF e que todos os atributos que no so chave sejam mutuamente independentes, isto , que no existam funes que definam um ao outro. Portanto, sempre a chave por inteiro deve definir toda a tabela. Isto exige que atributos que no dependem diretamente da chave sejam separados em uma tabela distinta. Em outras palavras, caso exista um ou mais atributos que dependam de um atributo no-chave, estes atributos devero ser extrados para outra tabela. A tabela abaixo no est na 3NF: FUNCIONARIOS = {ID + NOME + ID_CARGO + DESCRICAO_CARGO} O problema que o campo DESCRICAO_CARGO depende exclusivamente do campo ID_CARGO, que no faz parte da chave da tabela. Para deixar esta tabela na 3NF, basta extrair o campo para outra tabela: FUNCIONARIOS = {ID + NOME + ID_CARGO} CARGOS = {ID_CARGO + DESCRICAO} Outro exemplo que pode ser dado: ITEM_VENDA = {ID + COD_PRODUTO + PRECO_UNI + QUANTIDADE + TOTAL} Neste caso, como o atributo TOTAL produto (dependente) dos campos PRECO_UNI e QUANTIDADE, o campo TOTAL pode ser eliminado para se adequar 3FN, ficando a relao correta assim: ITEM_VENDA = {ID + COD_PRODUTO + PRECO_UNI + QUANTIDADE} T_Produto = {PRECO_UNI + QUANTIDADE + TOTAL}

Normalizao em banco de dados Observao importante: Muitas pessoas confundem a 2NF com a 3NF. Entretanto, a 2NF probe que determinados atributos dependam de parte de uma chave composta, enquanto que a 3NF probe que determinados atributos dependam de atributos no-chave.

3

Forma normal Boyce/Codd (BCNF)Definio que engloba as outras formas normais, e define que uma tabela est em BCNF se, e somente se, todo determinante funcional for em relao a uma chave candidata. Na prtica, uma tabela est em BCNF se estiver em 3NF e no existir dependncia funcional dentro da chave primria. Ou seja, se todos os atributos so funcionalmente dependentes da chave, de toda a chave e nada mais do que a chave. Ou, em outras palavras, todos os determinantes so chaves candidatas. Um modelo que est em BCNF est pronto para ser implementado numa arquitetura de banco de dados relacional.[1] O Modelo Relacional de Dados - Parte 04 (http:/ / imasters. uol. com. br/ artigo/ 2521/ bancodedados/ o_modelo_relacional_de_dados_parte_04/ )

Fontes e Editores da Pgina

4

Fontes e Editores da PginaNormalizao em banco de dados Fonte: http://pt.wikipedia.org/w/index.php?oldid=24083166 Contribuidores: Anyav, Bbranta, Bons, BrunoSupremo, Camponez, Categorizador, ChristianH, Dreispt, Dtonon, Epinheiro, Fabiano Tatsch, Faustino.F, Felipegiotto, Flaviodemenezes, Gunnex, JSSX, Kleiner, Lucianowjr, Lus Felipe Braga, Manuel Anastcio, Mschlindwein, Pietro Roveri, Porantim, Rgiachini, Santana-freitas, Theus PR, 79 edies annimas

LicenaCreative Commons Attribution-Share Alike 3.0 Unported http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/