Refer the following chart to understand the actions Database Design Studio takes and the user options available to configure foreign key referential constraints.
The Key Condition determines the nullability of the foreign column, while the Foreign Key Rules determine the action to be taken upon the rows in the foreign table when the referenced table is modified.
The Connectivity governs the Foreign Key Location and the Participation governs the Key Condition and the Foreign Key Rules. Where there is more than one option for a Foreign Key Rule, the application selects the first and makes the others optional.
Warning: Some may question why there is no Cascade rule shown as available for 1:M NA constraints. We do not recommend that you use a cascading delete because of unpredictable side effects with foreign keys that are not part of the primary key. (Refer to the participation section for an example that could have terrible side effects if implemented as a cascading delete.) However, DDS does support cascading deletes but advises that the end user use their discretion in doing so.
See also: Many to Many, One to Many, One to One, Weak, Specialization and Referential Constraints