 |
Now that CaseTalk warns the user it cannot determine to which way a binary fact type (with two seperate uc's) should be grouped, and therefor leaves it as is, a problem arises. Since tables require a primary key on either one, one of the UC's will be dominant and become primary key. In addition: When both roles contain a Totality Constraint, a series of subsets will be generated. Some of these subsets will define regular foreign keys, and some will generate regular subsets to reflect the transformed TC. Now when generating a script which actually supports subtype relationships (such as CDM in PowerDesigner), the script is generated faulty, since we can no longer determine what the generated SC's should represent. Which is the foreign key, which is the subtype/supertype, and which is a regular subset constraint? Some indication should be stored with the SC to indicate the function it replaces during GLR. |
|
|
The conceptual starting point. Where all roles are specified as "do not group" to force the error to appear. ig.png (21,724 bytes) |
|
|
After GLR, the diagram will show as this. The SC's themselves are not clearly defined. Therefor a well defined scripts cannot be generated for PowerDesigner. igg.png (12,258 bytes) |
|
|
The SQL92 script shows an error too:
...
-- subtype relationship
ALTER TABLE "MICRO_TOPO_LINEAIR_OBJECT"
ADD FOREIGN KEY ("LINEAIR_OBJECT_FUNCTIONEEL_OBJECT")
REFERENCES "LINEAIR_OBJECT" ("INFRA_OBJECT_FUNCTIONEEL_OBJECT");
-- foreign key
ALTER TABLE "MICRO_LINK_VERVULLER"
ADD FOREIGN KEY ("MICRO_LINK")
REFERENCES "MICRO_LINK" ("LINK");
-- subset constraint
ALTER TABLE "MICRO_LINK"
ADD CHECK ("LINK"
IN (SELECT "MICRO_LINK" FROM "MICRO_LINK_VERVULLER"));
-- foreign key
ALTER TABLE "MICRO_LINK_VERVULLER"
ADD FOREIGN KEY ("MICRO_TOPO_LINEAIR_OBJECT_FUNCTIONEEL_OBJECT")
REFERENCES "MICRO_TOPO_LINEAIR_OBJECT" ("LINEAIR_OBJECT_FUNCTIONEEL_OBJECT");
-- This should be a subset and not a regular foreign key
ALTER TABLE "MICRO_TOPO_LINEAIR_OBJECT"
ADD FOREIGN KEY ("LINEAIR_OBJECT_FUNCTIONEEL_OBJECT")
REFERENCES "MICRO_LINK_VERVULLER" ("MICRO_TOPO_LINEAIR_OBJECT_FUNCTIONEEL_OBJECT");
...
CaseTalk cannot distinguish subset constraints from regular foreign keys. It tries to determine that from the structures. If a subset refers to a uc which is also marked to be primary key, it assumes it is a regular foreign key, instead of a subset constraint. However since tables require a primary key, some uc's are promoted to become one. And in these cases the formerly known subset gets determined to become a foreign key. Therefor the SC needs an extension to mark the SC to be a FK or a regular SC. |
|
|
An internal hack created a fix by using the SC comments internally. A future release will contain a more structured storage for this, extending SC with an additional column specifying wether it originated from a transformed TC or from a grouped Role. |
|
|
Closing automatically, stayed too long in resolved state. Feel free to re-open with additional information if you think the issue is not resolved. |
- Anonymous
