[fdo-users] Question on associations between classes

[Maksim Sestic]

I was thinking of using following FDO approach, please correct me if I'm
wrong at some point:

1) Annotations
1.1) Create Annotation Class (not FeatureClass) since Classes are globally
accessible throughout DataStore.
1.2) Annotation class, among other properties, posesses one geometric
property (it's insertion point). It does not posses identity property since
it's always used as a child of a FeatureClass.
1.3) Create FeatureClass named "Parcel". It posesses identity, data and
geometric properties. As an extra, it also posseses an Object property - a
collection of Annotation objects - meaning that one Parcel may posses zero
or more Annotations.

2) Projects
2.1) Create globally accessible Project Class (not FeatureClass).
2.2) Project class posesses identity and data properties.
2.3) Create FeatureClass named "Parcel". It posesses identity, data and
geometric properties. As an extra, it also posesses an Association property.
2.4) An instantiated Project object gets associated to Parcel feature class
in the following manner:
2.4.1) FdoAssociationPropertyDefinition::SetAssociatedClass refers to
existing Project class instance.
2.4.2) FdoAssociationPropertyDefinition::SetMultiplicity is set to "1"
(given Project instance may hold only one Parcel instance).
2.4.3) FdoAssociationPropertyDefinition::SetReverseMultiplicity to "0" (a
Project may or may not have Parcels when instantiated).
2.4.4) SetReverseName to "Parcel"
2.4.5) Set Delete rule to Break (I don't want to have my Parcel deleted if
someone deletes Project containing it, since some other Project might also
refer to the same Parcel. I also don't want my Project instance affected if
someone deletes this particular Parcel either).
2.4.6) Rinse and repeat 2.4.1) to 2.4.5) for each Project this Parcel
belongs to.

Now, for the tricky part - one Parcel may get associated to more than one
Project. Is it possible to add more than one
FdoAssociationPropertyDefinition to a FeatureClass?

Someone might ask why don't I associate features to the projects (other way
round), meaning that Project class has association property associating zero
or more feature classes. The answer is simple - anytime schema changes and
new feature class gets added to it - I would have to change Project's
associtaion definition to include newly added feature class. Or am I wrong?
:-)

Regards,
Maksim Sestic



Maksim Sestic wrote:
> 
> Dear all,
> 
> I need to decide on what approach to take regarding logically associated
> classes described by schema:
> 
> 1) My features have annotations
> Each instance of my FeatureClass may have 0..n annotations. Describing
> them is a lesser problem, the general question is - how do I store
> annotations and how do I relate physical class to them? I was thinking to
> resort to standard RDBMS approach - creating Annotations feature class
> (table) with rows (annotation instances) pointing to it's owner (physical
> class). Maybe there's more "proper" approach, as shortly described in FDO
> DevGuide, using other types of Classes than the FeatureClass?
> 
> 2) My features belong to projects
> Each instance of my FeatureClass may belong to 0...n projects. Meaning -
> one feature may belong to two (or more) different projects at the same
> time. Naturally, there's only one instance of a feature class in a
> datastore. Using classical RDBMS approach, I would create Projects table
> with records describing actual projects, accompanied by related table to
> keep pointers on features belonging to that project. What FDO has to say
> about this type of association?
> 
> With kindest regards,
> Maksim Sestic
> 

-- 
View this message in context: http://www.nabble.com/Question-on-associations-between-classes-tf4073626s18162.html#a11592628
Sent from the fdo-users mailing list archive at Nabble.com.