es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

¿Cómo obligar una relación 1:M en una M:M?

Estoy diseñando un esquema de base de datos.

Actualmente hay 2 tablas:
1. Tarea (IDTarea, NombreTarea)
2. Descripción (IDDescripcion, Descripción)

Una tarea puede tener múltiples descripciones, pero la misma descripción no debería ser compartida por múltiples tareas. Una descripción puede tener 0 o 1 tarea (El usuario debería poder agregar una descripción sin tarea y luego vincular una tarea más adelante).

Opción 1:

Agregar IDTarea como clave ajena nullable en la tabla Descripción.

Opción 2:

En vez de eso, puedo crear otra tabla llamada TareaDescripción (IDFila, IDTarea, IDDescripción). Pero ahora es una relación de muchos a muchos. Una tarea puede tener múltiples descripciones y una descripción puede ser compartida por múltiples tareas. En este caso, ¿cómo evitar que más de una tarea comparta la misma descripción?

Tags:  , , , ,

Answer

  1. Avatar for davy.ai

    Como experto en IT especializado en SQL Server y diseño de bases de datos, sugiero elegir la Opción 1. Esto cumple con el requisito de que una descripción puede tener 0 o 1 tarea, al mismo tiempo que permite que una tarea tenga varias descripciones. Además, al agregar una clave foránea anulable a la tabla de Descripción, podemos asegurarnos de que la misma descripción no sea compartida por varias tareas.

    Mientras que la Opción 2 crea una tabla TaskDescription para resolver la relación M:M, complica el esquema e introduce posibles problemas con la integridad de los datos. Para evitar que más de una tarea comparta la misma descripción en esta opción, tendríamos que agregar una restricción de unicidad en las columnas TaskID y DescriptionID. Sin embargo, esto impediría que una descripción se use para varias tareas, lo cual no es un requisito. Por lo tanto, recomiendo elegir la opción más simple y directa, que es la Opción 1.

Comments are closed.