O que é normalização (ou normalização)?


Respostas:


171

A normalização é basicamente projetar um esquema de banco de dados de forma que dados duplicados e redundantes sejam evitados. Se algum dado for duplicado em vários locais do banco de dados, existe o risco de ele ser atualizado em um local, mas não no outro, levando à corrupção dos dados.

Existem vários níveis de normalização de 1. forma normal a 5. forma normal. Cada forma normal descreve como se livrar de algum problema específico, geralmente relacionado à redundância.

Alguns erros de normalização típicos:

(1) Ter mais de um valor em uma célula. Exemplo:

UserId | Car
---------------------
1      | Toyota
2      | Ford,Cadillac

Aqui, a coluna "Carro" (que é uma string) tem vários valores. Isso ofende a primeira forma normal, que diz que cada célula deve ter apenas um valor. Podemos normalizar esse problema com uma linha separada por carro:

UserId | Car
---------------------
1      | Toyota
2      | Ford
2      | Cadillac

O problema de ter vários valores em uma célula é que é complicado atualizar, consultar e você não pode aplicar índices, restrições e assim por diante.

(2) Ter dados não-chave redundantes (ou seja, dados repetidos desnecessariamente em várias linhas). Exemplo:

UserId | UserName | Car
-----------------------
1      | John     | Toyota
2      | Sue      | Ford
2      | Sue      | Cadillac

Esse design é um problema porque o nome é repetido em cada coluna, embora o nome seja sempre determinado pelo UserId. Isso torna teoricamente possível alterar o nome de Sue em uma linha e não na outra, o que é corrupção de dados. O problema é resolvido dividindo a tabela em duas e criando uma relação de chave primária / chave estrangeira:

UserId(FK) | Car               UserId(PK) | UserName
---------------------          -----------------
1          | Toyota            1          | John
2          | Ford              2          | Sue
2          | Cadillac

Agora pode parecer que ainda temos dados redundantes porque os UserId's são repetidos; No entanto, a restrição PK / FK garante que os valores não possam ser atualizados de forma independente, portanto, a integridade é segura.

É importante? Sim, é muito importante. Por ter um banco de dados com erros de normalização, você corre o risco de obter dados inválidos ou corrompidos no banco de dados. Como os dados "vivem para sempre", é muito difícil se livrar dos dados corrompidos quando eles entram no banco de dados pela primeira vez.

Não tenha medo da normalização . As definições técnicas oficiais dos níveis de normalização são bastante obtusas. Parece que a normalização é um processo matemático complicado. No entanto, a normalização é basicamente apenas o bom senso e você descobrirá que, se projetar um esquema de banco de dados usando o bom senso, ele normalmente será totalmente normalizado.

Existem vários equívocos em torno da normalização:

  • alguns acreditam que os bancos de dados normalizados são mais lentos e a desnormalização melhora o desempenho. Isso só é verdade em casos muito especiais. Normalmente, um banco de dados normalizado também é o mais rápido.

  • às vezes, a normalização é descrita como um processo de design gradual e você tem que decidir "quando parar". Mas, na verdade, os níveis de normalização apenas descrevem problemas específicos diferentes. Os problemas resolvidos por formulários normais acima da 3ª NF são problemas bastante raros em primeiro lugar, então é provável que seu esquema já esteja em 5NF.

Isso se aplica a qualquer coisa fora dos bancos de dados? Não diretamente, não. Os princípios de normalização são bastante específicos para bancos de dados relacionais. No entanto, o tema geral subjacente - que você não deve ter dados duplicados se as diferentes instâncias podem ficar fora de sincronia - pode ser aplicado amplamente. Este é basicamente o princípio SECO .


4
O exemplo que você deu para o primeiro normal não é exatamente correto. Sempre me lembro das três primeiras formas normais pelos termos repetição, redundante, não dependente. Dados repetidos referem-se a quando os desenvolvedores de banco de dados novatos escrevem tabelas defs que incluem colunas como DogName1, DogName2, DogName3, etc.
Bill

2
@Bill: Por que você acha que o exemplo que forneci não está correto? Você conhece uma definição de 1NF em que o exemplo seria adequado?
JacquesB

Por que a normalização não é necessária na programação orientada a objetos - mas apenas quando se trata de bancos de dados? Acho que já existe um processo de normalização embutido no núcleo de qual programação orientacional a objetos está totalmente fora - não é?
Lealo de

@Lealo Não, de forma alguma. Você sempre pode mapear o estado de um design OO trivialmente para um banco de dados / design "relacional" com tabelas - isso é o que ORM é - mas o banco de dados / design que você obtém é uma representação relacional do design OO, não uma representação relacional de o negócio , e não apenas a representação relacional do design OO está claramente sujeita a anomalias de atualização e redundância que a normalização gerencia, mas os métodos OO têm que impor as restrições apropriadas (não documentadas) (complexas) ("representação invariável") manualmente.
philipxy

@Lealo: O princípio se aplica a OOP na medida em que você nunca deve ter as mesmas informações (na forma mutável) em dois objetos diferentes, uma vez que eles podem ficar fora de sincronia.
JacquesB

45

As regras de normalização (fonte: desconhecida)

  • A chave ( 1NF )
  • A chave inteira ( 2NF )
  • e nada além da chave ( 3NF )

... Então me ajude Codd.


12
Eu acho isso um pouco vago sem um contexto adequado, não é?
Rik

3
Pode ser um pouco vago, mas é um ótimo lembrete para quem tem o contexto. Eu sei o que é normalização e como fazê-lo, mas nunca consigo me lembrar o que é cada uma das formas.
Benjamin Autin

1
A wikipedia explica isso aqui - "Exigir a existência de" a chave "garante que a tabela esteja em 1NF; exigir que atributos não-chave sejam dependentes de" a chave inteira "garante 2NF; exigir ainda que atributos não-chave sejam dependentes de" nada mas a chave "garante 3NF."
Kcats Wolfrevo

De acordo com a wikipedia, a fonte é Bill Kent: "[Todo] [atributo] não chave deve fornecer um fato sobre a chave, a chave inteira e nada além da chave."
apteryx

19

Mais importante ainda, serve para remover a duplicação dos registros do banco de dados. Por exemplo, se você tiver mais de um lugar (mesas) onde o nome de uma pessoa possa aparecer, mova o nome para uma mesa separada e faça referência a ele em todos os outros lugares. Dessa forma, se você precisar alterar o nome da pessoa posteriormente, você só precisa alterá-lo em um lugar.

É crucial para o design adequado do banco de dados e, em teoria, você deve usá-lo tanto quanto possível para manter a integridade dos dados. No entanto, ao recuperar informações de muitas tabelas, você está perdendo um pouco de desempenho e é por isso que às vezes você pode ver tabelas de banco de dados desnormalizadas (também chamadas de achatadas) usadas em aplicativos de desempenho crítico.

Meu conselho é começar com um bom grau de normalização e só fazer a desnormalização quando realmente necessário

PS também verifique este artigo: http://en.wikipedia.org/wiki/Database_normalization para ler mais sobre o assunto e sobre as chamadas formas normais


Você também ficaria bastante surpreso com o quão pouca desnormalização é realmente necessária em aplicativos transacionais. Em um aplicativo monstro para o qual fiz o modelo de dados, um esquema com 560 tabelas tinha apenas 4 itens de dados desnormalizados.
ConcernedOfTunbridgeWells

Evita "anomalias de atualização". Ele faz isso eliminando certos tipos de duplicação.
S.Lott

“Meu conselho é começar com bom grau de normalização e só fazer a desnormalização quando realmente for necessário”. Este conselho é muito ruim! Eu ainda não vi nenhuma ilustração adequada desta "pseudo-teoria". Menos 1.
Philippe Grondier

7

Normalização um procedimento usado para eliminar redundância e dependências funcionais entre colunas em uma tabela.

Existem várias formas normais, geralmente indicadas por um número. Um número mais alto significa menos redundâncias e dependências. Qualquer tabela SQL está em 1NF (primeira forma normal, praticamente por definição) Normalizar significa alterar o esquema (muitas vezes particionando as tabelas) de forma reversível, fornecendo um modelo funcionalmente idêntico, exceto com menos redundância e dependências.

A redundância e a dependência de dados são indesejáveis ​​porque podem levar a inconsisências ao modificar os dados.


5

Destina-se a reduzir a redundância de dados.

Para uma discussão mais formal, consulte a Wikipedia http://en.wikipedia.org/wiki/Database_normalization

Vou dar um exemplo um tanto simplista.

Suponha que o banco de dados de uma organização que geralmente contém membros da família

id, name, address
214 Mr. Chris  123 Main St.
317 Mrs. Chris 123 Main St.

poderia ser normalizado como

id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27

e uma mesa familiar

ID, address
27 123 Main St.

Normalização quase completa (BCNF) geralmente não é usada na produção, mas é uma etapa intermediária. Depois de colocar o banco de dados no BCNF, a próxima etapa geralmente é desnormalizá- lo de forma lógica para acelerar as consultas e reduzir a complexidade de certas inserções comuns. No entanto, você não pode fazer isso bem sem normalizar adequadamente primeiro.

A ideia é que as informações redundantes sejam reduzidas a uma única entrada. Isso é especialmente útil em campos como endereços, onde o Sr. Chris envia seu endereço como Unit-7 123 Main St. e a Sra. Chris lista Suite-7 123 Main Street, que apareceria na tabela original como dois endereços distintos.

Normalmente, a técnica usada é encontrar elementos repetidos e isolar esses campos em outra tabela com ids exclusivos e substituir os elementos repetidos por uma chave primária que faça referência à nova tabela.


1
BCNF não é "perfeito". Existem formas normais superiores, até 6NF, onde todas as suas tabelas são apenas uma chave e um valor de dados. No entanto, raramente é usado
Rik,

Não concordo que o BCNF raramente seja usado e normalmente desnormalizado. Na verdade, seu exemplo normalizado já está em BCNF, e se você desnormalizá-lo, você voltaria à estaca zero.
JacquesB de

3

Citando CJ Data: Teoria É prática.

Saídas da normalização resultarão em certas anomalias em seu banco de dados.

Saídas da primeira forma normal causarão anomalias de acesso, o que significa que você terá que decompor e verificar os valores individuais para encontrar o que está procurando. Por exemplo, se um dos valores for a string "Ford, Cadillac" fornecida por uma resposta anterior, e você estiver procurando por todas as ocorrências de "Ford", terá que abrir a string e olhar para o substrings. Isso, até certo ponto, frustra o propósito de armazenar os dados em um banco de dados relacional.

A definição de Primeira Forma Normal mudou desde 1970, mas essas diferenças não precisam preocupar você por agora. Se você projetar suas tabelas SQL usando o modelo de dados relacional, suas tabelas estarão automaticamente em 1NF.

Saídas da segunda forma normal e além causarão anomalias de atualização, porque o mesmo fato é armazenado em mais de um lugar. Esses problemas tornam impossível armazenar alguns fatos sem armazenar outros fatos que podem não existir e, portanto, devem ser inventados. Ou quando os fatos mudam, você pode ter que localizar todos os locais onde um fato está armazenado e atualizar todos esses lugares, para não acabar com um banco de dados que se contradiz. E, ao excluir uma linha do banco de dados, você poderá descobrir que, se o fizer, estará excluindo o único lugar onde um fato que ainda é necessário está armazenado.

Esses são problemas lógicos, não problemas de desempenho ou de espaço. Às vezes, você pode contornar essas anomalias de atualização por meio de uma programação cuidadosa. Às vezes (frequentemente) é melhor prevenir os problemas em primeiro lugar, aderindo aos formulários normais.

Apesar do valor do que já foi dito, deve ser mencionado que a normalização é uma abordagem ascendente, não uma abordagem descendente. Se você seguir certas metodologias em sua análise dos dados e em seu projeto inicial, pode ter a garantia de que o projeto estará em conformidade com 3NF, no mínimo. Em muitos casos, o design será totalmente normalizado.

Onde você pode realmente querer aplicar os conceitos ensinados sob normalização é quando você recebe dados legados, de um banco de dados legado ou de arquivos compostos de registros, e os dados foram projetados em total ignorância das formas normais e das consequências de partir deles. Nesses casos, você pode precisar descobrir os desvios da normalização e corrigir o design.

Aviso: a normalização é frequentemente ensinada com conotações religiosas, como se cada desvio da normalização total fosse um pecado, uma ofensa contra Codd. (pequeno trocadilho aí). Não compre isso. Quando você realmente aprende design de banco de dados, não apenas saberá como seguir as regras, mas também saberá quando é seguro quebrá-las.


2

A normalização é um dos conceitos básicos. Significa que duas coisas não influenciam uma na outra.

Em bancos de dados significa especificamente que duas (ou mais) tabelas não contêm os mesmos dados, ou seja, não possuem redundância.

À primeira vista isso é muito bom porque suas chances de fazer alguns problemas de sincronização são próximas de zero, você sempre sabe onde estão seus dados, etc. Mas, provavelmente, seu número de tabelas aumentará e você terá problemas para cruzar os dados e para obter alguns resultados resumidos.

Portanto, no final você irá finalizar com um projeto de banco de dados que não é puramente normalizado, com alguma redundância (estará em alguns dos níveis de normalização possíveis).


2

O que é normalização?

A normalização é um processo formal em etapas que nos permite decompor as tabelas do banco de dados de forma que a redundância de dados e as anomalias de atualização sejam minimizadas.

Cortesia do processo de normalização
insira a descrição da imagem aqui

Primeira forma normal se e somente se o domínio de cada atributo contém apenas valores atômicos (um valor atômico é um valor que não pode ser dividido), e o valor de cada atributo contém apenas um único valor desse domínio (exemplo: - domínio para o a coluna de gênero é: "M", "F".).

A primeira forma normal impõe estes critérios:

  • Elimine grupos repetidos em tabelas individuais.
  • Crie uma tabela separada para cada conjunto de dados relacionados.
  • Identifique cada conjunto de dados relacionados com uma chave primária

Segunda forma normal = 1NF + sem dependências parciais, ou seja, todos os atributos não-chave são totalmente dependentes da chave primária.

Terceira forma normal = 2NF + sem dependências transitivas, isto é, todos os atributos não-chave são totalmente dependentes DIRETAMENTE e funcionais apenas da chave primária.

A forma normal de Boyce-Codd (ou BCNF ou 3.5NF) é uma versão ligeiramente mais forte da terceira forma normal (3NF).

Nota: - As formas normais Second, Third e Boyce – Codd referem-se às dependências funcionais. Exemplos

Quarta forma normal = 3NF + remover dependências multivaloradas

Quinta forma normal = 4NF + remover dependências de junção


0

Como Martin Kleppman diz em seu livro Designing Data Intensive Applications:

A literatura sobre o modelo relacional distingue várias formas normais diferentes, mas as distinções são de pouco interesse prático. Como regra geral, se você estiver duplicando valores que podem ser armazenados em apenas um lugar, o esquema não é normalizado.


-10

Ajuda a evitar dados duplicados (e pior, conflitantes).

No entanto, pode ter um impacto negativo no desempenho.


Tendo trabalhado com dados normalizados e não normalizados, prefiro diminuir a velocidade com a normalização em vez de perder ou ter dificuldade em manter o aplicativo ou banco de dados.
Schalk Versteeg

1
mecanismos de banco de dados modernos empregam cache, o que geralmente torna os bancos de dados normalizados mais eficientes do que os não normalizados. em caso de dúvida, meça.
Steven A. Lowe,

1
Um design desnormalizado pode ser mais rápido para uma consulta específica, mas um design normalizado oferece um meio-termo ao fornecer um desempenho razoável para uma variedade muito maior de consultas.
Bill Karwin

@Bill, eu teria que discordar um pouco. A única maneira de um banco de dados totalmente normalizado ajudar no desempenho é evitando que o sistema tenha que lidar com dados redundantes. Fora isso, é a pior situação do ponto de vista de desempenho.
Brian Knoblauch

Essa resposta não acrescenta nada de valor às respostas existentes.
cimmanon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.