Would a composite unique constraint also fulfill a need of a non-unique index created on the primary field?

Current Setup:

Suppose if I have a table called [Table1] with the following fields in it (only relevant fields are shown)

[RowId] int non null identity (1, 1) primary key

[OwnerId] int non null has unique constraint (uq_table1_owner), and foreign key to [OwnerTable]

New Requirement:

Now I want to alter [Table1] and add an optional foreign key to [Table2] called [Table2RowId], which could be null. Further I want to set [OwnerId] + [Table2RowId] unique constraint on [Table2] (uq_table1_ower_table2).

Challenge:

With this new requirement in place, I have to remove the existing unique constraint set on [OwnerId] so that there could [Table1] can have rows like these:

[OwnerId]           [Table2RowId]

1                             1

1                             2

2                             1

Question

To keep performance of the existing code unaffected should I replace existing uq_table1_owner with non-unique index ix_table1_owner?

OR

Would uq_table1_ower_table2 automatically do ix_table1_owner’s job? And just delete uq_table1_owner and do not create ix_table1_owner.