¿Qué tipo de regla de normalización no viola este?

Question

Supongamos que tengo dos tablas en una base de datos, T ₁₀ y T ₁₁ , que tienen 10 y 11 columnas, respectivamente, donde 10 de las columnas son exactamente los mismos en ambos.

Lo que (si lo hay) fórmula de normalización estoy violando?

Answer 1

Editar: Se me ha informado de que no se violan las formas normales aquí en teoría. Dado que esta era la respuesta aceptada, lo estoy dejando aquí por referencia, y porque el pensamiento sobre 3NF en la práctica puede ayudar a situaciones que evitar como en la pregunta.

Tercera forma normal (3NF) , sobre todo porque si los mismos datos se lleva a cabo en ambas tablas, a continuación, todos los atributos de cada tabla no depende directamente de la llave de su tabla correspondiente.

Answer 2

Lo creas o no, la duplicación de columnas a través de tablas no viola ninguna forma normal teórica de por sí. A excepción de dominio / forma normal llave (DKNF), formas normales se definen en términos de tablas individuales, no múltiple,. DKNF se define en términos de restricciones, de los cuales hay ninguno en el caso general. Por lo tanto, si hay una violación de una forma normal:

• debe ser específico a una de las mesas y existe independientemente de tener ambas tablas (es decir, la tabla todavía violar la forma normal, incluso si ha quitado la otra mesa), o
• la relación tiene una restricción que viole DKNF, lo que significa que no es un ejemplo del caso general descrito en la pregunta sino un caso más específico. No son las columnas duplicadas que crean la violación pero en cambio la restricción adicional en la columna adicional.

Tenga en cuenta la , utilizando las definiciones breves del artículo de Wikipedia:

  

1NF

  

    

la tabla representa fielmente una relación y no tiene grupos de repetición.

   

Éste es bastante sencillo. El término "repetición de grupos" tiene varios significados en la teoría, pero ninguno de ellos tiene nada que ver con columnas duplicadas o datos.

  

  

2NF

  

    

Ningún atributo no primo en la tabla es funcionalmente dependiente de un subconjunto propio de cualquier clave candidata.

    

Aquí, el término es importante examinar "dependencia funcional". En esencia, una dependencia funcional es donde se proyecta una relación con dos columnas, X e Y, y terminar con una función X → Y. No se puede tener una dependencia funcional entre dos (o más) tablas ^* . Además, claves candidatas no pueden abarcar varias tablas.

  

  

3NF

  

    

Cada atributo no primo no es transitiva depende de cada clave candidata en la tabla.

    

Transitive dependencia se define en términos de dependencia funcional: una dependencia transitiva es una dependencia donde X → Z sólo porque X → Y y Y → Z. X, Y y Z debe ser en la misma tabla, porque estos son dependencias funcionales.

  

  

4NF

  

    

Cada dependencia multivalor no trivial en la tabla es una dependencia de una superclave.

    

multivalor dependencia es un poco más difícil, pero puede ser ilustrado con un ejemplo: "cuando las tuplas (a, b, c) y (a, d, e) existen en r, las tuplas (a, b, e) y (a, d, c) también debe existir en r"(donde "R" es una mesa). Lo más importante para el asunto que nos ocupa, una dependencia multivalor sólo se aplica a una sola tabla.

  

  

5NF

  

    

Cada no trivial se unen a la dependencia en la tabla está implícito en las superclaves de la tabla.

    

Una tabla tiene una unirse a la dependencia si se puede expresar como la unión natural de otras tablas . Estas otras tablas, sin embargo, no deben existir en la base de datos. Si la tabla T ₁₁ en el ejemplo, tenían un unirse a la dependencia, todavía tendría una mesa, incluso si retira T ₁₀

  

  

6NF (C. Fecha)

  

    

características de las tablas no no trivial se unen a las dependencias del todo (con referencia al titular generalizada unirse).

    

El mismo razonamiento para 5NF.

  

  

Primaria Key Forma Normal (EKNF)

  

    

Cada dependencia funcional no trivial en la tabla es o bien la dependencia de un atributo clave primaria o una dependencia de un superkey.

    

El mismo razonamiento para 2NF.

  

  

Boyce-Codd Forma Normal (BCNF)

  

    

Cada dependencia funcional no trivial en la tabla es una dependencia de una superclave.

    

El mismo razonamiento para 2NF.

  

  

Dominio / Key Forma Normal (DKNF)

  

    

Cada restricción en la tabla es una consecuencia lógica de restricciones del dominio de la tabla y las restricciones de claves.

    

Si T ₁₁ tiene una restricción que depende de T ₁₀ , entonces es ya sea una restricción de clave o una restricción más complejo que todavía se refiere a T ₁₀ . El último caso no es el caso general mencionado en la pregunta. En otras palabras, si bien puede haber esquemas específicos con columnas duplicadas que violan DKNF, no es cierto en general. Además, es la restricción (no la forma normal) que se define en términos de varias tablas y la restricción (no la duplicación columna) que causa DKNF violación.

  

---

El propósito de la normalización incluye la prevención de anomalías. Sin embargo, la normalización no es completa, ya que no garantiza una base de datos relacional será completamente libre de anomalías. Este es un caso donde la práctica diverge de la teoría.

Si esto no te convence, considere el esquema consejos de KM., Comentario en el que T ₁₁ representa una historia (o versionado) versión de T ₁₀ . La clave primaria de T ₁₁ consta de las columnas de clave primaria mantenidas en común con T ₁₀ , además de la columna extra (la columna de la fecha / versión). Que T ₁₁ tiene diferentes claves candidatas hace toda la diferencia entre un diseño anomalía y propenso anomalía libre, normalizada.

^* Alguien podría pensar que usted podría utilizar une para crear una dependencia entre dos tablas. Mientras que una unión podría crear una tabla que tiene una dependencia, existe la dependencia de esta tabla, no entre los componentes de la unión. En el caso que nos ocupa, este nuevo medio que una de las mesas sería una tabla unida y sufriría de la propia dependencia, con independencia de la otra tabla en la base de datos.

Answer 3

Quizás la regla de evitar los datos redundantes? (Es decir, los mismos datos en dos tablas)

Answer 4

si 10 de las 11 columnas son los mismos, ¿por qué no esta simplemente ser una mesa, donde la columna 11 está en blanco izquierdo (junto con una posible columna 12 para denotar el tipo de datos que es, es decir, qué tabla se habría sido en un principio)?

Answer 5

Depende lo que hay en las tablas.

Si no hay registros están relacionados entre sí (por ejemplo, si una tabla está archivada simplemente registros, pero originario de retirados de la primera tabla) que está no viola ninguna regla.

Pero si esos son los mismos registros de cada tabla, usted tiene un problema de dependencia - que undécima columna es sólo depende del valor de la clave del registro, no las columnas adicionales. Suponiendo que todas las columnas diez no están involucrados en la clave principal, que ha violado tercera NF.

Answer 6

Tener dos relaciones idénticas o casi idénticas no es en sí misma una violación de cualquiera de las formas normales habituales. Outis muy exhaustiva ha explicado por qué. Bien podría ser una violación de la Principio de diseño ortogonal sin embargo, que es otro aspecto de la teoría de diseño de base de datos relacional.

Answer 7

Si todas las columnas 10 son parte de su clave, a continuación, Segunda Forma Normal: La eliminación de datos redundantes. En concreto, es aplicable el "Nonsurrogate Versus sustitutos claves principales" dilema - para ser honesto, no recuerdo ninguna de esas dos opciones para ser "violar" 2NF, pero la clave sustituta es definitivamente más cerca del espíritu de 2NF

Answer 8

Sólo claves primarias pueden ser redundantes entre las mesas. Tener cualquier cantidad de columnas de clave no primarios en varias tablas viola la tercera forma normal.