Удалить правила для отношений "один-на-один"

Документация Apple Правила удаления связей проста и понятна. Но это говорит только об отношениях "один-ко-многим" ( "Удалить правила для отношений" один-к-одному "легко вывести). Неясно, что означают эти правила для отношений" многие-к-одному". Так что проясните их здесь.

Мы используем пример Employees-Department, используемый в документации Apple. Хотя последствия реальной жизни могут быть смешными в отношении этих правил, применяемых к отношениям Сотрудники и Отдел, мы, как программисты, говорим только о своих логических последствиях здесь.

Запретить
Если в назначении отношения есть объект, исходный объект не может быть удален.

Например, если вы хотите удалить сотрудника, независимо от того, есть ли другие сотрудники в его отделе, вы должны убедиться, что отдел сначала удален, иначе сотрудник не может быть удален.
аннулирует
Удалите исходный объект из обратного отношения объекта к месту назначения. (См. Краткое объяснение @bshirley)

Например, если вы удаляете сотрудника, удалите его из отношений сотрудников своего отдела. Это имеет смысл только в том случае, если количество оставшихся сотрудников отдела больше требуемого минимального количества или если вы добавите новых сотрудников для отдела до следующей операции сохранения.

[ Вопрос: Если это последний сотрудник, отношения сотрудников отдела станут пустыми или пустыми?]
(Ответа на этот вопрос @TechZen: Отношение A to-many всегда возвращает заданный объект. Оно никогда не является ником. Если на другой стороне отношения нет объектов, набор пуст.)
Каскад Удалите объект в месте назначения.

Например, если вы удаляете сотрудника, удалите его отдел одновременно, даже если в отделе есть еще другие сотрудники.

( Предоставление обслуживания. Обычно это приводит к "цепочке делегирования по всей диаграмме объектов", как описано в его примере в @TechZen.)
Нет действий
Не делайте ничего для объекта в месте назначения.

Например, если вы удаляете сотрудника, оставьте его отдел таким, какой он есть, даже если он все еще считает, что он владеет этим сотрудником.

Смысл определения правил "Удалить правила для многих-ко-многим" можно сделать здесь.

Ответ 1

Это правила удаления для всех отношений (а не атрибуты). Они применимы для отношений в или ко многим.

Nullify - если вы удаляете сотрудника, обратная связь устанавливается равной нулю, если это было 1-к-1, то буквально, в этом случае сотрудники отдела сокращаются на один
Каскад - если вы удалите сотрудника, его отдел будет удален. Департамент будет следовать правилу удаления во всех его свойствах: 1) если правило удаления служащих было Cascade, все сотрудники были бы удалены этим действием; 2) если сотрудники удалили правило, было Nullify, все сотрудники были бы "застряли" без отдела

Ответ 2

Вы, кажется, предполагаете, что есть некоторые изменения в поведении правил удаления между "один-ко-многим" и "много-к-одному", но их нет. Все работает точно так же. Если вы думаете об этом, то это должно быть так, потому что "один ко многим" - это просто взаимные отношения много-к-одному.

Я думаю, что это идея взаимных отношений, которая вас трогает. Каждая сторона отношения определяется отдельно и имеет свое собственное правило удаления, которое может отличаться от правила удаления с другой стороны.

Возьмем, к примеру, стандартный стандартный отдел и сотрудника.

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 отношения to-many на стороне может блокировать удаление объектов с другой стороны.

Возьми отношения Департамента ↔ > Сотрудник. С точки зрения Департамента, объект Департамента должен иметь как минимум одного сотрудника. Если у него только один сотрудник, то этот сотрудник не может быть удален. Если сам объект Департамента удаляется, все его сотрудники также удаляются. С точки зрения работника каждый сотрудник должен иметь отдельный отдел. Любая попытка сохранить значение nil для значения объекта объекта сотрудника приведет к ошибке проверки. Однако, если объект employee удален, то ничего не происходит с объектом отдела вообще, за исключением того, что он теряет один из своих объектов-сотрудников. Однако, если объект employee является единственным объектом-сотрудником в этой связи, объект "Департамент" блокирует удаление.

Каскадное удаление, как следует из названия, может выставить цепочку делегирования по всей диаграмме объектов. Когда вы удаляете объект Department, он удаляет все связанные с ним объекты Employee, каждый из которых, в свою очередь, удаляет все объекты Project.

Но что, если у вас есть правило каскадного удаления, установленное с обеих сторон отношения "многие ко многим":

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

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

В этом случае удаление любого одного объекта в графе приведет к удалению всех других объектов, связанных либо с ключом. Удаление одного объекта Beta приведет к удалению всех его объектов Alpha, которые, в свою очередь, удалили бы все их бета-объекты, которые, в свою очередь, удалили бы все их объекты Alpha... и так далее, пока все связанные объекты не будут удалены.

Очевидно, что двухстороннее отношение к каскаду - это хороший способ стрелять в ногу.

В суммировании:

Отношения определяются по обе стороны отношений каждой сущностью независимо.
Удалить правила можно переопределить с помощью опции или mincounts.
Понимание поведения во время выполнения отношений требует объединения эффектов правил удаления, опциональности и mincounts.

Одна из причин создания редактора модели данных заключалась в том, чтобы наложить некоторую ограничительную логику на правила отношений, чтобы сохранить/предупредить кодировщиков от создания неожиданных и перекрестных целей.