Hi.
Here's a copy of a question I posted to "datamodel Message Board" at unfortunately, there were no responses. For me, it's a real "show-stopper"; really don't know, how we can use PowerDesigner 9 in an effective way unless this problem is solved or worked around. Someone MUST have run into the same problem, or am I the only one to define more than one N:1 relationship from one entity to another and inherit from the first one
With PD6, this worked fine, with PD9, I'm in a most serious trouble with this scenario. Here it goes:
Hi again.
Here's another scenario to clarify my problems with PD9:
Create 2 entities named Entity_1 and Entity_2, each with one attribute, which is also the primary identifier.
These are Attribute_1 and Attribute_2. Now build THREE relationships from E1 to E2, which are named Relationship_1 to _3.
Now create a 3rd entity Entity_3 with an Attribute Attribute_3. Create NO primary id for this, rather let Entity_3 INHERIT
from Entity_1 (and inherit the primary id from there). Then uncheck the "Generate" checkbox for Entity_1.
Then generate the default PDM. As expected, 2 tables are created, ENTITY_2 and ENTITY_3. The first problem arising is a small one:
within ENTITY_3, three foreign key columns were generated and named: ATTRIBUTE_2 (migrated from Entity_2's primary id),
ENT_ATTRIBUTE_2 and ENT_ATTRIBUTE_3. The order in which the relations are processed determines the naming of the column, ok,
but shouldn't it have been ENT_ATTRIBUTE_22 instead of ENT_ATTRIBUTE_3? As said above, the first one is migrated; the 2nd one
gets the three-letter-prefix from the referenced table ("ENT"ity_2), and the third one gets a number appended, starting with 2.
With PD6, this number was appended to the three-letter-prefix (much better).
Here's the scheme again: PK, XXX_PK, XXX_PK2, XXX_PK3 (old (and better) scheme was PK, XXX_PK, XXX2_PK, XXX3_PK).
Since the primary key column in our example occasionally ends in a number, PD9 seems to get
confused and mixes up the "2" at the end of "ATTRIBUTE_2" with it's own "numeric tails".
But that's only a hint to the coming problems; the model I have to maintain has thousands of columns created with the
old naming scheme (PK, XXX_PK, XXX2_PK, XXX3_PK, ...). When migrating this model, I have to rely on PD9 keeping all
the "old" column names in sync with the new convention. If sync is lost, everything goes down the drain...
But back to our small model; at some point (don't know exactly when) things begin to go wrong:
though I made only a minor change to the CDM and the PDM, PDM generation (with "Preserve Modifications" on)
shows a merge window with lots of
actions, which all are about swapping the names of the foreign key columns created from Relationship_1 to Relationship_3.
PD9 now seems to process the Relationships in another order: Relationship_2 is processed first, so it's migrated to
a column named ATTRIBUTE_2, while Relationship_2 createw ENT_ATTRIBUTE_2 and finally Relationship_1 creates
ENT_ATTRIBUTE_3. This order seems to be non-deterministic! You need only two relationships between two entities, and after some
time this phenomenon occurs, at last with all models I created after this scheme. Some generations run fine, while the
next time, PD9 begins to "swap" foreign key column names.
This sure is hell! Hope I could clarify my problem. Up to now, it's kind of a show-stopper and makes PD9 unusable with models where multiple relations between the same entities occur, that is, nearly always...
Has anyone else met these problem, and how did you handle it? Does anyone know a solution?
TIA.
Here's a copy of a question I posted to "datamodel Message Board" at unfortunately, there were no responses. For me, it's a real "show-stopper"; really don't know, how we can use PowerDesigner 9 in an effective way unless this problem is solved or worked around. Someone MUST have run into the same problem, or am I the only one to define more than one N:1 relationship from one entity to another and inherit from the first one
With PD6, this worked fine, with PD9, I'm in a most serious trouble with this scenario. Here it goes:Hi again.
Here's another scenario to clarify my problems with PD9:
Create 2 entities named Entity_1 and Entity_2, each with one attribute, which is also the primary identifier.
These are Attribute_1 and Attribute_2. Now build THREE relationships from E1 to E2, which are named Relationship_1 to _3.
Now create a 3rd entity Entity_3 with an Attribute Attribute_3. Create NO primary id for this, rather let Entity_3 INHERIT
from Entity_1 (and inherit the primary id from there). Then uncheck the "Generate" checkbox for Entity_1.
Then generate the default PDM. As expected, 2 tables are created, ENTITY_2 and ENTITY_3. The first problem arising is a small one:
within ENTITY_3, three foreign key columns were generated and named: ATTRIBUTE_2 (migrated from Entity_2's primary id),
ENT_ATTRIBUTE_2 and ENT_ATTRIBUTE_3. The order in which the relations are processed determines the naming of the column, ok,
but shouldn't it have been ENT_ATTRIBUTE_22 instead of ENT_ATTRIBUTE_3? As said above, the first one is migrated; the 2nd one
gets the three-letter-prefix from the referenced table ("ENT"ity_2), and the third one gets a number appended, starting with 2.
With PD6, this number was appended to the three-letter-prefix (much better).
Here's the scheme again: PK, XXX_PK, XXX_PK2, XXX_PK3 (old (and better) scheme was PK, XXX_PK, XXX2_PK, XXX3_PK).
Since the primary key column in our example occasionally ends in a number, PD9 seems to get
confused and mixes up the "2" at the end of "ATTRIBUTE_2" with it's own "numeric tails".
But that's only a hint to the coming problems; the model I have to maintain has thousands of columns created with the
old naming scheme (PK, XXX_PK, XXX2_PK, XXX3_PK, ...). When migrating this model, I have to rely on PD9 keeping all
the "old" column names in sync with the new convention. If sync is lost, everything goes down the drain...
But back to our small model; at some point (don't know exactly when) things begin to go wrong:
though I made only a minor change to the CDM and the PDM, PDM generation (with "Preserve Modifications" on)
shows a merge window with lots of
actions, which all are about swapping the names of the foreign key columns created from Relationship_1 to Relationship_3.
PD9 now seems to process the Relationships in another order: Relationship_2 is processed first, so it's migrated to
a column named ATTRIBUTE_2, while Relationship_2 createw ENT_ATTRIBUTE_2 and finally Relationship_1 creates
ENT_ATTRIBUTE_3. This order seems to be non-deterministic! You need only two relationships between two entities, and after some
time this phenomenon occurs, at last with all models I created after this scheme. Some generations run fine, while the
next time, PD9 begins to "swap" foreign key column names.
This sure is hell! Hope I could clarify my problem. Up to now, it's kind of a show-stopper and makes PD9 unusable with models where multiple relations between the same entities occur, that is, nearly always...
Has anyone else met these problem, and how did you handle it? Does anyone know a solution?
TIA.
