Salve,
il problema e' complesso... vedi benissimo che il vincolo ha path multipli e proprio per questo motivo il database engine ti indica che "normalmente" non e' buona prassi agire in questo senso, e suggerisce appunto il workaround di impostare l'azione del CASCADE a NO ACTION, permettendo quindi la "sola definzione del vincolo" (prassi comunque corretta in modo da autodocumentare la relazione tra le entita',
lasciando il vincolo "disabilitato"') e suggerendo altresi l'uso di altri modi di gestire la referential integrity dichiarativa, cosa che in questi casi avviene solitamente attraverso triggers,
https://support.microsoft.com/en-us/help/321843/error-message-1785-occurs-when-you-create-a-foreign-key-constraint-tha
il trigger consente infatti la completa autonomia in quanto conterra' (a tua cura) la logica completa del "path" che intendi seguire, quindi la logica la devi implementare direttamente, magari anche in "azioni sequenziali" dove l'ordine di esecuzione e' fondamentale, mentre il constraint lascia "nel dubbio" il motore relazionale, e non avendo altra logica implementata, non e' in grado di scegliere il path da seguire.
l'uso di trigger ti consente la piu' completa liberta' e mantiene direttamente legato alla definizione DDL la soluzione del problema, ma anche l'uso di una stored procedure ovviamente fa al caso, tanto piu' che (ovviamente :D), dal punto di vista del dba, non sarebbe "buona cosa" dare accesso diretto agli sviluppatori alle base tables, preferendo quindi per l'accesso ai dati al solo utilizzo di stored procedures... sicuramente qui do adito all'apertura di un flame ed alla riapertura della relativa guerra di religione in corso tra dev e sys, ma tant'e' :D
salutoni romagnoli
--
Andrea