Association Class Vs Associative Tables

[jeshaw2]

I've been told that describing a UML Association Class as being analogous to an Associative Table (in Relational theory) is imperfect if not incorrect.  If true, conceptually, how are they different?

[thomaskilian]

Hi Jim,
first: who told you that? Ask him for an explanation.

Second: The table is a projection of the associtation class. That means the class itself will use the table for its purpose. You must not use a table, but it is convenient - and it makes sense. So what the heck?

[Paolo F Cantoni]

Hi Jim,

I'm with Thomas on this...

[size=13]N-Ary Associations and Association Class[/size] lays out my main thoughts.

[size=13]Modeling Dependency Injection[/size] also has some relevant discussions, as does: [size=13]Lozenge (tm) & OCL[/size].

As Thomas points out, making such assertions without any provided justification - is your correspondent doing you an injustice!

Coming from a Data Management background, it has been obvious to me that (as again, Thomas says) the Table is the projection of the Class and while you don't need a table (Remember our slot injection example?) it "fits the bill" nicely.

In my view, the AssociationClass and the Association "Lozenge" are often misunderstood.

Paolo

[jeshaw2]

OK guys, I'll grant you all that you've said.  Most helpful for me in this context was:

That means the class itself will use the table for its purpose. You must not use a table, but it is convenient

I'm reading in the last sentence where it says "You must not use a table" as "You need not use a table".  Is that OK Tom?

The "erroneous" proposition at the start of this thread appeared in the writing of a UML ontologist somewhere, but it was over a year ago that I saw it and I'm not able to get back the the source.  Moving on however...

BTW:  Paolo, here is my suggested notation for for an n-Ary Association Class.

What do you think of this as a work-around to EA's unique interface?

I'm in the process of setting up my instructional web site for my Summer lectures.  Part of the course involves student developed web sites where they will publish their term papers.  I thought to provide an example term paper by writing a simple monograph on UML Classifiers.  The intent is to get a double whammy;  teach a bit of UML and demonstrate how to publish a document on a web site.

This topic has exploded into a very large document for I've discovered that almost all UML elements are, in fact, Classifiers.  Classifiers have attributes and operations and are Generalizable.  So now I have a lot of UML elements to analyze in terms of their being Generalizable.  The Class and Interface classifiers are well known and will be easy to write about.  But at the moment, I'm considering the Association Class.  I'm using the above diagram as a case study in this context.

At present I'm stroking my beard and thinking about:

• What are the semantic implications if the Record class were participating in an inheritance hierarchy?  and,
• What can we say about behaviors assigned to the Record class?  What might they do?

This is leading me away from a simple corollary between Association Class and Association Table.  Association Class may use the Association Table, but I don't think they are analogous in the same sense that the n-Ary diamond element represents an Associative Table with an nAry compound primary key.

I'm looking for some insight on this if you are interested in providing any.

Cheers!
Jim

[Paolo F Cantoni]

At present I'm stroking my beard and thinking about:

• What are the semantic implications if the Record class were participating in an inheritance hierarchy?  and,
• What can we say about behaviors assigned to the Record class?  What might they do?

This is leading me away from a simple corollary between Association Class and Association Table.  Association Class may use the Association Table, but I don't think they are analogous in the same sense that the n-Ary diamond element represents an Associative Table with an n-Ary compound primary key.

Jim,

I'll reply in short snippets as I'm fairly busy at the moment.

Firstly, an AssociationClass is a ordinary Class PLUS the (specifically unidirectional) attributes that correspond to the AssociationEnds for each end in the n-Ary Association.  From the n-Ary Association representation point of view, I would NOT expect any other Feature - behavioural or otherwise.  Thus if you remove these special attributes, you should be left with an ordinary Class (which may be empty).

If the n-Ary lozenge element represents an Associative Table with an n-Ary compound candidate key (note important change of language), and the AssociationClass is merely the alternate representation of the lozenge then the AssociationClass represents the Associative table.  Somewhere else I mention that the normal representation of the AssociationClass is a binary AssociationClass, but that's just illustrative.  The concept is more general.

As far as inheritance is concerned, there's no reason why the AssociationClass/Lozenge shouldn't be part of an inheritance hierarchy, you just have to be careful to distinguish the "ordinary" class inheritance from the AssociationEnd inheritance.

I realize this is a huge summary, but that's all I can spare for the present.  Let me know if you need more.

Paolo

[jeshaw2]

Oh Ratzenfratz!

I was hoping we could get more bang for the $ with the Association Class, but is seems it is not much more than a simple UML notational device for an Associative Table.

you just have to be careful to distinguish the "ordinary" class inheritance from the AssociationEnd inheritance.

When you have the time, you might expand just a bit on this statement.  But now, I'm not sure of the value generalization brings to this classifier.

Thanks
Jim

[thomaskilian]

OK guys, I'll grant you all that you've said.  Most helpful for me in this context was:
 I'm reading in the last sentence where it says "You must not use a table" as "You need not use a table".  Is that OK Tom?...

Absolutely. Sorry for using English so sloppy in that respect. In fact it's not my mother language...