Depois da parte de construção da aplicação, vem a parte de criação do banco de dados. O cliente na maioria dos casos, precisa reaproveitar seus dados que estão armazenados em planilhas Excel e documentos txt. Com isso, cabe a pergunta: Como pegar os dados que foram armazenados de qualquer maneira em uma planilha Excel e passar para um banco de dados que possui várias regras de integridade e consistência? A resposta para essa pergunta se denomina normalização.

O que é e para que serve?

Normalização é uma ferramenta usada no projeto lógico que serve para reestruturar tabelas e atributos, reduzindo assim redundâncias e permitindo o correto crescimento do banco de dados. Por meio dela que bancos com muita movimentação garantem sua integridade após remoção, inserção e alteração dos dados.

O processo de normalização conta com 6 formas:

  • 1° Forma Normal
  • 2° Forma Normal
  • 3° Forma Normal
  • FNBC (Forma normal de Boyce e Codd)
  • 4° Forma Normal
  • 5° Forma Normal

 A partir da 3° forma normal diz-se que o banco de dados já se encontra normalizado. A FNBC, a 4FN e a 5FN são usadas para refinar ainda mais o banco. No entanto alguns projetos decidem parar na 3FN pois as outras formas, dependendo da situação, podem exigir um pouco mais de processamento. Nesse post, vamos abordar apenas as 3 primeiras, porque são as mais usadas. As outras são usadas em casos bem específicos… deixaremos para um próximo post.

Problemas de tabelas não normalizadas

Problemas de Inserção

  • Só é possível inserir um cliente se o mesmo adquirir um produto
  • Só é possível inserir um produto se algum cliente adquiri-lo

Problemas de alteração

  • Para atualizar o telefone do cliente todos os outros registros deverão ser atualizados.
  • Para atualizar o preço do produto todos os registros desse mesmo produto deverão ser atualizados.

Problemas de exclusão

  • Se os produtos adquiridos por algum cliente forem excluídos, os dados cadastrais do mesmo se perderão.

Formas normais e suas aplicações

1FN  2FN  3FN

As formas normais são sequenciais, ou seja, se um banco se encontra na terceira forma normal, isso também significa que o mesmo está na segunda e também na primeira. Por isso devemos sempre começar a normalização pela primeira forma normal, para que não hajam problemas mais a frente na nossa normalização.

Primeira Forma Normal

Podemos dizer que uma tabela se encontra na Primeira Forma Normal se:

  • Possui chave primária;
  • Não possui grupos repetitivos;
  • Todos os seus atributos são atômicos, ou seja, não precisa ser decomposto.

Para chegar a primeira forma normal devemos: Determinar o atributo que possui característica de chave primária, tornar todos atributos atômicos, transformar o grupo repetitivo em uma nova tabela, levando a chave primária da tabela na qual estava, para manter a ligação entre a tabela criada e a original. Depois aplicamos também sobre essa nova tabela a primeira forma normal.

Aplicação:

Tabela (cod_cliente, nome_cliente, tel1, tel2, endereco, cod_produto, nome_produto, preco, quantidade)

Cliente (cod_cliente, nome_cliente, tel1, tel2, rua, bairro, cidade, estado)

Produto (cod_cliente, cod_produto, nome_produto, preco, quantidade)

Segunda Forma Normal

Podemos dizer que uma tabela se encontra na Segunda Forma Normal se:

  • Está na primeira forma normal;
  • Não possui dependências parciais da chave primária;

Para chegar a segunda forma normal verifique se a chave primária dessa tabela é composta ou simples. Se for simples, já se encontra na segunda forma normal. Se for composta, verifique se todos os atributos da relação dependem de todos os atributos que compõem a chave primária. Por exemplo, se a chave primária é composta dos atributos A , B e o campo C em questão depende somente de B. Se sim, já está na segunda forma normal. Se não, pegue o atributo (C) que depende parcialmente da chave primária e crie uma nova tabela. Essa tabela terá como chave primária o campo da chave primária original que determinou o campo C (nesse exemplo é o B) e adicione como atributo simples da relação o C. Veja o exemplo abaixo: (Obs: ➙ significa “determina”, ou seja, define, indica, aponta)

Aplicação:

Cliente (cod_cliente, nome_cliente, tel1, tel2, rua, bairro, cidade, estado) (não possui chave primária composta)

Produto (cod_cliente, cod_produto, nome_produto, preco, quantidade) 

cod_produto ➙ nome_produto, preco (dependência parcial)

cod_cliente, cod_produto ➙ quantidade (dependência total)

Resp: Produto (cod_produto, nome_produto, preco) 

Resp: Compra (cod_cliente, cod_produto, quantidade)

Terceira Forma Normal

Podemos dizer que uma tabela se encontra na Terceira Forma Normal se:

  • Está na segunda forma normal;
  • Se nenhum dos campos foram determinados transitivamente pela chave primária.

Para chegar a terceira forma normal verifique os campos que não são chave primária. Se algum desses campos não chave possuir dependência com outro campo não chave, então essa tabela não se encontra na terceira forma normal. Veja o exemplo abaixo:

Carro (placa, modelo, km_rodados, cod_fabricante, nome_fabricante)

Placa, modelo ➙ km_rodados

Placa, modelo ➙cod_fabricante

Placa, modelo ➙ nome_fabricante

Cod_frabricante ➙ nome_fabricante

Carro (placa, modelo, kmRodados, cod_fabricante)

Fabricante (cod_fabricante, nome_fabricante)

Conclusão

Aplicando essas três formas normais podemos dizer que o nosso banco já está normalizado. Alguns bancos, com muita movimentação, necessitam de uma normalização mais específica. Esses bancos usam também a FNBC, a quarta e a quinta forma na normalização. Por isso, para um próximo assunto, iremos dar continuidade a normalização de dados, abrangendo essas formas. Contudo, para a maioria dos casos a terceira normalização já está suficiente.


6 comentários

Marcio Wanderley · 27/11/2017 às 21:48

Como identifico dependencias? Tem alguma forma de identificar ou vai no que se acha?

    SpaceProgrammer · 29/11/2017 às 16:10

    Olá Marcio.
    Nos exercícios de normalização, geralmente as dependências funcionais vem escritas (Ex: Placa, modelo ➙ km_rodados). Já com relação a criação de um banco, na prática, isso precisa ser visto na hora de documentar o sistema. Se não conseguir identificar as dependências funcionais, pergunte ao cliente.

etecAluno · 24/06/2019 às 11:42

bd é bao d+

Marcelo · 12/03/2020 às 19:20

Acho que tem um erro na explicação da 2º forma normal. Explica que se a chave primária for simples seu banco já está na 2º forma normal, e caso seja uma chave composta(acredito que dois ou mais atributos) deve-se verificar a dependência dos atributos com essa chave composto olhando de forma individualizada a cada atributo que a forma, porém na explicação diz que o banco está na 2º forma normal por ter um atributo dependendo apenas de uma parte da chave composta e logo depois contradiz isso isolando esse atributo parcialmente dependente com a parte da chave primária em uma tabela diferente.

Deixe um comentário

Avatar placeholder
Cupom 10% OFF
Experimente o criador de sites com inteligência artificial da Hostinger
SPACEPROGRAMMER10
Cupom 10% OFF
Experimente o criador de sites com inteligência artificial da Hostinger
SPACEPROGRAMMER10