[ZODB-Dev] Re: [Zope3-dev] PROPOSAL: ZODB Relationships

[Roché Compaan]

* Phillip J. Eby <pje at telecommunity.com> [2003-05-09 17:34]:
> At 11:28 AM 5/9/03 +0200, Roché Compaan wrote:
> >On Thu, 08 May 2003 19:58:22 -0400
> >"Phillip J. Eby" <pje at telecommunity.com> wrote:
> >>
> >> A final comment...  Once this takes directionality into consideration, 
> >you
> >> might consider calling it an 'Association' rather than a 
> >'Relationship', as
> >> it would then largely meet the MOF and UML semantics of an
> >> "Association".  That is, an association is a collection of directed links
> >> between objects.  It would then make sense to refer to refer to the
> >> 'RelationshipView' as an 'AssociationEnd'.
> >
> >We used the term Relationship because the proposal is based on the
> >entity-relationship model. I am not too familiar with MOF so maybe you
> >can explain how it will apply to the current proposal.
> 
> From the MOF 1.4 specification:
> 
> "Associations are the MOF Model’s primary construct for expressing the 
> relationships
> in a metamodel. At the M1 level, an M2 level MOF Association defines 
> relationships
> (links) between pairs of instances of Classes. Conceptually, these links do 
> not have
> object identity, and therefore cannot have Attributes or Operations."
> 
> If I understand the Relationship objects in your proposal, they correspond 
> to the M1 level definition of an Association in UML and the MOF.  That is, 
> they are a collection of links between objects.  An association provides 
> operations to create and destroy links.  (The M2 level isn't relevant to 
> this discussion, as the M2 level is the *specification* of the 
> relationship; if your proposal involved ways of specifying the multiplicity 
> of the ends, their aggregation kinds, what interface(s) objects on each end 
> had to implement, etc., then that would be on the M2 level.)
> 
> Anyway, it's a straightforward mapping from the formal semantics of a UML 
> association, to the relationships you defined, provided that the 
> relationships are directional.

This model seems like a perfect fit for what we want to achieve. I read
through the chapter on associations in the MOF specification but found
it quite terse and assumes some knowledge that I don't have. Can you
help me apply it to an example so that I can revise the current API.
I'll ramble some more to help me understand it.

If one takes the course teacher relationship from the API then I suppose
one would have an association instance with two association ends named
course and teacher. If we say that a course has only one teacher then
the association end named course will have a cardinality of one and
teacher will have a cardinality of many (I don't think the term
multiplicity will work here - it looks like it has fixed upper and lower
bounds. Or can you have a N multiplicity?)

What attribute on the association determines the direction?

> 
> 
> > Thanks for your
> >comments Phillip. I was hoping you say something because you must have
> >thought about this when designing PEAK.
> 
> I thought about it quite a lot, but I haven't implemented such "external" 
> relationship management because I have found that using Coad's "yellow role 
> object" patterns (sort of like persistent adapters) are a cleaner solution 
> for the actual use cases, at least for the kind of apps I work with.
> 
> But, if I were going to implement them, I'd say your proposal is in the 
> right direction.  I understand that making relationships symmetrical 
> certainly makes for easy lookups: just insert a pair for each direction, 
> then do a one-way lookup.  Whereas directionality requires that you supply 
> a parameter for the direction, and then either store the direction or use a 
> forward map and a backward map.  OTOH, storing the forward and backward 
> maps takes little more space than storing a map with both forward and 
> backward entries.
> 

So instead of storing both entries in course_teachers we store an entry
in course_to_teacher and an entry in teacher_to_course?

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za