Eliminar reglas para la relación de muchos a uno

Question

La documentación de Apple de Relationship Delete Rules es simple y clara. Pero solo habla de Relación uno a muchos (Eliminar reglas para One-to-One relación son fáciles de inferir). No está claro lo que significan estas reglas para la relación Many-to-One. Así que vamos a aclararlos aquí.

Utilizamos el empleado-Departamento ejemplo utilizado en la documentación de Apple. Aunque las implicaciones de la vida real pueden ser ridículas de estas reglas que se aplican a la relación Empleados-Departamento, nosotros, como programadores, solo estamos hablando de sus implicaciones lógicas aquí.

• Denegar
  Si hay un objeto en el destino relación, entonces el objeto de origen no se puede eliminar.

  Por ejemplo, si desea eliminar un empleado, sin importar si todavía hay otros empleados en su departamento, debe asegurarse de que el departamento se elimine por primera vez, de lo contrario, el empleado no puede ser eliminado.

• Nulidad
  Retire el objeto de origen de la relación inversa del objeto en el destino. (Consulte la explicación concisa de @ bshirley)

  Por ejemplo, si elimina a un empleado, quítelo de la relación de empleados de su departamento. Esto solo tiene sentido si la cantidad de empleados restantes del departamento es mayor que el recuento mínimo requerido, o si se asegura de que agrega nuevos empleados para el departamento antes de la siguiente operación de salvar.

  [Pregunta: Si es el último empleado, será empleados del departamento relación se convierta en conjunto vacío o nulo?]
  (Answer @TechZen:. A a-muchos relación siempre devuelve un objeto de conjunto Nunca es nula. Si no hay objetos en el otro lado de la relación, el conjunto está vacío.)

• Cascade eliminar el objeto en el destino de la relación.

  Por ejemplo, si elimina un empleado, elimine su departamento al mismo tiempo, incluso si todavía hay otros empleados en el departamento.

  (Uso Caveat: Por lo general provoca una "una cadena de margarita de deleciones en toda la gráfico de objetos", como se describe por @TechZen en su ejemplo.)

• No Acción
  No hacer nada al objeto en el destino de la relación.

  Por ejemplo, si elimina un empleado, abandone su departamento tal como está, incluso si aún cree que es el propietario de ese empleado.

Los significados de las normas de supresión de muchos-a-muchos relación se puede deducir de aquí.

Answer 1

Estas son las reglas de eliminación para todas las relaciones (no atributos). Son aplicables para to-One o a-Many relaciones.

• Nulidad - si elimina un empleado, la relación inversa se establece en nula, si era 1-a-1, entonces, literalmente, en los empleados de este departamento de la caja se reduce en uno

• Cascade: si elimina un empleado, se eliminará su departamento. El Departamento seguirá la regla de eliminación en todas sus propiedades, 1) si la regla de eliminación de empleados fue Cascade, todos los empleados serían eliminados por esta acción; 2) si los empleados Eliminar regla era Nulidad, todos los empleados serían "varados" sin un departamento

Answer 2

usted parece estar asumiendo que hay algún cambio en el comportamiento de las normas de supresión entre uno-a-muchos y muchos a uno pero no hay. Todo funciona exactamente de la misma manera. Si piensas en ello, tiene que ser así porque un uno-a-muchos es solo la relación recíproca de un muchos-a-uno.

Creo que es la idea de una relación recíproca lo que lo está trayendo hasta aquí. Cada lado de la relación se define por separado y tiene su propia regla de eliminación que puede ser diferente de la regla de eliminación en el otro lado.

Tomemos como ejemplo el departamento y el empleado estándar común.

Department{ 
    name:string 
    employees<--(required,cascade)-->>Employee.department 
} 

Employee{ 
    name:string 
    department<<--(required, nullify)-->Department.employee 
    projects<--(optional,cascade)-->>Project.owner 
} 

Project{ 
    name: 
    owner<<--(required,nullify)-->Employee.projects 
} 

Nota que cada relación, cada línea de flecha en el modelo gráfico, tiene dos descripciones que se le atribuye en la relación recíproca (que es la forma estándar.) Cada descripción describe la relación de la "perspectiva" de uno de las entidades relacionadas. Entonces, cada relación de uno a muchos es solo el reverso de una relación de muchos a uno.

Además, no la relación opcional/requerida/mincount de una relación de muchos a un lado puede bloquear las eliminaciones de objetos en el otro lado.

Tel. < - >> Relación de empleados. Desde la perspectiva del Departamento, un objeto del Departamento debe tener al menos un empleado. Si solo tiene un empleado, entonces ese empleado no puede ser eliminado. Si el objeto del Departamento mismo se elimina, también se eliminan todos sus empleados. Desde la perspectiva del empleado, cada empleado debe tener un solo departamento. Cualquier intento de guardar un valor nulo para el valor del departamento de un objeto empleado arrojará un error de validación. Sin embargo, si el objeto empleado se elimina, entonces nada le sucede al objeto del Departamento, excepto que pierde uno de sus objetos de empleado. Sin embargo, si el objeto empleado es el único objeto empleado en la relación, el objeto del Departamento bloqueará la eliminación.

Una eliminación en cascada, como su nombre lo indica, puede desencadenar una serie de eliminaciones en todo el gráfico del objeto. Cuando elimina un objeto del Departamento, elimina todos sus objetos relacionados del Empleado, cada uno de los cuales a su vez borra todos sus objetos del Proyecto.

Pero lo que si usted tiene una eliminación en cascada conjunto de reglas a ambos lados de una relación de muchos a muchos como esto:

Alpha{ 
    betas<<--(cascade)-->>Beta.alphas 
} 

Beta{ 
    alphas<<--(cascade)-->>Alpha.betas 
} 

En ese caso, la supresión de cualquier objeto en el gráfico sería eliminar todos los demás objetos relacionados por cualquiera de los keypath. Al eliminar un objeto Beta se eliminarían todos sus objetos Alpha que a su vez eliminarían todos sus objetos Beta que a su vez eliminarían todos sus objetos Alpha ... y así sucesivamente hasta que todos los objetos relacionados alcanzables fueran eliminados.

Obviamente, una relación en cascada de dos caras a muchas es una buena manera de dispararse en el pie.

En resumen:

• relaciones se definen a ambos lados de las relaciones de cada entidad independiente.
• Las reglas de eliminación se pueden anular por opcionalidad o minicomputaciones.
• Comprender el comportamiento en tiempo de ejecución de una relación requiere combinar los efectos de las reglas de eliminación, opcionalidad y minicuentas.

Una razón para la creación del editor de modelo de datos fue imponer cierta lógica restrictiva en las reglas de relación para mantener/advertir a los codificadores de la creación de reglas cruzadas e inesperadas.