sql cerrado relaciones de bucle; ¿qué puede salir mal?

Question

Estoy trabajando con una base de datos con el siguiente diseño. He leído que no es una buena práctica tener bucles cerrados, en un diseño de base de datos, y tengo más de uno. Pero no puedo recordar por qué. Así que no sé cómo esto podría afectar a mí. Cualquier ejemplo de cómo esto podría ser peligroso?

Editar: pasó por mis libros electrónicos, encontrado lo que estaba leyendo era A partir del diseño de base de datos desde el principiante al profesional , editor:. APRESS
simplemente advierten contra esto, pero dan una razón vaga por qué. No, no estamos usando disparadores. Alguien tiene una explicación más clara?
Gracias Extracto, p.109:

  

Una pequeña empresa que tenga empleados que cada uno   trabajar para una de un número de diferentes   grupos de proyectos pequeños. Cada grupo y   todos sus empleados están alojados en una   habitación en particular con habitaciones grandes   vivienda varios groups.We pueden requerir   información tal como la que cada   empleado se encuentra, un particular,   número de teléfono del empleado, dónde encontrar   un grupo en particular, que los empleados   trabajo en cada grupo, que se encuentra en cada uno   cuarto, y así sucesivamente. Uno de datos posible   modelo se muestra en la Figura 5-7. Tomar un   momento para entender el modelo de datos   y la información que contiene aproximadamente   el número de grupos en una habitación y por lo   por este problema en particular. los   modelo tiene información redundante. lata   ves lo que es?

  

Con respecto al ejemplo 5-3, si   regularidad que desee encontrar un empleado de   número de teléfono, podríamos pensar que el   top relación en la Figura 5-7 entre   De los empleados y de habitaciones serían un útil   ruta directa. Sin embargo, esta misma   la información disponible es muy fácil   por una ruta alternativa a través de Grupo.   Podemos encontrar (sólo uno) de los empleados   grupo y luego encontrar de ese grupo (uno   solamente) habitación. Esta es una manera muy sencilla   la recuperación (que no implica toda la   complicaciones con las fechas que plagaron   el pequeño albergue en el Ejemplo 5-2).   Sin embargo, la relación extra no es   simplemente innecesaria, es peligroso.   Con dos rutas para el mismo   información, corremos el riesgo de obtener dos   diferentes respuestas a menos que los datos son   muy cuidadosamente mantenida. Siempre que una   grupo cambios empleado o un grupo   desplaza habitaciones, habrá dos   instancias de relación para actualizar.   Sin actualización mucho cuidado   procedimientos, que podrían llegar a tener   que Jim está en el Grupo A, que se encuentra en   Sala 12, mientras que la otra ruta puede   Jim han asociado directamente con el sitio   15. información redundante es propenso a las inconsistencias y debe ser siempre   eliminado.

Answer 1

No he tenido problemas en el pasado usando referencias de "bucle cerrado" entre grupos de tablas (es decir, al menos 3 en el bucle de relación). El único problema que se me ocurre sería si se utiliza disparadores, e incluso entonces sólo sería un problema si está actualizando las otras mesas en el "bucle" en el gatillo.

¿Tiene una referencia para el lugar donde se lee este consejo por no tener bucles cerrados?

Para los otros que comentado la foto se puede ver si copia el enlace en nueva ventana: http: // imgur .com / ChFL1

Answer 2

No todas las bases de datos han diferido relación activada la Comprobación y no todas las bases de datos permiten la inserción de dos registros en dos tablas diferentes en un comunicado.

Imagine que tiene un FOREIGN KEY de A a B y desde B a A.

En un principio, ambas mesas están vacías.

¿Cómo se va a insertar el primer disco?

No se puede insertar cualquier cosa para A ya que tiene que hacer referencia a un registro en B (que está vacío), y de la misma manera no se puede insertar cualquier cosa en B.

Answer 3

No diría que "no es una buena práctica tener bucles cerrados". Sin embargo, ellos no llaman la atención sobre un problema potencial. Por lo que sería un buen hábito para comprobar todos los circuitos cerrados de la posibilidad de este problema.

El ejemplo de libro de texto parece bastante claro para mí. Hay 2 formas en las cuales / teléfono del empleado se puede determinar la ubicación:

• Empleado -> Grupo -> Habitación -> Teléfono
• o Empleado -> Habitación -> Teléfono

Esto es como el almacenamiento de dos variables para la misma cosa que deben mantenerse en sincronía. Habrá la posibilidad de que algo va mal y las variables terminar con diferentes valores - entonces usted tiene que preguntar: "¿Cuál de los dos es correcta"

Así que el ejemplo de libro de texto destaca el problema que tiene que ver nuestro para. Sin embargo, el problema realmente se reduce a semántica . Es decir. ¿qué significan las relaciones. En el ejemplo de libro de texto, ambos caminos a Room significa exactamente lo mismo. Sin embargo, si el Group -> Room fuera simplemente un 'defecto' para cada empleado porque los empleados de alto rango podrían obtener su propia habitación, o empleados de forma temporal podría ser asignado a trabajar en otro lugar fuera de su grupo, entonces la relación adicional estaría justificada.

De pasar a su diseño, esto es lo que debe hacer:

• Busque grupos cerrados
• Evaluar la semántica / propósito / significado de las relaciones
• Asegúrate de que no se acaba de crear dos rutas de acceso a exactamente el mismo información .

Por ejemplo, usted tiene:

• TestSample -> Bobina -> Losa
• TestSample -> Placa -> Losa

( perdonar a la comprensión posiblemente absurda de su terminología .) ¿Esto quiere decir que su muestra de ensayo puede ser en 2 placas diferentes al mismo tiempo? ¿O quiere decir que su muestra de prueba se compone de una placa y una bobina que podría tener (pero no necesariamente) provienen de diferentes losas?