Exemplos de normalização de dados no ASP.NET

Exemplos de normalização de dados no ASP.NET

Neste post, veremos como podemos usar diferentes formas de normalização de banco de dados para normalizar nossos projetos e superar sua violação. A normalização de banco de dados é uma técnica de design de banco de dados que consiste em formulários de normalização 1NF, 2NF e 3NF. A normalização do banco de dados não garante redundância de dados nas tabelas.

Vamos dar uma olhada nas três formas básicas de normalização com seus exemplos apropriados:

1 NF: 1 NF diz que não deve haver coluna de repetição

Neste formulário, veremos como a coluna de repetição pode ocorrer e a maneira de remover a coluna de repetição.

image1

A figura acima mostra que, na tabela do cliente, o pedido da coluna é repetido por cliente, não cumprindo as regras de 1 NF. Essa violação deixou inconsistência e duplicidade de dados no banco de dados.

Desvantagem de evitar as regras da 1 NF:

  • Estrutura inadequada do design do banco de dados: suponha que um cliente precise solicitar 4 pedidos, mas você pode ver na imagem acima que há espaço para apenas 3 pedidos. Portanto, você não pode armazenar o número do pedido 4; para isso, observando a figura acima, é necessário alterar a tabela para adicionar um novo pedido da coluna4.
  • Desperdício de espaço: um segundo cliente chega e ele pede apenas dois pedidos1 e 2. Agora, a tabela para este cliente usando apenas duas colunas order1 e order2 e o espaço para a terceira coluna está vazio e o espaço para o Order3 permanece sem uso
  • Duplicidade: a coluna está se repetindo se você evitar as regras de 1 NF

Implementando o design do banco de dados 1NF: para superar o problema de duplicidade, vou dividir a tabela em duas tabelas separadas. A imagem a seguir é uma implementação de regras no formato 1NF. Eu dividi o

Repetindo a coluna em outra tabela chamada tabela de pedidos .

image2

image3

Você pode ver que o MANOJ encomendou 3 itens na tabela de pedidos com ORDERID 1, 2, 3. E a ASHOK encomendou apenas 2 itens ORDERID 4 e 5.

Com esse tipo de implementação, o 1NF possui as seguintes vantagens:

Vantagem de ter 1 NF Rules:

Estrutura de design de banco de dados adequada:

Não precisamos alterar as tabelas se os clientes solicitarem um novo pedido. Um novo pedido deve ser registrado na tabela de pedidos com o Key OrderId exclusivo .    

Espaço utilizado:

Se os clientes solicitarem mais de um item ou apenas um pedido, os espaços desses registros serão utilizados sem desperdício na tabela de pedidos.

Nenhuma duplicidade de coluna

Pela implementação do design do 1NF, você pode ver que o 1NF removeu a redundância da coluna

2NF:

  • 2NF diz que todos os atributos dependem da chave primária completa.
  • A tabela deve satisfazer a condição de 1NF
  • As tabelas têm relacionamento adequado usando chave estrangeira.

Na imagem a seguir, você pode ver a tabela CUSTOMERORDERDETAIL . Portanto, na tabela a seguir, temos duas chaves primárias CUSTOMERID E ORDERID.

image4

Portanto, nesta tabela o cliente1 solicitou eletrônicos, metais comuns e agricultura e o cliente 2 solicitou metais duros e metais macios. Estou armazenando essas informações junto com o nome do cliente. Mas o problema nesta tabela é que, para cada vez que tenho o ID do cliente, preciso colocar o nome e o telefone do cliente. Se o MANOJ encomendou 10 pedidos, terei que armazenar seu nome e número de telefone dez vezes, para que isso seja chamado de redundância.

Desvantagem de evitar regras 2NF

Dados inconsistentes

Podemos ver que o nome e o telefone do cliente não dependem totalmente da identificação do pedido, depende da identificação do cliente independentemente da identificação do pedido que o cliente tem o mesmo nome. O nome do cliente depende apenas do relacionamento parcial que é o ID do cliente. Isso deixou dados inconsistentes em nosso banco de dados.

Consultas DML lentas

Se eu precisar atualizar o número de telefone do MANOJ com o ID do cliente 1, então o número de telefone com o mesmo número de redundância do ID do cliente 1. Isso torna nossa consulta DML lenta devido ao processamento de dados de redundância.

Implementando o design do banco de dados 2NF: para superar a redundância e a dependência parcial, vou dividir esta tabela. Se não armazenarmos o nome e o telefone do cliente na tabela CUSTOMERODERDETAIL , não teremos o problema. Vou dividir esta tabela em duas partes da tabela, juntamente com o relacionamento. Portanto, temos dois tipos de informações nesta tabela: informações do cliente e informações do pedido. Ao fazer a junção na tabela de clientes e na tabela de pedidos , podemos obter as informações contidas em CUSTOMERORDERDETAIL.

Dividi a tabela CUSTOMERORDERDETAIL em duas partes. Fiz a junção nessas tabelas para que eu possa obter todas as informações contidas em CUSTOMERORDERDETAIL

image5

Portanto, se você olhar a imagem a seguir, armazenei o número de telefone e o nome do cliente de CUSTOMERID específico apenas uma vez. Da mesma forma, tenho loja ORDERID apenas uma na tabela de pedidos.

image6

Vantagem

Dados consistentes: um pedaço de armazenamento de informações em um só lugar

Consultas DML rápidas: o 2nF torna a consulta DML rápida porque não temos dados redundantes.

3NF:

  • 3NF diz que todas as colunas dependem de forma não transitória da chave primária
  • Deve satisfazer todas as condições de 1NF e 2NF

Portanto, pelas regras acima, podemos dizer que todos os atributos que não são de chave devem depender não transitivamente da chave primária.

Vamos ver a figura a seguir, na figura a seguir tenho tabela de faturas. InvoiceName é uma chave primária.

image6

Portanto, o atributo da cidade deve depender não transitivamente do InvoiceName e o atributo do país deve depender não transitivamente do InvoiceName. Aqui podemos ver que o país não depende diretamente do InvoiceName. Podemos derivar o país da cidade.

No exemplo acima, podemos ver a violação transitiva Ashok pertencer à Índia, porque Ashok pertence a Mohali. Os manoj pertencem à Índia porque os manoj pertencem a panchkula, chamada informação transitiva que precisa ser evitada.

Desvantagem de evitar regras 3NF:

  • Dados transitivos
  • Dados redundantes

Implementando o projeto 3NF: Para superar o problema das informações transitivas, dividi os dados transitivos em uma nova tabela chamada tbllocation

image7

Agora na tabela de faturas ASHOK pertence à MOHALI e na tabela de localização MOHALI pertence à Índia. Então agora eu removi as informações transitivas na tabela de faturas.