Generalization links on tables and DDL

[CJ]

G'day,

EA (I'm using v4 build 722) allows creating a generalization link between two db tables (classes stereotyped as table).

While diagrams show inherited attributes for some table (say table2) that has a parent table (say table1), inherited attributes don't get included in the DDL for table2.

Please add the following capability: when generating DDL for a table, include in the DDL any attributes and operations that are inherited from a parent table.

This would provide awesome flexibility when data modeling.

[sargasso]

This is a fascinating idea.

I am not a real fan of UML data modelling - why they had to do something "different" from IE crowsfeet is beyond me.

However the idea of inheriting attributes/keys has got me rethinking the value.

Jason,

Have you got some information you can share on how you are using this in practice?  I can see its use as "template tables" or "data patterns" (for example "Car" is a specialization of the "Vehicle" table type), but are there other uses?  BTW, if this is the only use could you achive the same result by creating your own patterns?

tia
Bruce

[thomaskilian]

The funny thing is that inherited operations are shown (e.g. for primary keys) but the DDL does not show them. I guess this is simply an implementation error of EA.

Thomas

[CJ]

G'day Bruce and all,

(Wouldn't it be great if all of the advantages of object-orientation in classes were available to tables???)

My practical needs for this are more geared towards "traceability" for "requirement" and "change" items, the breakdown of the tasks related to a "requirement" or "change" item, and the use of the relationship matrix.

- Link "change" and "requirement" objects to a group of table columns that I want to drop or add.

Putting the columns into a parent table would allow me to highlight them, and to link the group of them (i.e. link the parent table) to a "change" (or "requirement") ... currently, I can only link my "change" to notes, linked to the columns in the original table.

- Sharing column definitions amongst any number of tables.

I've got one table that many others have foreign key constraints on.  If all of these tables had as a parent a table with that foreign key column, then I would only ever need to change that column definition once, and all child tables would inherit the change.

- Externalizing table columns for any other reason.

Since EA already handles inheritance of attributes (including displaying them and generating them in code), it would probably (guess ) be easy to set up the same for tables - displaying them and generating DDL.