If you look at MSSQL (which is our DB) you can mark several columns as primary key then making the combination actually PK
OK, Martin, at this point you have actually marked a set of columns are columns
in a primary key. You are therefore describing a concatenated primary key.
and if you import is from DB to EA they all appear as PK non-unique and a function is created which combined them all as PKs.
No... The EA function defines the primary as a set of columns. The PK marker against the column, ONLY categorizes it as a column IN a primary key. I, too, was initially confused by this. It's important that we (and Sparx) recognize this distinction.
The same way if you create a table and mark several columns as PKs you'll see EA indeed creates this function.
In my opinion it is the correct behavior, but even if it isn't and the current behavior is then it is not consistent, so it a bug.
I opened a bug any way.
As far as I can tell, the previous EA behaviour (as I last checked it - not recently) was correct. The behaviour should be consistent both defining the key directly or reverse engineering.
As you remark, the current v7.0 behaviour is WRONG!(FWIW, I suspect the bug occurs because if there is only one column in the primary key, the column
should be marked as unique. However as soon as there is more than one, the unique bit
must be reset for all the columns - I suspect the code doesn't check this latter case)
By the way, Sparxians, from a theoretical perspective, the columns of a concatenated primary key should be non-unique and ONLY the combination of columns provide a unique "identity". If any of the columns of the concatenated key is, itself, unique then you are violating one of the rules of relational design: "The key, the whole key and nothing but the key"
HTH,
Paolo
