Attribute type identified by name, not EAID?

[dr_shorthair]

We are using EA's DDL transform to generate table schemas from a class model. In the model we use a mixture of class attributes and associations. Some attributes have complex types corresponding to other classes in the model. When the table schema is generated, these appear as table columns, where we expected to see links.

Inspection of the XMI representation of the model shows that an attribute type is given by its name, with no EAID link to the class. This is surprising. Are class attributes really not meant to link to the class definition of their type?

(We had also come across these previously in XMI processing.)

[peter.zrnko]

If you set an attribute type using "..." button or combo box and not just typing the name and export the parent package with option "Fulll EA RoundTrip" selected, you can see in the XMI something like this:

Code: [Select]

<UML:Class name="Class1" ...>
        ...
        <UML:Classifier.feature>
          <UML:Attribute name="attr1" ...>
              ...
              <UML:StructuralFeature.type>
                 <UML:Classifier xmi.idref="EAID_463C5EBE_E065_44aa_BA91_BF9417ACD0BE"/>
              </UML:StructuralFeature.type>
              ...I think this the EAID you are looking for.

to the DDL trnasform:
You want to see links. In the table schema do you mean foreign keys? Even the FK has to have a table column which is then used in the FK definition.

[Peter Warren]

thats correct Peter.  When we do the transform on a class that contains other classes as attributes we expected 1 table for each class with FKs joining them.  However, what we get is 1 table with columns of user defined types with the same name as our classes.

Is there a way to tell the transform that we want to map attributes that are know to be defined classes to individual tables with FK joins?

Thanks

[Eve]

I've just had a little play with the transformation.

You should get something like what you want by changing the Attribute template to the following.

Code: [Select]

%if attClassifierGUID != ""%
ForeignKey
{
  %TRANSFORM_REFERENCE("General",attGUID)%
  Source
  {
    %TRANSFORM_REFERENCE("Table",classGUID)%
    name=%qt%%CONVERT_NAME(attName, "Camel Case","Pascal Case")%%qt%
    Column
    {
      name=%qt%%attName%ID%qt%
      type=%qt%%CONVERT_TYPE(genOptDefaultDatabase,"Integer")%%qt%
    }
  }
  Target
  {
    %TRANSFORM_REFERENCE("Table",attClassifierGUID)%
    Column
    {
      name=%qt%%CONVERT_NAME(attType, "Pascal Case","Camel Case")%ID%qt%
      type=%qt%%CONVERT_TYPE(genOptDefaultDatabase,"Integer")%%qt%
    }
  }
}
%else%
Column
{
  %TRANSFORM_CURRENT("type", "stereotype", "collection", "constant", "containment", "ordered", "static", "volatile")%
  type=%qt%%CONVERT_TYPE(genOptDefaultDatabase,attType)%%qt%
}
%endIf%Feel free to modify it from there.

[Peter Warren]

that worked perfectly.

 Thank you Simon

[Eve]

Good to hear it worked.

I'll see about getting that included in the standard transformation, but bear in mind that you'll probably end up with duplicate connections if you also have that attribute represented as an association.

[Peter Warren]

Thanks again Simon,

Our class models are designed with both associations and attributes used to represent this kind of relationship.  However, I don't think both would exist in the same place.

Pete