Que tipo de regra de normalização isso viola?

Question

Suponha que eu tenha duas tabelas em um banco de dados, t₁₀ e T₁₁, com 10 e 11 colunas, respectivamente, onde 10 das colunas são exatamente as mesmas em ambas.

Qual (se houver) regra de normalização estou violando?

Answer 1

EDIT: Fui informado de que nenhuma forma normal é violada aqui em teoria. Como essa foi a resposta aceita, estou deixando aqui a referência e porque pensar sobre o 3NF pode, na prática, ajudar a evitar situações como essa na pergunta.

Você está violando o Terceira forma normal (3NF), porque se principalmente os mesmos dados forem mantidos em ambas as tabelas, cada atributo de cada tabela não depende diretamente da chave de sua respectiva tabela.

Answer 2

Acredite ou não, duplicar colunas entre as mesas não viola a forma normal teórica por si só. Exceto pela forma normal de domínio/chave (DKNF), as formas normais são definidas em termos de tabelas individuais, não múltiplas. O DKNF é definido em termos de restrições, das quais não há nenhum no caso geral. Assim, se houver uma violação de uma forma normal:

• Deve ser específico para uma das tabelas e existe independentemente de ter as duas tabelas (ou seja, a tabela ainda viola a forma normal, mesmo se você removesse a outra tabela), ou
• A relação tem uma restrição que viola o DKNF, o que significa que não é um exemplo do caso geral descrito na pergunta, mas um caso mais específico. Não são as colunas duplicadas que criam a violação, mas a restrição adicional na coluna extra.

Considere o formas normais, usando as breves definições do artigo da Wikipedia:

1nf

A tabela representa fielmente uma relação e não possui grupos repetidos.

Este é bastante direto. O termo "grupos de repetição" tem vários significados na teoria, mas nenhum deles tem nada a ver com colunas ou dados duplicados.

2nf

Nenhum atributo não prático na tabela depende funcionalmente de um subconjunto adequado de qualquer chave candidata.

Aqui, o termo importante a ser examinado é a "dependência funcional". Essencialmente, uma dependência funcional é onde você projeta uma relação com duas colunas, x e y, e acaba com uma função x → y. Você não pode ter uma dependência funcional entre duas (ou mais) tabelas^*. Além disso, as teclas candidatas não podem abranger várias tabelas.

3nf

Todo atributo não prático depende não-transitamente de todas as chaves candidatos da tabela.

A dependência transitiva é definida em termos de dependência funcional: uma dependência transitiva é uma dependência em que x → z apenas porque x → y e y → Z. x, y e z devem estar na mesma tabela porque essas são dependências funcionais.

4nf

Toda dependência não trivial de multivalunto na tabela é uma dependência de uma superkey.

Dependência multivaluga é um pouco mais complicado, mas pode ser ilustrado com um exemplo: "Sempre que as tuplas (a, b, c) e (a, d, e) existem em r, as tuplas (a, b, e (a, d, c) também deve existir em r "(onde" r "é uma tabela). Mais importante ainda para o assunto em questão, uma dependência multivalunta se aplica apenas a uma única tabela.

5nf

Toda dependência de junção não trivial na tabela está implícita pelas super teclas da tabela.

Uma mesa tem um Junte -se à dependência se puder ser expresso como a junção natural de outras mesas. Essas outras tabelas, no entanto, não precisam existir no banco de dados. Se a Tabela T.₁₁ No exemplo, tinha uma dependência de junção, ele ainda teria um mesmo se você removesse a Tabela T₁₀

6nf (C. Data)

Recursos de tabela Não há dependências de junção não triviais (com referência ao operador de junção generalizado).

Mesmo raciocínio para 5nf.

Formulário normal da chave elementar (Eknf)

Toda dependência funcional não trivial na tabela é a dependência de um atributo de chave elementar ou uma dependência de uma superkey.

Mesmo raciocínio para 2nf.

Boyce - forma normal (BCNF)

Toda dependência funcional não trivial na tabela é uma dependência de uma superkey.

Mesmo raciocínio para 2nf.

Formulário normal de domínio/chave (DKNF)

Toda restrição na tabela é uma consequência lógica das restrições de domínio da tabela e das principais restrições.

Se t₁₁ tem uma restrição que depende de t₁₀, então é uma restrição essencial ou uma restrição mais complexa que ainda se refere a t₁₀. O último caso não é o caso geral mencionado na questão. Em outras palavras, embora possa haver esquemas específicos com colunas duplicadas que violam o DKNF, isso não é verdade em geral. Além disso, é a restrição (não a forma normal) que é definida em termos de várias tabelas e a restrição (não a duplicação da coluna) que causa violação do DKNF.

---

O objetivo da normalização inclui a prevenção de anomalias. No entanto, a normalização não está completa, pois não garante que um banco de dados relacional esteja completamente livre de anomalias. Este é um exemplo em que a prática diverge da teoria.

Se isso ainda não o convencer, considere o comentário do esquema KM.₁₁ representa uma versão de história (ou versão) de T₁₀. A chave primária de T₁₁ consiste nas colunas de chave primária mantidas em comum com t₁₀, mais a coluna extra (a coluna Data/versão). Que t₁₁ Possui diferentes chaves candidatas faz toda a diferença entre um projeto normalizado propenso a anomalia e sem anomalia.

^*Alguém pode pensar que você poderia usar junções para criar uma dependência entre duas tabelas. Embora uma junção possa criar uma tabela que tenha uma dependência, a dependência existe nesta tabela, não entre os constituintes da junção. No caso em questão, isso novamente significa que uma das tabelas seria uma mesa unida e sofreria com a própria dependência, independentemente da outra tabela no banco de dados.

Answer 3

Talvez a regra de evitar dados redundantes? (ou seja mesmo dados em duas tabelas)

Answer 4

Se 10 das 11 colunas são iguais, por que essa não pode ser apenas uma tabela, onde a 11ª coluna é deixada em branco (junto com uma 12ª coluna possível para denotar qual tipo de dados é, ou seja, qual tabela teria sido em originalmente)?

Answer 5

Depende do que está nas mesas.

Se nenhum registro estiver relacionado (por exemplo, se uma tabela for simplesmente registros arquivados, mas removidos da primeira tabela), você não está violando nenhuma regra.

Mas se esses são os mesmos registros em cada tabela, você terá um problema de dependência - essa décima primeira coluna depende apenas do valor da chave do registro, não das colunas adicionais. Supondo que todas as dez colunas não estejam envolvidas na chave primária, você violou a 3ª NF.

Answer 6

Ter duas relações idênticas ou quase idênticas não é uma violação de nenhuma das formas normais usuais. Outis explicou de maneira muito abrangente o porquê. Pode muito bem ser uma violação do Princípio do design ortogonal No entanto, que é outro aspecto da teoria do design do banco de dados relacional.

Answer 7

Se todas as 10 colunas fizerem parte da sua chave, a segunda forma normal: eliminando dados redundantes. Especificamente, isso se enquadra em um dilema "não renunciado versus chaves primárias de substituição" - para ser sincero, não me lembro de nenhuma dessas duas opções de "violar" 2NF, mas a chave substituta está definitivamente mais próxima do espírito de 2NF

Answer 8

Somente as chaves primárias podem ser redundantes entre as tabelas. Ter qualquer quantidade de colunas não primárias em várias tabelas viola a terceira forma normal.