Segunda forma normal as cinco formas normais

Este tutorial explica a segunda forma normal, relacionada ao banco de dados relacional. É a segunda parte da série: as cinco formas normais. A explicação dessas cinco formas normais segue uma história, que começa a seguir: um pai morreu e deixou algum dinheiro para seu filho. O filho decidiu usar o dinheiro para abrir uma loja de conveniência. O filho empregou alguns trabalhadores (funcionários). Tudo na loja já está abastecido e a equipe começou a vender para alguns clientes. No início do funcionamento da loja, que não faz muito tempo, o filho, que é o proprietário, e seus trabalhadores, não sabiam nada sobre as formas normais.

Você já é amigo do filho, o proprietário. Você finalmente concluiu esta série de tutoriais sobre formulários normais, sabe tudo sobre formas normais e se tornou um desenvolvedor de banco de dados. Você visitou a loja de seu amigo ontem e notou que eles tinham apenas uma tabela de transações, que não cumpriu a primeira forma normal. Você então ensinou o proprietário e seus funcionários sobre como produzir a tabela de transações na primeira forma normal. Eles entenderam e a mesa que agora têm na primeira forma normal é:

Esta é a tabela de transações. Há uma coluna para a chave primária, que é transídeo (incremento automático).

Como qualquer primeira forma normal pode ter vulnerabilidades, você as visitou hoje (a loja) para treiná -las na segunda forma normal, a fim de reduzir as vulnerabilidades.

Antes de começar a fazer qualquer coisa, o proprietário perguntou:

“Esta tabela de transações atual não é muito grande?

Ouvi dizer que as empresas que não usam computadores registram seus dados em diferentes ledgers.

Eu acho que esta tabela de transações realmente consiste em duas tabelas de transação menores, que podem ter novos nomes de tabela de vendas e tabela de pedidos.”

Você responde enquanto sorri:

“Sim, a tabela de transações atual é muito grande.”

Você passou a parabenizá -lo por ser positivamente curioso, especialmente em relação ao seu negócio. Você concorda com os pensamentos dele. Você continua dizendo que existem realmente três mesas principais: a tabela de vendas, a tabela de pedidos e a tabela de produtos. Quando as tabelas de vendas e pedidos forem identificadas, elas substituem a tabela de transações. A tabela de vendas e a tabela de pedidos são tabelas menores (metade) em si mesmas. A tabela de produtos é claramente uma entidade. Deve ser obtido da tabela de transações anteriores anteriores.

No entanto, essas três tabelas obtidas da grande mesa anterior ainda estariam na primeira forma normal. O segundo formulário normal aborda o problema da repetição (redundância), e não é isso que acontece aqui.

Nota: O segundo formulário normal pode não abordar todos os problemas de repetição (redundância).

Você, o desenvolvedor do banco de dados e um amigo do proprietário, continua a produzir as três tabelas com sua participação da seguinte forma:

As principais entidades

As entidades principais são as três tabelas principais mencionadas anteriormente. Na coluna anterior, com o título, a ação tem venda ou ordem. Venda significa que o produto nessa linha foi vendido a um cliente. Ordem significa que o produto nessa linha foi ordenado de um fornecedor. Uma loja de conveniência precisa encomendar produtos antes de vendê -los.

As colunas correspondentes às três tabelas são as seguintes:

Vendas (Saleid, Produto, Cliente, Funcionário, SellingPrice)

Order (OrderId, Produto, Fornecedor, Funcionário, CostPrice)

Produtos (ProductId, Produto, Categoria)

Cada notação de tabela tem uma chave primária sublinhada. Cada uma dessas tabelas ainda está na primeira forma normal. E assim, cada número de chave está relacionado diretamente aos seus valores de linha.

Na tabela de vendas, os Saleids não são as cópias dos transídeos. Na tabela de pedidos, os OrderIds também não são as cópias dos transídeos. Cada uma das colunas SaleId e OrderId é o incremento automático, começando de 1. A tabela de transações e seus IDs de linha não são mais importantes, pois todas as informações na tabela de transações estão agora nessas três tabelas. As colunas SaleId e OrderID substituem a tabela de transações, mas não copiando. A tabela de vendas não possui a coluna do fornecedor e a tabela de pedidos não possui a coluna do cliente, que estavam juntas na tabela de transações. Além disso, nenhuma das tabela tem a coluna de ação desde que a venda e pedidos agora está separada, e os dois valores de venda e ordem não são mais necessários.

A coluna de categoria, que estava na coluna de transação, não está na tabela de vendas nem na tabela de pedidos. Está na tabela de produtos. Isso ocorre porque o valor da categoria em cada linha está relacionado apenas ao valor do produto e não à outra célula na linha. A coluna de categoria deve sair da tabela de transações junto com a coluna do produto para obter a tabela de produtos. Esse raciocínio tem algo a ver com dependência transitiva na produção da terceira forma normal que será discutida no próximo tutorial.

A tabela de produtos obtida da tabela de transações anterior é:

Tabela de produtos

Observe que esta tabela não tem nenhuma repetição do nome do produto (para baixo) que possa estar na tabela de transações. Além disso, cada valor do produto está presente e cada valor de categoria também está presente.

Esta tabela ainda está em 1nf. A dependência dos valores de uma linha está relacionada apenas à chave primária, até agora. Os valores na coluna da categoria repetem à medida que a coluna é descendente. A confeitaria se repete duas vezes. “Soff refrige” se repete quatro vezes. “Produto de laticínios” repete três vezes. A repetição é redundante e causa problemas contábeis. Colocar uma mesa em 2nf significa remover muitas repetições. Esta remoção de repetições não é feita arbitrariamente.

A tabela de vendas obtida da tabela de transações anterior é:

Tabela de vendas

Quatro novas linhas são adicionadas e houve alguma modificação para melhorar a explicação. Uma coluna de data é introduzida pelo mesmo motivo. Agora, existem 15 linhas nesta tabela de vendas em vez de 11 para a tabela de transações.

Regras do negócio

O que é uma venda? Se o mesmo funcionário vender para um determinado cliente na mesma data pelo menos um produto, essa é uma venda. Mesmo no mesmo dia (data), se um cliente vier duas vezes e for servido por dois funcionários diferentes, essas são duas vendas. Se um cliente ocorrer duas vezes no mesmo dia e for servido pelo mesmo funcionário, mesmo que os dois conjuntos de produtos sejam diferentes, ambas as comingas formam uma venda. Em uma venda, um cliente pode comprar um ou mais produtos. Em outras palavras, em uma venda, o trio (cliente, funcionário e data) deve ser o mesmo. Uma vez que um desses valores de trio muda, essa é outra venda. Diferentes vendas são identificadas por diferentes Saleids na tabela anterior. E assim, os Saleids repetem. Diferentes valores de coluna repetem em suas colunas.

Na primeira venda, que tem duas linhas e o mesmo Saleid, John Smith, um cliente, comprou um doce e um sprite de Jacob Jones na mesma data.

Na manhã de 09/06/22, James Taylor, um cliente, veio e comprou dois iogurte e uma Coca-Cola. Essa é uma venda. São necessárias três linhas na tabela com o mesmo SaleId.

No mesmo dia, mas à tarde, o mesmo James Taylor veio e comprou a Pepsi, mas de um funcionário diferente, que é Peter Lewis. O trio agora tem uma mudança com um funcionário diferente. E assim, esta é uma venda diferente causada por uma mudança em um dos trio. Como essa é uma venda diferente, ele tem uma linha diferente na tabela com um SaleID diferente.

Em 09/08/22, Susan Wright, um cliente, veio e comprou dois queijo e um leite de Mary Baker. Essa é uma venda porque o trio permanece o mesmo (nas três linhas). No entanto, são necessárias três linhas na tabela. Como o trio permanece o mesmo, o Saleid também permanece o mesmo.

O restante das fileiras para baixo na tabela não tem a mesma repetição Saleid. Esta tabela ainda está em 1nf. A dependência até agora para os valores de uma linha ainda está relacionada apenas à chave primária dessa linha. Cada coluna tem valores repetidos. A repetição em uma coluna não deve necessariamente estar em células consecutivas descendo.

Veja quando considerar o preço ou a coluna do price de venda na seção tutorial de repetições de manuseio. Colocar uma tabela em 2NF resolve o problema das repetições comuns do conjunto (redundância) nas linhas.

A tabela de pedidos obtida da tabela de transações anterior é:

Tabela de pedidos

Esta tabela ainda está na primeira forma normal. Existe a possibilidade de qualquer valor em qualquer coluna repetir abaixo de sua coluna. Essas repetições são abordadas neste tutorial para ter a segunda forma normal da tabela.

Neste ponto, você, o desenvolvedor do banco de dados, concordou com a sugestão da equipe para colocar a tabela de transações em mesas menores. E você coloca a tabela de transações em mesas menores (entidades) de uma maneira conveniente. A equipe, incluindo seu proprietário, agora acredita que eles também têm o potencial de entender completamente as formas normais e estão dispostos a aprender mais porque sua sugestão se materializou.

No entanto, você, o desenvolvedor do banco de dados, insiste neles que a tabela de transações original não existe mais e foi substituída pelas três mesas menores. As vendas e a tabela de pedidos substituem essencialmente a tabela de transações. O transídeo (ID da transação) não é mais relevante. É substituído pelo SaleId e OrderId em duas mesas diferentes.

As principais entidades que agora são tabelas menores da tabela de transações originais são: a tabela de produtos, a tabela de vendas e a tabela de pedidos. Você, o desenvolvedor do banco de dados, continua a explicar e insistir para que essas mesas novas, mas menores, ainda estejam na primeira forma normal. Substituir uma tabela por suas tabelas de entidade principal não é normalização porque nenhum dos tipos de definições de dependência é usado para quebrar a grande mesa. Você, o desenvolvedor do banco de dados, continua colocando as três tabelas na segunda forma normal da seguinte maneira:

Lidar com repetições

A tabela de produtos

Na tabela de produtos, os valores da coluna de categoria repetem. Todos os nomes (valores) da coluna de categoria devem ser removidos da tabela de produtos em uma tabela de categorias onde não haveria repetições limitadas. A tabela de categorias se torna:

Tabela de categorias

A tabela de categorias não tem mais nenhum item como "refrigerante" que repete. Esta tabela é mais curta verticalmente que sua colocação na tabela de produtos anteriores.

Qualquer tabela precisa de uma chave primária. Até agora, a tabela de categorias consiste em uma coluna em que todos os valores são únicos e não há célula vazia ou valor nulo. Esta coluna pode ser a coluna de chave primária para a tabela de categorias. No entanto, pode ser melhor ter uma chave primária de incremento automático. A tabela de categorias modificadas a seguir mostra o seguinte:

Tabela de categorias - 2nf

Esta é a tabela de categorias finais. Está agora em 1nf e 2nf. E a tabela de produtos originais? Uma nova tabela de produtos precisa ser criada. Na nova tabela, qualquer nome de categoria na tabela original será substituído pelo ID correspondente na tabela de categorias. Então, a tabela de produtos se torna:

Tabela de produtos - 2nf

A coluna de categoria é substituída pela coluna CategoryId. As informações para os valores da categoria ainda estão lá na tabela de produtos como categoryids. A coluna de categoria é colocada logo após a coluna do ProductID, em vez de após a coluna do produto para melhor apresentação. Esta tabela não é mais curta que a tabela de produtos originais, mas ainda tem uma vantagem.

“Qual é a chave principal da tabela de produtos?”Perguntado por um dos funcionários. Observe que em cada linha, o ProductId e CategoryId dependem do valor do nome do produto (valor). Se o ProductId ou o CategoryId for alterado para qualquer linha, a nova combinação de ProductID e CategoryId apontaria para um nome diferente do produto (valor). Em outras palavras, um nome de produto (valor) em uma linha está relacionado ao produto e categoryid dessa linha. Devido a essa dependência (dependência funcional) da combinação ProductId e CategoryID em um nome de produto específico (valor), tanto o productId quanto o categoryID formam a chave primária.

Quando uma chave é uma combinação de mais de uma coluna, a chave é chamada de chave composta. A notação da tabela para esta nova tabela de produtos é:

Produtos (ProductId, CategoryId, Product)

A relação entre o ProductID e CategoryId é muitos para um.

Cada nome da coluna para a chave primária (chave composta desta vez) está sublinhada. Os valores da categoria na tabela de produtos e os valores da categoria na tabela de categorias fazem as correspondências exatas entre as duas tabelas.

A notação da tabela para a tabela de categorias é:

Categorias (categoryId, categoria)

As novas tabelas que substituíram a tabela de produtos originais são: tabela de categorias e tabela de produtos (mesmo nome). Essas tabelas estão agora na primeira forma normal e na segunda forma normal. Veja as regras reais para a segunda forma normal na seguinte discussão.

A tabela de vendas

As seções de remar em que o SaleId se repete, mas os valores da célula da coluna não se repetem, precisam ser removidos da tabela de vendas e colocados em uma nova tabela. Na nova tabela, as seções de linha idênticas (colunas), onde os valores das células se repetem junto com o SaleId na tabela de vendas não serão incluídos. Ou seja, qualquer valor celular ou seção de fila como o trio (cliente, funcionário e data) que deve se repetir com o mesmo SaleId na tabela de vendas não será incluído na nova tabela, mesmo que a repetição seja apenas uma vez. Os valores da coluna do produto que podem mudar com o mesmo SaleId na tabela de vendas devem estar na nova tabela. É introduzida uma nova coluna que possui o número dos mesmos produtos vendidos para um determinado SaleId. Que mantém a nova tabela em 1nf, levando -a para 2NF. A nova tabela é chamada de tabela de saledetails. Se o desenvolvedor não conseguir encontrar um novo nome adequado para a nova tabela, algo deu errado com sua análise. A tabela de saledetails se torna:

Saledetails - 2nf

A tabela de saledetails, removida da tabela de vendas, está agora na segunda forma normal e ainda na primeira forma normal. O SaleId da tabela de vendas original deve ser incluído na tabela Saledetails para manter o relacionamento entre a tabela de vendas original e a nova tabela de saledetails. Agora, existem 13 linhas na tabela de saledetails em vez de 15 da tabela de vendas original.

Na tabela de vendas original, qualquer coluna cujo valor não mudou, enquanto o Saleid não estava mudando, permaneceu na tabela de vendas original e não foi removido. Estes são essencialmente o trio (cliente, funcionário e data) nesta situação. Os valores da coluna do produto foram alterados enquanto o SaleID não estava mudando, então deve ser removido. Se o preço ou os valores da coluna do preço de venda mudar enquanto o SaleId não estiver mudando, ele também deve ser removido.

Todo mundo viria a uma loja e apenas compraria apenas uma lata de leite? Não. Para qualquer cliente que compra, digamos 4 latas de leite, o número 4 se encaixaria bem na coluna Numbersold na linha apropriada.

“E qual é a chave principal da nova tabela de saledetails?”Perguntado pelo proprietário. Esta é a sua resposta como desenvolvedor de banco de dados:

Observe que em cada linha, o SaleId e o produto dependem do número de números e do SellingPrice (valores). Se o SalesId ou o nome do produto for alterado para qualquer linha, a nova combinação do SaleID e do produto apontará para uma linha diferente do número de números e SellingPrice. Em outras palavras, um número de números e SellingPrice Row está relacionado aos valores SaleID e do produto dessa linha. Devido a essa dependência (dependência funcional) da combinação de vendas e produtos em uma linha específica, tanto o vendedor quanto o produto formam a chave primária. O produto também deve ser sublinhado.

Quando uma chave é uma combinação de mais de uma coluna, a chave é chamada de chave composta. A notação da tabela para esta nova tabela de saledetails é:

Saledetails (Saleid, Produto, Numbersold, SellingPrice)

A relação entre o vendedor e o produto é muitos para muitos.

“Eu pretendo informatizar o banco de dados. Como já existe uma tabela de produtos com o ProductID, não seria melhor substituir o produto como parte da chave pelo ProductID? Em seguida, o computador usará o ProductID da tabela Saledetails e procurará o nome do produto da tabela de produtos ”, observa o proprietário.

Você, o desenvolvedor e treinador de banco de dados, sorri enquanto balance a cabeça. E esta é a sua resposta:

“Proprietário, você está bem. Você está entendendo mais rápido do que eu esperava. Quando um banco de dados estará apenas em livros de exercícios (ledgers), sempre que possível, ele terá nomes de texto em vez de IDs numerados. Quando um banco de dados estará em um computador, sempre que possível, ele terá IDs numerados em vez de nomes de texto. O computador conectará os IDs e nomes de texto numerados em suas tabelas e imprimem os nomes de texto quando uma consulta for emitida.

Deixe -me ter a honra de fazer a informatização; Mas para a informatização, você vai me pagar.”E assim, a notação da tabela para a tabela de saledetails se torna:

Saledetails (SaleId, ProductId, Numbersold, SellingPrice)

“O que resta da tabela de vendas?”Perguntado por um dos funcionários. As colunas cujos valores não mudaram enquanto o Saleid não estava mudando na tabela de vendas. O Saleid também permanece porque "governa" cada linha na mesa de vendas. A nova tabela de vendas se torna:

Tabela de vendas - intermediário

O produto e as colunas do price de venda onde houve mudança de valor enquanto o SaleID não estava mudando foi removido. Agora, existem claramente algumas linhas completas duplicadas. Tais duplicatas já foram contadas e registradas na tabela de saledetails na coluna de números. Na tabela real de saledetails, a contagem é 2 ou 1. Portanto, as duplicatas não precisam ser levadas em consideração na nova tabela de vendas. Se as duplicatas forem permitidas, uma das regras da primeira forma normal seria violada. A nova tabela de vendas se torna:

Tabela de vendas - 2nf

Esta tabela de vendas nova e final está em 2NF e ainda em 1nf. Nenhum Saleid ocorre mais de uma vez nesta tabela. Existem 10 linhas aqui, e não 15, quando comparadas com a tabela de vendas original. Esta nova tabela de vendas é mais curta que a original por cinco linhas.

Esta tabela de vendas final possui apenas uma coluna de chave primária que é o SaleId. Está sublinhado. Os valores Saleid na tabela de vendas e valores SaleID na tabela Saledetails fazem as correspondências exatas entre as duas tabelas.

A notação da tabela para a tabela de vendas é:

Vendas (Saleid, Cliente, Funcionário, Data)

E a notação de tabela para a tabela de saledetails é:

Saledetails (SaleId, ProductId, Numbersold, SellingPrice)

As novas tabelas que substituíram a tabela de vendas originais são: tabela de saledetails e tabela de vendas (mesmo nome). Essas tabelas estão agora na primeira forma normal e na segunda forma normal. Veja as regras reais para a segunda forma normal na seguinte discussão:

A tabela de pedidos

A análise semelhante à da tabela de vendas pode ser feita para que a tabela de pedidos tenha as novas tabelas de substituição:

Order (OrderId, Fornecedor, Funcionário, Data)

e

OrderDetails (OrderId, ProductId, numberbought, CostPrice)

Neste ponto, você, o desenvolvedor do banco de dados, acabou de ilustrar para os funcionários, incluindo o proprietário sobre como o 2NF é produzido a partir do 1NF.

O proprietário agora pergunta: “É assim que formaremos a tabela 2NF da tabela 1NF?Você, o desenvolvedor do banco de dados, responde da seguinte maneira:

"Bem, sim. No entanto, qualquer maneira que você use para formar um 2nf a partir do 1nf deve respeitar as regras do 2NF.”Você então explica as regras do 2NF.

Regras para a segunda forma normal

Para que uma tabela esteja na segunda forma normal, deve respeitar as duas regras a seguir:

1) A tabela já deve estar na primeira forma normal.

2) Não deve haver dependência parcial.

A dependência funcional ou simplesmente dependência é explicada na parte anterior da série, a primeira forma normal. A explicação é brevemente repetida aqui e então a dependência parcial será explicada.

Dependência funcional

Em qualquer tabela na primeira forma normal, uma vez que uma chave primária é conhecida, o restante dos valores na linha da chave primária pode ser buscada. Por exemplo, na primeira tabela no exemplo anterior, os valores para a chave primária número 10 são: pasta de dente, produtos de higiene pessoal, empresa de limpeza, Peter Lewis, Ordem e 4. Então, o número principal 10 depende desses valores. Uma chave primária identifica exclusivamente todos os seus valores.

Dependência parcial

Dependência parcial é uma situação com chave composta em que um valor de chave não primário em uma linha pode ter apenas parte da chave composta, e.g. uma de suas células dependendo disso. Nas tabelas anteriores com teclas compostas, cada valor de chave não primária em uma linha possui as duas células da chave primária, dependendo dele. A segunda regra para o 2NF diz que não deve haver dependência parcial. E não há dependência parcial em nenhuma das mesas anteriores.

Ambas as células da chave composta dependem de cada valor na linha para todas as tabelas acima com teclas compostas. Se fosse dependência parcial, uma célula na chave composta dependeria de alguns valores na linha, e a outra célula da chave composta dependeria dos outros valores da mesma linha.

Produção de 2NF da tabela de produtos e tabela de vendas em comparação

A tabela de produtos tem um limite de comprimento (para baixo). A tabela de vendas não tem um limite de comprimento porque é uma tabela de transações. No entanto, essa diferença não é o que necessariamente dá às duas tabelas suas diferentes maneiras de obter as tabelas 2NF.

Na tabela de produtos 1NF fornecida, as categorias se repetem para baixo. A coluna da categoria é removida para formar uma nova tabela de comprimento limitado e a chave composta vai para a tabela pai, a tabela de produtos.

Na tabela de vendas 1NF fornecida, o conjunto SaleID e correspondente de outras células da mesma linha se repetem para baixo. As colunas bastante não repetidas foram removidas para formar uma nova tabela e a chave composta vai para a tabela infantil, a tabela Saledetails. As tabelas de vendas e saledetails são de comprimentos ilimitados.

Neste ponto, você, o desenvolvedor de banco de dados que treina a equipe, incluindo seu proprietário, pede a todos que verifique se todas as novas tabelas estão realmente na primeira e segunda formas normais. Eles devem fazer isso com sucesso e responder sim.

E então, você conclui.

Conclusão

Uma tabela está na segunda forma normal se cumprir as seguintes regras:

1) A tabela já deve estar na primeira forma normal.

2) Não deve haver dependência parcial.

Para todas as tabelas com teclas primárias compostas, todos os valores-chave não primários em uma linha determinam cada um dos primários do valor da chave dessa linha.

Tomar uma tabela de 1NF a 2NF envolveria o manuseio de um grande grupo repetido (conjunto de células).

Embora algumas vulnerabilidades tenham sido eliminadas, uma tabela em 2NF ainda tem outras vulnerabilidades. Mais dessas vulnerabilidades serão tratadas no próximo tutorial (artigo) sobre a terceira forma normal.

Pelas perguntas que os membros da equipe estão fazendo e o feedback deles, isso mostra que eles entenderam tudo o que foram ensinados até agora. Você deve parabenizá -los antes de sair e voltar novamente para discutir sobre a terceira forma normal.