Boyce-Codd, quarta e quinta formas normais

“Esta é a parte quatro da série, as cinco formas normais. A forma normal de Boyce-Codd é abreviada BCNF. Também é conhecido como 3.5nf. 3.5 é 3½. Vem depois da terceira forma normal. A quarta forma normal é abreviada 4NF e vem depois da forma normal da Boyce-Codd. A quinta forma normal é abreviada 5NF e vem após a quarta forma normal.

Este tutorial (artigo) é a quarta parte da série tutorial, as cinco formas normais. Este tutorial explica BCNF, 4NF e 5NF.

Este tutorial segue um enredo da seguinte maneira: um pai morreu. Ele deixou algum dinheiro para seu filho. Seu filho decidiu usar o dinheiro para abrir (iniciar) uma loja de conveniência. A loja de conveniência já está abastecida e está operando há algum tempo. O filho tem alguns funcionários, chamados funcionários, nesta série tutorial. O filho é o proprietário. Antes de a loja funcionar, tanto o proprietário quanto os funcionários não sabiam as formas normais.

Você, o leitor, concluiu esta série de cinco formulários normais e também é um desenvolvedor de banco de dados. O filho do falecido pai é seu amigo. Você visitou a loja dele nos últimos três dias. No primeiro dia, você os visitou; Você treinou o proprietário e seus funcionários sobre como colocar uma tabela de banco de dados em 1nf. No segundo dia, você os treinou sobre como mover uma mesa de 1nf para 2nf. No terceiro dia, você os treinou sobre como mover uma mesa de 2nf para 3nf.

Hoje, no quarto dia, você visitou a loja para treinar apenas o proprietário no BCNF, 4NF e 5NF em seu escritório.”

Formulário normal de Boyce-Codd

A questão do BCNF ocorre quando há uma chave primária composta e um atributo de chave não primária (coluna), e a chave não primária depende funcionalmente da peça (e.g., um) dos principais atributos -chave, enquanto a tabela já está na terceira forma normal.

Isso implica que a coluna não prime (chave não primária) e a coluna Prime dependem da forma uma entidade e precisam ser removidas como uma tabela separada, onde a coluna não primária será a chave primária. A outra parte da chave primária composta formará uma nova tabela com a coluna não primária, e a coluna não primária não fará necessariamente parte da chave primária. A outra parte da chave primária composta continua sendo uma chave primária. Os possíveis dependentes relacionados da tabela pai acompanham adequadamente as duas mesas infantis.

A separação de tabelas para a forma normal de Boyce-codd não é realmente a mesma que a separação de tabelas em 2nf e 3nf.

Uma tabela está na forma normal de Boyce-codd se as seguintes regras forem obedecidas:

1. A tabela já deveria estar na terceira forma normal.
2. Nenhum atributo não prático (coluna) deve depender da parte da chave primária composta.

Este segundo ponto, conforme citado, é simplificado.

Exemplo

Na parte anterior desta série, a tabela Saledetails (com alguma modificação) foi dada da seguinte forma:

Saledetails (Saleid, Produto, Numbersold, UnitSellingPrice, desconto)

Uma tabela correspondente com dados é:

O preço de venda da unidade é do tipo, flutuação ou número. A chave primária nesta tabela é uma chave composta que consiste em SaleId e produto.

Esta tabela está em 3nf. O número de produtos vendidos pode ser considerado depender do produto e não do SaleId. Em outras palavras, uma chave não prática pode depender apenas da parte da chave primária composta. Isso não deve acontecer; E assim, a partir dessas três colunas, as duas tabelas a seguir podem resultar:

Quantidade (Numbersold, Produto)

e

Saledetails (Saleid, Numbersold)

Para a tabela, quantidade, a chave primária é os números. Para a nova tabela de saledetails, a chave primária ainda é Saleid.

Da tabela de saledetails dos pais, o único dependente para Numbersold é o produto. Da tabela de saledetails dos pais, os dependentes do SaleID são números, unitsellingPrice, desconto e sem produto. E assim as mesas devem realmente ser:

Quantidade (Numbersold, Produto)

e

Saledetails (Saleid, Numbersold, Numbersold, UnitSellingPrice, desconto)

Neste ponto, o proprietário faz o seguinte comentário:

“Acho que nunca vou querer saber a quantidade de um produto específico vendido sem querer conhecer o SaleID, que depende do trio (compra do cliente, vendendo funcionário e data da transação).Você, o desenvolvedor do banco de dados, responde da seguinte maneira:

“Nesse caso, permitimos que os saledetails e a tabela OrderDetails. Afinal, muitos bancos de dados comerciais por aí não vão além do 3NF, e os negócios são confortáveis. No entanto, sempre que você quiser saber disso para uma tabela semelhante, divida a tabela pai em tabelas BCNF.”

Quarta forma normal

1nf, 2nf, 3nf e bcnf dependem da dependência funcional. 4nf depende de um tipo especial de dependência funcional, que é bastante "perturbadora", especialmente se não bem compreendida. Essa dependência bastante perturbadora é chamada de dependência multivaluntada.

A dependência funcional é simplesmente chamada de dependência. No entanto, a dependência multivalunciada não é simplesmente chamada de dependência, pois isso traria confusão. É chamado de dependência multivaluntado.

Você, o desenvolvedor do banco de dados, diz ao proprietário o seguinte: “Deve interessar a você que uma tabela em 1nf, cada célula deve ter um único valor. Um problema um tanto semelhante ocorre aqui, mas com uma tabela que já está no BCNF após 3nf. A dependência multivalunciada é com a chave primária composta, e cada célula em toda a tabela já possui um único valor. Na questão 1NF, os múltiplos valores em uma célula não precisam preocupar uma chave. Com a edição 4NF, existem pelo menos três colunas. Se houver apenas três colunas, as três colunas formam a chave composta primária. Nesse caso, a primeira coluna de células pode determinar a segunda coluna de células, mas a segunda coluna é independente da terceira coluna. 4nf não permite isso.”

Em outras palavras, a questão pode ser que a segunda coluna depende da primeira coluna, e a terceira coluna ainda depende da primeira coluna e não tem nada a ver em termos de dependência da segunda coluna. 4nf não permite isso.

Antes de continuar com a explicação da dependência multivaluga, como a questão da quarta forma normal pode surgir deve ser explicada primeiro.

Como a questão do 4NF pode surgir com a loja de conveniência

Imagine que depois de algum tempo, você teve rivais (outras lojas de conveniência) em seu bairro, e você não está vendendo tanto quanto estava vendendo antes. Isso não poderia ser previsto quando você começou a loja de conveniência.

Ocorre a você que, se você puder reduzir seus preços, não abaixo do preço de custo, é claro, para seus clientes que mais compram, eles comprarão mais, e suas vendas e lucro aumentariam em relação ao nível desativado. Isso significa que você precisa saber onde esses clientes saem e seus endereços (ruas) para que você possa entregar produtos em suas casas. Novamente, esse problema não foi previsto no começo.

E assim você cria a tabela a seguir, na qual você trabalhará, até o BCNF, antes que a edição do 4NF possa se mostrar:

Entrega

Para você, o proprietário, seu interesse é a categoria do produto, o próprio produto a ser entregue e o endereço para entregar. Olhando para a mesa inteira, o restante das seções da linha, começando do nome personalizado para a extremidade direita, determine as três primeiras colunas. Em outras palavras, as três primeiras colunas formam a chave primária para o restante das colunas. Ou seja, as três primeiras colunas dependem do restante das colunas por linhas. E assim, os três primeiros títulos de coluna devem ser sublinhados com linhas únicas. Com isso, esta tabela está agora em sua primeira forma normal. Cada combinação de células horizontais nas três primeiras colunas é exclusiva.

Esta tabela também está na segunda forma normal, porque cada combinação de células horizontais nas três primeiras colunas é única e não há dependência parcial (com grupos repetidos). No entanto, não está na terceira forma normal porque as seções da linha (partes) começando do nome do personalizador para a extremidade direita Determine o ClientID (o ClusterID depende deles). Então, tudo o que precisa ser removido, deixando você com uma cópia do clientes. CustomerID agora é uma chave estrangeira e como parte da chave primária. A tabela está agora em 3nf.

Antes de você, o desenvolvedor e treinador de banco de dados, poderia continuar, o proprietário diz: “Em vez de trabalhar com a coluna da categoria, coluna de produtos e coluna de endereço, trabalharei com a coluna da categoria, coluna do produto e coluna do cliente, uma vez que o cliente é Conhecido, o endereço pode ser conhecido, e isso seria mais conveniente, especialmente para o computador.”

Sua resposta: “Isso é bom, proprietário. Você está no caminho certo. Isso é o que será feito.”

Lembre -se, a tabela de clientes já existe. Isso foi produzido na parte anterior desta série de tutoriais. Então, a única tabela para produzir agora é uma tabela apenas com as três chaves primárias.

Permutações de entrega de categoria, por produto

Infelizmente, as colunas desta chave primária composta não estão em 2NF entre si. Existem repetições dos valores celulares que descem para baixo, com dependência parcial na chave composta. Essas repetições não são tão construtivas quanto parecem.

Observe que a confeitaria está associada ao Cliente 1 e também está associada ao Cliente 2. O refrigerante está associado ao Cliente 1 e também está associado ao Cliente 2.

Se o cliente 1 pediu doces hoje, ele pedirá chocolate amanhã (não mostrado na mesa). A confeitaria está associada ao Cliente 1 através dos doces na mesa, mas também pode ser associado ao Cliente 1 através de chocolates nas entregas amanhã. Se o Cliente 1 pediu Sprite hoje, ele pedirá Coca-Cola amanhã. O refrigerante está associado ao Cliente 1 através do Sprite, na mesa, mas também pode ser associado ao Cliente 1 através da Coca-Cola. O mesmo problema de entrega ocorre com o cliente 2. Esse tipo de repetição é chamado de dependência multivaluntado.

Observe que na tabela acima, a coluna do produto não tem repetição (pelo menos por enquanto).

Para resolver esse problema, é melhor colocar primeiro essas repetições dos valores da coluna, da chave primária, na primeira forma normal para resultar no seguinte:

Permutações completas de entrega de categoria por produto

Permutação significa mudar a ordem de um acordo. Nesta situação, significa fornecer todas as diferentes ordens possíveis de produtos na coluna do produto. Agora, há mais repetições (mais redundância) nesta tabela do que no acima. A boa notícia é que essas três colunas agora estão bem, na primeira forma normal. 2NF e 3NF devem estar previstos para essas três colunas.

Lembre -se de que a entrega não foi prevista no início quando a loja começou (foi operacional). Se tivesse sido previsto, a primeira tabela de transações na primeira parte desta série tutorial teria sido assim:

Observe que os múltiplos valores em cada célula nesta coluna de produto têm mais fatores levados em consideração do que o que aconteceu na primeira tabela de transações na primeira parte da série. Trazer esta tabela para a primeira forma normal resultaria na tabela anterior, que é reimpresso aqui, para facilitar a referência ao leitor, com algumas modificações na coluna do produto:

As duas mesas de primeira forma normal são as mesmas porque a permutação na coluna do produto é relativa à coluna CustomerID. Não se esqueça que cada clusterID aqui identifica uma linha na tabela de clientes.

A definição de dependência multivalugurada significa que, se houver três colunas, x, y e z e para uma linha específica de valores x, y e z, respectivamente, uma dependência multivalulada x ->> y significa que, se escolhermos algum x realmente ocorrendo na tabela (chame essa escolha x_c) e compilar uma lista de todos os x_cCombinações YZ que podem ocorrer na tabela, como feito acima, descobriremos que x_c está associado às mesmas entradas Y, independentemente de Z. Portanto, essencialmente, a presença de z não fornece informações úteis para restringir os possíveis valores de y.

Na tabela acima, x_c, por exemplo, é confeitaria e um valor y correspondente é doce. A combinação de confeitaria e doces não tem nada a ver com a coluna CustomerID, onde o valor talvez 1 ou 2 nas linhas. Se x for tomado como refrigerante, um valor y correspondente seria Sprite. A combinação de refrigerante e sprite não tem nada a ver com as colunas do cliente, onde o valor talvez 1 ou 2 nas linhas.

Visto de uma segunda forma normal e pontos de vista de dependência funcional, a coluna de categoria depende da coluna do produto e também depende da coluna CustomerID, mas não depende das duas colunas quando combinado. Os valores na coluna do produto repetem, determinando os valores na coluna de categoria; e os valores na coluna CustomerID repetem, determinando os valores na coluna de categoria; Mas ambas as colunas juntas não determinam os valores na coluna de categoria.

Portanto, a tabela deve ser dividida em dois, com a categoria e as colunas de produtos indo de uma maneira e a categoria e as colunas do ClienteID indo para o outro lado, da seguinte maneira:

Tabela de produtos de categoria

Categoria - Tabela de clientes

Essas duas tabelas de crianças estão agora em 1nf, 2nf, 3nf, bcnf e o mais importante, 4nf. A tabela de produtos de categoria possui teclas primárias compostas. A tabela de category-clustomer também possui teclas primárias compostas. Cada uma das teclas da coluna já é uma chave primária em outra tabela no banco de dados, ou é uma chave estrangeira em alguma outra tabela no mesmo banco de dados.

Essas duas tabelas substituindo a tabela pai não são as únicas tabelas em todo o banco de dados. De fato, eles estão relacionados a outras tabelas no banco de dados. Portanto, ainda há algum trabalho de limpeza no projeto de design de banco de dados a ser feito sobre todo o banco de dados e essas duas novas tabelas.

Referindo-se à tabela de produtos de categoria, lembre-se de que já existe uma tabela de produtos em 4NF e uma tabela de categoria em 4NF no banco de dados. Para que uma tabela esteja em qualquer forma normal, ela não deve violar nenhuma dessas regras da forma normal. Os produtos ou a tabela de produtos possuem o ProductID como sua chave principal e categoria ou categoryId como uma chave estrangeira.

Portanto, a tabela de produtos de categoria produzida aqui, em 4NF, deve ser abandonada desde que as duas tabelas a seguir, que estão em 4NF, têm todas as suas informações (e mais):

Categorias (categoryId, categoryName, descrição)
Produtos (ProductId, CategoryId, SupplierId, Nome do ProductNe, UnitPrice, QuantityInstock, Reordenamento)

Por outro. De fato, a tabela deve ser melhor chamada, categorydelivery. Chamar -o de produtividade de produtos seria enganoso para programadores de banco de dados, mas não seria enganoso para os clientes, que são analfabetos no banco de dados. Então chame de categorydelivery. Na forma de notação de tabela, é:

Categorydelivery (categoria, clientes)

Lembre -se de que cada clusteriD refere -se a uma linha na tabela de clientes. A chave primária composta é: categoria, CustomerId. Como já existe uma tabela de categorias com categoryId, esta tabela deve realmente ser:

CategoryDelivery (categoryId, CustomerID, categoria)

onde categoryId depende da categoria (nome) e vice-versa.

Portanto, a questão da entrega traz uma tabela extra em 4nf. O restante das tabelas no banco de dados já está em 4NF, pois não violam as regras 4NF declaradas abaixo.

O problema de entrega não foi previsto antes do início da normalização em suas diferentes classes, no começo. Se tivesse sido previsto como indicado acima, a categoria de entrega teria chegado; Antes ou antes do terceiro estágio de formulário normal, sem qualquer menção ao 4NF.

Quarta Regras de Formulário Normal

Uma tabela está em 4NF se não violar as seguintes regras:

1. Já está na forma normal de Boyce-Codd.
2. A tabela não tem nenhuma dependência com vários valores.

Isso significa que uma tabela pode ser projetada pela primeira vez e já está em 4nf.

Quinta forma normal

As situações 5NF raramente ocorrem, mas quando elas ocorrem, a quinta forma normal deve ser levada em consideração para evitar qualquer problema contábil conhecido. A quinta forma normal também é conhecida como projeção, junte -se a forma normal. Com a quinta forma normal, existem pelo menos três colunas. Se houver apenas três colunas de interesse, há uma chave primária composta, que é composta pelas três colunas.

Imagine que você, o proprietário, teve até duas lojas de conveniência na mesma cidade e são fornecidas pelo mesmo conjunto de fornecedores. Ligue para essas lojas, Shop1 e Shop2. Os fornecedores veem essas duas lojas diferentes como dois clientes diferentes. Então, aqui, o cliente tem um significado diferente. Significa comprar e não a pessoa. O significado do produto permanece o mesmo.

Portanto, há uma tabela com as chaves primárias: fornecedor, produto e cliente. Aquilo é:

Tabela (fornecedor, produto, cliente)

A questão 5NF surge quando um determinado fornecedor pode fornecer um determinado produto a mais de um cliente (as duas lojas). Além disso, um determinado cliente pode receber um determinado produto de mais de um fornecedor. E um determinado cliente pode receber de diferentes fornecedores diferentes produtos. Ou seja, qualquer um dos três parceiros pode fazer as mesmas coisas com os outros dois parceiros.

Ou seja, um fornecedor pode corresponder a mais de um cliente. Um cliente pode corresponder a mais de um produto. E um produto pode corresponder a mais de um fornecedor. Isso significa que as três mesas binárias a seguir podem resultar:

Tabela de fornecedores-cliente
Tabela de produtos-cliente
Tabela de fornecimento de produtos

Se uma tabela parental puder ser dividida em três mesas menores sem perda ou adição de informações e, se quando as tabelas forem unidas, ainda não haverá perda ou adição de informações, a tabela pai deve ser quebrada. As mesas menores estão em 5nf. Nesse caso, a dependência de ingresso foi eliminada. Perda de informação significa perder relacionamentos de linha e adição de informações significa adicionar novos relacionamentos de linha.

Se isso quebrar e montar novamente levaria à perda ou adição de informações, a mesa não deve ser quebrada. Nesse caso, a tabela pai já está na quinta forma normal.

Neste ponto, você, desenvolvedor e treinador de banco de dados, diz: “Proprietário, deixo a colocação de dados nas tabelas (tabela pai e três mesas pequenas) como um exercício para você. Vou verificar isso amanhã.”

Quinto Formulário Normal Regras

Uma tabela está em 5NF se não violar as seguintes regras:

1. Já está na quarta forma normal.
2. A tabela não tem dependência de junção.

Isso significa que uma tabela pode ser projetada pela primeira vez, e já está em 5nf.

Conclusão

Uma tabela está na forma normal de Boyce-codd se as seguintes regras forem obedecidas:

1. A tabela já deveria estar na terceira forma normal.
2. Nenhum atributo não prático (coluna) deve depender da parte da chave primária composta.

Uma tabela está em 4NF se não violar as seguintes regras:

1. Já está na forma normal de Boyce-Codd.
2. A tabela não tem nenhuma dependência com vários valores.

Uma tabela está em 5NF se não violar as seguintes regras:

1. Já está na quarta forma normal.
2. A tabela não tem dependência de junção.

O proprietário agora diz: “Isso exige uma grande celebração para nós dois.”

Você, o desenvolvedor do banco de dados, responde: “Por que não esperamos até amanhã, quando vou juntar todas as mesas e melhorar a tabela de produtos?”

O proprietário reage sorrindo: “O que eu faria sem você?”

Você, o desenvolvedor do banco de dados, adiciona, sorrindo: “Vejo você amanhã então, em seu escritório." e sair.