This is actually an abstraction model issue. The relational model is having a problem with garbage input data.
To workaround the problem, select the 'Service Level Agreement' objectification and either make the other uniqueness constraint preferred, or introduce a refmode on the objectified entity type (select the name, use the RefMode property).
There are several contributing factors here that combined to create the problem:
The 'IT Unit' entity type plays no functional roles except for the relationship with 'Service Level Agreement'
The objectification of the 1-1 means that an attempt is made to absorb all of the objectified fields into the identifying role (Business Unit)
IT Unit is a subtype of Business Unit
The double mandatory constraints on the 1-1
The end result is that the absorbption attempts to make Business Unit a part of IT Unit because of the identification choice (the identified table absorbs its identifier), and IT Unit is a part of Business Unit because of the subtype. The absorption algorithm needs to catch this cycle and relax one of the 'part of' relationships to a 'reference' relationship. Essentially, you have a cyclic structure with 1-1 relationships between Business Unit, IT Unit, and Service Level Agreement. Cyclic 1-1s are nasty.
We had some work on cycle checking done during a student project well over a year ago, but it was unfortunately never integrated into the system. I doubt there is an easy fix for this that covers the full cyclic scenario, but there might be an easier fix to catch the basic cycle where 'a is part of b'/'b is part of a'.