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

Por que os caras do banco de dados falam sobre normalização?

O que é isso? Como isso ajuda?

Isso se aplica a qualquer coisa fora dos bancos de dados?

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 .

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.

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

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.

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.

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.

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).

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

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

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.

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

No entanto, pode ter um impacto negativo no desempenho.