Data modelling: removing primary key

[skiwi]

I added a primary key to a table that already had one primary key.

I then realised I didn't want to do that, and tried to remove it
(both by unselecting the PK check box, and by deleting the column).

In both cases I got the following error message.


Sorry this attribute is part of a foreigh key relationship.

The table had an association (connector) with another table, and EA has deduced the relationship.

Without deleting the connector how do I remove (this part of) the primary key.

I'm sure there is an easy answer, but it does not appear obvious.

Tia

[Paolo F Cantoni]

I added a primary key to a table that already had one primary key.
[size=18]...[/size]
The table had an association (connector) with another table, and EA has deduced the relationship.
[size=18]...[/size]

Just to be clear, this table is the foreign (parent) table in a foreign key constraint?

When you say EA has deduced the relationship are you saying you DIDN'T explicitly create the FK information, and so the connector doesn't have the «FK»  Stereotype?

In any event, I was ONLY able to reproduce your problem when the «FK» had been explicitly applied.  Up till that point, I could add/remove PK columns in the foreign table.

However, once you create the constraint,  EA (correctly) says you can't remove the additional column once the constraint is in place.

What EA incorrectly lets you do (or at least it let me do) is to allow you to add the PK column when the constraint had been applied - without asking if I wanted to cascade the change.  Consequently, I ended up (as I suspect you did) with an asymmetrical «FK» dialog - which by definition is inconsistent - since it's conceptually invalid.

To get around the problem you'll have to remove the «FK» constraint, but you don't have to delete the connector.  Just use the Foreign Keys... menu item to delete the constraint.  Remove your spurious column then recreate the constraint.

File an official bug report about EA allowing the addition of the column to the unique key of the foreign table (it doesn't have to be a PK!) while the FK Constraint was in place.

HTH,
Paolo

[Oliver F.]

Change the stereotype from "table" to something else.
This way the element changes dialogs and settings to becom a standard class in which you can either remove the faulty attribute or remove the sequence property from the former primary key.
Afterwards change the stereotype back to "table".

This should be doing the trick.

Oliver

[skiwi]

Thanks.
I'll try to create a test case to report.