Terceira forma normal - Third normal form

A terceira forma normal ( 3NF ) é uma abordagem de design de esquema de banco de dados para bancos de dados relacionais que usa princípios de normalização para reduzir a duplicação de dados, evitar anomalias de dados , garantir integridade referencial e simplificar o gerenciamento de dados. Foi definido em 1971 por Edgar F. Codd , um cientista da computação inglês que inventou o modelo relacional para gerenciamento de banco de dados .

Uma relação de banco de dados (por exemplo, uma tabela de base de dados ) é dito para satisfazer as normas de formulário normais terceiros se todos os atributos (por exemplo colunas do banco de dados ) são funcionalmente dependente em unicamente a chave primária . Codd definiu isso como uma relação na segunda forma normal, onde todos os atributos não primos dependem apenas das chaves candidatas e não têm uma dependência transitiva de outra chave.

Um exemplo hipotético de falha em atender à terceira forma normal seria um banco de dados de um hospital com uma tabela de pacientes que incluía uma coluna para o número de telefone de seu médico. O número de telefone depende do médico, e não do paciente, portanto, ficaria melhor armazenado em uma tabela de médicos. O resultado negativo de tal projeto é que o número de um médico será duplicado no banco de dados se eles tiverem vários pacientes, aumentando assim a chance de erro de entrada e o custo e risco de atualizar esse número se ele mudar (em comparação com um terceiro normal modelo de dados compatível com formulário que armazena apenas o número de um médico uma vez na mesa do médico).

Codd mais tarde percebeu que o 3NF não eliminava todas as anomalias de dados indesejáveis ​​e desenvolveu uma versão mais forte para resolver isso em 1974, conhecida como forma normal de Boyce-Codd .

Definição de terceira forma normal

A terceira forma normal (3NF) é uma forma normal usada na normalização do banco de dados . 3NF foi originalmente definido por E. F. Codd em 1971.

A definição de Codd afirma que uma tabela está em 3NF se e somente se ambas as seguintes condições forem mantidas:

• A relação R (tabela) está na segunda forma normal (2NF).
• Cada atributo não principal de R é não transitivamente dependente de cada chave de R.

Um atributo não primo de R é um atributo que não pertence a nenhuma chave candidata de R. Uma dependência transitiva é uma dependência funcional em que X → Z ( X determina Z ) indiretamente, em virtude de X → Y e Y → Z (onde não é o caso de Y → X ).

Uma definição 3NF que é equivalente à de Codd, mas expressa de forma diferente, foi dada por Carlo Zaniolo em 1982. Esta definição afirma que uma tabela está em 3NF se e somente se para cada uma de suas dependências funcionais X → A , pelo menos um dos seguintes as condições são válidas:

• X contém A (ou seja, A é um subconjunto de X , o que significa que X → A é uma dependência funcional trivial),
• X é uma superchave ,
• cada elemento de A  \  X , a diferença de conjunto entre A e X, é um atributo principal (ou seja, cada atributo em A  \  X está contido em alguma chave candidata ).

A definição de Zaniolo dá uma noção clara da diferença entre 3NF e a forma normal Boyce-Codd mais rigorosa (BCNF). BCNF simplesmente elimina a terceira alternativa ("Cada elemento de A  \  X , a diferença de conjunto entre A e X , é um atributo principal.").

"Nada além da chave"

Uma aproximação da definição de Codd de 3NF, paralela à promessa tradicional de fornecer evidências verdadeiras em um tribunal, foi dada por Bill Kent: "[todo] não-chave [atributo] deve fornecer um fato sobre a chave, a chave inteira, e nada além da chave ". Uma variação comum complementa essa definição com o juramento "então me ajude Codd ".

Exigir a existência de "a chave" garante que a tabela esteja em 1NF ; exigir que atributos não-chave sejam dependentes de "a chave inteira" garante 2NF ; exigir ainda que os atributos não-chave sejam dependentes de "nada além da chave" garante 3NF. Embora esta frase seja um mnemônico útil, o fato de mencionar apenas uma única chave significa que ela define algumas condições necessárias, mas não suficientes, para satisfazer a 2ª e a 3ª formas normais. Ambos 2NF e 3NF estão relacionados igualmente com todas as chaves candidatas de uma tabela e não apenas com qualquer chave.

Chris Date se refere ao resumo de Kent como "uma caracterização intuitivamente atraente" de 3NF e observa que, com uma ligeira adaptação, pode servir como uma definição da forma normal Boyce-Codd um pouco mais forte : "Cada atributo deve representar um fato sobre a chave, o todo chave, e nada além da chave. " A versão 3NF da definição é mais fraca do que a variação BCNF de Date, já que a primeira se preocupa apenas em garantir que os atributos não-chave sejam dependentes das chaves. Os atributos primários (que são chaves ou partes de chaves) não devem ser dependentes funcionalmente; cada um deles representa um fato sobre a chave no sentido de fornecer parte ou toda a chave em si. (Esta regra se aplica apenas a atributos funcionalmente dependentes, pois aplicá-la a todos os atributos proibiria implicitamente as chaves candidatas compostas, uma vez que cada parte de qualquer uma dessas chaves violaria a cláusula "chave inteira".)

Um exemplo de uma tabela 2NF que não atende aos requisitos de 3NF é:

Como cada linha da tabela precisa nos dizer quem ganhou um torneio específico em um determinado ano, a chave composta {Tournament, Year} é um conjunto mínimo de atributos garantidos para identificar exclusivamente uma linha. Ou seja, {Torneio, Ano} é uma chave candidata para a mesa.

A violação de 3NF ocorre porque o atributo não principal (data de nascimento do Vencedor) é transitivamente dependente da chave candidata {Torneio, Ano} por meio do atributo não principal Vencedor. O fato de a data de nascimento de Winner depender funcionalmente de Winner torna a tabela vulnerável a inconsistências lógicas, pois nada impede que a mesma pessoa seja mostrada com datas de nascimento diferentes em registros diferentes.

Para expressar os mesmos fatos sem violar 3NF, é necessário dividir a tabela em duas:

Não podem ocorrer anomalias de atualização nestas tabelas, porque ao contrário de antes, Winner é agora uma chave candidata na segunda tabela, permitindo assim apenas um valor para Data de nascimento para cada Vencedor.

Computação

Uma relação sempre pode ser decomposta na terceira forma normal, ou seja, a relação R é reescrita nas projeções R ₁ , ..., R _n cuja junção é igual à relação original. Além disso, esta decomposição não perde nenhuma dependência funcional , no sentido de que toda dependência funcional em R pode ser derivada das dependências funcionais que se mantêm nas projeções R ₁ , ..., R _n . Além disso, essa decomposição pode ser calculada em tempo polinomial .

Derivação das condições de Zaniolo

A definição de 3NF oferecida por Carlo Zaniolo em 1982, e dada acima, é provada da seguinte maneira: Seja X → A um FD não trivial (isto é, aquele em que X não contém A) e seja A um atributo não-chave. Também seja Y uma chave de R. Então Y → X.

Normalização além de 3NF

A maioria das tabelas 3NF está livre de anomalias de atualização, inserção e exclusão. Certos tipos de tabelas 3NF, raramente encontrados na prática, são afetados por tais anomalias; essas são tabelas que ficam aquém da forma normal de Boyce-Codd (BCNF) ou, se eles encontram o BCNF, ficam aquém das formas normais superiores 4NF ou 5NF .

Considerações para uso em ambientes de relatório

Embora o 3NF fosse ideal para processamento de máquina, a natureza segmentada do modelo de dados pode ser difícil de consumir por um usuário humano. A análise por meio de consultas, relatórios e painéis era frequentemente facilitada por um tipo diferente de modelo de dados que fornecia análises pré-calculadas, como linhas de tendência, cálculos do período até a data (mês até a data, trimestre até a data, ano atualizado), cálculos cumulativos, estatísticas básicas (média, desvio padrão, médias móveis) e comparações de períodos anteriores (ano atrás, mês atrás, semana atrás), por exemplo, modelagem dimensional e além da modelagem dimensional, achatamento de estrelas via Hadoop e ciência de dados .

Veja também

• Sistema de valor de atributo

Referências

Leitura adicional

links externos

• Dicas de Litt: Normalização
• Fundamentos de normalização de banco de dados por Mike Chapple (About.com)
• Uma introdução à normalização de banco de dados por Mike Hillyer.
• Um tutorial sobre as 3 primeiras formas normais por Fred Coulson
• Descrição dos fundamentos de normalização do banco de dados pela Microsoft
• Terceira forma normal com exemplos simples por exploreDatabase