Похоже, вы предполагаете, что есть некоторые изменения в поведении правил удаления между «один ко многим» и «многие к одному», но это не так.Все работает точно так же.Если вы думаете об этом, то так должно быть, потому что один-ко-многим - это просто взаимное отношение многих к одному.
Я думаю, что идея взаимных отношений сбивает вас с толку.Каждая сторона отношения определяется отдельно и имеет свое собственное правило удаления, которое может отличаться от правила удаления на другой стороне.
Давайте возьмем для примера общий стандартный отдел и сотрудник.
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
}
Обратите внимание, что каждое отношение, каждая стрелка в графической модели имеет два описания, прикрепленных к нему во взаимном отношении (который является стандартной формой). Каждое описание описывает отношение с «перспективы»одного из связанных лиц.Таким образом, каждое отношение «один ко многим» является лишь обратной стороной соответствующего отношения «многие к одному».
Кроме того, необязательный / требуемый / mincount отношения «ко многим» на стороне может блокировать удалениеобъекты на другой стороне.
Возьмите Отдел <- >> Отношения сотрудника.С точки зрения Департамента, объект Департамента должен иметь хотя бы одного сотрудника.Если у него только один сотрудник, этот сотрудник не может быть удален.Если сам объект отдела удаляется, то удаляются и все его сотрудники.С точки зрения сотрудника, каждый сотрудник должен иметь один отдел.Любая попытка сохранить значение nil для значения отдела объекта сотрудника приведет к ошибке проверки.Однако если объект работника удаляется, то с объектом Department вообще ничего не происходит, за исключением того, что он теряет один из своих объектов employee.Однако, если объект сотрудника является единственным объектом сотрудника в отношении, объект Department заблокирует удаление.
Каскадное удаление, как следует из названия, может вызвать последовательную цепочку удалений по всему графу объектов.Когда вы удаляете объект Department, он удаляет все связанные с ним объекты Employee, каждый из которых, в свою очередь, удаляет все свои объекты Project.
Но что, если у вас установлено каскадное правило удаления по обе стороны от многих ко многим?отношения, подобные этому:
Alpha{
betas<<--(cascade)-->>Beta.alphas
}
Beta{
alphas<<--(cascade)-->>Alpha.betas
}
В этом случае удаление какого-либо одного объекта в графе приведет к удалению всех других объектов, связанных с любым путем ключа.Удаление одного бета-объекта приведет к удалению всех его альфа-объектов, что, в свою очередь, приведет к удалению всех их бета-объектов, которые, в свою очередь, удалят все их альфа-объекты ... и так до тех пор, пока не будут удалены все связанные доступные объекты.
Очевидно, что двухсторонние каскадные отношения - хороший способ выстрелить себе в ногу.
Суммируя:
- Отношения определяются на обеих сторонах отношений каждой сущностью независимо.
- Правила удаления могут быть переопределены дополнительным или минимальным счетом.
- Понимание поведения отношений во время выполнения требует сочетания эффектов правил удаления, опциональности и mincounts.
Одной из причин создания редактора модели данных было наложение некоторой ограничительной логики на правила отношений, чтобы не дать кодировщикам / предупредить создание неожиданных и универсальных правил.