¿Sigue siendo normalizó db esquema? base de datos

Question

Tengo el siguiente db-esquema.

archivo , GRUPO y BLOQUE representar la estructura del objeto del archivo XML. archivo es la raíz. GRUPO tiene FK a archivo . BLOQUE tiene una FK a GRUPO y el otro FK a UNIDAD .

UNIDAD Grupos "similares" Bloques desde diffrent Grupos en el contexto de archivo .

La base de datos está en 3NF. Sin embargo, me gustaría saber que Bloques pertenecen a archivo .id = 1. Para ello, sin embargo, tengo que hacer una consulta que une los 4 mesas. Para optimizar este esquema, puedo crear la nueva relación UNIDAD n - FK -> 1 archivo . Sin embargo, mi consulta se une con sólo dos mesas en la db esquema optimizado. Y aquí está la pregunta: ¿es este DB (con este nuevo FK) todavía en 3 NF? Lo que dice la teoría?

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

o

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+

Answer 1

A partir de la información facilitada, parece que se trata de una verdadera jerarquía paralela. Sobre esta base, creo que el esquema modificado propuesto todavía se normalizó a 3NF.

Answer 2

No está claro cómo los ataques tabla de unidades en el esquema antes de realizar cambios.

Obviamente, después de realizar los cambios, todo lo que tiene que hacer para saber qué unidades pertenecen a un archivo es unirse a las tablas de archivos y la unidad.

Dado que las tablas están en 3NF cuando todas las dependencias funcionales se determinan mediante las teclas, las teclas enteros, y nada más que las teclas (por lo que me ayuda Codd), usted tiene que mirar a su esquema en el que la luz.

Teniendo en cuenta la información disponible, más probable es que las mesas están todos en 3NF (y BCNF y AFAICT en 4NF y 5NF también).

Answer 3

No creo que su "pie" cuervos soportes diagrama de las otras dependencias esbozan en su pregunta. ¿Cómo se te ocurrió con el 1: Muchos relación entre el archivo y UNIDAD

?

Estas son las dependencias funcionales que describes ...

• GRUPO -> archivo
• BLOQUE -> GRUPO
• BLOQUE -> UNIDAD

Además, supongo que cada uno de los atributos anteriores determinan funcionalmente algunos atributos adicionales que no aparecen en el lado izquierdo de cualquier otra dependencia funcional. Estos serían:

• archivo -> otro-archivo-atributos
• GRUPO -> otro grupo-atributos
• BLOQUE -> otro bloque-atributos
• UNIDAD -> otra unidad-atributos

La construcción de un conjunto de relaciones 3NF de lo anterior dependencias funcionales da:

• FileRelation: ( archivo , otra-file-atributos)
• GroupRelation: ( GRUPO , ARCHIVO , otra-group-atributos)
• UnitRelation: ( UNIDAD , otra de unidad atributos)
• BlockRelation: ( BLOQUE , GRUPO , UNIDAD , otra-block-atributos)

Este bonito mucho se corresponde con lo que usted ha descrito.

La determinación de qué UNIDAD casos se refieren a un archivo dado requiere una combinación de FileRelation a GroupRelation en archivo y luego a GroupRelation BlockRelation en GRUPO a continuación BlockRelation a UnitRelation en UNIDAD .

¿Quieres evitar este multi-tabla de unión mediante la inserción de una nueva relación alguna parte en el modelo que da una asignación directa de UNIDAD archivo . Tal relación implica la funcional dependencia:

• UNIDAD -> archivo

Esto parece el poco que agregó a la "cuervos pies" diagrama. Adición Esto introduce una lógica contradicción. Los soportes de esquema originales que tienen una determinada UNIDAD en relación con múltiples archivo casos. como en:

• FileRelation (F1, ...)
• FileRelation (F2, ...)
• GroupRelation (G1, F1, ...)
• GroupRelation (G2, F2, ...)
• BlockRelation (B1, G1, U1, ...)
• BlockRelation (B2, G2, U1, ...)
• UnitRelation (U1, ...)

ejemplo UNIDAD U1 se refiere a casos FILE F1 y F2. Ante esta situación, ya sea en el UNIDAD -> archivo dependencia funcional puede no ser compatible o el conjunto original de dependencias funcionales estaban incompletos y el esquema no es en 3NF.

En este punto es necesario para resolver si el mundo real es compatible con el archivo -> UNIDAD dependencia o no. Si lo hace, entonces el modelo original no está en 3NF y un poco más reelaboración del esquema está en orden. Si la dependencia no es compatible entonces el mejor que se puede decir es:

• archivo , UNIDAD -> no

y la relación correspondiente:

• FileUnit: ( archivo , UNIDAD )

es una desnormalización porque su contenido puede ser derivada a través de las tablas existentes dependencias funcionales.

============================================ =====================================

Editar

A partir de una serie de observaciones hechas a esta y otras respuestas, parece que:

• UNIDAD -> archivo

es una verdadera dependencia funcional, la dependencia funcional:

• BLOQUE -> UNIDAD

Si bien no es incorrecto, debe ser redundante. Creo que el conjunto correcto de 3NF las relaciones deeste modelo actual es:

• FileRelation: ( archivo , otra-file-atributos)
• GroupRelation: ( GRUPO , ARCHIVO , otra-group-atributos)
• UnitRelation: ( UNIDAD , ARCHIVO , otra de unidad atributos)
• BlockRelation: ( BLOQUE , GRUPO , otra-block-atributos)

Tenga en cuenta que el UNIDAD clave externa se ha reducido desde el BlockRelation. Esto se debe a la UNIDAD -> archivo FD hizo redundante. los ( BLOCK , UNIDAD ) relación ahora se forma uniendo UnitRelation a FileRelation en archivo entonces FileRelation a GroupRelation en archivo a continuación GroupRelation a BlockRelation en GRUPO .

El esquema original no estaba en 3NF debido a la no declarada dependencia funcional: UNIDAD -> archivo . El conjunto propuesto de las relaciones de arriba es en 3NF.

Nota: Cuando la normalización de un esquema, cada dependencia funcional necesita ser declarado en la delantera. Falta se puede cambiar la imagen completa!