|
Normalização de dados
Normalização de banco de dados é um conjunto de regras que visa, principalmente, a organização de um projeto de banco de dados para reduzir a redundância de dados, aumentar a integridade de dados e o desempenho. Para normalizar o banco de dados, deve-se examinar as colunas (atributos) de uma entidade e as relações entre entidades (tabelas), com o objetivo de se evitar anomalias observadas na inclusão, exclusão e alteração de registros. Atualmente, muitos sistemas de informação ainda não utilizam banco de dados relacionais, sendo esses chamados de sistemas legados. Os dados desses sistemas são armazenados em arquivos de linguagens de terceira geração, como COBOL ou BASIC, ou então, em banco de dados da era pré-relacional. Panorâmica informalPara adequar o banco de dados, é necessário avaliar com base em cinco regras, que recebem o nome de formas normais. Essas correspondem a um conjunto de regras de simplificação e adequação de tabelas. Diz-se que a tabela do banco de dados relacional está numa certa forma normal quando satisfaz as condições exigentes. O trabalho original de Edgar F. Codd, definiu três dessas formas, mas existem hoje outras formas normais geralmente aceitas. Damos aqui uma curta panorâmica informal das mais comuns. Cada forma normal listada abaixo representa uma condição mais forte das que a precedem na lista. Para a maioria dos efeitos práticos, considera-se que as bases de dados estão normalizadas se aderirem à terceira forma normal. Inicialmente, são definidos todos os atributos do documento, que estão relacionados a uma entidade principal, atribuindo uma chave primária. Feito isso, partimos para a análise do documento de acordo com as formas normais a seguir:
Visão FormalAntes de falar sobre normalização, é necessário utilizar alguns termos a partir do modelo relacional e defini-los na teoria de conjuntos. Estas definições muitas vezes serão simplificações de seus significados originais, uma vez que somente alguns aspectos do modelo relacional são levados em consideração na normalização. As notações básicas utilizadas no modelo relacional são nomes de relacionamentos e nomes de atributos, representados por cadeias de caracteres tais como Pessoas e Nomes; geralmente são utilizadas variáveis como r, s, t,… e a, b, c para o conjunto dados definido sobre eles. Outra notação básica é o conjunto de valores atômicos que contém valores tais como números e cadeias de caracteres. A primeira definição de interesse é a noção de tupla, que formaliza a noção de linha ou registro em uma tabela:
A próxima definição é a de relação na qual formaliza-se o teor de uma tabela como ele é definido no modelo relacional.
Como uma relação corresponde definitivamente com aquela que é usualmente chamada de extensão de um predicado em lógica de primeira ordem exceto que aqui nós identificamos os locais no predicado com nomes de atributos. Geralmente no modelo relacional um esquema de banco de dados é dito consistir-se de um conjunto de nomes relação, os cabeçalhos que são associados com esses nomes e as restrições que devem manter toda instância do esquema de banco de dados. Para normalização nós nos concentraremos nas restrições que indicam relações individuais, isto é, as restrições relacionais. O propósito destas restrições é descrever o universo relacional, ou seja, o conjunto de todas as relações que são permitidas para serem associadas com certos nomes de relação.
Restrições Chave e Dependências FuncionaisA restrição relacional mais importante é a restrição de Chave. Ela relaciona cada registro (tupla) a um (ou mais) valor índice.
Objetivos de normalizaçãoUm objetivo básico da primeira forma normal, definida por Codd em 1970, era permitir dados serem questionados e manipulados usando uma "sub-linguagem de dados universal" atrelada à lógica de primeira ordem. Questionando e manipulando dados em uma estrutura de dados não normalizada, como a seguinte representação não-1NF de transações de clientes de cartão de crédito, envolve mais complexidade do que seria realmente necessário:
Note que a tabela é composta pelas colunas cliente e transação, sendo que essa última contém 3 informações: identificador, data e valor. Para cada cliente corresponde um grupo repetitivo de transações. A análise automatizada de transação envolve dois estágios:
Por exemplo, para encontrar a soma monetária de todas as transações que ocorreram em outubro de 2003 para todos os clientes, o sistema necessitaria saber primeiro que precisa desempacotar o grupo de transações para cada cliente, então somar a quantidade de todas as transações de outubro de 2003. Um das visões mais importantes de Codd foi que a complexidade desta estrutura poderia ser removida completamente, levando a um poder e flexibilidade muito maior na forma de efetuar consultas. A normalização equivalente da estrutura acima seria assim:
Nessa nova estrutura, as chaves são {Cliente} e {Cliente ID} na primeira tabela e {Cliente ID, Tr. ID} na segunda. Agora cada linha representa uma transação individual, e um SGBD pode obter a resposta, simplesmente encontrando todas as linhas com data de outubro, somando então os valores. Formas NormaisPrimeira Forma Normal
Outra forma de identificar se a tabela não está na 1FN é verificando se existe tabela aninhadas, ou seja, mais de um registro para uma chave primária.
Observe a seguinte tabela: PEDIDOS = {COD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR} Considere um pedido como o número 00001, para este se observarmos o formulário em papel teremos muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento. Neste momento devemos idealizar o pedido número 00001 e efetuar os seguintes testes: {COD_PEDIDO | CLIENTE | VENDEDOR | ATENDENTE | PRODUTO | QUANT | VALOR} {00001 | "ANDRÉ" | "MARCO" | "JOAO" | "TENIS " | "1" | "50.00"} {00001 | "ANDRÉ" | "MARCO" | "JOAO" | "SANDALIA" | "2" | "80.00"} {00001 | "ANDRÉ" | "MARCO" | "JOAO" | "CARTEIRA" | "1" | "35.00"} Observe que para os dados do pedido 00001 lançados acima, apenas os atributos que estão em negrito SÃO ÚNICOS, pois não se diferem. Os demais atributos mudam, não cumprindo a 1FN onde os atributos devem ser atômicos, quer dizer únicos. Para testarmos um dos atributos e ter certeza que este é atômico, podemos efetuar uma pergunta conforme o exemplo abaixo: Podemos ter outro cliente para o pedido 00001? Não. Podemos ter apenas 1 cliente por pedido, sendo assim este atributo é atômico único para 1 pedido. Podemos ter outro vendedor para o pedido 00001? Não. Podemos ter apenas 1 vendedor por pedido. Podemos ter outro produto para o pedido 00001? Sim. Podemos ter vários produtos para um pedido, sendo assim, os campos aninhados devem ser extraídos para outra tabela.
Segunda Forma Normal
No caso de tabelas com chave primária composta, se um atributo depende apenas de uma parte da chave primária, então esse atributo deve ser colocado em outra tabela.
Terceira Forma NormalDefinição pelo Osório
A tabela a seguir não está na Terceira Forma Normal porque a coluna Total é dependente, ou é resultado, da multiplicação das colunas Preço e Quantidade, ou seja, a coluna total tem dependência transitiva de colunas que não fazem parte da chave primária, ou mesmo candidata da tabela. Para que essa tabela passe à Terceira FN o campo Total deverá ser eliminado, a fim de que nenhuma coluna tenha dependência de qualquer outra que não seja exclusivamente chave.
Aqui, após o atributo/coluna Total ser excluído da tabela, ela já na 3ª Forma Normal. Esse atributo pode ser movido para outra tabela referenciando a antiga.
Quarta Forma Normal
Relação não normalizada: Livros(nrol, (autor), título, (assunto), editora, cid_edit, ano_public) 1FN: Livros(nrol, autor, assunto, título, editora, cid_edit, ano_public) 2FN: Livros(nrol, título, editora, cid_edit, ano_public)
AutAssLiv(nrol, autor, assunto)
3FN: Livros(nrol, título, editora, ano_public)
Editoras(editora, cid_edit)
AutAssLiv(nrol, autor, assunto)
Na 3FN, a base de dados ainda apresenta os seguintes problemas:
Livros(nrol, título, editora, ano_public) Editoras(editora, cid_edit) AutLiv(nrol, autor) AssLiv(nrol, assunto) Quinta Forma NormalEstá ligada à noção de dependência de junção.
Exemplo: Sejam as relações R1(CodEmp, CodPrj) e R2(CodEmp, Papel) a decomposição da relação ProjetoRecurso(CodEmp, CodPrj, Papel). Exemplo
Forma Normal De Boyce-Codd
Exemplo
Sexta Forma Normal ou Forma Normal Chave-Domínio
Outras dependências
DesnormalizaçãoA criação de novas entidades e relacionamentos podem trazer prejuízos ao serem implementados em um SGBD. Devido a algumas relações excessivamente normalizadas, simples alterações no bancos de dados podem ocasionar uma profunda mudança na coerência de dados, assim entidades e relacionamentos devem ser desnormalizados para que o SGBD apresente um melhor desempenho. Além disso, entidades podem conter ocorrências de mudanças de informações ao longo do tempo e a desnormalização pode contribuir com a manutenção de dados sem afetá-los drasticamente. Para ilustrar o conceito podemos tomar como exemplo uma entidade denominada Vendedor com os seguintes atributos:
Um vendedor cadastrado pode mudar sua área de vendas mas os dados de vendas antigas, realizadas em regiões por onde trabalhou, devem ser mantidos no banco sem incoerência de dados. Assim, a entidade Vendedor deve ser mantida desnormalizada para que os dados não se tornem inconsistentes.
Nesse caso fomos obrigados a utilizar uma chave primária para manter a integridade de dados de Vendedor, o que mantém a entidade desnormalizada. Mas, ao optar pela desnomalização de dados devemos levar em conta o custo da redundância de dados e o uso das anomalias de atualização, o que não é interessante para grandes bancos de dados.
Atômicos significam que os valores não podem se repetir e nem atributos com mais de um valor. Monovalorado quer significar que os atributos possuem apenas um valor para uma entidade. Ex.: Eu não posso atribuir um CPF para mais de uma pessoa e nem atribuir o CPF e o Nome no mesmo campo.
Ver tambémReferências
<ref> definido em <references> não tem um atributo de nome.This article was originally based on material from the Free On-line Dictionary of Computing, used with permission. Update as needed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
