O que é normalização de banco de dados

O que é normalização de banco de dados

7 de março de 2017 1 Por Ramos de Souza Janones
Powered by Rock Convert

O que é normalização?

A normalização do banco de dados é o processo de transformações na estrutura de um banco de dados que visa a eliminar redundâncias e a eliminar anomalias de inserção, atualização e exclusão.

Ao efetuar o processo de normalização, os dados cadastrados no banco de dados ficarão organizados de uma forma melhor e ocuparão menos espaço físico. Entretanto, o processo de normalização também faz aumentar o número de tabelas e em muitos casos pode ser uma tarefa difícil de ser realizada. Além disso, bancos de dados normalizados além do necessário podem ter desempenho ruim e/ou complexidade excessiva.

Anomalias

A principal finalidade do processo de normalização é eliminar as anomalias de inserção, atualização e exclusão. A anomalia ocorre quando não há forma de se cadastrar alguma determinada informação sem que alguma outra informação também seja diretamente cadastrada. Por exemplo, imagine que você tenha uma tabela funcionário com os seguintes dados: codigo, nome, projeto, onde a tabela projeto corresponde ao nome do projeto no qual um funcionário foi alocado. E então você tem os seguintes dados:

codigo  nome    projeto
1         Pedro     Vendas
2         Maria      Vendas
3         Carlos     Cadastro de clientes

 

E então surgiu um projeto novo: O de emissão de notas fiscais. Como você cadastra esse novo projeto? A resposta é que não dá para cadastrar, pois para fazer isso você teria que ter algum funcionário nesse projeto – ou seja, temos uma anomalia de inserção.

Curso de PHP ERP com NFe.

Se no exemplo anterior, o funcionário Carlos fosse desligado da empresa e o removermos da tabela, a informação sobre o projeto de cadastro de clientes é perdida. Isso é um efeito colateral indesejado – é a anomalia de exclusão. Se no entanto ele apenas fosse remanejado para o novo projeto de notas fiscais, nós também perderíamos a informação acerca da existência do projeto de cadastro de clientes – essa é a anomalia de alteração.

O problema que origina essas anomalias é o fato de a informação do projeto estar toda dentro da tabela de funcionários, que não é o lugar dela. Se tivermos duas tabelas relacionadas (1-para-N) – funcionários e projetos – as anomalias desaparecem.

Anomalias também têm relação com o conceito de integridade referencial.

Integridade Referencial

Integridade referencial é um conceito relacionado à chaves estrangeiras. Este conceito diz que o valor que é chave estrangeira em uma tabela destino, deve ser chave primária de algum registro na tabela origem. Quando essa regra é desrespeitada, então temos o caso em que a integridade referencial é violada.

Vejamos a terminologia: Integridade vem de íntegro, inteiro, completo, correto. Referencial vem de referência, indicar algo ou alguém. Portanto, integridade referencial é indicar algo ou alguém de forma íntegra, completa, correta.

Por exemplo, veja essas duas tabelas:

Carros
Placa (PK) | Modelo | Proprietário (FK)
-----------+--------+------------------
ABC-1233 | Passat | 1
DEF-4566 | Fiesta | 2
UUV-7890 | Palio | 1

Proprietários
ID (PK) | Nome
--------+------
1 | Pedro
2 | Maria

 

Estas tabelas têm integridade referencial, pois os carros que têm proprietário com ID 1, podem ser encontrados na tabela de proprietários como sendo do Pedro. O carro de proprietário com ID 2 pode ser encontrado como sendo da Maria.

Agora, imagine que nós venhamos inserir um carro de placa EJB-6520, do modelo Celta e do proprietário com o ID 3. Ocorre que não há nenhum proprietário de ID 3. Se o banco de dados permitir essa inclusão, ocorrerá uma violação da integridade referencial, pois estará sendo feita uma referência a uma entidade inexistente. O mesmo ocorreria se quisermos alterar o proprietário de um dos carros colocando o ID do proprietário como 3.

Por outro lado, se nós quisermos deletar a Maria do banco de dados sem deletar o carro de placa DEF-4566 e nem alterá-lo, novamente teremos uma violação da integridade referencial, pois se o banco de dados permitir que essa exclusão seja feita, a integridade referencial será violada ao termos um carro que tem como dono, uma entidade agora inexistente.

A maioria dos bancos de dados relacionais modernos existentes impõe integridade referencial quando você tenta inserir, alterar ou excluir entidades no qual há chaves estrangeiras envolvidas. Entretanto, o MySQL quando utilizado com engine MyISAM é uma notável exceção (o recomendável é utilizar InnoDB nesses casos). Também é possível que as tabelas tenham sido modeladas sem que a chave estrangeira tenha sido explicitamente modelada no banco de dados e fique apenas implícita no nível da aplicação, e portanto o banco de dados não terá como verificar a integridade nesse caso.

Se uma violação de integridade ocorrer, o seu banco de dados apresentará registros inconsistentes que apontam para entidades que não existem, o que tende a se manifestar nas aplicações sob a forma de vários tipos de problemas.

Primeira forma normal (1NF)

A primeira regra para eliminar as anomalias é:

Não devem existir colunas multivaloradas.

O que é uma coluna multivalorada? É uma coluna na qual é possível armazenar-se mais de um valor por registro. Por exemplo, imagine que você tenha na sua tabela de clientes as colunas codigo, nome e telefones, preenchidos assim:

codigo nome              telefones
1          Paulo            99567-4289, 3605-4900
2          Maria            97223-0444
3           Alan -
4          Juliana          2853-0266, 96610-5480, 2410-9941

 

Observe que a coluna de telefones é multivalorada. Inserir, atualizar e excluir telefones nesse esquema é algo complicado de se fazer. Pesquisar por algum número de telefone específico também é algo complicado. A solução para isso é dividir em duas tabelas:

Cliente
codigo nome
1          Paulo
2          Maria
3           Alan
4          Juliana

Telefone
codigo   codigo_cliente    numero
1                 1                    99567-4289
2                 1                    3605-4900
3                 2                    97223-0444
4                 4                    2853-0266
5                 4                    96610-5480
6                 4                     2410-9941

 

Ao eliminar-se todas as colunas multivaloradas, o banco de dados atinge uma forma estrutural denominada de primeira forma normal, ou simplesmente 1FN.

Chaves candidatas e superchaves

Antes de prosseguir com as demais formas normais, faz-se necessário introduzir-se os conceitos de chaves candidatas e superchaves.

A chave primária é aquele conjunto de colunas que serve para identificar a tupla de uma forma única (pode ser só uma coluna, ou podem ser duas ou mais). É importante que o projetista do banco de dados saiba identificar quais são as colunas mais apropriadas para serem eleitas como parte da chave primária.

Entretanto, às vezes há mais do que um conjunto de colunas que poderia ser chave primária. Cada um desses conjuntos é chamado de chave candidata. Por exemplo, em uma tabela Pessoa que tenha os campos CPF, RG, Estado e Nome, tanto o CPF quanto o RG junto com o Estado são chaves candidatas. Assim, é possível chegar-se ao Nome a partir do CPF, mas também é possível chegar-se ao Nome a partir do RG e do Estado.

Qualquer conjunto de colunas que tenha como subconjunto, uma chave candidata é denominado de superchave.

Segunda forma normal (2FN)

A segunda forma normal é aquela que diz que:

Todas as colunas devem ter dependência funcional com a totalidade de cada chave candidata.

Na maioria dos casos por “cada chave candidata“, entenda-se por “com a chave primária“, exceto se houver mais do que uma chave candidata.

Além disso, para que uma tabela esteja na segunda forma normal, ela deve estar antes de tudo, na primeira forma normal.

Uma coluna está em dependência funcional com a chave primária quando ela é determinada no domínio da aplicação por meio da chave primária. Uma coluna não tem dependência funcional com a chave primária quando ela é definida de forma independente da chave primária ou quando ela é definida a partir de alguma outra coluna que não seja a chave primária.

Uma dependência funcional pode ser dita estar na totalidade da chave primária quando todos os campos da chave primária são necessários para estabelecer-se a relação de dependência. No caso de a chave primária ser composta, é possível se ter uma dependência parcial.

Para dar um exemplo da 2FN, imagine que sua empresa tenha representantes comerciais atuando em clientes e queira representar a relação de quais representantes comerciais atuam em quais clientes. Nessa tabela (vamos chamar de representação), temos as colunas nome_cliente e nome_representante como chaves primárias e temos também as colunas endereço_representante, endereço_cliente e valor_contrato.

Observe que as colunas endereço_representante e endereço_cliente dependem da chave primária. Mas eles não dependem de toda a chave primária, cada um depende apenas de parte dela. A solução neste caso é ter uma tabela de clientes (com o endereço do cliente), uma tabela de representantes comerciais (com o endereço dele também) e deixar na tabela de atuação as respectivas chaves estrangeiras com o valor do contrato.

Terceira forma normal (3FN)

A terceira forma normal é aquela que diz que:

Todas as colunas devem ter dependência funcional com a totalidade de cada chave candidata e nada mais além do que essas chaves candidatas.

Novamente, na maioria dos casos por “cada chave candidata“, entenda-se por “com a chave primária“, exceto se houver mais do que uma chave candidata. Se a única chave candidata existente for a chave primária, isso ficaria assim:

Todas as colunas devem ter dependência funcional com a totalidade da chave primária e nada mais além da chave primária.

Além disso, para uma tabela estar na terceira forma normal, ela deve estar primeiramente na segunda forma normal (e também na primeira). A parte de depender da totalidade de cada chave candidata é abordada na segunda forma normal, então o foco aqui é depender de nada mais que essas chaves.

Por exemplo. Imagine a tabela de carros com as colunas placa (chave primária), cor, nome_proprietário, endereço_proprietário:

placa             cor              nome_proprietário               endereço_proprietário
ABX-1234     azul            José                                      Rua X, 123
NNU-5566    verde          Marcos                                 Rua exemplo, 5678
SGH-7210     preto          Maria                                    Avenida teste, 7743
ERT-6902     vermelho    José                                      Rua X, 123
BGH-5431     preto          José                                      Rua X, 123

 

LEIA TAMBÉM:  SQL Server - Uso de ISNULL e COALESCE em uma pesquisa

Observe o endereço do proprietário – ele é uma violação da terceira forma normal. Observe que o endereço do proprietário é definido como resultado de quem é o proprietário, e não como consequência da placa do carro. Se o José mudar de endereço e atualizarmos o endereço de apenas um dos carros dele, o banco de dados ficará inconsistente (há anomalia de alteração). Se a Maria comprar mais um novo carro e adicionarmos com um outro endereço, também ficará inconsistente (anomalia de inserção). Se o Marcos vender o carro dele, o seu endereço será esquecido (anomalia de exclusão). A solução novamente, é separar em duas tabelas:

Carro
placa           cor          proprietário
ABX-1234    azul                  1
NNU-5566   verde               2
SGH-7210   preto                3
ERT-6902   vermelho          1
BGH-5431   preto                1

Proprietário
codigo   nome                 endereço
1             José                    Rua X, 123
2             Marcos               Rua exemplo, 5678
3             Maria                  Avenida teste, 7743

 

Forma normal de Boyce-Codd (BCNF)

Existe uma forma normal que é um pouco mais forte que a terceira forma normal, mas que não é requisito necessário para atingir-se a quarta (ou mesmo a sexta). Essa é a forma normal de Boyce-Codd (BCNF), também chamada por vezes de 3.5NF ou de forma normal de Boyce-Codd-Heath.

É bem raro encontrar-se casos de tabelas que estejam na terceira forma normal, mas não na forma normal de Boyce-Codd. Além disso, existem casos (incomuns) onde essa forma normal é impossível de ser atingida (diferentemente das formas entre a primeira e a sexta, que sempre podem ser atingidas).

A diferença aparece quando há mais do que uma chave candidata e elas tem alguma intersecção. A ideia é que os campos que são chaves candidatas sempre determinem os demais campos, e nunca sejam determinados por esses. Assim sendo, na forma normal de Boyce-Codd não é permitido chegar-se a uma chave candidata com base em alguma outra chave candidata por meio de dependências funcionais.

Em outro exemplo, vamos dizer que cada pizza pode ter várias coberturas diferentes, cada uma de um tipo diferentes e que você tem dois tipos de pizzas com essas coberturas:

Pizza     Cobertura     Tipo de cobertura
-------- ----------           -------------
1          muçarela          queijo
1          pepperoni         carne
1          azeitonas          vegetal
2          muçarela           carne
2          linguiça             queijo
2          pimenta             vegetal

 

Há duas chaves candidatas aí: Pizza e tipo de cobertura definem a cobertura usada. Uma outra chave candidata é que a partir da pizza e da cobertura utilizada, nós podemos definir o tipo da cobertura utilizada.

Note que para qualquer que seja a chave candidata que nós olhamos, a demais coluna depende da totalidade da chave candidata e de nada mais do que a chave candidata, então a terceira forma normal foi atingida.

Bem, tem algo errado aí, pois linguiça não é um queijo e muçarela não pode ser carne e queijo ao mesmo tempo – apesar de termos atingido a terceira forma normal, ainda temos anomalias.

A solução é novamente dividir em duas tabelas:

Pizza    Cobertura
-------- ----------
1        muçarela
1        pepperoni
1        azeitonas
2        muçarela
2        linguiça
2        pimenta

Cobertura   Tipo da cobertura
----------  -------------
muçarela    queijo
pepperoni   carne
azeitonas   vegetal
linguiça    carne
pimenta     vegetal

 

Quarta forma normal (4FN)

É raro encontrar-se casos de tabelas que estejam na terceira forma normal, mas não na quarta. A quarta forma concerne em anomalias existentes na relação entre diferentes colunas da chave primária, e só se aplica em tabelas com chaves primárias compostas por três colunas ou mais.

Para uma tabela estar na quarta forma normal, ela tem que primeiramente estar também na terceira forma normal. A forma normal de Boyce-Codd não é necessária.

É meio difícil de se explicar, mas imagine que tenhamos o caso de representantes comerciais atuando em clientes, onde vários representantes podem atuar em vários clientes e que tenhamos contratos de prestação de serviços em que vários representantes atuam em vários contratos. E então temos a seguinte tabela, onde todas as colunas são chave primária:

representante contrato    cliente
Geraldo              1        loja de roupas
Geraldo              1        hospital
Geraldo              2        loja de roupas
Geraldo              2        hospital
Marta                1        loja de brinquedos
Marta                1        hospital
Marta                3        loja de brinquedos
Marta                3        hospital
Luís                   2        loja de roupas
Luís                   2        loja de brinquedos
Luís                   4        loja de roupas
Luís                   4        loja de brinquedos

 

LEIA TAMBÉM:  Southbank Software apresenta dbKoda: uma ferramenta de desenvolvimento Open Source para MongoDB

Observe que temos relações de muitos-para-muitos entre representantes e contratos e entre representantes e clientes. Mas não temos entre clientes e contratos! Aqui está a violação da forma normal e a possibilidade de se ter algum tipo de anomalia. O ideal é separar em duas tabelas, uma com a relação entre representantes e clientes e outra com a representação entre representantes e contratos:

representantes-contratos
Geraldo                1
Geraldo                2
Marta                  1
Marta                  3
Luís                     2
Luís                     4

representantes-clientes
Geraldo        loja de roupas
Geraldo        hospital
Marta          loja de brinquedos
Marta          hospital
Luís             loja de roupas
Luís             loja de brinquedos

Observe que na tabela original nós temos informações redundantes. Por exemplo, a informação que Marta está no contrato 1 aparece duas vezes. Se deletássemos a tupla Marta-1-hospital, teríamos uma anomalia de exclusão, vez que Marta atua no hospital (contrato 3) e Marta está no contrato 1 (na loja de brinquedos). Também temos uma anomalia de inserção no caso de termos algum representante alocado para algum contrato no qual não haja ainda nenhum cliente.

Quinta forma normal (5FN)

A quinta forma normal (também chamada de é mais restrita que a quarta, e também se aplica à tabelas com 3 ou mais colunas na chave primária. Novamente, para que a quinta forma normal seja atingida, é necessário atingir-se a quarta forma normal primeiramente.

Vamos imaginar um caso semelhante ao que usei na quarta forma normal, mas que dessa vez além de existir a relação entre representantes e clientes e entre representantes e contratos, também temos a relação entre clientes e contratos. Dessa forma, temos essa tabela:

representante  contrato  cliente
Geraldo       1        loja de roupas
Geraldo       1        hospital
Geraldo       2        loja de roupas
Marta         1        hospital
Marta         3        loja de brinquedos
Marta         3        hospital
Luís          2        loja de roupas
Luís          4        loja de brinquedos

 

Observe que essa tabela é diferente daquela que usamos na quarta forma normal. Há algumas redundâncias, como por exemplo ela diz duas vezes que Geraldo está na loja de roupas e que o contrato 1 é aplicado ao hospital. A técnica usada para colocarmos na quarta forma normal não se aplica, pois para quaisquer duas colunas obtidas da chave, existe uma relação (ou seja, temos a relação contrato-cliente também). Assim, essa relação já está na quarta forma normal, mas ainda há espaço para normalização. Ao decompormos ela em três relações diferentes, chegamos a quinta forma normal:

representantes-contratos
Geraldo        1
Geraldo        2
Marta          1
Marta          3
Luís           2
Luís           4

representantes-clientes
Geraldo        loja de roupas
Geraldo        hospital
Marta          loja de brinquedos
Marta          hospital
Luís           loja de roupas
Luís           loja de brinquedos

contratos-clientes
1         loja de roupas
1         hospital
2         loja de roupas
3         loja de brinquedos
3         hospital
4         loja de brinquedos

 

Sexta forma normal (6FN)

Para uma tabela chegar a sexta forma normal, ela primeiramente deve estar na quinta forma normal. Ela dita que:

Toda tabela só pode ter uma ou nenhuma coluna que não seja parte da chave primária.

Encontrar casos onde a quinta forma normal foi atingida mas a sexta não, é fácil: Qualquer tabela com duas ou mais colunas que não sejam chave primária são uma violação da sexta forma normal.

Entretanto, encontrar-se casos onde a sexta forma normal faça sentido de ser aplicada e traga algum benefício real com isso é bem raro – na maior parte dos casos aplicá-la acaba sendo maluquice, pois a aplicação desta forma normal tende a produzir uma explosão no número de tabelas sem trazer nenhum ou quase nenhum benefício com isso. A sexta forma normal não foi definida para ser algo útil na prática, ela tem mais a finalidade de ser um limite teórico que defina qual é o ponto final a partir do qual nenhuma outra normalização seria possível.

Para ver como seria o processo aqui (e também duvidar de qualquer benefício real que isso traga), imagine a tabela pessoa com os campos codigo (chave primária), nome (NOT NULL), sexo (NOT NULL) e cor_favorita (NULLABLE), e tenhamos esses registros:

codigo nome        sexo   cor_favorita
1      Marcela     F      verde
2      Rodolfo     M      -
3      Tiago       M      amarelo
Ela seria decomposta assim:

pessoa-nome
1      Marcela
2      Rodolfo
3      Tiago

pessoa-sexo
1      F
2      M
3      M

pessoa-cor-favorita
1      verde
3      amarelo

 

Observe que cada coluna que não fazia parte de chave primária acabou indo parar em uma tabela separada. Observe também que a tabela pessoa-cor-favorita não tem um registro para o elemento 2 (o Rodolfo). Essa forma de normalização elimina a necessidade de se ter NULLABLE em colunas, e todas as colunas resultantes são NOT NULL. Os casos das colunas que eram nulos simplesmente acabaram sendo omitidos dos registros resultantes.

Forma normal de domínio-chave (DKNF)

A forma normal de domínio-chave é a que dita que:

Todas as restrições de integridade do banco de dados devem ser impostas ou por restrições de chave ou por restrições de valores de domínio.

Por restrições de chave, entende-se chaves primárias e chaves estrangeiras. Por valores de domínio entende-se o conjunto de valores válidos para cada determinada coluna.

Esta forma normal é bem forte, sendo mais forte que a quinta forma normal e que a forma normal de Boyce-Codd juntas. Porém, ela não é mais forte que a sexta, uma vez que permite a existência de várias colunas que não sejam parte da chave primária em uma mesma tabela e nem a sexta é mais forte que ela, uma vez que não há mecanismo na 6FN que garante que todas as restrições de integridade sejam modeladas tal como exige a DKNF.

Os cursos online de programação e tecnologia mais recomendados para 2019

Esta forma normal é o nirvana, a utopia, o estado ideal e perfeito da normalização. Entretanto, na prática, é quase impossível de se atingi-la porque qualquer banco de dados com regras de negócio com alguma complexidade provavelmente vai ter algum tipo de regra de consistência que não tem como ser modelada apenas como restrições de chave ou de valores de domínio. Entretanto, mesmo quando inatingível, um esforço para chegar próximo a ela é válido por eliminar várias possibilidades de anomalias.

Outras formas normais

Existe um algoritmo publicado (algoritmo de Barnstein) para se normalizar tabelas e levá-las até a terceira forma normal. Entretanto, pesquisas realizadas posteriormente descobriram que esse algoritmo é um pouquinho mais rígido do que a terceira forma normal exige, mas ainda sem satisfazer a forma normal de Boyce-Codd ou a quarta forma normal. Por esse motivo, a forma normal atingida por esse algoritmo foi chamada de forma normal de chave elementar (EKNF).

Uma outra forma normal existente, mais forte que a quarta forma normal e que a forma normal de Boyce-Codd juntas, porém mais fraco que a quinta forma normal e a forma normal de Boyce-Codd juntas é a href=”https://researcher.watson.ibm.com/researcher/files/us-fagin/icdt12.pdf” rel=”nofollow noreferrer”>forma normal de tupla essencial (ETNF). Os autores que definiram essa forma normal a colocam como uma alternativa para a quinta forma normal padrão, que embora seja mais fraca, seria tão efetiva quanto. A ETNF é atingida quando a BCNF for atingida e pelo menos uma chave candidata tiver apenas um campo. Os autores também se referem a outros trabalhos que definem a forma normal de superchaves (superkey normal form – SKNF), a forma normal livre de redundâncias (redundancy-free normal form – RFNF) e forma normal de chave completa (key-complete normal form – KCNF). A 5NF+BCNF é mais forte que a SKNF que é mais forte que a RFNF que é mais forte que a ETNF que é mais forte que a 4NF+BCNF. Também é demonstrado que a KCNF é igual a RFNF, embora tenham sido definidas por pessoas diferentes e de formas diferentes.

Ah, e é claro, temos também a forma não-normalizada (Unnormalized form), que é aquela forma que não se adequa nem mesmo a primeira forma normal.

Até onde normalizar?

Em geral, muitos ficam satisfeitos em atingir a terceira forma normal e não se preocupam muito com as demais formas normais superiores a essa porque:

  • Se aplicam a casos raros, pois quando a terceira forma normal é atingida, quase sempre a Boyce-Codd, a quarta e a quinta também foram por sorte ou acidente. Isso ocorre porque é difícil se ter um caso na 3NF que não está na BCNF e também porque tabelas com três ou mais colunas na chave primária e que tenham relações de dependência entre essas colunas são algo bem raro.
  • Uma vez que a terceira forma normal é atingida (e provavelmente, por sorte a quarta e a quinta também), restam bem poucas possibilidades que permitam a introdução de anomalias. Procurar atingir a sexta forma normal é em geral maluquice e não trás benefício prático algum. Procurar atingir a forma normal de domínio-chave é quase sempre impossível, embora essa busca possa revelar ainda alguma possibilidade de anomalia que possa ser eliminada.
  • Por vezes, para melhorar-se o desempenho do banco de dados ou simplificar-se a sua estrutura, a recomendação acaba sendo a de desnormalizar algumas coisas. Muitos sistemas com foco em dataware house ou business inteligence são normalizados só até a segunda forma normal, muitas vezes sendo concebidos a partir de estruturas que já estava na terceira forma normal e que sofreram uma desnormalização.

Onde posso aplicar o conceito de normalização?

O conceito de normalização e as formas normais se aplicam somente aos bancos de dados relacionais. Outros tipos de bancos de dados que não sejam relacionais (por exemplo, uma aplicação que salve dados em arquivos organizados em pastas), também podem ter conceitos análogos a normalização para eliminar-se redundâncias, melhorar-se a estrutura e reduzir-se a possibilidade de produzirem-se anomalias. Entretanto, nesse campo, os conceitos de normalização não são tão bem definidos quanto no caso de bases de dados relacionais e cada caso terá as suas particularidades.

O caso do NoSQL em especial é bem interessante, pois a ideia dele é modelar dados que não necessitam ter uma forte consistência (o que se denomina consistência eventual), e muitas vezes os seus dados provêm de locais onde não há uma estrutura muito forte e bem definida para os dados. Por esse motivo, não faz tanto sentido falar-se em normalização em bases NoSQL quanto se faz com SQL relacional, pois a ideia do NoSQL é aceitar, tolerar e saber lidar com eventuais anomalias e ser capaz de se virar mesmo se elas surgirem. Bases de dados NoSQL sacrificam consistência em troca de escalabilidade, e por esse motivo, anomalias tem que ser toleradas. Apesar disso, ainda assim existem alguns conceitos referentes à normalização em NoSQL, mas não são tão bem definidos ou amadurecidos. Veja um pouco sobre isso aqui.

Normalização de dados e normalização de banco de dados

Para fechar a resposta à sua pergunta, normalização de banco de dados consiste na normalização da estrutura do banco de dados, enquanto que normalização de dados corresponde à normalização dos dados já existentes nas tabelas.

Entretanto, especialmente em caso de reestruturações de bancos de dados que já estão em produção, os dois conceitos andam tão juntos e misturados que nem acaba fazendo sentido falar-se em um deles sem estar falando também do outro. Daí, em muitas situações que acontecem na prática, eles acabam sendo colocados como se fossem sinônimos.

Outros tutoriais e dicas sobre PHP:

Os cursos online de programação e tecnologia mais recomendados para 2019

Subscribe to our mailing list

* indicates required


Além de PHP e MySQL, deseja receber outro tema?

LEIA TAMBÉM:  SQL - Entenda as diferenças entre aspas simples e duplas
Email Format


Curso de Inglês para Programadores.Powered by Rock Convert

Ramos de Souza Janones

Janones, é um empreendedor brasileiro apaixonado por empreendedorismo e tecnologia. Ao longo dos anos trabalhando com o desenvolvimento de softwares desktop desde a linguagem Clipper, passando pelo Delphi e atualmente com Java.

Optou pela formação de Publicidade e Marketing por sua segunda empresa de tecnologia ter participado do "boom" da internet nos anos 90 e na procura de melhorar seus conhecimentos em negócios.

Em razão da principal formação e profundos conhecimentos em programação e banco de dados, é capaz de realizar o desenvolvimento de aplicativos web, desktop e mobile com maior criatividade e inovação que profissionais de desenvolvimento com uma formação única e mais especifica, dedicada somente ao desenvolvimento de softwares.

Com toda sua experiência com empresas de software, sua formação e paixão por negócios escreveu o livro "Marketing para Empresas e Profissionais de Software", publicado pela editora carioca Ciência Moderna em 2012. Além de outros livros sobre programação.
Sumário
O que é normalização de banco de dados
Nome do artigo
O que é normalização de banco de dados
Descrição
A normalização do banco de dados é o processo de transformações na estrutura de um banco de dados que visa a eliminar redundâncias e a eliminar anomalias de inserção, atualização e exclusão.
Autor
Nome
Ramos da Informática
Logo