2.6.2 Designing relationships

Please note: this project is inactive since early 2006

2.6.2 Designing relationships

A relationship and its inverse relationship (when defined) define an association. If a relationship has no inverse, the corresponding association is said to be uni-directional, otherwise it is bi-directional. Associations can be of the three kinds, with the following constraints:

One-to-many

this is the most common case. To define a one-to-many relationship between the entities Writer and Book, like this:

   +--------+           +--------+
   | Writer |           | Book   |
   +--------+           +--------+
   | .....  |           | .....  |
   | toBooks|<-------->>|toAuthor|
   +--------+           +--------+

(extracted from the full model defined at section 2.1.1) you need to perform the following steps:

Both entities should (already) have a primary key defined, e.g. id (see 2.6.1). The id will use the python type int and the SQL type INTEGER.
Define a foreign key in Book, i.e. an attribute, say FK_Writer_id, which is not a class property and is mapped to the python type 'int' and the SQL type INTEGER as well.
Define a relationship toBooks in Writer, joining the primary key id to the destination entity Book 's foreign key FK_Writer_id, with a multiplicity's upper bound , say, *.
Define a relationship toAuthor in Book, joining the foreign key FK_Writer_id to the Writer 's primary key Writer.id, with a multiplicity's upper bound equal to 1.

One-to-one

One-to-one relationships should be modeled as one-to-many relationships, to which you add custom validation logic to enforce that the toMany relationship does not have more than one object in relation (in the future we will support one-to-one relationship, by supporting propagation of primary keys)

Many-to-many

While automatic handling of many-to-many relationships is not supported yet, many-to-many relationships can be modeled and used with minimal efforts. Please refer to the dedicated section 2.6.3, below.

You may want to specify an other inverse relationship than the one calculated by the framework. (Note that when working with the ZModelizationTool, it shows you the inverse relationship it finds for a given relationship when in the Entity's global view. If the inverse relationship is not found or is wrong, first check that the relationships are correctly defined.)

The way an inverse relationship is calculated is simple: the framework looks at the destination entity and searches for a relationship whose joins have source and destination attributes corresponding one-to-one to the destination and source attributes in the original relationship's joins. And if this is not clear, look at the example above (step-by-step procedure to build a one-to-many association): toBooks is the inverse relationship for toAuthor and conversely, as expected.

If, however, the framework is not able to find the correct inverse relationship, you can force it to use you own point of view; for a complete description of how this can be done, refer to CustomObject.inverseForRelationshipKey() documentation string.

Comments are welcome: Sebastien Bigaret / Modeling Home Page
Hosted by: