Primary Key Migration - Hierarchical Structures

Question

Hi,
I'm involved in looking at a migration of a hierarchical database to ORACLE. For some table types the primary keys at the top of the hierarchy are compound ones and these need to be migrated to the next level of hierarchy. At the
next level of hierarchy there are further columns that need to become part of the primary key at that level.
Where the hierarchies get deep I'm looking at a pretty large primary key if this method is used.
Table A
Columns A1,A2
Primary Key A1,A2
Table B
Columns A1,A2,B1,B2
Primary Key A1,A2,B1,B2
Foreign Key referencing table A columns A1,A2
Table C
Columns A1,A2,B1,B2,C1,C2
Primary Key A1,A2,B1,B2,C1,C2
Foreign Key referencing table B columns A1,A2,B1,B2
To me this looks quite unwieldy so I was strongly considering giving tables A,B an C a new primary key 'ID'
column generated from a sequence and using that to maintain the relationships thus:
Table A
Columns ID,A1,A2
Primary Key ID
Unique Constraint A1,A2
Table B
Columns ID,A_ID,B1,B2
Primary Key ID
Unique Constraint A_ID,B1,B2
Foreign Key A references A column ID
Table C
Columns ID,B_ID,C1,C2
Primary Key ID
Unique Constraint B_ID,C1,C2
Foreign Key B_ID references B column ID
This involves another index for the ID column on each table I know, but it stops replication of data and would enable changes to the key values without losing the entire hierarchical relationship.
Does anyone have any experience with either of these two approaches who could shed some light on the pitfalls of each approach?
Thanks in advance
Mike

Answer 1

This seems to affect migrations from MS Access as well, so I guess it applies to all source db types. If it helps, PK's are created with SD 1.2.0 / 28.54, but not with 1.2.0 / 29.98.
As a related point it would be useful to show the constraint metadata in the captured and converted model info, rather than only see it as part of the gen script ?
Cheers
Jules